Cluster

A mesgd cluster replicates account and access-control state across nodes so that the service does not depend on a single copy of the database. Membership starts from the nodes list in mesgd.config, such as {nodes, [mesgd@localhost]}. Database replication, shared key material, and OAuth request affinity each need to be configured for the cluster to behave consistently.

mesgd_cluster:add/1 adds a node and copies tables. mesgd_cluster:remove/1 drops that node's table copy when it is not the last copy, then forgets the node. mesgd_cluster:nodes/0 returns the list the process holds. Removing a node does not rewrite mesgd.config. The next start reads the file again.

Every node that calls another needs the same distribution cookie. The mesgd command sets its cookie from MESGD_COOKIE_FILE or from {cookie, Atom}. mesgd:start/0 does not. A node you start some other way keeps the VM cookie until you set it.

Database replication

On startup, mesgd adds the node to the configured nodes list, asks each peer with a one-second call, and joins the peers that answer before it creates tables. A peer that is down is skipped. That peer copies the tables when its own startup reaches the same step.

The shared tables are accounts, OAuth identities, the administrator audit, permissions, roles, and assignments. They are stored on disc, and a write needs a majority of the copies. A fresh node converts its schema from RAM to disc before the copies are added. Startup waits up to 10 seconds for the tables.

With one disc copy, that node can commit. With two disc copies, both nodes must accept a credential write. Plan for that before you add the second node. Do not create a second schema by starting Mnesia on a peer before it has joined.

Shared keys and OAuth affinity

Every node that serves accounts uses the same auth.key. The session signing key is derived from it. A node with a different key cannot open stored authenticator secrets and will not accept sessions the others issued. Back the key up apart from the Mnesia directory. Replacing the file does not re-encrypt secrets that are already stored.

An OAuth flow in progress lives on the node that started it. A restart drops a flow that has not finished. Send one browser's /auth/oauth/ requests to one node until the flow finishes. Finished account rows, sessions, and the provider index are in the shared tables, so a completed login is not tied to that process.

Statistics stay on the node

The statistics log is per node, in a directory named by the SHA-256 of the node name. Chart queries accept only scope=node. There is no combined cluster view. See Statistics.