ALTER CLUSTER posts UPDATE nodes

POST /cli -d "
ALTER CLUSTER posts UPDATE nodes
"

$params = [
  'cluster' => 'posts',
  'body' => [
     'operation' => 'update',
  ]
];
$response = $client->cluster()->alter($params);

utilsApi.sql('ALTER CLUSTER posts UPDATE nodes')

await utilsApi.sql('ALTER CLUSTER posts UPDATE nodes')

res = await utilsApi.sql('ALTER CLUSTER posts UPDATE nodes');

utilsApi.sql("ALTER CLUSTER posts UPDATE nodes");

utilsApi.Sql("ALTER CLUSTER posts UPDATE nodes");

utils_api.sql("ALTER CLUSTER posts UPDATE nodes", Some(true)).await;

{u'error': u'', u'total': 0, u'warning': u''}

{u'error': u'', u'total': 0, u'warning': u''}

{"total":0,"error":"","warning":""}

If authentication and authorization is enabled, ALTER CLUSTER ... UPDATE nodes, ALTER CLUSTER ... ADD, and ALTER CLUSTER ... DROP use the stored cluster user. To change the stored cluster user, grant replication permission to the new user and run:

ALTER CLUSTER posts UPDATE user 'repl_user'

The new stored user must be provisioned with matching authentication data on the nodes that will participate in later cluster operations. Those operations fail if the stored user is missing, has different auth data, or loses replication permission.

For instance, when the cluster was initially established, the list of nodes used to rejoin the cluster was 10.10.0.1:9312,10.10.1.1:9312. Since then, other nodes joined the cluster and now the active nodes are 10.10.0.1:9312,10.10.1.1:9312,10.15.0.1:9312,10.15.0.3:9312.However, the list of nodes used to rejoin the cluster has not been updated.

To rectify this, you can run the ALTER CLUSTER ... UPDATE nodes statement to copy the list of active nodes to the list of nodes used to rejoin the cluster. After this, the list of nodes used to rejoin the cluster will include all the active nodes in the cluster.

Both lists of nodes can be viewed using the Cluster status statement (cluster_post_nodes_set and cluster_post_nodes_view).

To remove a node from the replication cluster, follow these steps:

1. Stop the node
2. Remove the information about the cluster from <data_dir>/manticore.json (usually /var/lib/manticore/manticore.json) on the node that has been stopped.
3. Run ALTER CLUSTER cluster_name UPDATE nodes on any other node.

After these steps, the other nodes will forget about the detached node and the detached node will forget about the cluster. This action will not impact the tables in the cluster or on the detached node.

EXIT CLUSTER <cluster_name> is the online equivalent of the manual detach flow above. It removes the local node from the replication cluster, keeps the local tables intact as regular local tables, saves the local config, and then asks the surviving peers to refresh their persisted node lists using the existing ALTER CLUSTER ... UPDATE nodes machinery.

EXIT CLUSTER posts

Use EXIT CLUSTER when you want to detach only the current node. Use DELETE CLUSTER when you want to remove the cluster from every node.

EXIT CLUSTER is only allowed for a healthy local node in a primary cluster. If the command returns a warning, the local detach already succeeded, but some follow-up may still be required. In that case run ALTER CLUSTER <cluster_name> UPDATE nodes on any surviving node to finish refreshing the remaining cluster metadata.

If the surviving side becomes a clean one-node cluster after EXIT CLUSTER, it remains a replication cluster. After a clean shutdown, that surviving node can be started normally and should return as primary / synced; you do not need --new-cluster for this self-only case.

When a whole multi-node replication cluster is down, one node must be started first so the other nodes know which copy of the cluster to join.

There is one normal-startup exception: if the cluster had already become a clean one-node cluster, for example after the other nodes left with EXIT CLUSTER, start that remaining node normally. After a clean shutdown, Manticore restores that self-only cluster as primary / synced without --new-cluster.

That first-start decision is based on grastate.dat, the small replication state file stored in the cluster data directory. The most important fields are:

• seqno - the last transaction number known to that node
• safe_to_bootstrap - whether that node is marked as safe to start first after a clean shutdown

Example of what grastate.dat can look like after a clean shutdown:

# saved replication state
version: 2.1
uuid:    <cluster-uuid>
seqno:   12345
safe_to_bootstrap: 1

In this example:

• seqno: 12345 means this node knows about transactions up to sequence number 12345
• safe_to_bootstrap: 1 means this node is marked as safe to start first

If the whole cluster was shut down cleanly, start the node that was stopped last. In practice, this is usually the node with:

