MGR架构 ~ 节点的维护相关问题

一简介: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是有相关控制参数的
十二 总结
 本文只代表个人观点,如果有误,可以留言本人会进行改正