Details
-
Task
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
Supported migration combinations
Obviously, within 1.x code line - writers, readers, table services all need to co-exist for both table versions (tv) 6 & 8.
Reader 0.x | Reader 1.x tv=6/8 | Table Services 0.x | Table Services 1.x tv=6 | Table Services 1.x tv=8 | |
---|---|---|---|---|---|
Writer 1.x tv=6 | |||||
Writer 1.x tv=8 | |||||
Table Services 1.x tv=6 | |||||
Table Services 1.x tv=8 |
We are making the practical restriction that table services 0.x, need to be stopped first, upgraded to new binary 1.x, before resuming operations even for tv=6 to be able to co-exist with a 1.x tv=6 writer.
Recommended migration steps
- Stop any async table services in 0.x completely.
- Upgrade writers to 1.x with tv=6 (this won't auto-upgrade anything); 0.x readers will continue to work; writers can also be readers and will continue to read both tv=6.
- Upgrade table services to 1.x with tv=6, and resume operations.
- Upgrade all remaining readers to 1.x, with tv=6.
- Redeploy writers with tv=8; table services and readers will adapt/pick up tv=8 on the fly.
Things to be done during rolling upgrade
the 6 to 8 upgrade handler, need to handle the following.
|
Safe migration protocol :
<wip>
Downgrade tooling :
<wip>