• the most advanced seqno
• safe_to_bootstrap: 1

Start that node first. This tells Manticore to start a new copy of the cluster from that node. After that, start the remaining nodes normally so they can rejoin.

searchd --new-cluster

manticore_new_cluster

If another node is started first without the required clean-shutdown state, startup is refused to protect the cluster from being restored from an older copy.

If all nodes crashed or were shut down uncleanly, grastate.dat may no longer be trustworthy for normal bootstrap selection. In that case, find the node with the most recent data, usually the one with the largest seqno, and start it with --new-cluster-force. This overrides the normal protection and forces the cluster to start from the chosen node.

searchd --new-cluster-force

manticore_new_cluster --force

If a replication node or an entire cluster becomes unavailable, the correct recovery procedure depends on how many nodes are still reachable and whether the shutdown was clean or abrupt.

A replication cluster should be treated as one logical system rather than a set of unrelated servers. That gives you multi-master writes and consistent data, but it also means you must recover quorum carefully. In particular, do not run the manual recovery command that restores writes on the surviving side until you are sure the missing nodes are really gone. That command is shown later in this page as SET CLUSTER <name> GLOBAL 'pc.bootstrap' = 1. If you run it too early, you can create split-brain and end up with two independent clusters.

For the examples below, assume a cluster with nodes A, B, and C unless noted otherwise.

First identify which situation you are in:

• Is at least one node still online?
• Was the node stopped cleanly, or did it crash? A clean stop means searchd was shut down normally and had time to save its replication state before exiting. A crash, power loss, or kill -9 is not a clean stop.
• Does the surviving part of the cluster still have quorum? Quorum means enough nodes can still see each other to safely remain the writable cluster.
• If all nodes are down, which node should be started first to bring the cluster back?

Useful checks:

• SHOW STATUS LIKE 'cluster_<name>_status'
• SHOW STATUS LIKE 'cluster_<name>_size'
• SHOW STATUS LIKE 'cluster_<name>_node_state'
• if all nodes are down, inspect grastate.dat, the small replication state file stored in the cluster data directory. Look especially at seqno and safe_to_bootstrap: on a clean shutdown, the best node to start first is usually the one with the most advanced seqno and safe_to_bootstrap: 1. For the full bootstrap procedure, see Restarting a cluster.

Example of what grastate.dat can look like after a clean shutdown:

# saved replication state
version: 2.1
uuid:    <cluster-uuid>
seqno:   12345
safe_to_bootstrap: 1

In this example:

• seqno: 12345 means this node knows about transactions up to sequence number 12345
• safe_to_bootstrap: 1 means this node is marked as safe to start first

In a clean all-nodes-down recovery, this is usually the kind of node you start first with --new-cluster to bring the cluster back.

After recovery, wait until the restarted node reports cluster_<name>_status=primary and cluster_<name>_node_state=synced before treating it as fully writable again. You can check this with SHOW STATUS LIKE 'cluster_<name>_status' and SHOW STATUS LIKE 'cluster_<name>_node_state'. In local tests, restarted nodes sometimes spent a short time with cluster_<name>_node_state=joining and cluster_<name>_status=disconnected before reaching synced/primary.

If node A is stopped normally, nodes B and C keep serving writes. You can confirm that the cluster is still healthy on those nodes with SHOW STATUS LIKE 'cluster_<name>_status' and SHOW STATUS LIKE 'cluster_<name>_size'.

When node A starts again, it rejoins the cluster automatically. Until synchronization finishes, do not send writes to that node. Check SHOW STATUS LIKE 'cluster_<name>_status' and SHOW STATUS LIKE 'cluster_<name>_node_state' and wait for primary / synced.

If donor nodes B or C still have all the transactions that node A missed in their replication cache, node A can catch up using an incremental state transfer (IST). IST stands for incremental state transfer. It means the node receives only the transactions it missed, so recovery is usually faster and lighter. Otherwise it will require a snapshot state transfer (SST). SST stands for snapshot state transfer. It means copying table files from another node instead of just replaying the missing transactions. SST is heavier: it is usually slower, moves more data, and can make recovery more disruptive on large clusters.

If nodes A and B are stopped cleanly and node C remains online, node C can continue accepting writes. Check SHOW STATUS LIKE 'cluster_<name>_status' and SHOW STATUS LIKE 'cluster_<name>_size' on node C if you want to confirm it is now the only active node.

When nodes A and B start again, they rejoin automatically and synchronize from node C. While they are rejoining, check SHOW STATUS LIKE 'cluster_<name>_status', SHOW STATUS LIKE 'cluster_<name>_node_state', and SHOW STATUS LIKE 'cluster_<name>_size'. Wait until all nodes show primary / synced and the expected cluster size before treating recovery as complete.

