ITPub博客

MGR测试过程中出现的问题汇总

MySQL 作者:chenfeng 时间:2018-11-09 11:08:58 0 删除 编辑

MGR出现的问题大概总结为以下几点:

1.每次提交事务时尽量控制单次操作事务的数据量,减少大事物在其他节点check的时间和堵塞后面的操作带来的集群复制延迟,如事务回滚影响更大;

2.MGR集群环境部署对网络的依赖性较强,网络延时会导致整个集群性能的下降,集群内服务器尽量保持配置一致,集群内其中一服务器性能不好也会影响整个集群的整体性能;

3.DDL操作时,如操作的table有事物执行,在ddl时间内的所有的 插入,更新和删除操作记录到一个日志文件,然后再把这些增量数据应用到相应的表上(等表上的事务完全释放后),日志大小受innodb_online_alter_log_max_size参数限制,如写一直持续innodb_online_alter_log_max_size参数大小不好人为控制,会导致ddl执行失败;

4.Mysqldump会直接影响集群性能,xtrbackup因对磁盘io占用也会间接影响集群性能,建议备份节点考虑在mgr集群下挂载slave节点上执行备份;

5.版本升级,5.6在开启gtid后可直接升级至5.7.17并开启组复制模式;5.5版本则需要升级到5.6版本过渡一下才可升级为组复制模式。由于5.6、5.7版本上时间类型time,timestamp,datetime精度都支持到微秒精度,从5.5升级后带来的影响需要评估;

6.数据校验,现有工具Pt-table-checksum并不支持MGR集群的校验,仅可以对slave节点数据校验;

7.流量控制,当certifer_queue队列深度大于flow_crontrol_ certifer_threshold或者applier_queue队列深度大于flow_crontrol_ applier_threshold值时会触发流控制,触发流控制后写入会降低,这是为了避免更大的复制延迟,但是触发流控制后前端应用就会感觉可用率的下降,所以这个参数是个双刃剑,要根据实际生产环境设置,并且certifer_queue和applier_queue队列深度暂时没有监控项可监控,后期带来的运维问题也需要考虑;

8.MGR集群最多为9个节点,以5节点集群为例,集群内2个节点故障时,其余3个节点是可以继续提供服务的,但是当集群内有3个节点故障时,剩余2个节点就不能提供服务了,此时需要人工处理,如处理不当极容易发生脑裂现象。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/15498/viewspace-2219347/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
交流MySQL,MongoDB和Redis技术。 微信或QQ:410294

注册时间:2015-12-07

  • 博文量
    664
  • 访问量
    1405669