- 최신
- 최다 투표
- 가장 많은 댓글
- I am unsure how the lease DynamoDB table sources data from the Blue cluster and do we really a dynamo db table?
The DynamoDB table used in the architecture maintains the checkpoint (the commitNum and opNum that was last processed by the Lambda function). It is just a single row table that stores the checkpoint across Lambda invocations.
- Once the entire database is replicated will there be any notification in any logs confirming 100% replication?
The intent of Neptune Streams is to perform on-going replication as changes are made from the source. There is a CloudWatch dashboard that gets deployed with the Streams stack that provides a lag metric showing how far behind the target is from the source. That can be used to show when the target has all of the data from the source (lag of 0).
This blog post explains the architecture in detail: https://aws.amazon.com/blogs/database/capture-graph-changes-using-neptune-streams/
Thanks @Taylor-AWS.
2 - During an upgrade from version 1.2 to 1.3, data might be ingested into the 1.3 cluster after the upgrade. If I find that my application is not compatible with version 1.3 and wish to rollback, taking a snapshot of the 1.3 cluster and rolling back to version 1.2 is not possible. Does AWS recommend any best practices for handling this situation where the data from the 1.3 version needs to be transferred back to the 1.2 version?
This is really what the blue/green solution is for and what it is trying to avoid. By using the blue/green solution, the new cluster is created and upgraded to the latest version while leaving the old cluster in-place. This allows you to test your application against the new cluster before moving your production application to using the new cluster.
There are really only two options if you need to downgrade: