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 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

二、知其所以然

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从哪里读的数据

一、复制框架

二、知其所以然

猜你喜欢