如何修复MariaDB主从复制中MYI索引损坏的Delete_rows_v1事件错误

问题背景 #

两台MariaDB服务器搭建主从复制架构，意外关机重启后，db1和db2上的MyISAM表自动执行检查：

|  85 | db          | ip:55336 | db | Query       | 4398 | Checking table                                                        | tableName |    0.000 |

调整从库（db2）读取主库新二进制日志文件及位置（原复制无延迟）后，启动从库出现复制错误：

Could not execute Delete_rows_v1 event on table db.tableName; Index for table './db/tableName.MYI' is corrupt; try to repair it, Error_code: 126; handler error HA_ERR_WRONG_IN_RECORD; the event's master log binlog-file-01, end_log_pos 8980

主库db1已清空该表所有数据，需解决：是否要清空从库对应表数据并跳过复制步骤？或能否直接跳过该复制事件？

补充信息 #

• db2上的Exec_Master_Log_Pos为810
• db1上该日志文件的事件详情：

MariaDB [(none)]> SHOW BINLOG EVENTS IN 'binlog-file-01' from 810 limit 5;
+---------------------------+------+----------------+-----------+-------------+------------------------------------------------+
| Log_name                  | Pos  | Event_type     | Server_id | End_log_pos | Info                                           |
+---------------------------+------+----------------+-----------+-------------+------------------------------------------------+
| binlog-file-01 |  810 | Gtid           |         1 |         852 | BEGIN GTID 0-1-5630806796                      |
| binlog-file-01 |  852 | Annotate_rows  |         1 |         908 | DELETE FROM tableName              |
| binlog-file-01 |  908 | Table_map      |         1 |         993 | table_id: 107 (db.tableName) |
| binlog-file-01 |  993 | Delete_rows_v1 |         1 |        8980 | table_id: 107                                  |
| binlog-file-01 | 8980 | Delete_rows_v1 |         1 |       17006 | table_id: 107                                  |
+---------------------------+------+----------------+-----------+-------------+------------------------------------------------+
5 rows in set (0.02 sec)

修复步骤 #

方案一：修复从库损坏索引（优先尝试） #

错误根源是MyISAM表索引损坏，先尝试修复表：

1. 停止从库复制：

STOP SLAVE;

2. 在db2上修复损坏表：

REPAIR TABLE db.tableName;

3. 修复完成后启动复制：

START SLAVE;

修复成功后，复制会自动执行后续Delete事件，主库已清空表，从库执行Delete不会有数据不一致问题。

方案二：跳过故障事务+同步主库表数据 #

若索引修复失败，可跳过对应事务并同步表数据：

1. 停止从库复制：

STOP SLAVE;

2. 跳过当前出错的GTID事务：

SET GLOBAL gtid_slave_pos = '0-1-5630806800'; -- 将GTID最后一位加1，跳过该事务

若未使用GTID，直接跳转到事务结束的日志位置：

CHANGE MASTER TO MASTER_LOG_POS = 17006, MASTER_LOG_FILE = 'binlog-file-01';

3. 清空从库对应表数据：

TRUNCATE TABLE db.tableName;

4. 启动复制：

START SLAVE;

此时从库从17006位置开始复制，表数据与主库保持一致（均为空）。

方案三：跳过单个Delete事件（不推荐） #

不建议单独跳过单个Delete_rows_v1事件，因该事务包含多个Delete操作，单独跳过会导致事务不完整，易引发后续数据不一致。若一定要尝试，可跳转到第一个出错事件的结束位置：

STOP SLAVE;
CHANGE MASTER TO MASTER_LOG_POS = 8980, MASTER_LOG_FILE = 'binlog-file-01';
START SLAVE;

但后续仍有另一个Delete事件，大概率会因索引损坏再次报错，因此不推荐该方案。

注意事项 #

• MyISAM不支持事务，意外关机易引发索引损坏，建议将表转换为InnoDB引擎提升稳定性
• 操作前建议备份从库db.tableName表数据，避免数据丢失

内容的提问来源于stack exchange，提问作者Ela