目前我们有一套正在运行的 TiDB 生产集群，部署在现有机房。由于后续业务规划和机房迁移需求，业务系统需要逐步搬迁到新的机房。
为了承接迁移后的业务流量，我们计划在新机房再部署一套独立的 TiDB 集群。在整个搬迁过渡期间，旧机房和新机房的两套 TiDB 集群会同时存在一段时间。
初步设想如下：
- 旧机房 TiDB 集群作为当前生产主集群，继续承载线上业务读写。
- 新机房 TiDB 集群作为目标集群，用于承接迁移后的业务。
- 搬迁期间，希望通过数据同步方式，将旧集群的数据同步到新集群。
- 待新集群完成数据初始化、增量同步、数据校验和业务验证后，再择机将业务读写入流量从旧集群切换到新集群。
【TiDB 使用环境】生产环境
【TiDB 版本】v8.5.1 和 v8.5.6
【部署方式】机器部署
【操作系统/CPU 架构/芯片详情】
【机器部署详情】
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
- TiDB 官方是否支持两个独立 TiDB 集群之间的双向写入或双主模式？
- 如果业务层自行实现双写，是否存在比较成熟的实践方案？
- 两边同时写入时，唯一键、自增 ID、事务一致性、写入顺序和冲突解决应该如何处理？
- 如果出现一边写入成功、另一边写入失败，或者网络抖动导致写入重试，应该如何保证最终一致性？
- 对于这类跨机房迁移场景，社区更推荐“两地双写”，还是“单写旧集群 + 数据同步到新集群 + 切换窗口内完成主写切换”？（因为业务较多，不可能要求业务去修改代码）
我们目前比较担心两地双写会带来数据冲突、部分成功、数据分叉和后续修复成本较高的问题，所以想听听社区是否有实际落地经验或官方建议。
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】