# 故障处理流程
1. 故障检测：
– 通过监控系统或手动检查发现复制故障
– 确认故障的类型和范围

2. 故障分析：
– 收集故障相关的日志和状态信息
– 分析故障的原因和影响

3. 故障处理：
– 根据故障类型选择合适的处理方法
– 执行故障处理操作

4. 故障验证：
– 验证故障是否已解决
– 检查复制状态是否正常

5. 故障记录：
– 记录故障的原因、处理方法和结果
– 总结经验教训，避免类似故障再次发生

# 故障处理的关键步骤
1. 确认故障类型：通过SHOW SLAVE STATUS命令查看复制状态，确认故障类型
2. 收集故障信息：收集MySQL错误日志、复制状态信息等
3. 分析故障原因：根据收集的信息分析故障原因
4. 选择处理方法：根据故障原因选择合适的处理方法
5. 执行处理操作：执行故障处理操作，如重启复制线程、跳过错误、重新初始化从库等
6. 验证处理结果：验证复制是否恢复正常，数据是否一致
7. 记录故障信息：记录故障的详细信息，为后续故障预防提供参考

# 故障处理的注意事项
1. 保持冷静：在处理故障时保持冷静，避免因紧张而做出错误的决策
2. 优先保障数据安全：在处理故障时，优先考虑数据的安全性，避免数据丢失
3. 最小化影响：在处理故障时，尽量减少对生产系统的影响
4. 记录详细信息：详细记录故障的原因、处理方法和结果，为后续故障处理提供参考
5. 及时通知相关人员：在处理故障时，及时通知相关人员，确保信息的及时传递
6. 验证处理结果：在处理故障后，务必验证处理结果，确保故障已完全解决
7. 总结经验教训：在故障处理完成后，总结经验教训，避免类似故障再次发生

# 故障演练
# 演练目标
1. 熟悉故障处理流程：通过演练，熟悉不同类型故障的处理流程
2. 提高故障处理能力：通过演练，提高运维人员的故障处理能力
3. 验证故障处理方案：通过演练，验证故障处理方案的有效性
4. 发现潜在问题：通过演练，发现系统中潜在的问题，及时进行优化

# 演练类型
1. IO线程故障演练：模拟IO线程连接失败的情况，练习处理方法
2. SQL线程故障演练：模拟SQL线程执行错误的情况，练习处理方法
3. 复制延迟演练：模拟复制延迟过大的情况，练习处理方法
4. 数据不一致演练：模拟主从数据不一致的情况，练习处理方法
5. 主库故障演练：模拟主库故障的情况，练习主从切换的流程

# 演练步骤
1. 制定演练计划：确定演练的类型、时间、参与人员和步骤
2. 准备演练环境：搭建测试环境，模拟生产环境的配置
3. 执行演练：按照演练计划执行故障模拟和处理
4. 记录演练过程：详细记录演练的过程、遇到的问题和处理方法
5. 总结演练结果：总结演练的结果，分析存在的问题，提出改进措施
6. 优化故障处理方案：根据演练结果，优化故障处理方案

# 演练频率
– 小型系统：每季度进行一次故障演练
– 中型系统：每月进行一次故障演练
– 大型系统：每两周进行一次故障演练

# 演练文档
1. 演练计划：包括演练的目标、类型、时间、参与人员和步骤
2. 演练脚本：包括故障模拟和处理的脚本
3. 演练记录：包括演练的过程、遇到的问题和处理方法
4. 演练总结：包括演练的结果、存在的问题和改进措施

# IO线程故障处理
# 步骤1：检查IO线程状态
mysql> SHOW SLAVE STATUS\G;

# 步骤2：分析IO线程故障原因
# 常见IO线程故障原因：
# 1. 网络连接中断
# 2. 主库binlog损坏
# 3. 复制用户权限不足
# 4. 主库关闭或重启
# 5. 主库binlog文件被删除

# 步骤3：处理IO线程故障
## 情况1：网络连接中断
# 检查网络连接
ping 192.168.1.100

# 检查主库状态
mysql -h 192.168.1.100 -u root -pPassword123! -e “SHOW GLOBAL STATUS LIKE ‘Uptime'”;