If nodes A and B were intentionally removed from the cluster, for example with EXIT CLUSTER, and node C is now the only persisted node in the cluster, node C can also recover after its own clean restart with a normal daemon start. In that self-only case, --new-cluster is not required.

If all nodes in a multi-node cluster were stopped normally, the cluster is fully offline and must be started again in a special way so one node can become the first running node of the cluster.

On clean shutdown, each node writes its last transaction number to grastate.dat. The node that was stopped last is the safest node to start first:

• it has the most advanced seqno
• it has safe_to_bootstrap: 1

Start that node with --new-cluster. This tells Manticore to start a new copy of the cluster from that node. If you run Manticore via systemd on Linux, use manticore_new_cluster. It starts Manticore in --new-cluster mode for you.

After that, start the remaining nodes normally and let them rejoin. Verify recovery with SHOW STATUS LIKE 'cluster_<name>_status', SHOW STATUS LIKE 'cluster_<name>_node_state', and SHOW STATUS LIKE 'cluster_<name>_size'.

If you bootstrap a less advanced node first, a more advanced node may later join it and receive a full SST from an older state, which can discard transactions that existed only on the more advanced node. That is why the node with safe_to_bootstrap: 1 should be your first choice.

If node A disappears because of a crash or a network problem, nodes B and C will first try to reconnect to it. If that fails, they remove it from the cluster, recalculate quorum, and continue working as the primary cluster.

In local tests this peer removal was not immediate: the surviving nodes stayed at the old cluster size for a few seconds before dropping the failed peer and switching to the smaller primary cluster.

When node A is started again, it rejoins automatically and catches up the same way as after a clean one-node shutdown. Again, use SHOW STATUS LIKE 'cluster_<name>_status', SHOW STATUS LIKE 'cluster_<name>_node_state', and SHOW STATUS LIKE 'cluster_<name>_size' to confirm recovery is finished.

If nodes A and B are lost and only node C is still running, node C no longer has quorum in a three-node cluster. It switches to non-primary and rejects writes.

The write error is explicit:

ERROR 1064 (42000): cluster '<name>' is not ready, not primary state (synced)

If nodes A and B are only temporarily disconnected but can still see each other, they may continue accepting writes while node C remains isolated. Use SHOW STATUS LIKE 'cluster_<name>_status' on each side if you need to see which side is still writable.

If nodes A and B really crashed and node C is the only surviving copy you want to keep working with, run this command on node C to make it writable again:

SET CLUSTER posts GLOBAL 'pc.bootstrap' = 1

POST /cli -d "
SET CLUSTER posts GLOBAL 'pc.bootstrap' = 1
"

Important:

• run this only after you are sure the other nodes are unreachable
• run it only on the side that must survive
• after bootstrapping, the node can accept writes again and the other nodes can later rejoin from it

If every node crashed, grastate.dat is typically no longer trustworthy for normal bootstrap selection. In local tests, all nodes showed:

• seqno: -1
• safe_to_bootstrap: 0

In this situation, choose the node with the most recent data and start it with --new-cluster-force. This forces Manticore to start a new copy of the cluster from that node even though the usual clean-shutdown metadata is not trustworthy. If you run Manticore via systemd on Linux, use manticore_new_cluster --force. It starts Manticore in --new-cluster-force mode for you.

Then start the remaining nodes normally and let them rejoin. Verify recovery with SHOW STATUS LIKE 'cluster_<name>_status', SHOW STATUS LIKE 'cluster_<name>_node_state', and SHOW STATUS LIKE 'cluster_<name>_size'.

Split-brain risk is highest in even-sized clusters. For example, imagine four nodes split into two isolated pairs across two data centers. Each side has exactly half of the original members, so neither side has quorum and both sides stop accepting writes.

If you must restore writes before connectivity is fixed, choose only one side of the split and run the same recovery command there so that side becomes writable again. Before doing that, check SHOW STATUS LIKE 'cluster_<name>_status' on both sides so you know which side is currently non-primary.

SET CLUSTER posts GLOBAL 'pc.bootstrap' = 1

POST /cli -d "
SET CLUSTER posts GLOBAL 'pc.bootstrap' = 1
"

Never issue that statement on both sides. If you do, you will create two separate primary clusters, and they will not merge back automatically when the network recovers.

In local testing, abruptly losing half of a four-node cluster reproduced the same non-primary behavior and the same recovery command brought one surviving half back to primary.