Plan schema changes with room for downtime.
The planned update process distinguishes brief closure, lossless rollback and fixing forward.
Closure at your approved time
When an update changes the database schema, the plan is to close access briefly and allow ongoing work to finish before making the change. You must be able to approve the version change and choose its timing.
There is no fixed recurring maintenance window or promised maximum duration. A failed process may need investigation and controlled reopening; an expired deadline does not automatically reopen access.
Go back only when proven lossless
The planned release process permits rollback of schema changes only when there is documented proof that no data is lost. Otherwise, the problem must be fixed forward with a new change.
Switching to an older software version is therefore not a safe way back in itself. The actual database and its data must match the version before access reopens.
Explore installation and updatesA snapshot before the confirmed schema change
Before a confirmed pending schema change, the goal is for Tomstok to take a database snapshot automatically. The number of migration snapshots retained must be configurable; choosing zero means no such snapshot is taken.
The snapshot step has not been built yet. It must form part of your agreed backup and recovery process.
See backup and recovery responsibilitiesSee Tomstok with your products in mind.
Talk to us about your product range and production requirements.