When changing primary regions with DynamoDB Global Tables, how do you know when all writes to the primary have propagated to the new primary? Is the answer different between (a) when all regions are healthy and it's a scheduled change vs (b) when the primary has perhaps gone fully dark or appears degraded? Thanks!
First, in terms of keeping GOaST up, it is deployed across multiple regions, uses a DynamoDB Global Table and (as John suggested) we upgrade a region at a time. Second, when GOaST responds to the GMRlib, it not only provides current state, but also future state. The microServices using GMRlib can continue to run and even manage a primary rollover without GOaST. Finally, we can script sending state to GMRlibs if necessary.
When changing primary regions with DynamoDB Global Tables, how do you know when all writes to the primary have propagated to the new primary? Is the answer different between (a) when all regions are healthy and it's a scheduled change vs (b) when the primary has perhaps gone fully dark or appears degraded? Thanks!
Why not use global accelerator instead? Maybe less operationally expensive?
What if GOaST goes down?
First, in terms of keeping GOaST up, it is deployed across multiple regions, uses a DynamoDB Global Table and (as John suggested) we upgrade a region at a time. Second, when GOaST responds to the GMRlib, it not only provides current state, but also future state. The microServices using GMRlib can continue to run and even manage a primary rollover without GOaST. Finally, we can script sending state to GMRlibs if necessary.
@@barrysheward981 That is brilliant :) Thanks
@@barrysheward981 Thank you for sharing this - awesome talk.
@@barrysheward981 Are you planning to open source generic version of it ?