Support n-1 version compatibility

## Support n-1 version compatibility Previously `Support zero downtime upgrades`, renaming to be more accurate. This was a feature request from a user. Thanks for the feedback, @trevorr ! ### Problem "There is no official support for zero-downtime upgrades. Downtime causes us contractual headaches around SLAs and personal headaches around performing upgrades during the middle of the night on a weekend. I've done this successfully at my own risk, but it will make me increasingly nervous. This feature seems doable, even in the face of schema upgrades, with some constraints (both for FA and its users) on consecutive versions." Note that the only current downtime if you run multiple nodes is when there are database upgrades and the database after upgrade is not compatible with version N-1. This downtime is typically seconds in duration, but does depend on the size of your data. ### Solution Ensure that version N and version N-1 of the application work with version N and version N-1 of the database, so that you can step from N-1 -> N with both nodes and the database with zero degradation. ### Alternatives/workarounds Automate the upgrade, do it in the middle of the night or other low traffic time. Remain on an older version. Provide a 'read only' degraded mode when you are upgrading or figure out some other way for the system to operate in a degraded, but still available mode during a database upgrade. Another option would be for a clear blue/green strategy set of ins

Posted by mooreds on May 25, 2021, 9:10 PM

Tags

• support (Other)

Related issues

• some bike vendor told me that the biggest problem with regular to ebike conversion was that regular bike frames were not strong enough to...
• I think of this as the kiosk economy.
• What a goofy comment.
• There's lots of evidence for positive influences of Caffeine on the body (some negative as well), especially the brain.
• Compose support in WSLc
• [RFC] Roadmap to v2.0