MySQL主从复制

主从复制介绍：

基于binlog实现，主库发生新的操作，会记录binlog，从库获取主库的binlog进行回放，异步

搭建主从复制：

步骤：
主库开启binlog
主库建立专用的复制用户（replication slave）
从库先根据主库的备份恢复数据到一个节点
从库配置主库信息（ip、port、user、password、binlog起始位置）
从库开启复制线程，请求主库的binlog

（1）主库开启binlog
（2）server_id配置不同
（3）主库创建复制用户
grant replication slave on . to replication@’%’ identified by ‘123’;
（4）从库恢复主库备份数据：
主库备份：
mysqldump -S /data/3307/mysql.sock -A --master-data=2 --single-transaction -R -E --triggers > /tmp/full.sql
从库恢复数据：
set sql_log_bin=0;
source /tmp/full.sql;
（5）从库配置信息：
CHANGE MASTER TO
MASTER_HOST=‘172.17.0.8’,
MASTER_USER=‘replication’,
MASTER_PASSWORD=‘replication’,
MASTER_PORT=3306,
MASTER_LOG_FILE=‘binlog.000001’,
MASTER_LOG_POS=154,
MASTER_CONNECT_RETRY=10;

（6）开启复制线程（IO、SQL）
start slave;
（7）检查
show slave status\G;

主从原理：

（1）主从复制涉及的文件
主库：
binlog
从库：
master.info
relay-log 中继日志
relay-log.info

（2）主从复制涉及的线程
主库：
Binlog Dump
从库：
Slave_IO
Slave_SQL

（3）流程：
1、change master to 将主库信息（连接信息+复制起点）写入master.info文件
2、start slave 从库开启 SLAVE_IO、SLAVE_SQL 两个线程
3、IO线程连接主库，主库为从库生成一个Binlog Dump线程
4、IO线程根据binlog位置信息，请求主库的binlog，主库返回给从库新的binlog，从库接收到，更新master.info，并且写磁盘relay-log中。
5、SQL线程读取relay-log.info中的信息，获取到上次执行的relay-log偏移量，然后去relay-log中取对应的binlog进行回放，然后更新relay-log.info中的偏移量。
6、从库会定期清理回放过的relay-log
7、主库有更改，主库通过 Dump 线程发送一个signal通知从库

主从故障处理：

show slave status\G;

主库有关信息（master.info）：
Master_Host: 172.17.0.8
Master_User: replication
Master_Port: 3307
Connect_Retry: 10
Master_Log_File: binlog.000002
Read_Master_Log_Pos: 742

从库relay信息（relay-log.info）：
Relay_Log_File: VM-0-8-centos-relay-bin.000002
Relay_Log_Pos: 575
Relay_Master_Log_File: binlog.000002

从库线程运行状态：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:

过滤复制有关信息：
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:

从库延时主库的时间（被动）：
Seconds_Behind_Master: 0

延时从库配置（主动）：
SQL_Delay: 0
SQL_Remaining_Delay: NULL

GTID复制有关的信息：
Retrieved_Gtid_Set: 04799761-42a1-11eb-8833-525400aa6b19:4
Executed_Gtid_Set: 04799761-42a1-11eb-8833-525400aa6b19:1-4
Auto_Position: 0

主从延时：

（1）主库原因：
1、binlog写入不及时
sync_binlog=1
2、默认情况下，Dump线程是串行传输binlog，并发事物量大，传输慢
解决方案：
使用gtid，使用group commit的方式
3、主库特别繁忙
慢语句
锁等待
从库个数
网络延时

（2）从库原因：
1、传统复制中，如果主库并发事物量大，由于从库是单SQL线程处理relay-log，串行处理很慢。
5.6版本中，有了gtid，实现了多SQL线程处理relay-log，但是只支持不同库进行并发回放。
5.7版本中，增强了gtid，增加了seq_no，增加了新型并发SQL线程模式（logical _clock），MTS技术
2、主从硬件、配置参数不一样
3、主从索引不一样

主从架构演变：

1、延时从库
作用：应对逻辑删库或者物理删除数据
原理：IO线程不变，SQL线程延时执行
配置：
stop slave;
CHANGE MASTER TO
MASTER_DELAY = 300;
start slave;

2、过滤复制

3、gtid复制
主：grant replication slave on . to replication@’%’ identified by ‘123’;
从：
CHANGE MASTER TO
MASTER_HOST=‘172.17.0.8’,
MASTER_USER=‘replication’,
MASTER_PASSWORD=‘replication’,
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1;
start slave;

4、半同步
解决主从复制安全问题，性能太差，不用，原理同tcp的ack机制，相当于分布式事务。