We currently support limited live upgrade support. Live upgrades are only possible if the database revision does not change.
Upgrades which include database changes can not be handled live. We should provide ways to mitigate this limitation.
Mitigation Strategies
Cache writes
Write requests could be cached within a RabbitMQ and replayed once the upgrade process has been completed. Read requests would need to take the cached writes into account.
Read Only mode
Gentics Mesh could be put in a read-only mode which would reject each write and also notify the application that writes are currently not supported due to a maintenance task.
Some constraints (like uniqueness of segment field values) are handled by the database, how would this be done, if we have to consider cached writes also?
Cached writes would have to be considered in multiple places throughout the source code (while reading or writing) -> error prone
Cached writes would have to be considered on every read/write (graphql, navigation, ...) request -> performance
I think the Read Only mode is the simpler and cleaner option
We currently support limited live upgrade support. Live upgrades are only possible if the database revision does not change.
Upgrades which include database changes can not be handled live. We should provide ways to mitigate this limitation.
Mitigation Strategies
Cache writes
Write requests could be cached within a RabbitMQ and replayed once the upgrade process has been completed. Read requests would need to take the cached writes into account.
Read Only mode
Gentics Mesh could be put in a read-only mode which would reject each write and also notify the application that writes are currently not supported due to a maintenance task.