主从复制原理描述:
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会有自动清理的功能。(relay_log_purge=ON,定期删除应用过的relay-log)
复制
1、主库分析检查
show full processlist;
每个从库都会有一行dump相关的信息
HOSTS:
localhost:59946
State:
Master has sent all binlog to slave; waiting for more updates
如果现实非以上信息,说明主从之间的关系出现了问题
复制
从库:
show slave status \G
主库相关信息监控
Master_Host: 127.0.0.1
Master_User: repl
Master_Port: 3306
Master_Log_File: mysql-bin.000022
Read_Master_Log_Pos: 120
从库中继日志的应用状态
Relay_Log_File: 192-relay-bin.000061
Relay_Log_Pos: 282
从库复制线程有关的状态
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
主从复制故障分析
一、IO故障
1、连接主库
(1) 用户 密码 IP port
Last_IO_Error: error reconnecting to master 'repl@127.0.0.1:3307' - retry-time: 10 retries: 7
[root@db01 ~]# mysql -urepl -p123333 -h 127.0.0.1 -P 3307
ERROR 1045 (28000): Access denied for user 'repl'@'password' (using password: YES)
原因:
密码错误
用户错误
skip_name_resolve
地址错误
端口
复制
2、主库连接数上线,或者是主库太繁忙
show slave staus \G
Last_IO_Errno: 1040
Last_IO_Error: error reconnecting to master 'repl@127.0.0.1:3307' - retry-time: 10 retries: 7
处理思路:
拿复制用户,手工连接一下
[root@db1 ~]# mysql -urepl -p123 -h 127.0.0.1-P 3307
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1040 (HY000): Too many connections
处理方法:
set global max_connections=300;
(3) 防火墙,网络不通
复制
3、请求二进制日志
主库缺失日志
从库方面,二进制日志位置点不对
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'could not find next log; the first event 'mysql-bin.000001' at 154, the last event read from '/data/3307/data/mysql-bin.000002' at 154, the last byte read from '/data/3307/data/mysql-bin.000002' at 154.'
注意: 在主从复制环境中,严令禁止主库中reset master; 可以选择expire 进行定期清理主库二进制日志
解决方案:
重新构建主从
复制
二、SQL 线程故障
1、SQL线程功能
(1)读写relay-log.info
(2)relay-log损坏,断节,找不到
(3)接收到的SQL无法执行
复制
2、导致SQL线程故障原因分析
1. 版本差异,参数设定不同,比如:数据类型的差异,SQL_MODE影响
2.要创建的数据库对象,已经存在
3.要删除或修改的对象不存在
4.DML语句不符合表定义及约束时.
归根揭底的原因都是由于从库发生了写入操作.
Last_SQL_Error: Error 'Can't create database 'db'; database exists' on query. Default database: 'db'. Query: 'create database db'
复制
3、处理方法(以从库为核心的处理方案)
方法一:
stop slave;
set global sql_slave_skip_counter = 1;#将同步指针向下移动一个,如果多次不同步,可以重复操作。
start slave;
方法二:
/etc/my.cnf
slave-skip-errors = 1032,1062,1007
常见错误代码:
1007:数据库已存在,创建数据库失败
1008:数据库不存在,删除数据库失败
1032:无法执行DML
1049:数据库不存在
1050:数据表已存在
1051:数据表不存在
1062:主键冲突,或约束冲突
但是,以上操作有时是有风险的,最安全的做法就是重新构建主从。把握一个原则,一切以主库为主.
复制
mysql> stop slave;
Query OK, 0 rows affected (0.06 sec)
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;Query OK, 0 rows affected (0.00 sec)
mysql> start slave;Query OK, 0 rows affected (0.01 sec)
复制
主从搭建--->>MySQL主从复制
文章转载自VFrog,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。
评论
相关阅读
【MySQL 30周年庆】MySQL 8.0 OCP考试限时免费!教你免费领考券
墨天轮小教习
3037次阅读
2025-04-25 18:53:11
MySQL 30 周年庆!MySQL 8.4 认证免费考!这次是认真的。。。
严少安
862次阅读
2025-04-25 15:30:58
【活动】分享你的压箱底干货文档,三篇解锁进阶奖励!
墨天轮编辑部
503次阅读
2025-04-17 17:02:24
MySQL 9.3 正式 GA,我却大失所望,新特性亮点与隐忧并存?
JiekeXu
439次阅读
2025-04-15 23:49:58
3月“墨力原创作者计划”获奖名单公布
墨天轮编辑部
377次阅读
2025-04-15 14:48:05
MySQL 8.0 OCP 1Z0-908 考试解析指南(二)
JiekeXu
309次阅读
2025-04-30 17:37:37
SQL优化 - explain查看SQL执行计划(下)
金同学
285次阅读
2025-05-06 14:40:00
记录MySQL数据库的一些奇怪的迁移需求!
陈举超
283次阅读
2025-04-15 15:27:53
MySQL 8.0 OCP 1Z0-908 考试题解析指南
青年数据库学习互助会
266次阅读
2025-04-30 12:17:54
MySQL 30 周年庆!MySQL 8.4 认证免费考!这次是认真的。。。
数据库运维之道
266次阅读
2025-04-28 11:01:25