Azure SQL Database Geo-Replication大表：迁移及故障转移相关咨询

嗨，针对你提到的把非Azure数据库迁移到Azure SQL Database，同时用Geo-Replication做故障转移的场景，结合你那130+百万行的审计表，我来逐个拆解你的问题：

1. Seeding流程所需时长 #

这个没有固定的标准答案，主要取决于几个核心因素：

• 数据体量：你审计表有130+百万行，但还要看单条记录的大小（比如是否包含大字段、长文本），压缩后的实际传输数据量才是关键
• 网络带宽：主库（迁移后的Azure SQL主实例）到异地副库的网络链路带宽，千兆带宽和百兆带宽的传输效率差异会非常明显
• 主库负载：如果seeding期间主库还承担着高并发的生产读写，会拖慢快照生成和数据传输的速度
• Azure SQL性能层级：副库的服务层级（比如GP、BC系列）也会影响数据接收和写入的处理能力

一般来说，如果是千兆带宽、主库负载较低的理想情况，130M行的表可能需要几小时到十几个小时完成seeding。如果条件不理想（比如带宽有限、主库负载高），耗时可能会更久。建议你可以先找一个类似数据量的测试表跑一遍seeding，或者用Azure的迁移评估工具做个预估，心里更有数。

2. 是否需等待seeding完成后方可启用生产应用？ #

完全不需要！Geo-Replication的seeding是后台异步执行的，不会占用主库的核心业务资源。只要你完成了从非Azure数据库到Azure SQL主实例的初始数据迁移，就可以直接把生产应用切换到主库上运行。seeding过程会在后台默默同步数据到副库，完全不影响主库的正常读写。

3. 若seeding未完成时主库产生交易，这些交易在副库的同步情况？ #

放心，这些交易不会丢失，副库最终会同步所有数据。具体过程是：

1. Seeding启动时，主库会先生成一个初始数据快照，同步到副库
2. 在快照同步的过程中，主库上产生的所有新交易（插入、更新、删除）都会被实时记录到事务日志里
3. 当快照同步完成后，副库会自动开始追同步这些事务日志里的增量数据，最终和主库保持完全一致

不过要注意，在seeding完成前，副库处于只读状态，而且暂时无法作为故障转移目标使用——必须等seeding完成、进入正常的同步状态后，才能启用故障转移功能。

内容的提问来源于stack exchange，提问作者77Vetter