代码拉取完成,页面将自动刷新
同步操作将从 唯品会/drc 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
DRC的数据复制的性能,主要取决于Applier重放binlog的性能.
Applier性能有两方面:吞吐量和复制延迟。
吞吐量主要取决于:
复制延迟主要取决于:
关于Applier性能的简单测试数据如下表所示:
用例 | 源DB压力 | Applier与目标DB 延时(ms) | Applier吞吐量(tps) |
---|---|---|---|
测试1 | 16 threads,19200 tps | 0.02 | 8070 |
测试2 | 8 threads,11700 tps | 0.02 | 5050 |
测试3 | 4 threads, 6870 tps | 0.02 | 2960 |
测试4 | 2 threads, 4530 tps | 0.02 | 1950 |
测试5 | 1 thread , 2113 tps | 0.02 | 1274 |
测试6 | 16 threads,19200 tps | 0.21 | 4640 |
测试7 | 16 threads,19200 tps | 2.01 | 1145 |
sysbench用例: update_index sysbench与源数据库网络延时: 0.04ms Applier机器配置: 32 core, 32G RAM Applier与kafka集群网络延时: 5ms DB机器配置:32core,32G RAM, SAS盘
从上表我们可以看出:
其中,我们解释一下,Applier的吞吐量与sysbench.update_index的吞吐量差距的原因,主要是:
所以在100%写的情况下,Applier与源DB的吞吐量会有较大差距, 随着时间推移,DRC的复制延迟会越来越大。
但是对于读写混合负载,比如在sysbench.oltp压力测试下,Applier完全可以及时重放事务,不会造成主从延时。
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。