MySQL 5.6 测试之 Replication(主从复制)
一、简述
MySQL 5.6版本相比以前新增了很多令人激动的特性,简要介绍见:转:MySQL 5.6新特性。性能方面已经做过测试了,详细请见:MySQL 5.6 vs MariaDB 5.5 vs Percona(5.5 & 5.6) 之TPCC性能测试。接下来继续测试其Replication(主从复制)功能,看看是否依旧能让人激动。
二、测试环境
2.1 测试环境和之前一样,详细见下图:
2.2 自动化测试脚本 MySQL 5.6 vs MariaDB 5.5 vs Percona(5.5 & 5.6) 之TPCC性能测试 文中已提及,下载地址:tpcc-run.sh 。
2.3 重点配置选项差异对比
#binlog log-bin = binlog binlog_format = mixed gtid_mode = ON disable-gtid-unsafe-statements = 1 binlog_cache_size = 4M max_binlog_size = 1G max_binlog_cache_size = 2G sync_binlog = 1 expire_logs_days = 1 #relay log max_relay_log_size = 1G relay_log_purge = 1 relay_log_recovery = 1 master_verify_checksum = 1 master_info_repository = 'TABLE' slave_sql_verify_checksum = 1 slave_allow_batching = 1 log_slave_updates
MySQL 5.6宣称支持多线程并发复制,事实上是针对每个database开启相应的独立线程,如果线上业务中,只有一个database或者绝大多数压力集中在个别database的话,多线程并发复制特性就没有意义了。
三、测试结果
测试方法:部署master-slave replication环境后,在master上运行tpcc压力测试,然后观察tpcc测试结果,slave上数据复制进度以及数据一致性等。
TpmC结果对比(由于之前已做过其他对比测试,在这里仍旧以模式 "percona 5.6.6-m9-56(独享,1 bp)"(黄色底)为基准进行对比):
四、小结
percona 5.6在开启binlog,启用复制后,性能并不像以前的版本那样突降。在多次测试案例中,比没开binlog还要高,并且测试完毕后可保证数据一致性(测试期间2次kill -9了slave实例)。在以往的版本中,经过大压力测试或者线上运行一段时间后,数据很容易就不一致了。
另外,tpcc压1000个dw,循环3次,从8,16,32...~256线程并发跑,跑percona 5.6复制,slave比master慢了7小时18分钟,这方面仍有待改进。
建议继续学习:
- redis源代码分析 - replication (阅读:3394)
- 深入剖析 redis replication 主从连接 (阅读:2935)
- Heartbeat+DRBD+MySQL Replication故障处理 (阅读:2447)
- mysql replication 报告 (阅读:2190)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:yejr 来源: MySQL 中文网 -
- 标签: Replication 主从复制
- 发布时间:2012-10-14 22:20:44
- [66] Oracle MTS模式下 进程地址与会话信
- [65] Go Reflect 性能
- [64] 如何拿下简短的域名
- [60] android 开发入门
- [59] 图书馆的世界纪录
- [59] 【社会化设计】自我(self)部分――欢迎区
- [58] IOS安全–浅谈关于IOS加固的几种方法
- [54] 视觉调整-设计师 vs. 逻辑
- [48] 界面设计速成
- [48] 读书笔记-壹百度:百度十年千倍的29条法则