公众号开通接近8个月了，已发送文章45篇(其中转载了朋友公众号 @yangyidba 几篇文章)，总用户数958。公众号主要针对客户问题分享OceanBase的使用经验和原理。非常感谢大家的关注和支持！

这两个月完成了两个技术序列，部分内容有相应的在线直播。一是实践入门序列，二是从ORACLE/MySQL到OceanBase序列。两个序列内容也可能有重复，主要是多角度介绍OceanBase，方便不同技术背景的朋友了解OceanBase。

实践入门序列主要是介绍OceanBase集群的手动搭建、总控服务原理、负载均衡和高可用原理等，还有客户端工具DBeaver，常用SQL、性能测试建议等。具体链接请查看公众号的菜单里”OceanBase技术相关“。

学习OceanBase从搭建入手，已经有很多朋友手动搭建成功。也有少数朋友在集群初始化总控服务那一关没有过去(原因多是环境不正确或资源不够)。

总控服务是OceanBase很关键的一个服务，OceanBase的分区迁移、切换任务、冻结、转储/合并、扩容/缩容、DDL等。这些事件都可以从总控服务日志表里查看。

负载均衡和高可用是OceanBase最独特的特性。负载均衡和高可用均是以分区为粒度的(或者说是分区组)。有关分区的概念也是反复提起的，跟ORACLE分区概念一样，但不一样的是OceanBase的分区可以跨多个节点。同时分区又会跟分库分表类比，《分布式数据库选型——数据水平拆分方案》是对水平拆分技术理论的总结。

直播视频可以恩墨云平台很方便查看: https://cs.enmotech.com/course/17

相关PPT里有相应的原理动画演示，对理解OceanBase的扩容、分区迁移和高可用等原理有很大帮助。下载地址：

• OB直播间01_手把手教你搭建高可用的OceanBase数据库集群

• OB直播间02_OceanBase负载均衡和弹性伸缩实践原理

• OB直播间03_OceanBase高可用原理和演示

OceanBase 1.x版本兼容MySQL常用SQL，OceanBase 2.x版本开始兼容ORACLE常用SQL，后期重点方向是ORACLE兼容性。这里说的兼容性只是使用特征上像MySQL/ORACLE，底层原理依然是OceanBase自己的特点。所以深入使用的话还是要了解OceanBase跟ORACLE/MySQL的区别。具体连接请查看公众号菜单里“从ORACLE/MySQL到OceanBase序列"。

首先OceanBase在每个节点上会有一个OBServer进程，这是个单进程软件。多个节点的OBServer进程组成一个集群，管理着集群机器资源。OceanBase是分布数据库，业务数据分布在多个节点上，应用并不知道数据具体在哪个节点上，所以OceanBase的访问需要由一个反向代理OBProxy。

OceanBase的读写模型跟ORACLE/MySQL有很大不同，其数据写都在内存里不及时落盘，所以性能方面有自己特点。OceanBase有类似ORACLE的参数(parameters)用于调优集群性能，以及类似MySQL的变量(variables)用于调优租户性能。这个在OceanBase性能压测和稳定性压测中非常有用。

OceanBase的数据导出和导入，目前要借助外部工具DataX，将来会有类似MySQL的load data功能用于数据导入。OceanBase还支持集群和租户的物理备份和恢复。需要一个单独的备份服务器用于调度备份恢复任务，实际备份文件可以存储在共享存储、OSS或者NFS路径上。

OceanBase客户已经有从ORACLE/MySQL迁移的案例了，随着客户使用的深入，后续会有更多分享总结。

• 从ORACLE/MySQL到OceanBase入门 PPT

此外，针对OceanBase早期公众号文章做了一个汇总，详情请参见《OceanBase资料大汇总(20190720)》。

近2个月在多个客户现场做OceanBase性能和稳定性测试，有一些经验供大家参考。此前有总结过《OceanBase数据库实践入门——性能测试建议》偏重于准备。这里偏重于OceanBase端原理。

首先是导入数据报错。如果使用Java程序导入大量数据，为了导入性能，开发会用JDBC的addBatch功能批量写入很多数据，每个SQL就是一个事务。addBatch的本意是将多次sql当作一个批次发送到数据库端，减少网络上的消耗。开发在addBatch的时候可能会把批量写的很大，比如说几万或者十几万。如果此时还有很高的并发导入，则在OceanBase上有可能报内存相关错误。这是因为OceanBase支持SQL解析和执行计划缓存。一个addBatch的批次如果有几万或者十几万时，jdbc发出的SQL文本非常长，导致OceanBase内部解析时可能因为SQL解析内存不足而失败，或者解析成功了但不会缓存(因为太大)等。所以如果有并发批量导入，这个addBatch控制在几百或者几千以内，单个SQL的文本不会太长，能让OceanBase解析并缓存成功即可。具体SQL解析用了 多少内存或者是否成功，可以查看OceanBase的视图(gv$sql_audit)(参考《阿里数据库性能诊断的利器——SQL全量日志》)。

