MySQL 管理复制拓扑
本章主要讲复制故障转移、复制内部线程、复制监控手段，还有复制故障排查。
一、故障转移（重点）
主库故障之后，要挑选一个数据最新的从库升级成为新主库。
传统日志坐标方式：需要人工查找 binlog 文件和偏移坐标，操作麻烦，循环拓扑场景下很容易出错。
GTID 方式：故障转移更简单，直 接执行CHANGE MASTER TO，不用手动找日志位置，多主、循环拓扑也很好处理。
二、复制内部线程（重点）
1.主库 Binlog 转储线程（Dump 线程）：
每连接一个从库，主库就生成一个 dump 线程，把二进制日志事件发送给从库。GTID 自动定位模式下显示为 Binlog Dump GTID。
2.从属服务器线程：
I/O 线程：连接主库，接收主库传来的 binlog，写入本地中继日志。
SQL 线程：读取中继日志，把事件在本机执行，还原数据变更。
3.从库线程（单双线程）：
单线程从库：默认模式，只有 1 个 SQL 线程，串行执行中继日志里的事务，回放速度慢，容易产生复制延迟。
多线程（并行复制）从库：配置slave_parallel_workers开启，生成多个工作线程，可并发回放事务，加快同步速度。支持按库、逻辑时钟两种并行策略，也可以配置参数保证事务顺序。
4.并行复制（多线程复制 MTS）
默认从库是单线程执行中继日志。开启slave_parallel_workers，就会生成多个工作线程并发回放事务，提升从库同步速度。
有两种并行策略：按数据库并行、LOGICAL_CLOCK基于提交时间戳并行。还可以配置参数保证事务提交顺序。
5.控制和重置从属服务器
控制从库：可以整体启停复制START SLAVE、STOP SLAVE；也可以单独控制 I/O、SQL 线程。还支持START SLAVE UNTIL，让复制执行到指定日志 / GTID 就自动停下，方便故障处理。
重置从库：执行RESET SLAVE，清除从库保存的主库连接、日志坐标等复制信息，断开和旧主库关联，用来重新配置复制环境。
三、复制监控（重点）
核心命令SHOW SLAVE STATUS，是监控复制最主要手段。
1．关键字段：Slave_IO_Running、Slave_SQL_Running，两个都为 Yes 代表复制正常。
2．通过中继日志坐标、主库日志坐标，可以判断复制延迟。Seconds_Behind_Master用来查看从库同步延迟秒数。
3．Last_IO_Error、Last_SQL_Error可以查看 I/O、SQL 线程报错信息。
也可以通过performance_schema里复制相关表查看复制状态。
四、复制故障排查
1．先查看线程状态：show processlist观察 dump 线程、I/O 线程、SQL 线程运行情况。
2．看报错信息：读取错误日志，读取show slave status中的错误字段，定位是网络、权限、数据冲突还是配置问题。
3．常见故障：I/O 线程异常大多是网络、账号权限、server‑id 冲突；SQL 线程报错大多是数据不一致，从库数据被人为修改、主键冲突等。
4．排查时要确认所有实例server‑id互不相同，检查从库是否被手动修改过数据。
五、次要内容
重置从库RESET SLAVE相关操作，START SLAVE UNTIL条件停止复制属于实操细节。
整体：复制出问题优先看线程状态、报错信息；GTID 可以极大简化故障转移工作；开启并行复制可以缓解从库回放慢、复制延迟。