Mysql主从复制的三种同步方式和半同步复制配置(在你之后，人人都像你，人人都不是你。)

MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题：主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

主数据库配置

从数据库配置

查看半同步是否在运行

Rpl_semi_sync_master_clients #半同步复制客户端的个数 Rpl_semi_sync_master_net_avg_wait_time #平均等待时间（默认毫秒） Rpl_semi_sync_master_net_wait_time #总共等待时间 Rpl_semi_sync_master_net_waits #等待次数 Rpl_semi_sync_master_no_times #关闭半同步复制的次数 Rpl_semi_sync_master_no_tx #表示没有成功接收slave提交的次数 Rpl_semi_sync_master_status #表示当前是异步模式还是半同步模式，on为半同步 Rpl_semi_sync_master_timefunc_failures #调用时间函数失败的次数 Rpl_semi_sync_master_tx_avg_wait_time #事物的平均传输时间 Rpl_semi_sync_master_tx_wait_time #事物的总共传输时间 Rpl_semi_sync_master_tx_waits #事物等待次数 Rpl_semi_sync_master_wait_pos_backtraverse #可以理解为"后来的先到了，而先来的还没有到的次数" Rpl_semi_sync_master_wait_sessions #当前有多少个session因为slave的回复而造成等待 Rpl_semi_sync_master_yes_tx #成功接受到slave事物回复的次数

当半同步复制发生超时（由rpl_semi_sync_master_timeout参数控制，默认为10000ms，即10s），会暂时关闭半同步复制，转而使用异步复制，也就是会自动降为异步工作。

当 master dump 线程发送完一个事务的所有事件之后，如果在 rpl_semi_sync_master_timeout 内，收到了从库的响应， 则主从又重新恢复为半同步复制。

5.6 版本的半同步复制，dump thread 承担了两份不同且又十分频繁的任务：传送binlog 给 slave ，还需要等待 slave 反馈信息，而且这两个任务是串行的，dump thread 必须等待 slave 返回之后才会传送下一个 events 事务。dump thread 已然成为整个半同步提高性能的瓶颈。在高并发业务场景下，这样的机制会影响数据库整体的系统吞吐量(TPS)。 5.7 版本的半同步复制中，独立出一个 ack collector thread ，专门用于接收 slave 的反馈信息。这样 master 上有两个线程独立工作，可以同时发送 binlog 到 slave ，和接收 slave 的反馈。

1、master服务器高并发，形成大量事务 2、网络延迟 3、主从硬件设备导致 cpu主频、内存io、硬盘io 4、是同步复制、而不是异步复制

1、从库优化Mysql参数。比如增大innodb_buffer_pool_size，让更多操作在Mysql内存中完成，减少磁盘操作。 2、主从服务器在同一个机房 3、从库使用高性能主机。包括cpu强悍、内存加大。避免使用虚拟云主机，使用物理主机，这样提升了i/o方面性。从库使用SSD磁盘。

由于mysql主从复制是基于binlog的一种异步复制通过网络传送binlog文件，理所当然网络延迟是主从不同步的绝大多数的原因，特别是跨机房的数据同步出现这种几率非常的大，所以做读写分离，注意从业务层进行前期设计。

由于mysql主从复制是主数据库上面启动1个io线程，而从上面启动1个sql线程和1个io线程，当中任何一台机器的负载很高，忙不过来，导致其中的任何一个线程出现资源不足，都将出现主从不一致的情况。

主数据库上面设置的max_allowed_packet比从数据库大，当一个大的sql语句，能在主数据库上面执行完毕，从数据库上面设置过小，无法执行，导致的主从不一致。

key自增键开始的键值跟自增步长设置不一致引起的主从不一致。

mysql异常宕机情况下，如果未设置sync_binlog=1或者innodb_flush_log_at_trx_commit=1很有可能出现binlog或者relaylog文件出现损坏，导致主从不一致。

mysql本身的bug引起的主从不同步，一般不会

特别是高版本是主，低版本为从的情况下，主数据库上面支持的功能，从数据库上面不支持该功能的情况。

（1）先进入主库，进行锁表，防止数据写入

mysql> flush tables with read lock; mysql> show master status

（2）数据导出备份然后倒入从库

mysqldump -uroot -p --lock-all-tables --flush-logs db_name > /data/master.sql

（3）登录从库停止slave从节点

stop slave;

（4）倒入数据

mysql -u root -p db_name < /temp/master.sql 或mysql> source /temp/master.sql

（5）配置重新主从同步

前7步同上； 通过第7步的报错位置，在主库执行： mysqlbinlog -v --stop-position=xxx ./data/master-bin.xxx > ./binlog.update cat ./binlog.update |awk ‘/end_log_pos xxx/ {print NR}’ 根据上面的NR行数，查看附近的行，定位数据不一致的地方，后续手动补全 cat ./binlog.update |awk ‘NRxxx-50,NRxxx+50’|grep -i update -A 200|grep xxxx -B 200|less 找到数据位置，@1表第一个字段值；其中@1 @2 @3…分别对应表的列名 或： 比如，报错位置 end_log_pos 440267874。可利用mysqlbinlog工具找出440267874的事件 /usr/local/mysql-5.6.30/bin/mysqlbinlog --base64-output=decode-rows -vv mysql-bin.000003 |grep -A 20 ‘440267874’ 或者/usr/local/mysql-5.6.30/bin/mysqlbinlog --base64-output=decode-rows -vv mysql-bin.000003 --stop-position=440267874 | tail -20 或者usr/local/mysql-5.6.30/bin/mysqlbinlog --base64-output=decode-rows -vv mysql-bin.000003 > decode.log 主库创建临时表： Create table xxl_job_temp like xxl_job_log_report; 将该段数据写入临时表导出导入到备库； start slave; show slave status\G

结果说明

Slave_IO_Running： 该参数可作为io_thread的监控项，Yes表示io_thread的和主库连接正常并能实施复制工作，No则说明与主库通讯异常，多数情况是由主从间网络引起的问题； Slave_SQL_Running： 该参数代表sql_thread是否正常，具体就是语句是否执行通过，常会遇到主键重复或是某个表不存在。 Seconds_Behind_Master：是通过比较sql_thread执行的event的timestamp和io_thread复制好的event的timestamp(简写为ts)进行比较，而得到的这么一个差值；NULL—表示io_thread或是sql_thread有任何一个发生故障，也就是该线程的Running状态是No，而非Yes。0 — 该值为零，是我们极为渴望看到的情况，表示主从复制良好，可以认为lag不存在。正值 — 表示主从已经出现延时，数字越大表示从库落后主库越多。负值 — 几乎很少见，我只是听一些资深的DBA说见过，其实，这是一个BUG值，该参数是不支持负值的，也就是不应该出现。