# 重启IO线程
mysql> STOP SLAVE IO_THREAD;
mysql> START SLAVE IO_THREAD;

## 情况2：复制用户权限不足
# 检查主库复制用户权限
mysql -h 192.168.1.100 -u root -pPassword123! -e “SHOW GRANTS FOR ‘repl’@’192.168.1.101′”;

# 重新授权
mysql -h 192.168.1.100 -u root -pPassword123! -e “GRANT REPLICATION SLAVE ON *.* TO ‘repl’@’192.168.1.101’ IDENTIFIED BY ‘ReplPassword123!'”;
mysql -h 192.168.1.100 -u root -pPassword123! -e “FLUSH PRIVILEGES”;

# 重启IO线程
mysql> STOP SLAVE IO_THREAD;
mysql> START SLAVE IO_THREAD;

## 情况3：主库binlog损坏
# 检查主库binlog状态
mysql -h 192.168.1.100 -u root -pPassword123! -e “SHOW BINARY LOGS”;

# 查看主库错误日志
cat /mysql/data/error.log

# 重新初始化从库
# 在主库上创建新的备份
mysqldump -h 192.168.1.100 -u root -pPassword123! –single-transaction –master-data=2 –all-databases > full_backup.sql

# 在从库上恢复备份
mysql -h 192.168.1.101 -u root -pPassword123! < full_backup.sql # 重新配置复制 mysql -h 192.168.1.101 -u root -pPassword123! -e "CHANGE MASTER TO MASTER_HOST='192.168.1.100', MASTER_USER='repl', MASTER_PASSWORD='ReplPassword123!', MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=107;" mysql -h 192.168.1.101 -u root -pPassword123! -e "START SLAVE"; # 步骤4：验证IO线程状态 mysql> SHOW SLAVE STATUS\G | grep Slave_IO_Running;

# 预期输出：
# Slave_IO_Running: Yes

# SQL线程故障处理
# 步骤1：检查SQL线程状态
mysql> SHOW SLAVE STATUS\G;

# 步骤2：分析SQL线程故障原因
# 常见SQL线程故障原因：
# 1. 主键冲突
# 2. 表不存在
# 3. 权限不足
# 4. SQL语法错误
# 5. 数据类型不兼容

# 步骤3：处理SQL线程故障
## 情况1：主键冲突
# 查看错误信息
mysql> SHOW SLAVE STATUS\G | grep Last_SQL_Error;

# 跳过错误
mysql> STOP SLAVE SQL_THREAD;
mysql> SET GLOBAL sql_slave_skip_counter = 1;
mysql> START SLAVE SQL_THREAD;

# 或者使用pt-slave-restart工具跳过错误
pt-slave-restart –user=root –password=Password123! –socket=/mysql/data/mysql.sock

## 情况2：表不存在
# 查看错误信息
mysql> SHOW SLAVE STATUS\G | grep Last_SQL_Error;

# 在从库上创建缺失的表
# 从主库导出表结构
mysqldump -h 192.168.1.100 -u root -pPassword123! –no-data testdb test_table > table_structure.sql

# 在从库上导入表结构
mysql -h 192.168.1.101 -u root -pPassword123! < table_structure.sql # 重启SQL线程 mysql> START SLAVE SQL_THREAD;

## 情况3：权限不足
# 查看错误信息
mysql> SHOW SLAVE STATUS\G | grep Last_SQL_Error;

# 检查从库用户权限
mysql> SHOW GRANTS FOR ‘mysql.session’@’localhost’;

# 修复权限
mysql> GRANT ALL PRIVILEGES ON *.* TO ‘mysql.session’@’localhost’ WITH GRANT OPTION;
mysql> FLUSH PRIVILEGES;

# 重启SQL线程
mysql> START SLAVE SQL_THREAD;

# 步骤4：验证SQL线程状态
mysql> SHOW SLAVE STATUS\G | grep Slave_SQL_Running;

# 预期输出：
# Slave_SQL_Running: Yes

# 复制延迟故障处理
# 步骤1：检查复制延迟
mysql> SHOW SLAVE STATUS\G | grep Seconds_Behind_Master;

