OceanBase FAQ（不断更新）

报错信息：strong consistency across distributed node not supported
OB版本：  1.x
报错原因：
OceanBase 1.x 版本不支全局一致性查询。在1.x版本里，当SQL要查询的数据分布在不同OBServer节点上时，由于没有内置全局时钟，所以无法获取不同OBServer节点上同一个时刻的数据。
解决办法：
1. 在1.x版本里。如果SQL访问的是多个表，且表之间有业务联系，则将多个表设置为相同的表分组（tablegroup）可以规避这个问题；如果SQL访问的是单个分区表，且能接受延时，可以使用弱一致读hint来规避报错；否则，暂时无解。  弱一致读hint详情请参考官方文档 弱一致读(ob_read_consistency)
2. 计划在2.1版本里，支持全局一致性查询，就没有这个问题。

-------------------------

报错信息：ERROR 4624 (HY000): machine resource is not enough to hold a new unit
OB版本：所有版本
报错原因：
    OceanBase从某个角度来说就是将一批机器的资源（CPU/Memory/Disk）聚合在一起形成一个大的“资源池”，然后再从里面分配资源。每个租户都得绑定至少一个Resource Pool。Resource Pool就是从原始的“资源池”里创建出来的。每个Resource Pool由N个相同的Unit组成。每个Unit在某个具体的OBServer内部分配。当创建新的Resource Pool或者调大老的Resource Pool规格时，可能会因为没有OBServer可以分配出对应规格的Unit而报错。
解决办法：
    重新计算可用资源，调制分配资源的SQL里的规格。如果可用资源确实不够用，那就先补充机器资源或者释放不用的租户资源，然后再重试。

-------------------------

汇总一下有关OceanBase和开源相关的问题的答案。


1. OceanBase 0.4曾经开源，地址为 alibaba/oceanbase 。 喜欢看代码的从中可以学习到一些分布式数据库开发经验。
2. OceanBase从1.0版本不再开源，架构上做了很大的重构，对SQL和存储功能都有加强。不过关于LSM结构、冻结合并的原理没有大变。当前版本进入2.0。将来是否开源目前并无信息。
3. OceanBase 在用户体验上像MySQL，但是绝不是MySQL，也不是基于MySQL版本修改的，不是基于Postgre修改的，不是基于其他任何开源的产品修改的。OceanBase是蚂蚁自主研发的纯粹的分布式数据库，产品开发过程中，特别注意避免侵犯其他公司专利。所以OceanBase是按照一个商业通用数据库去规划设计的。
4. 随时欢迎开发能力很强的同学加入OceanBase内核开发团队。

-------------------------

1. OceanBase提供多租户能力（租户就是实例）。租户内的分布式事务需求，OceanBase是满足的。原理是两阶段提交协议，强一致。OceanBase对分布式事务两阶段提交过程做了一些优化，性能有提升。
2. 如果业务的事务范围超出了租户（实例）的边界，则必须借助第三方分布式事务中间件框架或者应用自己实现分布式事务。蚂蚁SOFA的分布式事务框架DTX支持三种分布式事务方法，即XA、TCC和FMT.其中TCC和FMT都是最终一致。

-------------------------

Q: OceanBase里创建索引是立即生效吗？唯一索引呢？
A： 分场景。

1. 如果是在create table里带上了索引（包括唯一索引，也就是唯一性约束），是立即生效的。
2. OB 1.x 版本里在表存在的情况下新建的索引（包括唯一索引），命令立即返回，但是索引不是立即生效。需要等到OB集群发起大合并之后才会生效。其中唯一索引需要等待两次大合并。所以运维建索引后需要安排1-2次大合并操作。
3. OB 2.x 版本里在表存在的情况下新建的索引（包括唯一索引），命令立即返回，索引也不是立即生效，但是索引开始后台异步创建，创建时间取决于数据量。

示例如下：
1. OB 1.x 版本的索引




2. OB 2.x 版本的索引

-------------------------

Q：OceanBase什么时候会触发「合并」？
A： OceanBase的数据写之前事务日志redo会及时落盘，但是数据的增量修改会一直在OB的增量内存memtable里，每天会落盘一次，这个就是合并。合并时间可以设定（major_freeze_duty_time）。另外，如果memtable使用率超过阈值（freeze_trigger_percentage），就会触发「冻结」，然后就是minor compaction，以及「转储」操作。转储会释放memtable内存，增量数据被输出到磁盘上，转储有次数限制（最大由参数minor_freeze_times），这个次数用完了就会触发「合并」。合并会比较耗OB的资源，时间长短取决于有多少增量数据要跟基线数据合并。


## 查看冻结转储参数
SHOW parameters WHERE NAME IN ('enable_major_freeze','minor_freeze_times','freeze_trigger_percentage','major_freeze_duty_time')
AND svr_ip IN ('11.166.175.6');


## 触发冻结合并
ALTER system major freeze;

SELECT sleep(1);

## 查看冻结合并历史
SELECT str_to_date(h.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create, module, EVENT,name1,value1,name2,value2
FROM __all_rootservice_event_history h
WHERE h.module IN ('daily_merge','major_freeze', 'root_service')
ORDER BY gmt_create DESC LIMIT 50;
示例：