General Maintenance Tasks
Most of the maintenance tasks can be done without taking the website or app offline if you have database replication. You'll remove one DB from the replica-set, apply what you need, and connect it again to your replica-set. While it's off, other DBs will keep the solution running.
Changing Database Schema
When you need to update your database schema, you'll be forced to bring your solution down for some minutes (or to a readonly state) IF the change breaks the old version. If your new schema just creates tables or fields, it will not impact an old version1, so this kind of schema change can be done online2 and using a Blue-Green deployment for your application to achieve a high availability.
If your new schema renames an existing field or remove it, to achieve 100% of uptime, you will need to follow these steps:
Renaming a Field
- If you need to rename from A to B, apply a schema change that adds a new field B and duplicates A content. Also, keep A intact.
- Deploy a new application that uses the field B and do not use the field A.
- Apply a schema change that removes B.
Removing a Field
- Do not apply any schema change.
- Deploy a new application that doesn't use the field that will be removed.
- Apply a schema change that removes the field.
Note 1: some ORM tools, like the .NET Entity Framework, associates each schema change with a migration ID. So, when you deploy a new schema version, old applications will instantly break. It is also avoidable if you disable this check.
Note 2: if your new schema adds a unique constraint, check or foreign key, the alter table command may need some significant time if you have thousand of rows. While the alter table is processing, the table will be locked even for selects and this can lead to some query timeouts depending how big is your data.