KunlunBase FAQ

1、KunlunBase 是否是默认开启分布式事务？是否有开关可以关闭？例如有的分布式数据库支持开关，可根据业务需求进行配置？

KunlunBase的分布式事务处理是自动运行的，没有开关切换。只有当一个事务确实写入了多个shard之后，才会做两阶段提交，否则就是一阶段提交，也就是说无需手动开关。

2、针对常规的统计信息，如TPS(含回滚率等)、QPS、RT等指标，在KunlunBase中如何查看？可以在系统视图中，还是在XPanel可查？

• 1.3 版本中可以在XPanel中查看。

3、KunlunBase 中锁的机制如何？文档中只看到 MySQL 中锁的处理机制。同理，死锁检测机制如何，相关参数有哪些？

• 计算节点中对表上锁，如果是DML语句，则获取行级意向锁；如果是DDL语句，则排他表级锁。存储节点中，与MySQL完全相同：DML语句的INSERT/DELETE/UPDATE语句在server层获取表级意向写锁，在innodb中则获取行锁；对于SELECT则获取全局和本地快照，不获取事务锁。DDL在server层和引擎层都获取表级排他锁。
• KunlunBase全局死锁检测技术 | Klustron

4、KunlunBase 常规的隔离级 RR、RC 都支持？

• 支持多种事务隔离级别：读已提交，可重复读，串行化。

5、关于序列问题，我看在是在元数据库中记录在一个表中。这里是否会存在性能瓶颈？此外，如果创建时指定Cache选型，在不同计算节点使用时，是Cache到本地，因此会存在跳号等问题吧

• 创建序列时可以指定cache多个值，以避免性能瓶颈。假如cache设置为1，则获取每一个值都需要修改元数据shard中的序列记录，那么性能就会损耗较大。
• 如果多个计算节点CN1，CN2同时在使用同一个序列，每个序列cache 20值，那么CN1使用的序列值100-119时，CN2在使用的序列值是120-139。

6、针对table group，我理解是人为设定表的存储位置；这与常规分布式数据库的ER表还有所不同。KunlunBase是否支持ER表？

• Table group用于确保多个表始终在同一个shard上面，仿佛是一个框子把这些表绑在一起。ER表确实可以被分组为同一个table group中，这样就可以确保这些表在同一个shard，即使扩容也会同时把一个table group中全部的表扩容到另一个shard。

7、PG支持的多种索引（如非BTree索引），是否在KunlunBase中可创建？

• 不可以。KunlunBase存储节点kunlun-storage基于MySQL开发，以避免PostgreSQL 存储引擎的性能问题，同时也就不再使用PostgreSQL的索引。不过，MySQL不仅支持b+tree索引，也支持空间索引，全文索引，因此并不存在无法索引的数据类型。

8、全局二级索引，是否有计划未来支持？

• 全局二级索引会严重降低数据增删改的性能，如果仅用于查询则很鸡肋。KunlunBase的计算节点知道每个表的分片所在的shard，因此即使查询条件没有指定shard key，也只需要到存储着这个表的分片的那几个shard去读写数据，并不会读写全部shard。

尽管如此，未来我们会根据用户需求来决定何时实现该功能。

9、视图是否支持跨分片的语句？如果支持，查询视图时会拆解视图后下推吗？

• 视图支持跨分片语句。在查询处理的转换阶段，各级视图的查询语句会合并到使用视图的顶层查询语句的语法树中，统一执行。因此在查询执行层面，并不知道那个查询语句是否使用了视图，因此也就不存在‘下推视图’这样的动作。

10、之前谈到的复合分片（分片+分片），分片分区方式是否支持？

• KunlunBase支持多级分区，每一级分区的方式和参数彼此独立没有影响。唯一一个要求是，每一级分区的shard key 列集合一定包含上面各级分区的shard key列集合。详见此文

11、游标是否支持？自定义函数是否支持？

• KunlunBase支持游标和自定义函数。不仅支持用PL/SQL定义存储过程，还可以用c/python,java,javascript, lua等多种编程语言定义存储过程。

12、字符集方面，MySQL 常见的UTF8MB4、GB18030 是否支持？

• 支持客户端使用GBK/GB18030/GB2312。
• KunlunBase 内部支持的字符集包括UTF8在内的unicode各种编码存储数据，但是不包括GBK/GB18030等，不过KunlunBase支持把客户端以中文GB系列编码输入的文本自动转换为内部支持的字符编码。

13、如果源库与目标库的字符集不同，但兼容情况下，通过KunlunBase提供的工具是否可实现迁移和同步能力？

