MySQL/MariaDB on AlmaLinux series, part 5. Part 1 installed MariaDB, part 2 covered users and remote access, part 3 covered backups, and part 4, GTID primary/replica replication, built an asynchronous replica on db2. This part turns db1, db2 and a new db3 into a three-node MariaDB Galera Cluster.
MariaDB Galera Cluster is a synchronous, multi-primary cluster: every node holds a full copy of the data, and a transaction is only committed once the whole cluster has certified it. There is no replica lag to watch for committed data, no “promote the replica” step, and losing one node of three leaves the other two serving reads and writes. The price is that every commit waits for a network round trip to the other nodes, only InnoDB tables are replicated, and the cluster needs a majority (quorum) to stay writable. This guide installs Galera on AlmaLinux 10, opens the firewall and SELinux ports, bootstraps the cluster, joins the other nodes, and covers verification, safe restarts, backups and the problems you will actually run into.
Applies to: AlmaLinux 10.x with MariaDB 10.11 and Galera 4 from AppStream (mariadb-server-galera). The same steps apply to RHEL 10, Rocky Linux 10 and Oracle Linux 10. MySQL has no Galera in its own packages; its built-in equivalent is Group Replication / InnoDB Cluster (see the note near the end).
Galera vs async replication: which do you need?
| Async GTID replication (part 4) | Galera Cluster (this part) | |
|---|---|---|
| Writes | One primary only | Any node (single writer recommended) |
| Commit | Local; replica applies later | Certified by the whole cluster before COMMIT returns |
| Data loss on primary crash | Possible (unreplicated transactions) | None for committed transactions |
| Failover | Manual promotion, re-point replicas | Clients just reconnect to another node |
| Nodes needed | 2+ | 3+ (or 2 plus the garbd arbitrator) |
| Network | Tolerates WAN latency | Low-latency LAN; every commit pays one round trip |
| Engines | Any | InnoDB only; every table needs a primary key |
Async replication is still the right tool for a remote DR site or a reporting copy; you can even hang an async replica off a Galera node later. Galera is for when you want a local HA database that survives a node failure without anyone running a failover.
Lab layout
| Host | IP | Role before | Role after |
|---|---|---|---|
db1.example.lan | 192.168.1.40 | Primary (parts 1-4), holds the data | Galera node, bootstraps the cluster |
db2.example.lan | 192.168.1.41 | Async replica (part 4) | Galera node, joins via SST |
db3.example.lan | 192.168.1.42 | New host | Galera node, joins via SST |
Prerequisites
- Three AlmaLinux 10 hosts on the same LAN, MariaDB installed and secured as in part 1 on db1. db2 and db3 only need the packages; their data will be replaced by a full copy from the cluster.
- Low latency between nodes (same data centre, ideally under 1 ms). Galera across a WAN works but every commit gets slower.
- chrony running on every node and name resolution (DNS or
/etc/hosts) for all three hosts. - A fresh, tested backup of db1 taken with the method from part 3. Converting a server to Galera is a change you want an easy way back from.
- Every application table using InnoDB and having a primary key (checked below).
- A maintenance window: db1 is restarted once to bootstrap the cluster.
Step 1: Check the existing data is Galera-ready
On db1, list any tables that are not InnoDB, and any InnoDB tables without a primary key. Galera only replicates InnoDB, and tables without a primary key replicate slowly and can diverge.
sudo mariadb -e "
SELECT table_schema, table_name, engine
FROM information_schema.tables
WHERE table_type='BASE TABLE'
AND engine <> 'InnoDB'
AND table_schema NOT IN ('mysql','information_schema','performance_schema','sys');
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 t.table_type='BASE TABLE' AND c.constraint_name IS NULL
AND t.table_schema NOT IN ('mysql','information_schema','performance_schema','sys');"Both queries should return nothing. Convert stragglers with ALTER TABLE shop.t ENGINE=InnoDB; and add a key with ALTER TABLE shop.t ADD COLUMN id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY FIRST; (test on a copy first; both rebuild the table).
Step 2: Retire the async replication from part 4
db2 will get a fresh copy of the data from the cluster, so stop and remove its replica configuration first. On db2:
sudo mariadb -e "STOP SLAVE; RESET SLAVE ALL;"
sudo systemctl stop mariadb
sudo mv /etc/my.cnf.d/zz-replica.cnf /root/zz-replica.cnf.part4
sudo mv /etc/my.cnf.d/zz-binlog.cnf /root/zz-binlog.cnf.part4 2>/dev/null || trueOn db1, the replication account is no longer needed. Keep the binary log settings for now; they move into the Galera file in step 6.
sudo mariadb -e "DROP USER IF EXISTS 'repl'@'192.168.1.41';"Step 3: Install the Galera packages (all three nodes)
sudo dnf install -y mariadb-server-galera mariadb-backup socat rsync policycoreutils-python-utils
rpm -q mariadb-server mariadb-server-galera galera
rpm -ql galera | grep libgalera_smm.somariadb-server-galera pulls in mariadb-server and the galera provider library (/usr/lib64/galera/libgalera_smm.so), the galera_new_cluster bootstrap wrapper and a default /etc/my.cnf.d/galera.cnf. mariadb-backup and socat are used by the mariabackup state transfer method chosen below. If you run the MariaDB 11.8 stream from part 1, check the matching package name with dnf list '*server-galera*'; all nodes must run the same major version.
Do not start MariaDB on db2 or db3 yet.
Step 4: Open the Galera ports in firewalld (all nodes)
| Port | Used for |
|---|---|
| 3306/tcp | Client connections |
| 4567/tcp (and udp only with multicast) | Galera group communication and replication |
| 4568/tcp | IST: incremental state transfer to a rejoining node |
| 4444/tcp | SST: full state transfer (mariabackup or rsync) |
Only the other cluster nodes need 4567, 4568 and 4444. Part 2 created a dbclients zone for trusted database sources; firewalld allows a source address in only one zone, so the simplest approach is to add the node addresses and Galera ports to that same zone. (Commands are explained in the firewalld cheat sheet.)
# Run on each node. Create the zone first if you skipped part 2:
# sudo firewall-cmd --permanent --new-zone=dbclients
for ip in 192.168.1.40 192.168.1.41 192.168.1.42; do
sudo firewall-cmd --permanent --zone=dbclients --add-source=${ip}/32
done
for port in 3306/tcp 4567/tcp 4568/tcp 4444/tcp; do
sudo firewall-cmd --permanent --zone=dbclients --add-port=$port
done
sudo firewall-cmd --reload
sudo firewall-cmd --zone=dbclients --list-allAn ALREADY_ENABLED warning just means part 4 already added that address. A ZONE_CONFLICT error means the address is bound to another zone; remove it there or add the ports to that zone instead.
Step 5: Let SELinux allow the Galera ports (all nodes)
Keep SELinux enforcing. The MariaDB daemon runs as mysqld_t and may only bind ports labelled mysqld_port_t. Check what the ports are labelled today:
sudo semanage port -l | grep -E '^mysqld_port_t'
sudo semanage port -l | grep -wE '4444|4567|4568'On a stock system 3306 is already mysqld_port_t, while 4567 and 4444 are usually pre-assigned to other types (tram_port_t and kerberos_port_t) and 4568 is unassigned. Add the label where it is missing and modify it where another type holds the port:
for p in 4444 4567 4568; do
sudo semanage port -a -t mysqld_port_t -p tcp $p 2>/dev/null \
|| sudo semanage port -m -t mysqld_port_t -p tcp $p
done
sudo semanage port -l | grep -E '^mysqld_port_t'Relabelling 4444 only matters if the same host also runs the obsolete Kerberos krb524 service, which a dedicated database node should not. State transfers also run helper scripts (wsrep_sst_mariabackup, socat, rsync); if a joiner fails during SST, check ausearch -m AVC -ts recent as shown in the troubleshooting section rather than turning SELinux off.
Step 6: Create the SST account (db1 only)
The mariabackup SST method runs mariadb-backup on the donor node, which needs a database account. Create it on db1 now; it reaches the other nodes through the cluster itself.
sudo mariadb <<'SQL'
CREATE USER 'sst'@'localhost' IDENTIFIED BY 'Use-A-Long-Random-SST-Passw0rd';
GRANT RELOAD, PROCESS, LOCK TABLES, BINLOG MONITOR ON *.* TO 'sst'@'localhost';
SQLBINLOG MONITOR is the MariaDB 10.5+ name for what older versions called REPLICATION CLIENT. Generate a real password (for example openssl rand -base64 24) and use it in the next step.
Step 7: Write the Galera configuration (all nodes)
Rather than editing the packaged galera.cnf, put the cluster settings in /etc/my.cnf.d/zz-galera.cnf. Files in that directory are read in alphabetical order and later values win, so this file overrides the defaults and survives package updates. On db1, first move the part 3/4 binary log file out of the way, because its settings are folded into this file:
# db1 only
sudo mv /etc/my.cnf.d/zz-binlog.cnf /root/zz-binlog.cnf.part4Then create /etc/my.cnf.d/zz-galera.cnf on every node. Only wsrep_node_name, wsrep_node_address and gtid_domain_id change per node:
sudo tee /etc/my.cnf.d/zz-galera.cnf <<'EOF'
[mariadb]
# --- required for Galera ---
wsrep_on = ON
wsrep_provider = /usr/lib64/galera/libgalera_smm.so
wsrep_cluster_name = "shop_cluster"
wsrep_cluster_address = "gcomm://192.168.1.40,192.168.1.41,192.168.1.42"
binlog_format = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
bind_address = 0.0.0.0
# --- this node (change on db2 / db3) ---
wsrep_node_name = "db1"
wsrep_node_address = "192.168.1.40"
gtid_domain_id = 11
# --- state transfer ---
wsrep_sst_method = mariabackup
wsrep_sst_auth = sst:Use-A-Long-Random-SST-Passw0rd
wsrep_provider_options = "gcache.size=1G"
# --- binary log kept for point-in-time recovery (part 3) ---
server_id = 1
log_bin = mariadb-bin
log_slave_updates = ON
binlog_expire_logs_seconds = 1209600
wsrep_gtid_mode = ON
wsrep_gtid_domain_id = 1
# --- applier threads, roughly the number of CPU cores ---
wsrep_slave_threads = 4
EOF
sudo chmod 640 /etc/my.cnf.d/zz-galera.cnf
sudo chown root:mysql /etc/my.cnf.d/zz-galera.cnfWhat the less obvious settings do:
wsrep_cluster_addresslists every node, including the node itself. A starting node tries each address until it finds a running member.innodb_autoinc_lock_mode = 2(interleaved) is required so that concurrent inserts do not deadlock on auto-increment locks. Galera also offsets auto-increment values per node by default (wsrep_auto_increment_control), so IDs will have gaps; that is expected.bind_address = 0.0.0.0replaces the single-address bind from part 2. The firewall zone limits who can actually connect. You can set it to the node’s own IP instead.gcache.sizeis the on-disk ring buffer of recent write-sets. A node that was down for less time than the gcache covers rejoins with a fast IST instead of a full SST. Size it to cover your longest planned maintenance.wsrep_gtid_mode, the sharedwsrep_gtid_domain_id,log_slave_updatesand the samelog_binname andserver_idon every node keep binary log GTIDs consistent across nodes, as the MariaDB documentation recommends. The per-nodegtid_domain_idvalues (11, 12, 13) keep any local, non-replicated transaction from colliding with cluster GTIDs.gtid_strict_modefrom part 4 is deliberately not carried over.wsrep_sst_authholds a password, which is why the file is mode 640 owned byroot:mysql.
On db2 set wsrep_node_name = "db2", wsrep_node_address = "192.168.1.41", gtid_domain_id = 12; on db3 use db3, 192.168.1.42, 13. Check the merged configuration on each node:
my_print_defaults --mysqld | grep -E 'wsrep|gtid|server_id|log_bin|bind'If a line appears twice, the last one is the value the server uses. The packaged galera.cnf sets wsrep_cluster_address="dummy://", which our file overrides.
Step 8: Bootstrap the cluster on db1
A new cluster is started exactly once, on the node that holds the data, with galera_new_cluster. It starts mariadbd with --wsrep-new-cluster, so the node forms a new cluster instead of looking for one. Never use it to start a node while other members are running, or you create a second, diverging cluster (a split brain).
# db1
sudo systemctl stop mariadb
sudo galera_new_cluster
sudo systemctl status mariadb --no-pager
sudo mariadb -e "SHOW GLOBAL STATUS WHERE Variable_name IN
('wsrep_cluster_size','wsrep_cluster_status','wsrep_local_state_comment','wsrep_ready');"Expected output on the first node:
+---------------------------+---------+
| Variable_name | Value |
+---------------------------+---------+
| wsrep_cluster_size | 1 |
| wsrep_cluster_status | Primary |
| wsrep_local_state_comment | Synced |
| wsrep_ready | ON |
+---------------------------+---------+Leave MariaDB on db1 enabled as a normal service (systemctl enable mariadb); you only use galera_new_cluster when there is no running cluster at all.
Step 9: Join db2 and db3
Start the remaining nodes one at a time with the normal service. Each finds db1, sees it has no state, and receives a full copy (SST) via mariadb-backup streamed over socat on port 4444. Any data that was in db2’s datadir is replaced.
# db2 first, then db3 once db2 shows Synced
sudo systemctl enable --now mariadb
sudo journalctl -u mariadb -f # watch the SST; Ctrl+C when it reports SyncedA large database can take a while; the donor (db1) keeps serving traffic while mariadb-backup copies it. On the joiner you will see the state move from Joining through Joined to Synced. If systemd times out during a very long SST, raise the start timeout with a drop-in:
sudo systemctl edit mariadb
# add:
# [Service]
# TimeoutStartSec=0Step 10: Verify the cluster
On any node:
sudo mariadb -e "SHOW GLOBAL STATUS WHERE Variable_name IN
('wsrep_cluster_size','wsrep_cluster_status','wsrep_connected','wsrep_ready',
'wsrep_local_state_comment','wsrep_incoming_addresses',
'wsrep_cluster_state_uuid','wsrep_last_committed');"All three nodes should report wsrep_cluster_size = 3, Primary, Synced, wsrep_ready = ON, the same wsrep_cluster_state_uuid, and wsrep_last_committed values that match (or nearly match under load). Now prove that writes really go everywhere:
# db3: write
sudo mariadb -e "CREATE DATABASE IF NOT EXISTS galera_test;
CREATE TABLE galera_test.t (id INT AUTO_INCREMENT PRIMARY KEY, node VARCHAR(10), ts DATETIME DEFAULT NOW());
INSERT INTO galera_test.t (node) VALUES ('db3');"
# db2: write
sudo mariadb -e "INSERT INTO galera_test.t (node) VALUES ('db2');"
# db1: read both rows
sudo mariadb -e "SELECT * FROM galera_test.t;"You should see both rows on db1 immediately, with non-consecutive IDs because of the per-node auto-increment offset. Keep the test table for the failure test below. Also confirm the existing application data and accounts from part 2 arrived on db3 with SHOW DATABASES; and SELECT user,host FROM mysql.user;.
Step 11: Test a node failure
# db3: simulate a failure
sudo systemctl stop mariadb
# db1: the cluster shrinks but stays Primary and writable
sudo mariadb -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"
sudo mariadb -e "INSERT INTO galera_test.t (node) VALUES ('db1-while-db3-down');"
# db3: rejoin; it should use IST (fast) because the gap is in gcache
sudo systemctl start mariadb
sudo journalctl -u mariadb --since "-5 min" | grep -iE 'IST|SST|Synced'
sudo mariadb -e "SELECT * FROM galera_test.t;" # db3 has the row written while it was down
# clean up (any node)
sudo mariadb -e "DROP DATABASE galera_test;"With three nodes, losing one leaves two of three, a majority, so the cluster stays Primary. Losing two at once (or a network split into 1+1+1) leaves no majority and the survivors stop accepting queries with WSREP has not yet prepared node for application use. That is Galera protecting you from split brain, not a bug.
Operating the cluster
Restarting one node
Use plain systemctl restart mariadb, one node at a time, waiting for Synced before moving on. This is also how you apply OS patches and minor MariaDB updates as a rolling upgrade.
Restarting the whole cluster
Stop nodes one at a time; the last node stopped has the newest data and marks itself safe to bootstrap. Check /var/lib/mysql/grastate.dat on each node:
sudo cat /var/lib/mysql/grastate.dat
# GALERA saved state
# version: 2.1
# uuid: 9a1c...-...
# seqno: 18452
# safe_to_bootstrap: 1Bootstrap with galera_new_cluster on the node with safe_to_bootstrap: 1 (the highest seqno), then start the others with systemctl start mariadb.
Recovering after all nodes crashed
After a power loss every node shows seqno: -1 and safe_to_bootstrap: 0. Recover the last committed position on each node without starting it for clients:
sudo -u mysql /usr/libexec/mariadbd --wsrep-recover --log-error=/tmp/wsrep-recover.log
grep 'Recovered position' /tmp/wsrep-recover.log
# WSREP: Recovered position: 9a1c...:18460Pick the node with the highest number after the colon, set safe_to_bootstrap: 1 in its grastate.dat (only on that one node), run galera_new_cluster there, and start the rest normally. Bootstrapping from a node that is behind silently throws away the transactions only the others had.
Two nodes only? Use an arbitrator
Two nodes cannot form a majority after one fails, so both stop. If you only have two database servers, run the Galera arbitrator garbd (shipped in the galera package) on a third small machine. It takes part in quorum votes but stores no data. Configure it in /etc/sysconfig/garb with GALERA_NODES and GALERA_GROUP="shop_cluster", open 4567/tcp to it, and start it with systemctl enable --now garb.
Backups from a Galera node
The part 3 backup script works on any one node. Run it on a node that applications do not write to, and add --galera-info to the mariadb-backup command so the backup records the cluster position. To keep a heavy backup from triggering flow control and slowing the cluster, desynchronise the node for the duration:
sudo mariadb -e "SET GLOBAL wsrep_desync = ON;"
sudo /usr/local/sbin/db-backup.sh
sudo mariadb -e "SET GLOBAL wsrep_desync = OFF;"Pointing applications at the cluster
Applications can connect to any node, but writing to several nodes at once causes certification conflicts: if two nodes change the same row at the same moment, one transaction is rolled back at commit with a deadlock error (1213). Most applications are happiest with one writer node at a time and the others used for reads and as hot standbys. A small HAProxy instance does this well:
# /etc/haproxy/haproxy.cfg (on an app or proxy host)
listen galera_write
bind 192.168.1.30:3306
mode tcp
option tcpka
option mysql-check user haproxy_check
server db1 192.168.1.40:3306 check
server db2 192.168.1.41:3306 check backup
server db3 192.168.1.42:3306 check backup-- on any Galera node; replicated to all. Allows only a check login, no privileges.
CREATE USER 'haproxy_check'@'192.168.1.30';Add 192.168.1.30 to the dbclients zone on each node, allow HAProxy to connect out on 3306 under SELinux with setsebool -P haproxy_connect_any 1, and pair two HAProxy hosts with a floating IP using keepalived for IP failover if the proxy itself must not be a single point of failure. Note that mysql-check only proves the port answers; for a check that a node is actually Synced, use a small script that reads wsrep_local_state (4 = Synced) behind an HTTP check.
Galera limitations worth knowing
- Only InnoDB is replicated. MyISAM/Aria tables exist only on the node where they were written.
- Tables need a primary key. Deletes on tables without one can be very slow on the other nodes and may diverge.
LOCK TABLES,GET_LOCK()and XA transactions are not supported across the cluster.- DDL (
ALTER TABLE) runs in Total Order Isolation by default: the whole cluster waits for it. For big tables, schedule it, or useSET SESSION wsrep_OSU_method='RSU';node by node for changes that are compatible both ways. - Huge transactions are limited by
wsrep_max_ws_sizeand stall the cluster while they replicate. Break bulk loads into batches of a few thousand rows, or enable streaming replication for that session (SET SESSION wsrep_trx_fragment_size=10000;). - The slowest node sets the pace: flow control pauses writes while any node’s apply queue is too long.
Encrypting cluster traffic
Galera replication traffic on 4567/4568 and SST on 4444 are unencrypted by default, so keep the nodes on a dedicated, trusted network. To encrypt replication, give each node a certificate signed by your CA (with both TLS Web Server and Client Authentication in its extended key usage) and add the paths to the provider options on every node:
wsrep_provider_options = "gcache.size=1G;socket.ssl_cert=/etc/pki/tls/certs/db1.crt;socket.ssl_key=/etc/pki/tls/private/db1.key;socket.ssl_ca=/etc/pki/tls/certs/db-ca.crt"All nodes must switch at the same time (a full cluster restart), because encrypted and unencrypted nodes cannot talk to each other. Part 7 of this series covers client TLS in detail.
Troubleshooting
Bootstrap fails: “It may not be safe to bootstrap the cluster”
grastate.dat has safe_to_bootstrap: 0 because this node was not the last one to stop. Find the most advanced node as shown in “Recovering after all nodes crashed” and bootstrap that one. Only edit the flag when you are sure.
Joiner fails with “failed to reach primary view” or times out
- From the joiner, test each port:
nc -zv 192.168.1.40 4567(installnmap-ncat). A timeout points at firewalld on the other node; “connection refused” means nothing is listening. - Check
wsrep_cluster_nameis identical on every node andwsrep_cluster_addressstarts withgcomm://. - Make sure at least one listed node is actually running and
Primary.
SST fails
# on the joiner
sudo journalctl -u mariadb --since "-15 min" | grep -iE 'sst|error'
sudo ls -l /var/lib/mysql/*.log
sudo cat /var/lib/mysql/mariabackup.backup.log # on the donor
sudo cat /var/lib/mysql/mariabackup.prepare.log # on the joiner
sudo ausearch -m AVC -ts recentAccess denied for user 'sst': thewsrep_sst_authpassword does not match the account on the donor.socat: not foundormariabackup not in path: installsocatandmariadb-backupon every node, because any node can be donor or joiner.- AVC denials for
mysqld_t: confirm step 5 was done on both donor and joiner. If a denial remains, review it withausearch -m AVC -ts recent | audit2whyand build a narrow local module withaudit2allow -M galera_localrather than setting SELinux permissive. - Port 4444 already in use: a previous SST is stuck. Stop MariaDB on the joiner and look for a leftover
socatprocess.
“WSREP has not yet prepared node for application use”
The node is not part of a Primary component, usually after losing quorum. Check wsrep_cluster_status on all nodes. If one surviving node is definitely the most current and the others are gone for good, you can force it to become Primary with SET GLOBAL wsrep_provider_options='pc.bootstrap=YES'; on that node only. Then rebuild the others by letting them rejoin.
Deadlock errors (1213) at COMMIT
Certification conflicts from writing the same rows on different nodes. Send writes to a single node (the HAProxy setup above), and make sure the application retries a transaction that fails with 1213.
The whole cluster is slow
sudo mariadb -e "SHOW GLOBAL STATUS WHERE Variable_name IN
('wsrep_flow_control_paused','wsrep_local_recv_queue_avg','wsrep_local_send_queue_avg','wsrep_cert_deps_distance');"A wsrep_flow_control_paused value well above 0 means a node cannot keep up. Find the node with the long receive queue, then look at its disk and CPU, raise wsrep_slave_threads towards wsrep_cert_deps_distance, and check for large transactions or DDL.
MySQL equivalent
Oracle MySQL does not ship Galera. Its built-in synchronous option is Group Replication, usually deployed as InnoDB Cluster with MySQL Shell and MySQL Router. The concepts (majority quorum, single-primary mode recommended, primary keys required) are the same, but the setup commands are entirely different. Percona XtraDB Cluster is the Galera-based option for MySQL-compatible servers.
Quick reference
| Task | Command |
|---|---|
| Bootstrap a new / fully stopped cluster | galera_new_cluster (one node only) |
| Start or join a node | systemctl start mariadb |
| Cluster size and state | SHOW GLOBAL STATUS LIKE 'wsrep_cluster_s%'; |
| This node’s state | SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment'; |
| Who is in the cluster | SHOW GLOBAL STATUS LIKE 'wsrep_incoming_addresses'; |
| Last committed seqno | cat /var/lib/mysql/grastate.dat |
| Recover position after a crash | sudo -u mysql /usr/libexec/mariadbd --wsrep-recover |
| Pause a node for backup | SET GLOBAL wsrep_desync = ON; |
| Force Primary (last resort) | SET GLOBAL wsrep_provider_options='pc.bootstrap=YES'; |
Next in the series
Part 6 covers performance tuning: the InnoDB buffer pool, the slow query log and finding the queries that hurt. Earlier parts: part 4, GTID primary/replica replication, part 3, backups and point-in-time recovery, part 2, users, grants and remote access and part 1, install and secure MariaDB/MySQL. For the classic two-way setup on older systems, see configuring MySQL multi-master replication.
Official references: RHEL 10: deploying MariaDB Galera Cluster, MariaDB: configuring MariaDB Galera Cluster, MariaDB: using GTIDs with Galera Cluster and Galera Cluster documentation.