1.主从复制故障分析：
1.1监控方法
show slave status \G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
1.2 IO线程
1.2.1正常状态：
Slave_IO_Running: Yes
1.2.2非正常状态:
Slave_IO_Running:
NO/Connecting
1.2.3故障原因：
连接主库:
(1)网络，防火墙，端口
(2)用户 密码 权限
replication slave
(3)主库连接数上限
mysql> select @@max_connections;
| @@max_connections |
| 151 |
请求日志，接收日志
(4)版本不统一 5.7 native 8.0 sha2
故障模拟:
主从中的线程管理:
start slave;
stop slave;
单独开启线程：
start slave sql_thread;#单独启动sql线程
start slave io_thread;#单独启动io线程
start stop sql_thread;#单独关闭sql线程
start stop io_thread;#单独关闭io线程
解除从库身份：
reset slave all;
故障模拟:change master 密码写错误
io线程连接connectioning状态
故障处理: 手工连接
直接用repl 用户进行登陆 看是否报错。
1.密码错误
2.连接数超过上限 too many connection
5）请求日志，接收日志
故障原因：
（1）主库二进制日志不完整,损坏，不连续
(2)从库请求的起点问题
（3）主从的server_id(server_uuid)相同
（4）relaylog 问题
模拟故障:
主库 reset master;清除了binlog.
生产中如果要 reset master ；
如果业务繁忙期间做，有可能会导致数据hang。
如果要恢复主从，需要重新搭建主从。
++++++++++++正确的姿势+++++++++++++++
1.找业务不繁忙期间，停业务5分钟。
2.等待从库重放完所有的主库日志
3.主库reset master;
4.从库重新同步主库日志
1)stop slave;
2)reset slave all;
3)change master to
......
......
4)start slave;
第三方工具 pt
1.3 SQL线程故障
1.3.1 主要做什么工作？
回放relay-log中的日志。可以理解为执行relay-log SQL:
1.3.2SQL线程故障本质？
为什么SQL线程执行不了SQL语句。
1.3.3原因整理。
创建的对象已经存在。
需要操作的对象不存在。
约束冲突。
SQL_MODE
参数,版本
以上问题：大几率出现在从库写入或者双主
结构中容易出现。
参数，版本
1.3.4 故障模拟
（1）从库创建oldguo数据库。
（2）主库创建oldguo数据库。
（3）检查从库slave状态
Slave_SQL_Running:No
从库报错，停止复制。
1.3.5 处理故障
（1）思路1:一切以主库为准
将从库进行反操作一下，重启线程。
从库:drop databases oldguo;
从库： start slave ;
(2)思路2:以从库为准,跳过此次复制错误
方法一：
stop slave;
set global sql_slave_skip_counter = 1;
start slave;
仅限于比较简易的操作环境。
第三方工具（后面实操）：帮助我们检查主从是否一致，并修复数据一致。
方法二：暴力方法，遇到自动跳过
/etc/my.cnf
slave-skip-errors=1032,1062,1007
常见错误代码：
1007：对象已存在
1032：无法执行DML
1062:主键冲突，或约束冲突
(3)思路3:
重新搭建主从，备份恢复+重新构建。
问题：
1.主库出了问题怎么办？
#物理
1.看主库是否能ssh上。
2.检查binlog是否完整。
3.手工追加日志到最新位置。
4.从库替代主库工作。
#逻辑 drop
只能通过备份去恢复
2.双主情况下，一个宕机，另一个也有问题。
只能备份+binlog恢复。
从库怎么当主库？
1.恢复最新状态
2.取消从库身份
3.清空binlog日志信息
扩展：
1.从库只读
select @@read_only; #普通用户只读
select @@super_read_only; #普通管理员只读
2.中间件(读写分离)
网友评论