第二类是查询超时报错。导入大量数据后需要查看数据量的时候，可能会报查询超时。OceanBase对每个SQL的执行有个默认超时时间限制(10秒)，如果查询时间很长，需要调大这个参数或者临时用hint加长参数值。具体参考《从ORACLE/MySQL到OceanBase：数据库超时机制》。

第三类是大事务报错。在业务测试oceanBase过程中，可能会有很多大事务并且有一定的并发。OceanBase压力不大的时候这些都没有问题，但是如果压测到数据库性能瓶颈时，很可能会碰到一些事务报错。通常原因是由于OBServer节点CPU利用率满了导致节点间RPC通信出现排队或者超时等，进而导致分布式事务的状态异常。OceanBase针对大事务是可以临时调整一些内部参数来规避这个报错。比如说增加RPC重试次数和超时等待时间。虽然避免了报错，但性能问题的本质并没有改变，事务的性能会下降(因为内部发生更多重试等待)。此外在故障切换时，如果是小事务，OceanBase会等事务提交；如果是大事务，OceanBase等100ms后就不再等会将事务回滚掉。

事务的大小是否构成影响，取决于OceanBase服务器当时的压力，以及事务的并发数。所以没有一个确切的值可以判断一定会出问题或者一定不会出问题。这就要求性能测试中对于事务的大小和并发数做到参数配置里。每次运行不同的参数进而找到一个性能和稳定性的平衡点。对于批量更新业务的测试，只要业务上能将大事务切分为很多小事务并行运行，那出问题的可能性就非常小。

第四类是内存报错。OceanBase的内存会分多个模块。其中主要是增量内存(占租户内存的一半)，用于存放增量写的内容。这块内存如果用尽OceanBase租户的写入就会停止(报错)。所以OceanBase会设置一个阈值来触发冻结操作(minor freeze)。冻结时活动的memtable会立即停止写入并生成新的memtable用于写入。老的memtable就从内存转储到磁盘以释放增量内存。转储对性能的影响很小，不过转储的次数是有限的，如果转储次数用尽了，会触发合并操作(major freeze)。合并是将内存中的memtable跟对应的基线数据(sstable)在内存中合并生成新的sstable写出到磁盘上，合并对数据库性能的影响会比较明显，所以一般控制在业务低峰期做。为了避免压测导致增量内存用尽，可以将转储次数设置的很大。并且在压测过程中观察增量内存的消耗速度和转储的时间间隔，从而估算出一个安全的转储次数。

转储只是释放内存，如果业务写入消耗内存的速度比转储释放内存的速度快很多，还是有可能导致增量内存用尽。所以OceanBase 2.x新增了限速功能。当增量内存使用率超过阈值时，OceanBase会强制让相应的写等待，以降低速度。实际测试发现，限速逻辑是非常给力的，类似于汽车的制动。对于限速阈值的设置，也需要多次压测观察内存使用比例和消耗速度得到一个恰当的值。设置的过低，会防范过严影响整体写入性能；设置的过高，可能出现刹不住导致内存报错。在蚂蚁业务里也有很多数据导入的场景，用DataX导入的时候客户端会自行判断当前增量内存使用比例，在业务端自己限速。这个控制更灵活一些。

在内存模块里，还有一些是用于SQL解析，排序等。其中任何一个模块内存用尽都会报类似“内存不足”等错误，这个给问题排查带来了一些不便。后期应该会改进。具体内存模块介绍可以先看《产品模块原理系列 |OceanBase内存管理原理解析》。

此前在介绍OceanBase事务时我多次提及OceanBase的也支持WAL(Write-Ahead Logging)机制，说OceanBase在修改数据块之前先生成相应的Redo日志。这点严格来说不准确。OceanBase的写是记录增量，不是修改数据块，先生成增量数据，然后在COMMIT的时候才去生成相应的事务日志(CLog)，然后这个事务日志要在本机落盘和同时发往其他副本所在节点落盘。总体上事务日志还是在数据之前落盘(当然增量数据并不及时落盘)。

如果您对OceanBase有任何想了解的，欢迎公众号留言。其他的跟数据库架构、运维和性能调优有关的问题也可以留言。大家的问题就是我写作思路的源泉。
为了便于问题沉淀(其他人可以看到)，您也可以通过下面这个小程序发起提问。