boysxw
2023 年2 月 14 日 17:52
#1
生产环境, oceanbase 3.1.4CE版本,1-1-1架构集群,单库大小2.5TB,其中有几个热表写入比较高,(约20个clog文件/分钟)
问题:现对某zone扩容一台机器后,同zone分区均衡同步非常慢,单台机器24小时还未同步完成,(排除目标服务器性能/压力问题)
现象:热表单个partition在2GB左右,同步partition期间clog有延迟记录,消的比较快,但也要1~2小时。__all_virtual_clog_stat表clog显示延迟追上后,再下一个partition同步时,该虚拟表又开始clog延迟.
问题:
1、2GB的分区,为何同步时感觉会这么慢?
2、对于高热的表,新增节点时partition均衡同步时,原理不知怎么样的,是依赖clog回放成最新数据吗?
1 个赞
厌离
2023 年2 月 14 日 18:05
#3
从实现的角度来说,扩容的时候,实际上是选择出一部分副本迁移到扩容的机器上。
从迁移的角度来看,副本能迁移成功的前提肯定是是把迁移源端的数据全都复制过来才可以迁移成功,所以在写入比较大的情况下,有可能存在迁移比较慢,可能会经过很多次的重试才能让迁移的目的端达到同步的状态。
迁移副本做了什么呢?在目的端创建副本,拷贝基线,拷贝副本的一些元信息,拉日志同步,所以迁移发生时,迁移目的端就会落后,这个是预期内的。
1:1:1的机器,不知道你的primary_zone的配置是什么样子的,迁移副本的时候需要把leader切走才能进行迁移,切leader在迁移中是很耗时的操作。如果是因为这个的影响,建议按zone扩容,扩容的之前,调整primary_zone,保证要扩容的zone上没有分区的leader。
boysxw
2023 年2 月 14 日 18:32
#4
谢谢,复核primary_zone,确实包含了正在扩容的zone。已修改为其它zone,正在观察.
boysxw
2023 年2 月 14 日 18:51
#6
请问拷贝基线,是指所有partition都是同一个基线Time1,如果有1K个partition,那么每个partition都要从time1---->当前Time2的clog重拉一遍吗?(期间对整个集群做了major freeze,好像还会拉比较早的clog)
boysxw
2023 年2 月 15 日 09:05
#8
切换primary_zone到其它zone后,观察问题还是存在,看来还是在同步clog上耗时
boysxw
2023 年2 月 15 日 09:32
#9
每个partition有自己的位点,展示的延迟的7万秒之前的clog,这个比较疑惑
mysql> select now() currenttime,/+ MONITOR_AGENT READ_CONSISTENCY(WEAK) / __all_tenant.tenant_id,__all_tenant.tenant_name,clog_stat.svr_ip, clog_stat.replica_type, clog_stat.max_clog_sync_delay_seconds from ( select table_id>>40 tenant_id,svr_ip,replica_type, max(next_replay_ts_delta) / 1000000 as max_clog_sync_delay_seconds from __all_virtual_clog_stat group by tenant_id, replica_type,svr_ip having max_clog_sync_delay_seconds<18446744073709 ) clog_stat left join __all_tenant on clog_stat.tenant_id=__all_tenant.tenant_id where max_clog_sync_delay_seconds>200;
mysql> select max(START_TIME) max_START_TIME,max(end_time) max_END_TIME from gv$merge_info where TYPE=‘major’ ;
±---------------------------±---------------------------+
| max_START_TIME | max_END_TIME |
±---------------------------±---------------------------+
| 2023-02-15 08:34:03.432950 | 2023-02-15 08:34:18.228607 |
±---------------------------±---------------------------+
1 row in set (0.12 sec)
mysql> select max(START_TIME) max_START_TIME,max(end_time) max_END_TIME from gv$merge_info where TYPE=‘major’ and START_TIME<‘2023-02-15’;
±---------------------------±---------------------------+
| max_START_TIME | max_END_TIME |
±---------------------------±---------------------------+
| 2023-02-14 17:46:14.337883 | 2023-02-14 17:46:14.487143 |
±---------------------------±---------------------------+
最早的执行中的任务
镜水
2023 年2 月 15 日 10:44
#10
可以查一下gv$merge_info where TYPE=‘minor’ ;看下转储的时间
boysxw
2023 年2 月 15 日 16:36
#11
正在等clog同步的表,gv$merge_info where TYPE=‘minor’ and table_id=xxxx,有做minor的记录.