Application upgrade support #7
Description
From @krasserm on September 14, 2015 12:7
Context
An Eventuate application version 1 is replicated across multiple locations and shall be upgraded to version 2. In the following description, a single local event log per location is assumed. This can be easily extended to multiple event logs. Depending on version compatibility, several scenarios can be distinguished.
Backwards and forward compatibility
Version 2 is backwards compatible to version 1 and version 1 is forward compatible to version 2. In this case, locations can be upgraded incrementally with the following procedure at each location.
- Stop making updates to the event log of a location i.e. stop accepting commands and replicating events from other locations (= close replication connections from this location to other locations).
- Close all replication connections from other locations to this location. The result is that this location is now completely disconnected.
- Start version 2 at this location
and replicate all events from version 1 to version 2 (by opening a replication connection from version 2 to version 1). This recovers application state in version 2. As an optimization, this step could also run in parallel with previous steps (with minor modifications, in order to ensure that version 2 is running read-only, i.e. only reading from but not writing to the event log, while version 1 is still running and writing. When version 2 caught up, stop version 1 and allow version 2 to write). - From version 2, open replication connections to other locations in both directions. Locations running version 1 will be able to process events from version 2 (forward compatibility) and vice-versa (backwards compatibility).
Backwards compatibility only
Update: this section is obsolete with RBMHTechnology/eventuate#218 and the procedure described in the previous section can be applied.
Version 2 is backwards compatible to version 1 but version 1 is not forward compatible to version 2. In this case, locations can also be upgraded incrementally with the following procedure at each location.
- Steps 1-3 are identical to the procedure described in section Backwards and forward compatibility.
- From version 2, open replication connections to locations running version 2 in both directions but open replication connections to locations running version 1 only in one direction, so that events are replicated from version 1 to version 2 but not in the other direction.
Version incompatibility
Version 2 is not backwards compatible to version 1. This scenario may arise after a more complex log migration and locations should be upgraded with the following procedure.
- Stop accepting commands at each location.
- Wait for all replicas to converge.
- Close all replication connections.
- Start version 2 at each location and migrate all events from version 1 to version 2 by running a log migrator instead of a simple replicator. After completion, version 2 can recover from the migrated log. As an optimization, this step could also run in parallel with previous steps (with minor modifications).
- Update sequence numbers of replication progress metadata at each location. This might be necessary because log migrations may merge or split events which has an impact on these numbers.
- Open replication connections to other locations in both directions. Since all locations have already been upgraded to version 2, only connections between the same versions are established.
Copied from original issue: RBMHTechnology/eventuate#107