一、背景

具体架构上游是tidb,经由cdc同步到mysql,同步出错的原因是因为不支持的ddl语句，一共有两个ddl同时执行

报错语句：

alter table table_name rename column column_name1 to column_name2

以前总能碰到mysql的DDL在tidb上不支持，这种情况下的DDL是特别注意的，但是tidb用习惯后，没有注意这一点，查了mysql5.7官网才发现，确实是不支持字段的rename操作，可以通过change column等来达到效果

二、解决问题

1.下游执行报错DDL语句的变种

alter table table_name change columncolumn_name1 column_name2varchar(20) not null default abc

2.查看同步任务

# 注意ctl要根据自己的版本来写，记录查看的tso位置 tiup ctl:v4.0.13 cdc changefeed --pd=http://pd_ip:pd_port list # 或者用下面的语句，-s表示显示简略的信息，不加显示全部信息 tiup ctl:v4.0.13 cdc changefeed --pd=http://pd_ip:pd_port query [-s] -c changefeed_id

3.删除同步任务

tiup ctl:v4.0.13 cdc changefeed --pd=http://pd_ip:pd_port remove -c changefeed_id

4.创建同步任务

# 重点是--start-ts,假设步骤2查出来的tso是431875738828800000，那么想要跳过失败的ts,这里的start-ts要比失败之处的tso+1,所以这里的start-ts应该设置为431875738828800001 tiup ctl:v4.0.13 cdc changefeed create --pd=http://pd_ip:pd_port --sink-uri="mysql://mysql_connect_info/" --changefeed-id="changefeed-id" --start-ts=431875738828800001 --sort-engine="unified" --config=./cdc.yaml

小结：这是正常的处理方式，到目前为止第一个ddl的错误正常解决，但很快，第二个ddl的报错就到了，cdc再次不能正常同步，这时候再进行一次上面的操作，但是这里就出现了问题，看接下来的处理

三、特殊处理

1.遇到的问题

1.1 remove不掉

remove后用list查看发现被remove掉的changefeed还存在，然后新建的同步业务也不同步，问题类似于tug论坛里的问题，其现象是已有的这个issue，还有一些相关的issue可以做参考issue1,issue2,issue3

1.2 create成功后同步状态不更新

这个是因为remove后很快就进行create导致的，问题和tug论坛里的问题情况二一样

2.尝试过的办法

# 1.暂停已经remove的任务，没有变化 pause -c changefeed_id # 2.采用force命令remove,没有变化 remove -c changefeed_id --force # 3.进入到cli命令行进行remove,没有变化 # 4.重启cdc,没有变化 restart/reload -R cdc # 5.通过curl来删除，报找不到任务，以此推断changefeed_id已经被删除，但是还没有完全清除，存在etcd中，导致的list中还存在 curl -X DELETE http://127.0.0.1:8300/api/v1/changefeeds/changefeed_id # 6.等，其实这是最没技术含量的方式，我等了将近20分钟后，发现list后任务已经正常删除了 # 7.不安全的方式，重点，这个方式不要随便使用，尽量不要在正式环境上使用，因为这个命令会清理所有changfeed的信息 tiup cdc:v4.0.13 cli --pd=pd_host:pd_port unsafe reset

3.最终解决方案

如果不着急可以先等一段时间，半个小时左右，（在这期间可以调大上游的gc时间，以免等待时间过长，超过了gc时间，导致丢数据的情况），再进行list,发现remove信息没有后即可正常进行接下来操作

# 预留足够的时间给cdc同步 update mysql.tidb set VARIABLE_VALUE="24h" where VARIABLE_NAME="tikv_gc_life_time";

如果很着急且等了一段时间后都没有反应，则可以进行unsafe reset,不过要记录下所有任务的信息，以防万一，这一步操作之后所有的changefeed都需要重建

tiup cdc:v4.0.13 cli --pd=pd_host:pd_port unsafe reset

4.监控的问题

在正式下线任务的时候，会收到已经下线的cdc任务的报警,这也是低版本cdc的一个bug,如果不升级的话，遇到的时候可以通过reload cdc来解决