码迷,mamicode.com
首页 > 数据库 > 详细

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

时间:2020-05-19 09:11:34      阅读:74      评论:0      收藏:0      [点我收藏+]

标签:二进制文件   端口   log文件   概率   set   state   global   xxx   响应   

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

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.1 排查主库binlog请求不到异常

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

标签:二进制文件   端口   log文件   概率   set   state   global   xxx   响应   

原文地址:https://www.cnblogs.com/quzq/p/12907895.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!