一简介:MGR节点的相关维护
二 两种情况
1 MGR读节点异常停止,然后重新启动加入节点进行数据同步
2 MGR读节点新加入集群成员,启动复制进行数据同步
三 通用过程
1 新加入节点通过通道group_replication_recovery进行异步的GTID复制
2 开启复制后,先应用本地没加入队列的relay-log中的事务
3 进行change随机进行选举组列表的机器作为dononr(有可能是写节点)
4 扫描donor节点最早的binlog日志开始逐渐扫描,读取,应用.(已经应用完的不会继续应用)
5 应用完binlog日志开始应用缓存在内存的消息队列
6 新节点设置为状态online
四 相关参数
group_replication_recovery_retry_count 重试次数
group_replication_recovery_reconnect_interval 重试间隔时间
五 特点
1 随机选择donor节点,改进了以前安装配置列表总选择一个节点的问题
2 由于是异步复制,donor本身是可读写的
六 备份相关
数据
1 指定备份方案,用于新节点加入或者故障节点的恢复
2 备份工具采用xtrabackup恢复即可
3 采用最新的备份恢复读节点,防止应用时间过长导致集群性能问题
binlog
1 指定binlog保留方案,防止因为purge binlog导致读节点无法同步数据的问题发生
七 一般过程
1 采用xtrabackup恢复出单实例
2 节点进行安装组件初始化
3 手动进行set purge,跳过已执行事务
4 开启复制并观察延时和状态
八 注意事项
1 最好在业务低峰期实现节点加入操作,防止集群受到影响
2 选取最新的备份,在binlog差量不大的情况下加入操作,防止集群收到影响
九 错误系列
1 从节点恢复所需要的donor节点的binlog被purge导致无法正常追赶的情况
2 发生OOM操作,在新加入节点应用binlog太多,内存队列堆积导致发生OOM甚至整个集群不可用
我们可以发现 都能根据第六部分进行解决
十 节点发生错误几种情况
1 读节点停止复制
2 读节点down掉
十一 和PXC的对比
1 donor节点不会停止应用队列,据我测试,依然会正常运行
2 依靠并行复制+binlog传输会快速追赶事务
3 追赶事务途中也会在内存中存储消息队列,但是暂没发现控制参数.pxc是有相关控制参数的
十二 总结
本文只代表个人观点,如果有误,可以留言本人会进行改正