# 步骤2：分析复制延迟原因
# 常见复制延迟原因：
# 1. 主库写入量大
# 2. 从库性能不足
# 3. 网络延迟
# 4. 从库SQL线程执行缓慢
# 5. 大事务

# 步骤3：处理复制延迟故障
## 情况1：主库写入量大
# 优化主库写入
# 1. 优化SQL语句
# 2. 增加主库硬件资源
# 3. 分片处理

# 情况2：从库性能不足
# 提升从库性能
# 1. 增加从库硬件资源
# 2. 优化从库配置
# 3. 启用并行复制

# 启用并行复制
mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_DELAY=0;
mysql> SET GLOBAL slave_parallel_type = ‘LOGICAL_CLOCK’;
mysql> SET GLOBAL slave_parallel_workers = 4;
mysql> START SLAVE;

# 情况3：网络延迟
# 优化网络
# 1. 使用专用网络
# 2. 增加网络带宽
# 3. 减少网络跳数

# 情况4：从库SQL线程执行缓慢
# 优化从库SQL执行
# 1. 优化从库配置
# 2. 清理从库日志
# 3. 检查从库锁等待

# 查看从库锁等待
mysql> SHOW PROCESSLIST;

# 情况5：大事务
# 优化大事务
# 1. 分解大事务
# 2. 减少事务持有的锁时间
# 3. 优化事务中的SQL语句

# 步骤4：验证复制延迟
mysql> SHOW SLAVE STATUS\G | grep Seconds_Behind_Master;

# 预期输出：
# Seconds_Behind_Master: 0

# 复制冲突故障处理
# 步骤1：检查复制冲突
mysql> SHOW SLAVE STATUS\G | grep Last_SQL_Error;

# 步骤2：分析复制冲突原因
# 常见复制冲突原因：
# 1. 从库误操作：在从库上执行写操作
# 2. 主库和从库数据不一致：初始数据同步不完整
# 3. 复制错误未及时处理：导致数据累积不一致
# 4. 多源复制冲突：多个主库向同一个从库复制数据

# 步骤3：处理复制冲突故障
## 情况1：从库误操作
# 停止复制
mysql> STOP SLAVE;

# 恢复从库数据
# 方法1：使用主库备份恢复
mysqldump -h 192.168.1.100 -u root -pPassword123! –single-transaction –master-data=2 –all-databases > full_backup.sql
mysql -h 192.168.1.101 -u root -pPassword123! < full_backup.sql # 方法2：使用pt-table-sync工具同步数据 pt-table-sync --execute --verbose --host=192.168.1.100 --user=root --password=Password123! --databases=testdb h=192.168.1.101,u=root,p=Password123! # 重新配置复制 mysql> CHANGE MASTER TO MASTER_HOST=’192.168.1.100′, MASTER_USER=’repl’, MASTER_PASSWORD=’ReplPassword123!’, MASTER_LOG_FILE=’binlog.000001′, MASTER_LOG_POS=107;
mysql> START SLAVE;

## 情况2：主库和从库数据不一致
# 使用pt-table-checksum工具检查数据一致性
pt-table-checksum –host=192.168.1.100 –user=root –password=Password123! –databases=testdb

# 使用pt-table-sync工具同步数据
pt-table-sync –execute –verbose –host=192.168.1.100 –user=root –password=Password123! –databases=testdb h=192.168.1.101,u=root,p=Password123!

# 步骤4：验证复制状态
mysql> SHOW SLAVE STATUS\G | grep Slave_SQL_Running;

# 预期输出：
# Slave_SQL_Running: Yes

# 步骤5：预防复制冲突
# 1. 严格控制从库的写权限
# 2. 启用GTID复制
# 3. 定期检查数据一致性
# 4. 及时处理复制错误

# IO线程连接失败处理案例
# 故障现象
mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Connecting to master
Master_Host: 192.168.1.100
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000001
Read_Master_Log_Pos: 107
Relay_Log_File: relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: binlog.000001
Slave_IO_Running: Connecting
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 107
Relay_Log_Space: 154
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 2003
Last_IO_Error: error connecting to master ‘repl@192.168.1.100:3306’ – retry-time: 60 retries: 1
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 0
Master_UUID:
Master_Info_File: /mysql/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp: 230401 10:00:00
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:

