|
|
|
|
|
|
by nuclearnice3
1525 days ago
|
|
|
I like this approach. I'm picturing your migration script looping over shards. It flips it to read-only, migrates, then flips back to read-write. How did the app handle having some shards in read-write mode pre-migration and other shards in read-write post-migration simultaneously. |
|
|
The app handled it by proxying calls to the new implementation if the shard was marked as "post-migration", the API stayed the same. If it was "in migration", all write operations returned an error. If the state was "pre-migration", it worked as before.
I don't already remember the details but it was something about the event queue or the notification queue which made me prefer this approach over the others. When a shard was in migration, queue processing was also temporarily halted.
Knowing that a shard is completely "frozen" during migration made it much easier to reason about the whole process.