MariaDB Common Problems

The InnoDB-level problems in MySQL Common Problems apply here too. These are the MariaDB-specific ones.

Node reports non-Primary

wsrep_cluster_status is non-Primary. The node has lost quorum and refuses queries.

This is Galera working as designed: a minority partition must not accept writes. Restore network connectivity so the majority reforms. Only if a genuine majority is permanently lost should you force a node to become primary — and that is a data-divergence risk:

SST takes hours on every restart

A joining node falls back to a full state transfer because the donor's gcache no longer holds the write sets it missed. Increase gcache.size so routine restarts qualify for an incremental transfer instead:

wsrep_provider_options = "gcache.size=4G"

Size it from your write volume and the longest routine outage — a node down for ten minutes should never need a full copy.

The whole cluster is slow because one node is

Flow control throttles the cluster to the slowest member.

SHOW STATUS LIKE 'wsrep_flow_control_paused';
SHOW STATUS LIKE 'wsrep_local_recv_queue_avg';

Find the member with the growing receive queue. The cause is usually weaker hardware, a slower disk, or wsrep_slave_threads set too low for the write rate.

Deadlock errors on commit that make no sense

In Galera, a certification conflict is reported to the client as a deadlock at commit time, even though no lock cycle occurred locally. It means another node committed a conflicting change first.

Retry the transaction. If it happens frequently, route writes for that dataset to a single node — see Galera Cluster.

A table has no primary key and does not replicate

Galera requires a primary key on every replicated table. Rows without one cannot be identified deterministically across nodes.

SELECT t.table_schema, t.table_name
FROM information_schema.tables t
LEFT JOIN information_schema.table_constraints c
  ON c.table_schema = t.table_schema AND c.table_name = t.table_name
 AND c.constraint_type = 'PRIMARY KEY'
WHERE c.constraint_name IS NULL
  AND t.table_schema NOT IN ('mysql','information_schema','performance_schema','sys');

Autoincrement values jump

With innodb_autoinc_lock_mode = 2 — mandatory in Galera — each node allocates from a strided range, so identifiers are unique but not contiguous. This is correct behaviour, not a fault. Do not rely on auto-increment values being gapless or ordered by insertion time.

Cannot bootstrap after a full shutdown

grastate.dat on each node records safe_to_bootstrap. If no node has it set to 1, the cluster was not shut down cleanly. Compare seqno across nodes and bootstrap from the highest, accepting that anything the others held beyond it is lost. Recording seqno values before acting is what makes that decision auditable.