Relay log read failure表明从库relay-bin.*文件或relay-log.index损坏，需先STOP SLAVE，验证损坏后重置SQL线程起点：记下Master_Log_File和Master_Log_Pos，执行RESET SLAVE再CHANGE MASTER TO指定位置启动复制。
看到Relay log read failure就先停SLAVE，别删文件
这个错误不是网络或权限问题，而是从库本地的relay-bin.*文件已损坏或不完整。直接rm -f删除relay-bin.*或relay-log.index会导致START SLAVE报Could not read from relay log index file或卡死——MySQL不会自动重建索引，也不会扫描磁盘找现存文件。
必须先执行STOP SLAVE，确保Slave_IO_Running和Slave_SQL_Running都为No；再检查ps aux | grep mysql确认没有残留的复制线程在运行。
用mysqlbinlog验证是否真损坏
别只信错误日志，动手验证最可靠。从SHOW SLAVE STATUS\G中提取Relay_Log_File（比如mysqld-relay-bin.000121），然后执行：
mysqlbinlog /var/lib/mysql/mysqld-relay-bin.000121 | head -20
如果输出含以下任一内容，基本坐实损坏：
-
Invalid replication event或unknown binlog event type（CRC校验失败） -
Failed to open file（文件被截断或权限不对） - 直接段错误（segfault）或空白输出（二进制头损坏）
注意：--base64-output=DECODE-ROWS可能掩盖损坏特征，首次验证时不要加。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
区分是relay-bin.*损坏还是relay-log.index损坏
两类问题现象接近，但处理路径完全不同：
-
relay-bin.*损坏：有明确
Could not parse relay log event entry，Relay_Log_File非空但指向非法内容，Seconds_Behind_Master为NULL，Slave_SQL_Running为No -
relay-log.index损坏：MySQL启动失败、
SHOW SLAVE STATUS中Relay_Log_File为空、Seconds_Behind_Master为NULL且无Last_SQL_Error；此时ls -1v hostname-relay-bin.[0-9]*能列出文件，但relay-log.index内容错乱或为空
关键判断点：执行ls -1v hostname-relay-bin.[0-9]*，看输出是否与relay-log.index内容一致，末尾不能有空行。
安全重置SQL线程起点，避免丢事务
核心目标是让SQL_THREAD从IO_THREAD已拉取的最新位置继续执行，不丢、不重、不越界：
- 执行
SHOW SLAVE STATUS\G，记下Master_Log_File（如mysql-bin.000123）和Master_Log_Pos（如456789）——这是唯一可信的“已同步到主库哪”的坐标 - 执行
RESET SLAVE：清空所有relay-bin.*和relay-log.index，重置Relay_Master_Log_File和Exec_Master_Log_Pos - 执行
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000123', MASTER_LOG_POS=456789，再START SLAVE
跳过后无法默认保证数据一致——损坏意味着至少有一段变更没执行，必须结合主库mysqlbinlog交叉校验，并人工补漏。GTID模式下sql_slave_skip_counter完全无效，必须用SET GTID_NEXT + 空事务方式跳过。
