MySQL复制框架

1、复制框架

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

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 status\G结果解读、判断复制是否有延迟、经过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开始能够动态更改从库的过滤规则

View Code

2、知其因此然

一、主从结构的瓶颈点是什么？
• sql_thread单线程
• 对于没有缓存热点数据的从库，大部分DML操做需从磁盘读数据到内存，更新后再刷新到磁盘，须要通过读磁盘、写undo、写redo、写binlog、写数据文件等过程
二、row格式下从库是如何应用主库上的更新？
• 有主键/非空惟一索引，只需匹配主键/非空惟一索引便可，其余列的数据是否一致不做校验
• 有其余二级索引，经过二级索引找到对应记录，而后匹配全部列是否与更新前主库上的列一致
• 没有索引，全表扫描匹配记录
所以，在没有主键/非空惟一索引的状况下，须要匹配全部的列来肯定是不是同一条记录
三、为何建议从库开启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表
四、半同步/加强半同步复制主从会不会存在延迟？
会。半同步/加强半同步复制只保证relay log在从库写入并刷盘，并无论sql_thread是否已应用relay log，所以会存在延迟现象。
五、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不一致
六、show slave status 从哪里读的数据？
show slave status从内存中读出来的。 若是slave_relay_log_info基于Innodb表，二者是一致的。若是基于非事务表，默认配置颇有多是不一致的。若是须要一致能够经过修改sync_relay_log_info=1
扩展阅读：FAQ: show slave status从哪里读的数据
七、sql_slave_skip_counter跳过一个事务？
sql_slave_skip_counter以event为单位skip，直到skip完第N个event所在的event group才中止。对于事务表，一个event group对应一个事务，一个事务能够包含多个DML操做；对于非事务表，一个event group对应一个DML操做。一个DML操做包含多个events。
对于103二、1062错误尽可能修补数据，让复制进程在从库应用变动
扩展阅读：跳过复制错误——sql_slave_skip_counter
八、pt-table-checksum 3.0.4/3.0.9检测不出主从差别？
使用以往的pt-table-checksum参数选项，在主从不一致的状况下，检测不出差别。原觉得工具备bug，却未曾发现工具提供对应的参数选项~.~
其实能够在命令行带上--set-vars binlog_format='statement'
扩展阅读：pt-table-checksum检测不出主从差别处理