MySQL复制框架

一、复制框架

开始接触复制时，看到各种各样的复制，总想把不同类型对应起来，结果越理越乱~
究其原因就是对比了不同维度的属性，不同维度得出的结果集之间必然存在交集，没有必要将不同维度的属性安插到成对的萝卜与坑

MySQL复制框架
    Replication Methods
        Binary Log File Position Based Replication(Traditional)
        Global Transaction Identifiers Based Replication(GTID)
    Synchronization Types
        Asynchronous Replication：默认是异步复制
        Semisynchronous Replication：半同步(AFTER_COMMIT)、增强半同步(AFTER_SYNC)
        Synchronous Replication：MySQL Group Replication 、MGR和PXC的区别
    Replication Formats
        Statement-Based Replication(SBR,<5.7.7默认)
        Row-Based Replication(RBR,>=5.7.7默认)
        Mixed-Based Replication(MBR)
    复制原理
        复制线程：Dump_Thread、IO_Thread、SQL_Thread
        GTID原理：构成、gtid_executed表如何写入及压缩、GTID Limit、GTID和传统复制切换(>=5.7.6支持在线切换)
    复制监控管理
        复制中断处理：1062(duplicate-key)、1032(no-key-found)、1677(data-type-convert)
        复制延迟排查：show slave statusG结果解读、判断复制是否有延迟、通过SQL_Thread定位执行的操作
        复制结构调整：增加/删减节点、提升/降低节点的角色
        Binlog Server：利用mysqlbinlog命令备份远程的Binlog
        数据一致性校验：主从数据为什么不一致、什么时间需要校验数据、pt-table-checksum、pt-table-sync
    其他
        Multi-Threaded Slave(>=5.6.3)：5.6基于库级别DATABASE，5.7.2支持库级别和事务级别LOGICAL_CLOCK
        Delayed Replication(>=5.7)：做误操作恢复、测试系统在存在滞后时的行为、检查很久以前数据库的状态
        Multi-Source Replication(>=5.7.6)：集中备份、数据分析聚合、分片数据合并
        Replication Filter：5.7.3开始可以动态更改从库的过滤规则

二、知其所以然

1、主从结构的瓶颈点是什么？
• sql_thread单线程
• 对于没有缓存热点数据的从库，大部分DML操作需从磁盘读数据到内存，更新后再刷新到磁盘，需要经过读磁盘、写undo、写redo、写binlog、写数据文件等过程
2、row格式下从库是如何应用主库上的更新？
• 有主键/非空唯一索引，只需匹配主键/非空唯一索引即可，其他列的数据是否一致不作校验
• 有其他二级索引，通过二级索引找到对应记录，然后匹配所有列是否与更新前主库上的列一致
• 没有索引，全表扫描匹配记录
因此，在没有主键/非空唯一索引的情况下，需要匹配所有的列来确定是否是同一条记录
3、为什么建议从库开启log_slave_updates？
• 从库开启log_bin(本身操作记录binlog)+log_slave_updates(复制操作记录binlog)，那么binlog会记录所有的操作，可以用其做备份，做级联复制的中间节点
• 如果从库没有开启log_slave_updates，从库应用relay-log中的每个事务会执行一个insert...mysql.gtid_executed操作；如果开启了log_bin，在binlog发生rotate(flush binary logs/达到max_binlog_size)或者关闭服务时，会把所有写入到binlog中的Gtid信息写入到mysql.gtid_executed表
4、半同步/增强半同步复制主从会不会存在延迟？
会。半同步/增强半同步复制只保证relay log在从库写入并刷盘，并不管sql_thread是否已应用relay log，因此会存在延迟现象。
5、show master status 从哪里读的数据？
show master status/show slave status中的Executed_Gtid_Set取自@@global.gtid_executed
扩展阅读：gtid_executed和gtid_purged变量是如何初始化的、为什么还原innobackupex备份后查看到的Executed_Gtid_Set与xtrabackup_binlog_info不一致
6、show slave status 从哪里读的数据？
show slave status从内存中读出来的。 如果slave_relay_log_info基于Innodb表，两者是一致的。如果基于非事务表，默认配置很有可能是不一致的。如果需要一致可以通过修改sync_relay_log_info=1
扩展阅读：FAQ: show slave status从哪里读的数据
7、sql_slave_skip_counter跳过一个事务？
sql_slave_skip_counter以event为单位skip，直到skip完第N个event所在的event group才停止。对于事务表，一个event group对应一个事务，一个事务可以包含多个DML操作；对于非事务表，一个event group对应一个DML操作。一个DML操作包含多个events。
对于1032、1062错误尽量修补数据，让复制进程在从库应用变更
扩展阅读：跳过复制错误——sql_slave_skip_counter
8、pt-table-checksum 3.0.4/3.0.9检测不出主从差异？
使用以往的pt-table-checksum参数选项，在主从不一致的情况下，检测不出差异。原以为工具有bug，却不曾发现工具提供对应的参数选项~.~
其实可以在命令行带上--set-vars binlog_format='statement'
扩展阅读：pt-table-checksum检测不出主从差异处理
9、relay-log获取数据
传统复制环境，slave在relay_log_recovery=1 && relay_log_purge=0的情况下
开启relay-log自动修复机制，发生crash时根据relay_log_info中记录的已执行的binlog位置从master上重新抓取回来再次应用，以此避免部分数据丢失的可能性
由于崩溃或停止MySQL时，SQL_Thread可能没有执行完全部的relay-log，最后一个relay-log中的一部分数据会被重新获取到新的relay-log文件中。当relay_log_purge=0时，旧relay-log不会被purge，也就是说，这部分数据重复存在于新旧relay-log。在MHA中，如果此实例选作Latest Slave，那么其他slave通过relay-log补偿差异数据时就可能会报错~
启用GTID复制模式，建议设置relay_log_recovery=0，从库使用GTID SET范围向主库请求binlog；未启用GTID复制模式，一定要设置relay_log_recovery=1，否则从库崩溃恢复后容易出现I/O线程找不到正确位置的问题
扩展阅读：MHA-Failover可能遇到的坑