MySQL_16_主从复制
@
主从复制
主从复制：实现多台MySQL服务器之间数据同步
主从复制优点：
1）负载均衡：将读写分离，实现对读密集型应用的优化；
2）高可用性：可实现快速故障切换；
3）数据备份：提高数据安全性；
复制原理
主从复制的2个日志：
1）二进制日志（Binlog）：二进制方式记录数据库中每个操作；
2）中继日志（Relaylog）：Binlog在从库的暂储位；
//从库可设置参数以实现SQL线程执行事件后写入从库的二进制日志
主从复制的3个线程：
1）主库的二进制日志转储线程：将数据库二进制日志中事件记录到Binlog；
2）从库的I/O线程：连接主库，将Binlog复制到本地的Relaylog；
3）从库的SQL线程：根据Relaylog执行事件；
//I/O线程通过普通客户端方式连接主库，以唤醒二进制日志转储线程
主从复制流程：
1）主库通过二进制日志转储线程将数据库的二进制日志中事件记录到Binlog；
2）从库通过I/O线程将Binlog读取到本身的Relaylog；
3）从库的SQL线程读取Relaylog并执行；
//二进制日志通过事务的提交顺序记录（而非语句的执行顺序）
如：主从复制（一主一从）
//二进制日志转储进程读取所有二进制日志中的事件后会进入睡眠状态
//再次记录新事件时，主库会通过发送信号量以唤醒二进制转储线程
主从复制的4个文件：
（1）二进制日志文件名.index
1）功能：记录各个二进制日志文件路径（每行记录个）；
2）未被该文件记录的二进制日志文件，无法被MySQL识别；
//默认名为：mysql-bin.index
（2）中继日志文件名.index
1）功能：记录各个中继日志文件路径（每行记录个）；
2）未被该文件记录的中继日志文件，无法被MySQL识别；
//默认名为：mysql-relay-bin.index
（3）master.info
1）功能：以纯文本格式记录从库连接主库所需的信息；
2）该文件同时记录用于复制用户的密码（需注意其权限安全问题）；
（4）relay-log.info
1）功能：记录当前中继日志文件相较于Binlog的偏移量；
2）通过该文件I/O线程在断开后可继续正确复制；
配置复制
配置复制：通过配置文件和用户实现主从复制
（1）主从库创建用于复制的用户，并赋予权限
1）主库用户：备库用于连接；
2）备库用户：方便后期的故障转移；
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON 范围
TO 用户名 IDENTIFIED BY '密码';
//多赋予“REPLICATION CLIENT”权限是保证监控和管理复制；
（2）配置主库的配置文件（需重启服务）
1）必选配置参数
//必须是全局唯一
server_id=主库ID
//显示指定，避免其他因素导致复制失败（默认随主机名）
log_bin=Binlog存储路径
//默认值STATEMENT（基于语句），可指定为ROW（基于行）或MIXED（混合）
binlog_format=复制方式
//仅适用于二进制日志（Relaylog不可），默认值0
sync_binlog=是否每次提交事务前将二进制日志同步到磁盘
2）可选配置参数（常用）
//默认0，为读写（不能阻止拥有特殊权限的线程修改数据）
read-only=是否只读
//默认值6000，单位秒
binlog_expire_logs_seconds=Binlog的保留时长
//最大值和默认值均为1GB
max_binlog_size=单个Binlog的大小
binlog-ignore-db=不用于复制的库名
//默认全部数据库
binlog-do-db=用于复制的库名
（3）配置备库的配置文件（需重启服务）
1）必选配置参数
//必须是全局唯一
server_id=备库ID
relay_log=Relaylog存储路径
2）可选配置参数（常用）
//默认0，为读写（不能阻止拥有特殊权限的线程修改数据）
read-only=是否只读
//默认0（关闭），开启该该参数可使从库成为其他数据库的相对主库
log_slave_updates=是否将SQL线程执行事件记录到二进制日志
//建议与主库保持一致，以便故障转移
log_bin=Binlog存储路径
（4）备库指定主库（主要指定Binlog）
1）备库通过以下命令指定主库（也可用该命令修改Binlog）：
CHANGE MASTER TO MASTER_HOST='主库IP',
MASTER_USER='主库用户',
MASTER_PASSWORD='用户密码',
MASTER_LOG_FILE='Binlog路径',
//若指定日志偏移量为0，则代表从Binlog最初开始复制
MASTER_LOG_POS='日志偏移量';
（5）备库启动主从复制
1）备库通过以下命令启动主从复制：START SLAVE;
2）“STOP SLAVE”命令可停止主从复制，但停止后需重配置再开始主从复制
主从替换
1）停止主库上的所有写操作（最好关闭所有客户端）；
2）“FLUSH TABLES WITH READ LOCK”给所有表上锁；
3）关闭所有正在进行的事务（结束任何进行的写入）；
4）选择个备库作为主库（偏移量的最大值）；
5）新主库上执行“STOP SLVAE”命令；
6）新主库上执行“CHANGE MASTER TO MASTER_HOST= ' '”命令；
7）新主库上执行“RESET SLVAE”命令；
8）通过“SHOW MASTER STATUS”查看新主库的Binlog偏移量；
9）根据偏移量指向新主库；
10）确保从库的Binlog追赶上后，关闭旧主库并同时激活新主库事件；
11）将所有客户端连接转到新主库；
//偏移量计算公式：Master_Log_File/read_Master_Log_Pos
1）查看主从复制中主库状况：SHOW MASTER STATUS
2）查看主从复制中从库状态：SHOW SLAVE STATUS
3）删除指定Binlog文件：PURGE MASTER LOGS 二进制日志路径
4）删除所有Binlog和master.info，并断开和主库的连接：RESET SLAVE
复制方式
基于语句
基于语句复制（Statement-Based Replication，SBR）：再次执行主库的SQL
1）基于语句复制也称为逻辑复制
2）复制模式：STATEMENT
基于语句的优点：
1）实现简单，技术成熟；
2）Binlog文件小（无须记录每行的变化）；
3）Binlog可用于实时还原；
4）可兼容多个版本；
基于语句的缺点：
1）部分SQL无法被正确复制；
2）数据更新必须是串行的（持有较多锁）；
3）主从库的Schema需相同（存储引擎也需相同）；
4）存储过程和触发器存在无法复制问题；
使用以下函数的SQL语句，基于语句无法成功复制：
LOAD_FILE()、UUID()、USER()、FOUND_ROWS()、SYSDATE()
基于行
基于行复制（Row-Based Replication，RBR）：只记录更新后的数据
1）基于语句复制也称为物理复制
2）复制模式：ROW
//基于行整体上由于基于语句（适用于大多数场景）
基于行的优点：
1）可正确复制每行数据，且任何情况均可复制；
2）执行更新SQL语句时持有的锁较少；
3）复制数据块（拥有主键的更快）；
4）从库可执行多线程复制；
基于行的缺点：
1）Binlog文件较大（需记录每行更新数据）；
2）事务回滚时，Binlog中大量无效数据；
3）并发写的支持性较低；
混合
混合复制（Mixed-Based Replication，MBR）：动态调用基于语句和基于行
1）普通SQL默认使用基于语句，较复杂SQL则使用基于行
2）复制模式：MIXED
复制拓扑
复制拓扑：主从复制的多种实现方式
复制拓扑应遵顼以下基本原则：
1）主库可拥有多个从库；
2）从库只能拥有一个主库；
3）从库可成为其他数据库的相对主库；
2）每个从库都必须拥有全局唯一的库ID；
一主多从
一主多从：仅有一个主库，但主库拥有多个从库
1）适用场景：多读少写；
2）从库之间不能进行交互，且必须保证每个从库ID全局唯一；
双主单写
双主单写（双主复制）：互为对方的主从库，但仅有一个数据库可进行写操作
1）适用场景：频繁切换主从库（热备份）；
2）数据库配置和Schema需保持相同，但两个数据库的库ID需不同；
//SQL线程会丢弃Relaylog中事件记录的库ID和本身ID相同的事件
//也可设置为双主双写，但其弊大于利
分发主库
分发主库：使用专门用于分发Binlog文件的从库
1）适用场景：从库较多
2）分发主库使用Blackhole做存储引擎，同时不接受任何其他请求；
缺点：
1）无法使用从库代替主库（分发主库导致日志偏移量不同）；
树/金字塔
树/金字塔：多层主从库关系
1）适用场景：多读
2）中间层发送故障时，会导致多个数据库随之下线；
