mysql 半同步复制~ 整体概述与改进

一 简介:今天来聊聊增强半同步复制这一强悍的特性

二 原理解析

    1 AFTER_COMMIT（5.6默认值）

      master将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log)，同时主库提交事务。master等待slave 反馈收到relay log，只有收到ACK后master才将commit OK结果反馈给客户端。
     
    2  AFTER_SYNC（5.7默认值，但5.6中无此模式）

     master 将每个事务写入binlog , 传递到slave 刷新到磁盘(relay log)。master等待slave 反馈接收到relay log的ack之后，再提交事务并且返回commit OK结果给客户端。 即使主库crash，所有在主库上已经提交的事务都能保证已经同步到slave的relay log中

三 5.7改进点     

   1 模式改为after_commit,在收到ack回复信息后才进行事务层的提交和客户端的返回,进一步提高主从的一致性程度
   2 ack信息确认有专门的线程处理,原来dump线程既要处理binlog传输又要确认ACK信息,极大的影响了主从的并发
   3 新增rpl_semi_sync_master_wait_slave_count参数,这就是我们上面所说 只要有一个从库返回ack信息,就代表半同步复制完成.极大的调节了整个架构的灵活性
   4 MySQL 5.7 对binlog lock进行了以下两方面优化:
        1. 移除了dump thread对binlog的互斥锁
        2. 加入了安全边际保证binlog的读安全
   5 5.7新的并行复制特性更加可以应用到半同步复制上,提升了整体性能

四 半同步复制转化为异步复制的风险

   1 主和从集群机器之间的网络,注意流量监控 
   2 从集群整体的复制是否健康,注意集群从库健康监控
   3 从集群整体的IO较高,注意从库延迟和慢查询监控

 五   相关重要参数和监控   

一 状态监控,监控状态是否开启
   show status like 'Rpl_semi_sync_master_status';
    show status like 'Rpl_semi_sync_slave_status';
二 没有收到ACK应答的事务数
    show status like 'Rpl_semi_sync_master_no_tx'

六 搭建

    1 master      

     install plugin rpl_semi_sync_slave soname 'semisync_slave.so';

     install plugin rpl_semi_sync_master soname 'semisync_master.so';
     set global rpl_semi_sync_master_enabled= 1;
     set global rpl_semi_sync_slave_enabled = 1;
     set global rpl_semi_sync_master_timeout=1000;

   2 slave   

     install plugin rpl_semi_sync_master soname 'semisync_master.so'; 

    install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
    set global rpl_semi_sync_slave_enabled = 1;
    set global rpl_semi_sync_master_enabled= 1;
    set global rpl_semi_sync_master_timeout=1000;

 3 slave 

    1 重启复制进程,进行角色注册(stop slave,start slave)

    2 观察日志和相关变量 

      Start semi-sync replication to master 半同步复制开启

  3 将配置写入配置文件中,同时开启是因为故障切换后继续执行半同步复制

 4 小结 

   1 调节异步复制忍受时间为1s,防止影响业务

    2 默认接收到一个client即可,不需要调节

 七 上线部署

     对增强复制状态进行监控,如果频频发生切换到异步情况一定要定位原因

 八  增强半同步复制问题

     幽灵事务 

     1 当sync_binlog =1 时 唤醒dump binlog的时机是在binlog evnet加入sync队列,这造成一种情况,当主库cash后 请注意 这时候还没唤醒dump binlog线程,重启重做,根据故障恢复机制,如果binlog存在并且完成,就会重做,但实际上此数据还没传到从库.

        这就造成了原主比新主多数据的情况.必须原主进行重做才能加入集群,否则会造成数据冲突

      

九   最佳架构

     MHA(0.57)+MYSQL(5.7.21)（并行复制+半同步增强)+sync-binlog=1(binlog刷新策略)

十  增强半同步复制监控

       1、Rpl_semi_sync_master_status：表示主库是否启用半同步
       2、Rpl_semi_sync_slave_status：表示从库是否启用增强半同步
      3、Rpl_semi_sync_master_tx_avg_wait_time：表示等待slave响应的事务平均等待时间，如果该值比较大的话可以检查一下网络情况了
      4、Rpl_semi_sync_master_tx_waits：表示slave响应的事务数，该值如果增长较快的话也需要检查准备之间的网络情况
      5、Rpl_semi_sync_master_wait_sessions：表示当前master上正在等待ack的会话数
      6、Rpl_semi_sync_master_yes_tx：表示增强半同步复制下的事务数
      7、Rpl_semi_sync_master_no_tx：表示异步复制的事务数，该值如果变化了，那么也需要检查半同步复制是否已经退化为异步复制，在退化时从error log也可以看到