这升级后的效果确实明显

每位老师讲的都不错，收益颇丰

所有集群从5.0.3替换成6.5.x版本

升职加薪

你上下游tidb实例的表是不是一直有数据变更？ 如果是的话，你可能就需要使用 TiDB 的 snapshot 功能，开启的话会使用历史数据进行对比 snapshot = “386902609362944000” 你可以试试

你说的没毛病，但是很多公司DBA是没有root用户登录权限的

那你可以手动设置session级别的tidb_allow_remove_auto_inc变量设置成on，然后在该session手动执行alter 删除主键的SQL语句，然后dm同步任务跳过报错的DDL语句，这样也是没问题的，我生产上很多DDL同步问题，我都是这么干的

tidb_allow_remove_auto_inc变量设置成on，允许tidb移除自增主键，然后之后在调整回去 [image]

生产环境的话，建议创建一个tidb用户，所有节点的tidb用户都相同，然后部署的时候使用tidb用户进行部署，tiup部署的时候加上-p参数，示例：tiup cluster check ./topology.yaml --user tidb -p

试一试这种，我之前是未已有迁移任务增加需要迁移的表，这种是可性的 详细参考一下：https://docs.pingcap.com/zh/tidb/stable/dm-faq#如何为已有迁移任务增加需要迁移的表

薪资范围不应该也透露一下

尝试将 TiDB Server 的全局变量 max_allowed_packet 任务配置文件中的配置项 target-database.max-allowed-packet DM配置文件内容详细可参考：https://docs.pingcap.com/zh/tidb/stable/task-configuration-file-full

和父母一起购买年货、做年夜饭

如果表剩余的数据量远小于删除的数据量，建议创建一个中间表的方式来删除，然后rename表，最后drop掉旧表，我们目前就是这么干的

感觉像防火墙端口限制

手动把PD节点停掉，然后通过tiup来启动呢？ 从报错看scp,检查一下是不是ssh互信问题

学习到了

检查一下是不是连接账号的权限问题， 从 TiDB/MySQL 导出数据 需要的权限： PROCESS：需要该权限用于查询集群信息以获取 PD 地址，从而通过 PD 控制 GC。 SELECT：导出目标表时需要。 RELOAD：使用 consistency flush 时需要。注意，只有 TiDB 支持该权限，当上游为 RDS 或采用托管服务时，可忽略该权限。 LOCK TABLES：使用 consistency lock 时需要，需要导出的库表都有该权限。 REPLICATION CLIENT：导出 metadata 记录数据快照点时需要，可选，如果不需要导出 metadata，可忽略该权…

创建好DM同步之后，可以使用如下命令查看迁移任务状态以及迁移阶段：tiup dmctl --master-addr xxxx:8261 query-status xxx 迁移阶段:dump(全量导出) + load（全量导入） + sync（增量同步）