在Amazon RDS只读副本执行ALTER表语句时遇Apply Error 1677求助

我之前碰到过类似的RDS只读副本复制异常，结合你描述的情况，给你几个可行的排查和解决方向：

• 先核对主副库表结构的一致性
  错误提示提到第59列无法从datetime转varchar(10)，但你的ALTER语句是新增列，这说明复制线程在应用变更时，可能误判了列的位置或类型。请分别在主库和只读副本执行以下命令，对比sales_orders表的结构：

  DESCRIBE sales_orders;
  SHOW CREATE TABLE sales_orders;
  SELECT column_name, data_type, character_set_name FROM information_schema.columns WHERE table_name='sales_orders' AND ordinal_position=59;
  

  重点确认第59列的类型、字符集在主副库是否完全一致，有没有出现主库是varchar但副本是datetime的反向差异，或者列的位置因为之前未同步的变更发生了偏移。

• 检查RDS复制状态与错误详情
  登录RDS控制台查看只读副本的复制状态，或者在副本上执行SHOW SLAVE STATUS\G，重点查看Last_SQL_Error字段的完整错误信息，有没有更细节的提示。另外，确认副本的复制延迟是否正常，是否存在之前未完成的DDL同步任务。

• 验证主库DDL的执行完整性
  确保主库上的ALTER TABLE语句已经完全执行成功，没有中途中断或异常。可以在主库执行SHOW TABLE STATUS LIKE 'sales_orders';确认表状态正常，再通过information_schema.columns检查表中是否已经存在新增的dw_base_currency和dw_base_total列。

• 谨慎跳过复制错误（仅限确认结构一致后）
  如果已经确认主副库表结构完全一致，只是复制线程卡在这个错误上，可以使用RDS专用的存储过程临时跳过该错误：

  CALL mysql.rds_skip_repl_error;
  

  注意：执行此操作前一定要做好副本备份，确保跳过错误不会导致数据不一致，仅当你确认当前错误是复制线程的误判时再使用。

• 排查TokuDB引擎的特殊情况
  你提到参考过TokuDB副本的相关问题，需要确认主库和副本的sales_orders表是否都使用TokuDB引擎，且引擎版本一致。TokuDB的在线DDL复制机制和InnoDB有所不同，如果主副库引擎不一致或版本差异较大，可能会导致列类型解析异常。

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