mysql 主从复制原理，概念，故障的检控/分析/处理

Posted 2021-02-18 叶落kiss

1. 主从复制的原理 (Classic Replication)

1.1 主从中涉及到的文件和线程

1.1.1 涉及的线程

主库:
DUMP THREAD
从库:
IO  THREAD
SQL THREAD

1.1.2 涉及的文件

主库:
mysql-bin.000001　　　　=====》主库的二进制文件

从库: 
db01-relay.000001           ===》中继日志
master.info                 ===》主库信息记录日志
relay-log.info              ===> 记录中继应用情况信息

1.2 主从复制原理

 

 

 

 

 

 主从复制原理描述：

1.change master to 时，ip pot user password binlog position写入到master.info进行记录
2. start slave 时，从库会启动IO线程和SQL线程
3.IO_T，读取master.info信息，获取主库信息连接主库
4. 主库会生成一个准备binlog DUMP线程，来响应从库
5. IO_T根据master.info记录的binlog文件名和position号，请求主库DUMP最新日志
6. DUMP线程检查主库的binlog日志，如果有新的，TP(传送)给从从库的IO_T
7. IO_T将收到的日志存储到了TCP/IP 缓存，立即返回ACK给主库 ，主库工作完成
8.IO_T将缓存中的数据，存储到relay-log日志文件,更新master.info文件binlog 文件名和postion，IO_T工作完成
9.SQL_T读取relay-log.info文件，获取到上次执行到的relay-log的位置，作为起点，回放relay-log
10.SQL_T回放完成之后，会更新relay-log.info文件。
11. relay-log会有自动清理的功能。
细节：
1.主库一旦有新的日志生成，会发送“信号”给binlog dump ，IO线程再请求

2. 主从故障监控\\分析\\处理 *****

2.1 从库查看到的主从信息整理

mysql> show slave status \\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
# 主库的相关信息(master.info中的信息)
Master_Host: 192.168.0.104
Master_User: repl
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: mysql-bin.000011    # 获取到的最新的主库日志文件
Read_Master_Log_Pos: 779            # 当前主库最新的position位置

# 从库relay应用信息有关的(relay.info中的信息)
Relay_Log_File: 192-relay-bin.000005
Relay_Log_Pos: 992                        # 上下两个表示relay_log的文件名和position
Relay_Master_Log_File: mysql-bin.000011    # 对应主库的文件名

# 从库线程运行状态
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: 
Executed_Gtid_Set: 
Auto_Position: 0

2.2 故障排查思路

主从复制的核心就是从库的两个线程（io和sql）加上主库的dump线程，而dump线程又是主库自动开启的，出问题的概率不大。

从库线程之io线程解析：
io线程的工作职责：
　　1. 连接主库
　　2. 请求主库的binlog
　　3. 存储请求到的binlog
从库线程之sql线程解析:
sql线程工作职责:
　　1. 读取并执行relaylog中的日志
　　2. 更新relay-info中的信息

2.2.1 排查连接异常思路

手动使用复制账户连接主库，核对账户，密码，ip，端口等配置信息是否正确，如果是这些信息异常导致的，则按照以下步骤到从库重新设置。
核对防火墙的影响。

stop  slave  
reset slave all 
change master to xxxxxx
start slave

如果是因为数据库最大链接数满了引起的连接异常，可手动增大最大连接数限制

[root@db01 ~]# mysql -urepl -p123 -h 10.0.0.51 -P 3307 
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1040 (HY000): Too many connections
处理方法:
db01 [(none)]>set global max_connections=300;

2.2.2 排查主库binlog请求不到异常

1. 确认主从binlog是否开启
2. 确认从库配置的二进制日志文件是否存在
3. 针对主库做过重置二进制文件序号的命令(即主库执行了：reset master)解决办法？
　　分析，之所以同步失败，是因为主库重置了二进制序号，而该操作不会被从库同步到，所以导致从库中储存的二进制文件和position号无效。
　　主库执行：show binlog events in \'xxxxx.000001\';找到最开始的position号，从新配置从库的同步信息即可。
　　(reset master后刷出来的新二进制文件，开始的position号一定是154吗？)

2.2.3 排查sql线程异常:

1. relay-log文件找不到了. 重新构建主从
2. 报各种从库的对象存在,违反了约束等,虽然不大可能出现. 处理掉从库中异常提示中的问题.
3. 一切以主库为主.
不建议的操作如下:

方法一：
stop slave; 
set global sql_slave_skip_counter = 1;
#将同步指针向下移动一个，如果多次不同步，可以重复操作。
start slave;
方法二：
从库配置文件中添加跳过配置,出现以下异常时自动跳过
slave-skip-errors = 1032,1062,1007
常见错误代码:
1007:对象已存在
1032:无法执行DML
1062:主键冲突,或约束冲突

但是，以上操作有时是有风险的，最安全的做法就是重新构建主从。把握一个原则,一切以主库为主.

，以上操作有时是有风险的，最安全的做法就是重新构建主从。把握一个原则,一切以主库为主.

一劳永逸的方法:

(1) 可以设置从库只读.
db01 [(none)]>show variables like \'%read_only%\';
注意：
只会影响到普通用户，对管理员用户无效。
read_only　　# 用来控制普通用户只读
supper_read_only　　# 用来控制所有用户含root只读;

(2)加中间件
读写分离。
atlas
mycat
proxySQL
maxscale