• KunlunBase支持客户端使用常见字符集。只要源库字符编码是KunlunBase支持的客户端字符集（就是PostgreSQL支持的客户端字符集），那么数据以SQL语句送入KunlunBase后就被自动转换为KunlunBase内部字符集(UTF8等，CREATE DATABASE时可以指定）。
• 数据迁移工具cdc从mysql实例的binlog导入数据到KunlunBase时，只要这个字符编码是KunlunBase客户端支持的编码，那么就可以导入成功。

14、备份方面，我看目前支持物理备份到HDFS，是否支持备份到本地（或NFS上）？是否支持时点还原？是否支持对象闪回？

• 支持恢复到任意时间点。用户可以通过恢复到指定时间点来找回各种数据库对象。

15、常规的 MySQL 和 PG 的导入导出命令是否支持？是否可实现不通过计算节点，针对数据节点的快速导入？

• KunlunBase支持数据 支持PostgreSQL的数据导入命令，不支持MySQL的LOAD DATA导入命令。必须经过计算节点才能导入数据。

16、当前是否支持版本升级？滚动升级？降级？

• 正在做不停服的热升级即滚动升级，1.3版本中发布。升级和降级是一样的，都支持。

17、在扩展方面，针对计算节点的扩容是可以在线进行？是否有对应的LB方案提供？存储节点扩容方面，数据需手工做重分布？

• 可以在集群运行期间通过XPanel GUI界面或者调用cluster-mgr API随时增加计算节点，不影响已有连接中任何业务。计算节点加入集群完成初始化之后就可以对外提供服务。
• LB方案需要用户自己配置，在计算节点完成初始化之后，把它加入到LB的候选节点集合中即可。

18、读写分离方面，是否支持延迟感知（即将延迟大的从库剥离出来，不承担读）？针对跨片情况，是否支持读的一致性？

• 计算节点自动选择延时最小的备机来读取；如果从备机读取数据，则全局MVCC机制由于主备延迟不可预测因此无法正常工作。全局MVCC只能处理主节点读取数据的情况。

19、cluster_mgr、node_mgr，应支持高可用？如node_mgr异常，如何恢复？

• Cluster_mgr支持高可用，可以在clustermgr集群主节点退出后自动选出新主；nodemgr运行在每个server 中，由crontable或者linux system服务自动拉起。Cluster_mgr和nodemgr没有本地持久状态，所以无需数据恢复。

20、当出现脑裂时，cluster_mgr与计算和存储节点脑裂等，行为如何？是否做过混沌测试？

• Cluster_mgr和存储集群高可用机制确保了不会发生脑裂。
• 一个KunlunBase集群的多个计算节点之间没有直接复制关系，这些计算节点把DDL日志写入到元数据集群的ddl log，并且总是从中复制其他计算节点执行过的ddl log，来达到一个KunlunBase集群的所有计算节点具有相同的元数据。
• 做过节点故障的混沌测试，有大量自动测试，每天在Jenkins自动运行。

21、计算节点是否支持连接池处理？

• 支持外部连接池。

22、新增存储节点时，复制表（Mirror Table）如何处理？自动复制数据?

• 是的，见此文档

23、Xpanel 是否有慢查询能力

• 1.3版本会图形化显示慢查询及其相关信息，目前收集到了ES中，通过kinaba可以查找到。

24、存储节点是否支持国密算法？

• 1.3 版本实现国密算法加密插件

25、安全方面，如SQL审计、防火墙功能、白名单是否支持？

• 支持，这些功能都是直接使用PostgreSQL 自带功能。

26、KunlunBase是否完全遵循SQL92\SQL99标准？

• 几乎完全遵循，仅有少量例外，在现代软件开发中几乎不可能用到，在PostgreSQL的文档中有详细列出；另外，KunlunBase对于PostgreSQL的语法，针对分布式数据库的场景和特点，做了少量取舍，但是不会影响业务系统开发，详见 KunlunBase不支持的PostgreSQL语法和功能汇总。

27、KunlunBase是否支持CTE语法？

• 支持CTE, window function，以及cube,rollup, grouping set 等所有OLAP语法。

28、兼容Postgres，那是否在Postgres上注册的所有函数，可以不用调整直接注册在KunlunBase上？

• PostgreSQL的系统函数，在昆仑数据库中全都存在，可以直接在SQL语句中调用，且支持pg的plsql存储过程。并且可以使用CREATE EXTENSION语句，把pg 生态中的各种插件加上去来在KunlunBase中使用这些插件。
• pg生态绝大多数extension无需任何修改就可以挂到KunlunBase正常工作。只有postgis, pgvector等少量重量级的有自己的数据类型或者数据存储方法的extension，是需要我们进一步的研发工作特殊处理的。我们扩展了postgis，以便它可以挂到KunlunBase的计算节点上，并且与KunlunBase的存储节点读写GIS数据。对于pgvector我们也需要在KunlunBase的存储节点中实现向量数据管理，以便pgvector可以挂到KunlunBase的计算节点实现向量数据管理和查询功能

29、KunlunBase支持API连接还是JDBC连接操作，JDBC是否有特殊性？

• 通用的jdbc库就可以连，我们没有修改jdbc实现。而且各种编程语言的客户端连接库(connector)都可以连接，详见KunlunBase对当前主流编程语言的 MySQL connector 汇总
• KunlunBase支持MySQL和PostgreSQL两种连接协议和SQL语法，原本使用MySQL和PostgreSQL的应用软件系统，无需修改或者重新编译，就可以直接连接到KunlunBase正常工作

END