Periodic maintenance
EDB performs periodic maintenance to ensure stability and security of your clusters. We perform minor version upgrades and patch updates as part of this periodic maintenance.
Notification of upcoming maintenance
You're notified in the BigAnimal portal before maintenance occurs. Details are available on the BigAnimal status page. You can subscribe to get these updates in a feed by selecting Subscribe to Updates on the status page.
EDB reserves the right to upgrade customers to the latest minor version without prior notice in an extraordinary circumstance. You can't configure minor versions.
In some cases, these updates might terminate existing network connections to your clusters. If that happens, the outage is typically less than 30 seconds. Be sure your applications are configured to automatically reconnect when connections are interrupted. Most modern database libraries do this by default.
Specifying maintenance windows
If you want to control when the updates are pushed, you can specify a weekly maintenance window for each cluster or each data group in the case of a distributed high-availability cluster. BigAnimal displays a scheduled maintenance message on your cluster list four hours prior to the scheduled maintenance time to remind you of the upcoming maintenance window. This reminder allows you to make any necessary preparations, such as saving your work and closing any open connections. For more information on specifying maintenance windows, see Maintenance.
Maintenance for high-availability clusters
For primary/standby high-availability clusters, periodic maintenance is performed first on the standby replicas and then on the primary.
While there is no downtime during periodic maintenance, there will be a network connection reset as the primary is failing over.
Connectivity issues after an automatic upgrade
Most connectivity issues correct themselves when you reopen the connection after waiting for a minimum of five seconds. We recommend that you:
- Wait five seconds before your first attempt.
- For the next attempt, increase the wait by doubling the previous wait time. Keep trying this approach until you reach a maximum wait time of 60 seconds.
We also recommend that you set a maximum number of attempts to reopen the connection before your application reports that it can't reconnect.
When an active connection that's currently executing a command is interrupted, you might need to take extra action when reopening the connection. (For read-only transactions that were in progress, you can reopen the connection without any extra steps.) For a transaction that was writing to the database, you need to know whether the transaction was rolled back or whether it succeeded to determine whether you need to retry the transaction. If it was rolled back, you need to retry it. If it succeeded, you don't need to retry it. It's possible for a transaction to succeed without sending you the commit acknowledgment from the database server, so you'll need to add some logic to be sure.
Test your retry logic by creating an event that causes a brief downtime to see if it's handling these transactions correctly.