Troubleshooting

Start with the cluster panel (edit the Webserver component) and webserver ha status: they name the node and the cause in most cases.

Nodes

Symptom Cause and action
Every node answers 503 No majority: fewer than 2 of the 3 nodes can reach each other. Start or reconnect a node.
A node refuses to start: “peers answered but the cluster has no leader” It will not create a second cluster. Start enough of the other nodes.
A node refuses to start: “none of the peers answered” It cannot reach the addresses in Peers. Check them, the cluster port and the firewalls. On the very first node, set Bootstrap.
“refused the cluster key” in the log HA.Key differs on that node.
A node shows “Joining, catching up” Normal after a join or a long absence. It gets its vote once it holds everything.
An old node is refused after a recovery The cluster was rebuilt with ha recover. Delete that node’s ha folder and start it: it joins again.

License

Symptom Cause and action
The license is refused on one node That server is not listed in the cluster license. See When a new license is needed.
A Webserver refuses to start without its HA block A cluster license runs standalone on its first server only. See License.
New monitors are refused The cluster has had a single Webserver for longer than the grace period. See A cluster reduced to one Webserver.

Warnings of the cluster panel

The panel shows Cause and action
Check needed: “No shared address is set” AdvertiseAddress is missing on the active Webserver. See Shared address on every Webserver.
Check needed: “Shared address: … is not set up with the same address” The server named has another AdvertiseAddress, or none. Set the same one and restart it.
Check needed: “Webserver-Front: … could not update the Front” The server named lacks the replication key or pki files, or holds different ones. See Webserver-Front with a cluster.
Front not updated The active Webserver itself cannot feed the Front. Same fix, now urgent: the Front’s data is getting out of date.

Components

Symptom Cause and action
Components lose the Webserver after a failover They were set up with one node’s own address. Point them at the shared address.
After a failover the Webserver cannot reach a component That component’s firewall only allows the first Webserver. Allow both.
A Sentinel agent keeps the old Webserver address It cannot reach or resolve the shared address (the Webserver log says so), or it is too old to be told: upgrade it, or save it once from the Components page.
Links in notifications open one node Set webserverUrl to the shared address in integrator.json.

See also

Translations