# 故障分析
1. 从错误信息可以看到，IO线程无法连接到主库，错误码为2003
2. 可能的原因：网络连接中断、主库关闭、复制用户权限不足

# 故障处理
## 步骤1：检查网络连接
$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.500 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=0.450 ms

# 网络连接正常

## 步骤2：检查主库状态
$ mysql -h 192.168.1.100 -u root -pPassword123! -e “SHOW GLOBAL STATUS LIKE ‘Uptime'”;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| Uptime | 3600 |
+—————+——-+

# 主库运行正常

## 步骤3：检查复制用户权限
$ mysql -h 192.168.1.100 -u root -pPassword123! -e “SHOW GRANTS FOR ‘repl’@’192.168.1.101′”;
+————————————————-+
| Grants for repl@192.168.1.101 |
+————————————————-+
| GRANT REPLICATION SLAVE ON *.* TO ‘repl’@’192.168.1.101’ |
+————————————————-+

# 复制用户权限正常

## 步骤4：检查主库防火墙
$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306

# 防火墙允许3306端口

## 步骤5：检查主库max_connections
$ mysql -h 192.168.1.100 -u root -pPassword123! -e “SHOW GLOBAL VARIABLES LIKE ‘max_connections'”;
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| max_connections | 151 |
+—————–+——-+

$ mysql -h 192.168.1.100 -u root -pPassword123! -e “SHOW GLOBAL STATUS LIKE ‘Threads_connected'”;
+——————-+——-+
| Variable_name | Value |
+——————-+——-+
| Threads_connected | 100 |

# 连接数未达到上限

## 步骤6：检查从库配置
$ cat /mysql/data/my.cnf | grep server-id
server-id = 2

$ mysql -h 192.168.1.100 -u root -pPassword123! -e “SHOW GLOBAL VARIABLES LIKE ‘server_id'”;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| server_id | 1 |

# server-id配置正确

## 步骤7：重启IO线程
mysql> STOP SLAVE IO_THREAD;
mysql> START SLAVE IO_THREAD;

## 步骤8：验证IO线程状态
mysql> SHOW SLAVE STATUS\G | grep Slave_IO_Running;
Slave_IO_Running: Yes

# 故障解决

# SQL线程执行错误处理案例
# 故障现象
mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.100
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000001
Read_Master_Log_Pos: 2000
Relay_Log_File: relay-bin.000001
Relay_Log_Pos: 1500
Relay_Master_Log_File: binlog.000001
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1062
Last_Error: Error ‘Duplicate entry ‘1’ for key ‘PRIMARY” on query. Default database: ‘testdb’. Query: ‘INSERT INTO test_table (id, data) VALUES (1, ‘test’)’
Skip_Counter: 0
Exec_Master_Log_Pos: 1800
Relay_Log_Space: 2000
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1062
Last_SQL_Error: Error ‘Duplicate entry ‘1’ for key ‘PRIMARY” on query. Default database: ‘testdb’. Query: ‘INSERT INTO test_table (id, data) VALUES (1, ‘test’)’
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID:
Master_Info_File: /mysql/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 230401 10:30:00
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:

# 故障分析
1. 从错误信息可以看到，SQL线程执行错误，错误码为1062，错误信息为”Duplicate entry ‘1’ for key ‘PRIMARY'”
2. 原因是从库上已经存在id为1的记录，而主库又插入了一条id为1的记录，导致主键冲突

# 故障处理
## 步骤1：查看从库数据
mysql> USE testdb;
mysql> SELECT * FROM test_table;
+—-+——+
| id | data |
+—-+——+
| 1 | test |
+—-+——+

# 从库上已经存在id为1的记录

## 步骤2：查看主库数据
mysql> USE testdb;
mysql> SELECT * FROM test_table;
+—-+——+
| id | data |
+—-+——+
| 1 | test |
| 2 | test2 |
+—-+——+

# 主库上有id为1和id为2的记录

## 步骤3：跳过错误
mysql> STOP SLAVE SQL_THREAD;
mysql> SET GLOBAL sql_slave_skip_counter = 1;
mysql> START SLAVE SQL_THREAD;

