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个节点就不能提供服务了，此时需要人工处理，如处理不当极容易发生脑裂现象。
一、设备环境centos7.2两台MySQL 5.7MySQL 5.7主要特性：原生支持Systemd更好的性能：对于多核CPU、固态硬盘、锁有着更好的优化更好的InnoDB存储引擎更为健壮的复制功能：复制带来了数据完全不丢失的方案，传统金融客户也可以选择使用…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
