Can Mattermost Community Edition migrate a small application with zero downtime using HA?

Question

Goal
Migrate a small Mattermost application to a newer server version while keeping the API and web client available, using database schema migration and configuration changes already supported by the server.
Constraints
Mattermost applies supported schema migrations automatically during startup, but a single application node does not accept traffic while that migration runs. High Availability rolling restarts can reduce user-visible interruption, yet documented HA clustering is primarily an Enterprise feature, and Community Edition multi-node support depends on the specific release and license. Shared file storage is also required across nodes for attachments.
Questions

Does Mattermost Community Edition support active-active HA nodes against one shared database for rolling restarts?
Can a small Mattermost deployment complete a startup schema migration without any measurable API or web downtime?
What configuration or licensing change is required before treating multi-node Mattermost as a zero-downtime migration path?

Tasadduq Burney · Answer

No, Mattermost Community Edition (CE) cannot natively achieve true zero-downtime migration using active-active High Availability (HA) nodes. While you can simulate near-zero-downtime through manual rolling restarts with a load balancer, the platform lacks the coordinated multi-node orchestration found in the Enterprise edition.
The Migration Bottleneck
The primary obstacle is how Mattermost handles schema updates. When a Mattermost instance starts up, it checks the database version and applies necessary schema migrations automatically. During this process, the application is not ready to accept traffic. In a multi-node CE setup, if two nodes attempt to migrate the same database schema simultaneously, it can lead to database locks or corrupted states.

Achieving Near-Zero-Downtime
To minimize user impact during a small application migration, you must manually orchestrate the process using a load balancer (e.g., NGINX). Follow these steps:

Prepare Shared Storage: Ensure all nodes point to a shared file system (like NFS or AWS EFS) for attachments to maintain data consistency across nodes.
  Drain Traffic: Configure your load balancer to stop sending new sessions to Node A.
  Upgrade and Migrate: Update the Mattermost binary on Node A and restart the service. Wait for the schema migration to complete.
  Health Check: Once Node A is healthy and the API is responding, re-enable traffic in the load balancer.
  Repeat for Node B: Perform the same process on the remaining nodes.

Assumptions and Uncertainties
This approach assumes you are using an external database (PostgreSQL or MySQL) and a shared file store. It is uncertain how long the schema migration will take for your specific dataset size; if the migration takes minutes, the "downtime" for that specific node might exceed your load balancer timeouts, potentially causing errors for active users de-connected from that node.

To provide a more specific recommendation, what is the current size of your database and the number of concurrent users?

Can Mattermost Community Edition migrate a small application with zero downtime using HA?

Goal

Constraints

Questions

1 answer

The Migration Bottleneck

Achieving Near-Zero-Downtime

Assumptions and Uncertainties

Your perspective belongs here.

0 question comments