按我当前的理解，开源版本只会在晚上出发一次性合并，没有小版本的Minor freeze转储等操作。增量会一直在内存中不落盘，直到跟磁盘里的 SSTable 进行合并（Major freeze）。
如果我理解有误，请大家给答疑解惑。
如果我理解没错的话，数据是否存在丢失的风险？比如内存不够大装不下频繁的增删改操作产生的增量数据，此时OB是如何处理来避免数据丢失风险的？
有看到相关的内容提到如果内存不够用了就会在应用端报错并不能继续修改，此时只能进行内存扩容或对内存写入速度进行限流。
1 个赞
OceanBase 数据库的存储引擎基于 LSM-Tree 架构，数据大体上被分为 MemTable 和 SSTable 两部分，当 MemTable 的大小超过一定阈值时，就需要将 MemTable 中的数据转存到 SSTable 中以释放内存，我们将这一过程称之为转储。
转储触发
转储有两种触发方式：自动触发与手动触发。
当一个租户的 MemTable 内存的使用量达到
memstore_limit_percentage * freeze_trigger_percentage所限制使用的值时，就会自动触发冻结（转储的前置动作），然后系统内部再调度转储。也通过以下的运维命令手动触发转储。
minor_freeze_times 用于设置多少次小合并触发一次全局合并。值为 0 时，表示关闭小合并。
参数类型整型
默认值：100
取值范围：[0, 65535]
是否重启： OBServer 生效否
说明 minor_freeze_times 配置项与 major_compact_trigger 配置项具有相同功能。
合并前会有转储执行的，转储的触发又是内存使用率触发的，有一个参数，设置占用租户内存百分比，达到这个值就触发转储。
所以肯定不会丢数据，但是会拒绝写入。
我们开发测试环境搭建初期，批量导入MySQL数据到OB，写入量太大，直接报错了，不会在写入。
解决办法就是调低触发转储的内存比例，让尽快触发转储，多次转储在合并。尽量不影响业务。
1 个赞
所以按照大佬的说法，社区版支持自动转储和手动出发转储，但是只支持凌晨两点的合并操作。
可以通过调整自动转储的参数来控制内存数据尽快落盘，我这样理解是否正确～
如果没有转储，我相信没几个敢用社区版的OB的。
1 个赞
哈哈，是这么说。
只支持凌晨两点的合并操作这个说法不正确。这个2点是参数可以配置。
其他转储次数，百分比都是参数，自己设置。
1 个赞
感谢指出～