Scaling and High Availability

• Running multiple database instances concurrently
• Clustering or leader election
• Automated failover or replication

These features are planned for a future release.

Changed in 1.3

Until built-in support is available, use the following strategies to ensure resilience:

• Deploy EventSourcingDB on stable infrastructure with reliable storage
• Use automated restarts (e.g., via --restart always in Docker)
• Apply backup and restore strategies to protect against data loss
• Use network-level isolation to prevent conflicting deployments

One Server per Data DirectoryAdded in 1.3#

A server locks its data directory when it starts, through the file lock.esdl in it, and holds the lock until it shuts down, since two servers that wrote the same files at once could damage the data without either of them noticing. A second server on the same data directory, for example during a rolling update on a shared volume or by mistake, therefore refuses to start and exits with 1, with the message data directory is in use: another server has it open; stop that server, or give this one a data directory of its own.

So a rollout has to stop the old server before it starts the new one, for example through the strategy Recreate of a Kubernetes Deployment, or through a StatefulSet, as the reference manifest for Kubernetes uses. A rollout that starts the new server first, as a Deployment with the default strategy RollingUpdate and a single replica does, never gets the new server ready, and stalls with it restarting until the old one is stopped.

A data directory on a file system that cannot lock refuses the start as well, with the message data directory cannot be locked: its file system does not support locks, so a second server on it could not be kept out; give the server a data directory on a file system that does.

The lock ends with the process, so a server that crashed does not keep the next one from starting. Only on Windows, which lets go of the locks of a process that ended with a delay, may a start right after a crash be refused for a moment. Versions up to 1.2 neither take the lock nor respect it, so it keeps none of them out: stop such a version before you start this one on its data directory, as described in Upgrading EventSourcingDB.

Once native support for high availability is available, this page will be updated with configuration details and deployment patterns.