- 最新
- 最多得票
- 最多評論
Yes, your overall high land plan is correct, but to provide more context around cutover, you'll have to plan a schedule for this essentially.
When the actual data migration is complete and the change data capture is going on or the target is already in sync, during this cutover phase, the application will have to be stopped so no new writes can go to source database anymore. Next, you'll track the DMS task to ensure the data is in sync and once all changes have been pushed to target, you will then switch your application to target to Aurora. This will ensure there is no data inconsistency.
"Replicate on-going changes" means that any new changes to source RDS will keep replicating to target Aurora cluster.
I don't see the mention of the database engine, but if you are using MySQL or Postgres RDS, an easier strategy is to create an Aurora read replica which is relatively simple and can migrate all objects fully. The cutover plan would be the same for that though. You can stop application writes to RDS, once Aurora read replica is in sync, promote it to primary cluster and redirect application to this new Aurora cluster.
Helpful links:
相關內容
AWS 官方已更新 2 年前- AWS 官方已更新 6 個月前
Okay, so that means, there will be some downtime in the application, in order to make sure there are no writes to primary RDS DB.
I was also considering the Replica cluster approach, but it had small downtime during the cutover... SO, I was wondering if DMS could prevent that small downtime.
It seems like the downtime is going to be the same in both approaches.
Thanks for answering, :)