AWS MySQL RDS副本因MY-001525错误停止复制的解决咨询

问题核心 #

主库中last_used（datetime(6)类型）字段出现无效值'2022-09-15 13:11:10.-99999'，违反了MySQL对datetime微秒部分的格式要求（必须是6位0-9的数字），导致副本触发MY-001525错误停止复制。临时调整参数虽能恢复复制，但要彻底解决需从源头、数据修复、校验机制三方面入手：

1. 修复主库中的无效数据 #

• 先定位主库内的异常记录：

  SELECT * FROM your_table WHERE last_used = '2022-09-15 13:11:10.-99999';
  

• 将无效值修正为合法的datetime(6)格式，例如：

  UPDATE your_table SET last_used = '2022-09-15 13:11:10.000000' WHERE last_used = '2022-09-15 13:11:10.-99999';
  

  （若存在其他无效值，需批量排查并统一修正）

2. 从写入源头杜绝脏数据 #

• 启用主库严格SQL模式：修改RDS参数组，确保sql_mode包含STRICT_TRANS_TABLES，拒绝不符合格式要求的datetime写入。可执行全局生效命令（或通过RDS控制台修改参数组后重启主库）：

  SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';
  

  严格模式下，应用写入无效datetime时会直接报错，而非静默生成脏数据。
• 规范应用代码写入方式：禁止通过拼接SQL字符串生成datetime值，改用参数化查询。例如：
  • Java（JDBC）：使用PreparedStatement.setTimestamp()传递日期对象
  • Python（MySQLdb）：通过cursor.execute("UPDATE your_table SET last_used = %s WHERE id = %s", (valid_datetime, id))
    让数据库驱动自动处理格式，避免人为拼接导致的语法错误。

3. 优化副本复制的容错与监控 #

• 不建议长期依赖放宽校验的参数（如你当前使用的101参数），这类参数会降低数据一致性保障。可在副本上启用校验：

  SET GLOBAL slave_sql_verify_checksum = ON;
  

  确保复制的数据与主库完全一致。
• 定期监控复制状态，执行SHOW SLAVE STATUS\G查看Last_SQL_Error字段，一旦出现类似错误及时处理。

4. 校验主副本数据一致性 #

修复完成后，使用pt-table-checksum工具或RDS自带的数据一致性校验功能，对比主副本的your_table数据，确认无差异后再恢复正常业务流量。

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