MySQL 主从结构停库后重启操作及常见错误处理方法
一、MySQL 主从结构停库及重启
1、停库前准备（如果计划停库）
如果是计划性停库，建议事先做以下操作：
1.1 暂停从库复制
STOP SLAVE;
1.2 记录主库的当前二进制日志位点
SHOW MASTER STATUS;
1.3 从库记录当前的复制状态（可选备份）
SHOW SLAVE STATUS\G;
2、重启顺序
主从都停了之后的 重启顺序推荐如下：
2.1 先启动主库（Master）
systemctl start mysqld
# 或
service mysqld start
查看启动状态:
sudo systemctl status mysqld
确保主库启动后：
登录 MySQL 检查是否正常运行：
mysql -u root -p
查看主库的二进制日志状态：
SHOW MASTER STATUS;
2.2 再启动从库（Slave）
systemctl start mysqld
启动后，登录从库 MySQL，确认复制配置是否还在：
SHOW SLAVE STATUS\G;
如果 Slave_IO_Running 和 Slave_SQL_Running 都为 No，执行：
START SLAVE;
再检查状态：
SHOW SLAVE STATUS\G;
确认以下几个字段值：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0 或较小
二、常见错误1及处理方法
1.错误描述
mysql> SHOW SLAVE STATUS\G
结果显示:
Slave_IO_Running: YesSlave_SQL_Running: No
这说明从库已经成功连接主库（IO 线程正常），但 SQL 线程未运行，这通常是因为复制过程中出现了 SQL 执行错误（例如主库的 DML 在从库无法执行）。
2.处理方法
2.1 分析错误原因
SHOW SLAVE STATUS\G 输出结果中的主要字段含义说明如下:
字段名 说明
Master_Host 主库 IP 或主机名
Master_User 用于复制的用户名
Master_Port 主库端口号（默认 3306）
Master_Log_File 当前正在读取的 binlog 文件名
Read_Master_Log_Pos binlog 文件的读取位置
Relay_Master_Log_File SQL 线程正在执行的主库 binlog 文件
Exec_Master_Log_Pos SQL 线程执行到的位置
Master_UUID 主库的 UUID
Auto_Position 是否启用 GTID 复制（1 表示开启）
Master_SSL_Allowed 是否启用 SSL
Master_Server_Id 主库 server_id
Last_SQL_Error 显示 SQL 线程为什么停止（最关键）
Last_SQL_Errno 显示错误代码
Relay_Log_File 错误发生的位置Relay_Log_Pos 错误发生的位置
Seconds_Behind_Master 延迟情况本例中,Last_SQL_Error字段输出结果如下:
Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master’s binary log is corrupted (you can check this by running’mysqlbinlog’ on the binary log), the slave’s relay log is corrupted (you can check this by running ‘mysqlbinlog’ on the relay log), a network problem, or a bug in the master’s or slave’sMySQL code. If you want to check the master’s binary log or slave’s relay log, you will be able to know their names by issuing ‘SHOW SLAVE STATUS’ on this slave.
2.2 处理过程
步骤 1：停止复制线程
mysql> STOP SLAVE;
Query OK, 0 rows affected (0.00 sec)
步骤 2：重设 relay log（关键步骤）
mysql> RESET SLAVE;
Query OK, 0 rows affected (0.35 sec)
这个命令会清除 relay log 和 复制配置信息（如主库 IP、账号等）
所以你需要重新配置 CHANGE MASTER TO
步骤 3：查看是否启用了GTID
可能结果1:
mysql> SHOW VARIABLES LIKE 'gtid_mode';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_mode | OFF |
+---------------+-------+
1 row in set (0.00 sec)
当Value值为 OFF 时,说明未启用 GTID。
可能结果2:
mysql> SHOW VARIABLES LIKE 'gtid_mode';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_mode | ON |
+---------------+-------+
1 row in set (0.00 sec)
当Value值为 ON 时,说明启用了 GTID。
当启用了 GTID（即 gtid_mode = ON 且 MASTER_AUTO_POSITION = 1），MySQL 不再使用 binlog 文件和位置来控制复制，而是使用 GTID 来自动定位事务同步点。
补充:四种模式的使用场景对比
步骤 4：重新配置复制（在从库执行）
若未启用GTID,配置如下:
CHANGE MASTER TOMASTER_HOST='192.128.10.91',MASTER_USER='user1',MASTER_PASSWORD='Pasd1',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=12345;
其中MASTER_LOG_FILE和MASTER_LOG_POS的值可通过在主库执行如下命令获得:
mysql> SHOW MASTER STATUS;
若启用了GTID,配置如下:
mysql> CHANGE MASTER TO-> MASTER_HOST='192.128.10.91',-> MASTER_USER='user1',-> MASTER_PASSWORD='Pasd1',-> MASTER_AUTO_POSITION=1;
步骤 5：重新启动复制线程
mysql> START SLAVE;
Query OK, 0 rows affected (0.00 sec)
步骤 6：确认复制是否恢复
mysql> SHOW SLAVE STATUS\G
应该看到：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_SQL_Error: <空>
Seconds_Behind_Master: 0 -- 或一个合理的延迟
补:如果此时依然有类似如下错误
Last_IO_Error: error connecting to master ‘user1@192.128.10.91:3306’ - retry-time: 60 retries: 1
可能是因为user1的密码并非Pasd1,此时在确定可以修改user1密码(无其他重要程式使用该用户)的情况下,可将密码修改为Pasd1 。
再次执行SHOW SLAVE STATUS\G查看,结果应如下:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
三、常见错误2及处理方法
1.错误描述
mysql> SHOW SLAVE STATUS\G
结果显示:
Slave_IO_Running: NoSlave_SQL_Running: No
说明复制线程未启动。
2.处理方法
步骤 1：启动复制线程
START SLAVE;
步骤 2：再次查看复制状态，确认是否成功
SHOW SLAVE STATUS\G
应看到:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0 -- 或一个合理的延迟