## 步骤4：验证SQL线程状态
mysql> SHOW SLAVE STATUS\G | grep Slave_SQL_Running;
Slave_SQL_Running: Yes

## 步骤5：验证数据一致性
mysql> USE testdb;
mysql> SELECT * FROM test_table;
+—-+——+
| id | data |
+—-+——+
| 1 | test |
| 2 | test2 |
+—-+——+

# 数据一致，故障解决

# 复制延迟过大处理案例
# 故障现象
mysql> SHOW SLAVE STATUS\G | grep Seconds_Behind_Master;
Seconds_Behind_Master: 3600

# 故障分析
1. 从库落后主库3600秒，即1小时
2. 可能的原因：主库写入量大、从库性能不足、网络延迟、大事务

# 故障处理
## 步骤1：检查主库写入量
mysql> SHOW GLOBAL STATUS LIKE ‘Com_insert’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| Com_insert | 10000 |
+—————+——-+

mysql> SHOW GLOBAL STATUS LIKE ‘Com_update’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| Com_update | 5000 |
+—————+——-+

mysql> SHOW GLOBAL STATUS LIKE ‘Com_delete’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| Com_delete | 1000 |
+—————+——-+

# 主库写入量较大

## 步骤2：检查从库性能
# 检查从库CPU使用率
top

# 检查从库内存使用率
free -h

# 检查从库磁盘IO
iostat -x

# 从库性能不足

## 步骤3：启用并行复制
mysql> STOP SLAVE;
mysql> SET GLOBAL slave_parallel_type = ‘LOGICAL_CLOCK’;
mysql> SET GLOBAL slave_parallel_workers = 4;
mysql> START SLAVE;

## 步骤4：优化从库配置
# vi /mysql/data/my.cnf
[mysqld]
innodb_buffer_pool_size = 4G
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 2
sync_binlog = 0

# 重启MySQL
systemctl restart mysqld

## 步骤5：检查复制延迟
mysql> SHOW SLAVE STATUS\G | grep Seconds_Behind_Master;
Seconds_Behind_Master: 1800

# 复制延迟减少到1800秒

## 步骤6：增加从库硬件资源
# 增加从库CPU和内存
# 更换从库磁盘为SSD

## 步骤7：再次检查复制延迟
mysql> SHOW SLAVE STATUS\G | grep Seconds_Behind_Master;
Seconds_Behind_Master: 0

# 复制延迟恢复正常，故障解决

# 主从数据不一致处理案例
# 故障现象
# 使用pt-table-checksum工具检查数据一致性
$ pt-table-checksum –host=192.168.1.100 –user=root –password=Password123! –databases=testdb
TS ERRORS DIFFS ROWS CHUNKS SKIPPED TIME TABLE
04-01T11:00:00 0 1 10 1 0 0.010 testdb.test_table

# 故障分析
1. 从检查结果可以看到，testdb.test_table表存在数据不一致
2. 可能的原因：从库误操作、复制错误未及时处理、初始数据同步不完整

# 故障处理
## 步骤1：使用pt-table-sync工具同步数据
$ pt-table-sync –execute –verbose –host=192.168.1.100 –user=root –password=Password123! –databases=testdb h=192.168.1.101,u=root,p=Password123!

# 输出示例：
# Syncing h=192.168.1.101,u=root,p=…,P=3306
# DELETE FROM `testdb`.`test_table` WHERE `id`=’5′
# INSERT INTO `testdb`.`test_table` (`id`, `data`) VALUES (‘5’, ‘test5’)

## 步骤2：验证数据一致性
$ pt-table-checksum –host=192.168.1.100 –user=root –password=Password123! –databases=testdb
TS ERRORS DIFFS ROWS CHUNKS SKIPPED TIME TABLE
04-01T11:10:00 0 0 10 1 0 0.010 testdb.test_table

# 数据一致，故障解决

## 步骤3：预防主从数据不一致
1. 严格控制从库的写权限
2. 启用GTID复制
3. 定期使用pt-table-checksum工具检查数据一致性
4. 及时处理复制错误
5. 定期备份主库和从库数据