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

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

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

1.1.1 涉及的线程

主库:DUMP THREAD从库:IO THREADSQL 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_T7. 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-log10.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.104Master_User: replMaster_Port: 3306Connect_Retry: 10Master_Log_File: mysql-bin.000011 # 获取到的最新的主库日志文件Read_Master_Log_Pos: 779 # 当前主库最新的position位置# 从库relay应用信息有关的(relay.info中的信息)Relay_Log_File: 192-relay-bin.000005Relay_Log_Pos: 992 # 上下两个表示relay_log的文件名和positionRelay_Master_Log_File: mysql-bin.000011 # 对应主库的文件名# 从库线程运行状态Slave_IO_Running: YesSlave_SQL_Running: YesLast_IO_Errno: 0Last_IO_Error: Last_SQL_Errno: 0Last_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: 0SQL_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 xxxxxxstart 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吗?)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

相关文章