mysql复制

基于事务的复制

group commit：binlog中加入了一个队列

从库的配置要比主库的高才能追的上原因：（tokuDB replication read free）， 减少从库在sql_thread执行的时间，传统的执行时把SQL_thread的拉取到buffer pool中，在往磁盘上刷新。replication read free是直接刷新

复制的过程：

1.binlog写入

2.innodb引擎层写入commit

传统的复制（异步复制）：

主库下发single_update操作->dump线程 读到从库上，通过从库的IO thread读取放到本地，本地在sql thread执行

半同步复制：

主库在commit之后，对从库下发一个single_update操作， 此时主库告诉从库要更新了，但是不会释放连接告诉client已经完成，而是等待从库返回一个ack响应（保证了日志已经传到了从库上）（半同步相对于传统同步多了一步响应，对传输日志的保障）

commit时需要把binlog filename、position写入innodb redo log

半同步存在的风险：client1发起的更新操作commit后已经持久化了 ，本身没有收到ok，但是其他的clientN可以读到更新的数据（自己更新的数据自己没得到，其他人已经得到了）；2.发生crash时会导致主从数据不一致。

5.7 无损复制：

主库上写完binlog之后传到从库上，此时从库返回一个ack（单独的cordinator线程，主库上有ack collector thread），保证自己收到日志之后，主库再commit。

通过rpl_semi_sync_master_wait_point参数 来控制半同步模式下 主库在返回给会话事务成功之前提交事务的方式。

after sync （默认）：master 将每个事务写入binlog ,传递到slave，并且刷新到磁盘。master等待slave 反馈接收到事务并刷新到磁盘。一旦接到slave反馈，master在主库提交事务并且返回结果给会话。（在AFTER_SYNC模式下，所有的客户端在同一时刻查看已经提交的数据。假如发生主库crash，所有在主库上已经提交的事务已经同步到slave并记录到relay log。此时切换到从库，可以保障最小的数据损失。）

after commit：master 将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log)，然后在主库提交事务。master在提交事务后等待slave 反馈接收到事务并刷新到磁盘。一旦接到slave反馈，master将结果反馈给客户端。（风险：在AFTER_COMMIT模式下,如果slave 没有应用日志,此时master crash，系统failover到slave，app将发现数据出现不一致，在master提交而slave 没有应用。）

注意：复制过滤规则不要在主库，只在从库配置

show slave status no lock （偶尔现象：获取的gtid和前面的gtid有一个点或两个点的延迟，但是second_behind还是0）

group replication

single master 默认/mutli master

原理：二进制日志（row格式）+gtid（全局事务标识）；一个通信框架+事务排序控制（automic message delivery&total ordering of message），全局原子的消息队列，全局事务的排队系统把binlog传到其他节点上

group replication自增ID特性：自增ID的步长(offset)和server-id(推荐1-9)有关(auto_increment_increment,自增值；auto_increment_offset，步长)

mysql X协议监听的端口号：33060

group replication 备份不好搞定（mysqldump不支持；xtrabackup会造成集群性能损失严重（强一致性问题））

多源复制为什么不进行多点写入：

1.update基于长事务更新到同一行数据，会造成更新丢失

2.insert可以通过调整步长处理

3.delete删除同一行数据会出现1032错误，

多源复制的限制：

1.开启GTID

2.relay_log_info_reponsitory=table & master_info_reponsitort=table

3.relay_log_recovery=ON

译者介绍：家华，从事mysqlDBA的工作，记录自己对mysql的一些总结