实际修复是按照您说的方法，全部update ''，再alter not null default ''; 还好是dev环境，数据量小，如果生产环境，修复就很难了。

恩了是的。 [image]

数据平台建定时任务，工具自动处理么。

tidb null [image]

测试mysql5.7可以。 [image]

表结构贴错了，是null

1、指定后任务update 任务报错； 2、重建没制定kafka版本，能正常运行。

1、上述方案是迁移 2、升级也是一个大事，如果业务简单可以迁移完再升级，个人感觉俩事放一起，太复杂。

tidb会在机器起1个监控采集器，大部分公司服务器会自己部署监控采集器，这样就2个了。 具体为啥停别人的就不清楚了，应该是tiup工具写死了。

不停机迁移方案，我这边迁移很多次了，最大数据量30TB。 使用placement-rule方式迁移： 1、给集群tikv打标签，分为美国、新加坡 2、扩容新加坡tikv节点 3、扩容副本（通常跨区带宽费用很高，要分批扩容region副本） 3.1 扩容副本1，此时美国3，新加坡1 3.2 扩容副本2，此时美国3，新加坡2 4、副本主从切换： 切换region-leader到新加坡，并且新加坡3、美国2 5、下线美国副本 5.1 缩容美国副本，只留新加坡 5.2 缩容美国tikv，完成存储扩容，剩下tidb、pd迁移就很简单了。 另tiflash迁移会比较麻烦，要停机…

1、重新执行scale-in，等待任务到Stopping component node_exporter tiup cluster cluster-name scale-in xxx --wait-timeout=600 2、登陆10.155.78.148机器， sudo -i. ## 切换到root账号 systemctl stop node_exporter

1、有可能过了gc，已重开 2、除了这监控，自己采集有normal状态监控，但没采集checkpoint-lag，感觉有必要加上。

你没看错，就是卡住了，checkpoint lag 24weeks。 重要的是，没告警出来。 [image]

1、有主键 [image] 2、 [image] [image]

原始任务（告警太多）清理了，相同配置的任务。 { "upstream_id": 6965866413841334309, "namespace": "default", "id": "ticdc-topic-xxx", "sink_uri": "kafka://kafka-ip:9092/ticdc-topic-xxx?protocol=canal-json\u0026max-message-bytes=67108864\u0026replication-factor=2\u0026partition-num=8", "config": { "memory_quo…

有比较多重试日志 kafka: tried to use a client that was closed，其余就没了 [2025/03/20 09:47:42.013 +08:00] [WARN] [metrics_collector.go:96] ["Get Kafka brokers failed, use historical brokers to collect kafka broker level metrics"] [namespace=default] [changefeed=ticdc-topic-prod-xxxxx] [role=processor] [duration…

总共同步5张表，其余4张表能消费到数据。 [image]

看bug说的是非聚簇表，能否修改表结构为聚簇表？

确实不错，大数据场景也有生命周期概念，到期自动删，tidb也有这个特性。