servd

Database Upgrades

Servd routinely provides new database versions for you to use with your project. We do not update your project to any new database version automatically as this can cause disruption, instead, database upgrades can be triggered manually from within our dashboard.

The upgrade from MariaDB to MySQL 8 has additional requirements. You can read special instructions for that upgrade here.

Triggering An Upgrade #

Once the upgrade process has started it will run in the background until completion. You can check if the migration is still running by looking at the Task Bar at the bottom of most pages within the Servd Dashboard - you can see the database migration task status here along with any log output that it has produced.

Upgrade Strategies #

Database upgrades are applied in one of two different ways depending on their complexity and the specific versions being upgraded to and from.

In-Place Upgrade

An in-place upgrade simply switches the running database process for the new version withut performing any additional pre-upgrade steps.

If there are any data or configuration migrations required, the database will apply these during its initial boot process.

While any initial migrations are being applied the database will be unavailable, but as the changes are usually minor, the full process usually only takes a few moments, but can extend to severl minutes for very large databases.

Full Replacement Upgrades

When a direct upgrade is not feasible we use a full replacement strategy. This initially creates a full backup of each of your project's environments before destroying the old database entirely and creating a new one. The final step is reimporting all of the backups into the new database.

This process can take a substantial amount of time for larger databases so it is only used when absolutely necessary.

Offline Mode #

When triggering the upgrade you have the option to enable Offline Mode for the production environment's data migration. Offline Mode returns a 503 error for all incoming requests along with a generic, non-branded 'maintenance' page.

This can be useful for three reasons:

• It prevents users from making changes to data during and after the production backup being taken which would then be lost
• It prevents Craft error pages from being shown during the production import phase
• It prevents any upstream caches from caching responses generated half way through the process which might include errors or incorrect data

We recommend enabling Offline Mode for any transactional and commerce projects, or very large databases. However, if your project is using static caching and has a modestly sized database, you can leave Offline Mode disabled and end users are unlikely to notice anything during the process as the static cache will remain functional throughout.