Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Configuring a Galera cluster with MySQL-compatible software requires more than installing a normal MySQL server. Each host must run a wsrep-enabled distribution with a matching Galera provider, use the same cluster identity, advertise reachable addresses, and have replication traffic allowed through the firewall. Configure the nodes first, bootstrap exactly one node with the platform’s new-cluster procedure, then start every other node normally so it joins instead of creating a separate cluster.
What you are configuring
Galera is a virtually synchronous replication layer integrated through the wsrep interface. A transaction is replicated as a write set and the cluster maintains a primary component of participating nodes. The database server, wsrep provider library, service manager, network, and state-transfer method all have to agree; a regular MySQL installation does not become a Galera node simply because a few variables are added to an option file.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The exact commands and file locations depend on the distribution. MariaDB Galera packages, MySQL builds that include wsrep, and vendor distributions can use different provider paths, systemd units, bootstrap helpers, and state-snapshot-transfer methods. Treat the examples below as a version-aware procedure: confirm the package names, provider generation, service name, and bootstrap syntax supplied by your distribution before running them.
Decide the implementation before editing configuration
Confirm that the server has wsrep support
Install a server package explicitly described as wsrep-enabled and install its matching Galera provider on every host. The ordinary MySQL package from a distribution may not contain wsrep at all. Keep the server and provider generations compatible, and use the same major family across nodes unless the vendor documents a supported upgrade combination.
#1 Best Overall
After installation, verify the capability before writing a cluster configuration. Start the server as a standalone instance if necessary and run:
SHOW VARIABLES LIKE 'wsrep%';
SHOW STATUS LIKE 'wsrep%';If the variables do not exist, stop and install the correct build rather than trying to work around the missing provider. A server that starts successfully without wsrep is still only a standalone database.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesChoose node identities and addresses
Give every node a unique wsrep_node_name and a stable address for wsrep_node_address. Use addresses that other nodes can actually route to, not an internal interface that is hidden by cloud NAT or a host-only network. On multi-interface hosts, explicitly bind and advertise the interface used for inter-node traffic. DNS names are acceptable when they resolve consistently on every node; fixed private IP addresses are often easier to troubleshoot.
Select one cluster name and use it identically on all nodes. Build one peer list for wsrep_cluster_address, normally beginning with gcomm:// followed by the addresses of the initial peers. Change only node-specific values such as name and address between copies of the configuration.
Plan state transfer and credentials
A joining node may receive an incremental state transfer (IST) when the donor still has the required write sets, or a full state snapshot transfer (SST) when it does not. Decide which SST method your distribution supports and configure it consistently. Non-mysqldump SST methods use a dedicated transfer listener; credentials and file permissions must allow the donor and joiner to authenticate without exposing the password to ordinary users.
Schedule the first bootstrap while no application is writing to the new cluster. Have a second terminal or console available for service logs, because a failed join is usually explained there before SQL status becomes useful.
Install the wsrep-enabled stack
- Install the wsrep-enabled MySQL-compatible server package on every host.
- Install the Galera provider library version required by that server package.
- Install the distribution’s SST helper or provider-specific utilities if your selected method requires them.
- Enable the database service, but do not start all nodes simultaneously for the first formation.
- Record the service unit name and the vendor’s bootstrap command. Common patterns include a
galera_new_clusterhelper, a dedicated bootstrap systemd unit, or starting the server with--wsrep-new-cluster; these are not interchangeable on every platform.
Do not copy a provider path from a different distribution. Locate the actual Galera shared library installed on that host and use that path in wsrep_provider. A missing or incompatible library generally appears as a provider-load error in the service log.
Build the option-file configuration
Put the settings in the option file read by the server’s service unit. Packages commonly split settings across an included directory, so verify the active file with your distribution documentation rather than assuming one universal path. The following baseline shows the required roles; replace every example value.
[mysqld]
wsrep_on=ON
wsrep_provider=/path/to/libgalera_smm.so
wsrep_cluster_name=example_cluster
wsrep_cluster_address=gcomm://db1.example.internal,db2.example.internal,db3.example.internal
wsrep_node_name=db1
wsrep_node_address=db1.example.internal
binlog_format=ROW
default_storage_engine=InnoDB
wsrep_sst_method=your_supported_method
wsrep_sst_auth=sst_user:replace_with_secretThe first node’s file and the other nodes’ files should contain the same cluster name, provider generation, peer list, row-based binlogging, storage engine, and state-transfer policy. Change wsrep_node_name and wsrep_node_address for each host. Protect the option file if it contains SST credentials; grant read access only to the database service account and administrators.
Required options
| Option | Purpose | What to check |
|---|---|---|
wsrep_provider |
Loads the Galera provider library. | The file exists, is readable by the service, and matches the server build. |
wsrep_cluster_address |
Lists the gcomm peers used for discovery. | Every address resolves or routes from every node; do not leave a persistent empty peer list. |
wsrep_cluster_name |
Gives the cluster a shared identity. | Use exactly the same value on all members. |
wsrep_node_name |
Identifies one member in status output and logs. | Every node must have a unique value. |
wsrep_node_address |
Advertises the address other members use to reach the node. | Use the routable address, especially in cloud or multi-interface deployments. |
binlog_format=ROW |
Uses row-based binary logging required by the documented Galera setup. | Do not replace it with statement or mixed logging for this cluster. |
wsrep_on=ON |
Enables wsrep processing for the server. | Confirm the running value with SHOW VARIABLES. |
default_storage_engine=InnoDB |
Ensures new tables use the Galera-compatible transactional engine. | Check existing tables separately; changing the default does not convert them. |
wsrep_sst_method |
Selects the full-state transfer mechanism. | Use a method supported by this exact distribution and provider. |
Additional provider options may be necessary for TLS, listen addresses, donor selection, or flow control in a particular release. Add them only from the documentation for the installed provider. Avoid solving an address problem by putting an unroutable wildcard or a public address into the cluster list without understanding the resulting exposure.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Open the required network paths
Permit traffic in both directions between every intended member, and permit client traffic only from the application networks that need it. MariaDB’s Galera configuration reference documents these default roles:
| Port | Traffic | Firewall scope |
|---|---|---|
| 4567 | Galera replication and group communication | Allow between cluster nodes; allow the protocol and transport configured by the provider. |
| 4568 | Incremental State Transfer (IST) | Allow between potential donors and joiners. |
| 4444 | SST methods other than mysqldump |
Allow only between the selected donor and joining node when possible. |
| 3306 | Normal MySQL client connections by default | Allow from application and administration networks, not from the public internet. |
These are defaults, not guarantees: a changed listen port, provider setting, SST method, or service configuration changes the rule. Test both directions with the same hostnames or addresses used in wsrep_cluster_address. A successful ping does not prove that the required TCP ports are reachable.
Bootstrap the first cluster safely
Bootstrap is a one-time formation action. It tells the first server that no existing primary component should be discovered and that a new cluster UUID must be created.
- Stop the database service on all nodes. Confirm that no old member is still serving writes under the intended cluster name.
- Check the first node’s provider path, cluster identity, peer addresses, node address, firewall rules, and SST settings. Correct errors before starting.
- Start only the first node with the vendor’s new-cluster procedure. Depending on the package, that may be
galera_new_cluster, a dedicated bootstrap systemd command, or a server invocation containing--wsrep-new-cluster. - Watch the service log until the node reports a primary component and a local synchronized or ready state.
- Start each remaining node normally, without the new-cluster flag. It should discover the first node through
wsrep_cluster_addressand obtain IST or SST state. - Wait for each join to finish before sending it application traffic. A node that merely starts the SQL listener is not necessarily a cluster member.
The MariaDB Galera documentation’s warning is unambiguous: “Do not use the –wsrep-new-cluster option when connecting to an existing cluster.” Using it during an ordinary restart can create a second cluster rather than reconnecting to the established one.
Verify membership from SQL and logs
Run these checks on every node after startup:
SHOW STATUS LIKE 'wsrep_cluster_size';
SHOW STATUS LIKE 'wsrep_cluster_status';
SHOW STATUS LIKE 'wsrep_local_state_comment';
SHOW STATUS LIKE 'wsrep_ready';
SHOW STATUS LIKE 'wsrep_connected';
SHOW VARIABLES LIKE 'wsrep_cluster_address';
SHOW VARIABLES LIKE 'wsrep_on';wsrep_cluster_sizeshould equal the number of members you expect.wsrep_cluster_statusshould report the primary component, not a non-primary state.wsrep_local_state_commentshould reach the provider’s synchronized state after transfer completes.wsrep_readyandwsrep_connectedshould indicate that the node can process replicated traffic.- The running
wsrep_cluster_addressandwsrep_onvalues should match the intended configuration.
Also inspect the service log for the view that lists members, the selected donor, and the result of IST or SST. Check membership before changing application connection strings; otherwise an application can write to a standalone node while administrators believe it is protected by replication.
Rank #4
Understand IST, SST, and donor behavior
Incremental State Transfer
IST sends only the write sets that the joiner missed while it was offline. It normally uses port 4568. It is faster and less disruptive than a full snapshot, but it is possible only while a donor retains the required history and the joiner’s state is compatible.
State Snapshot Transfer
SST copies a complete database state from a donor to the joiner. Methods other than mysqldump use port 4444 by default. Expect a longer transfer and additional disk, CPU, and network load on the donor. Ensure the joiner has enough space for the snapshot plus its existing data directory, and confirm that the selected method is installed on both sides.
Choosing and protecting a donor
The provider may select a donor automatically or use a donor preference configured for the deployment. Keep at least one healthy member available to serve as a donor, and monitor logs during a large SST. Do not expose the SST listener broadly; restrict it to the cluster network and remove temporary firewall exceptions after testing.
Recover after a complete outage
A total outage is different from restarting one node. If every member stopped, there is no running primary component to discover, so choose the node with the most advanced replicated sequence state before forming a new component.
- Keep all database services stopped while you inspect each node’s
grastate.datand provider logs. - Identify the node whose state is most advanced according to the Galera recovery metadata and sequence information.
- On the selected node, follow the vendor’s documented safe-to-bootstrap procedure. The Galera guide describes setting
safe_to_bootstrap: 1in that node’sgrastate.datwhen appropriate. - Start the recovered primary with the platform helper, such as
galera_new_cluster, not by placing an emptygcomm://in the permanent option file. - Start the remaining nodes normally and verify their state transfers and primary membership.
Never persist an empty gcomm:// as a shortcut. Documentation warns that it creates a fresh cluster and can cause every restart to form a different cluster instead of rejoining the original one. Keep bootstrap settings transient and treat safe-to-bootstrap metadata as a recovery control, not a routine restart setting. Take a backup of the state metadata before manual recovery work and document which node was selected.
Best Value
Troubleshoot a node that will not join
| Symptom | Likely causes | Checks and corrective action |
|---|---|---|
| Server starts as a standalone database | wsrep disabled, provider failed to load, or the service was started without the cluster settings. | Check wsrep_on, wsrep_provider, the active option-file includes, and provider-load errors in the log. |
| Joiner cannot discover a peer | Wrong wsrep_cluster_address, DNS failure, incorrect advertised address, or blocked port 4567. |
Resolve every peer from the joiner, test TCP reachability in both directions, and use the routable interface in wsrep_node_address. |
| IST is unavailable and SST fails | Port 4568 or the SST port is blocked, the donor lacks the required history, or the SST method is missing or incompatible. | Read both donor and joiner logs, open the documented ports, install the matching helper, and retry after correcting credentials or method settings. |
| Cluster is non-primary | Network partition, loss of quorum, or an unsafe bootstrap attempt. | Stop applications, determine which component has the authoritative state, and use the documented full-outage recovery process rather than creating another cluster. |
| Node reports a duplicate identity | Two hosts share wsrep_node_name or advertise the same address. |
Assign unique node names and stable, distinct addresses, then restart the affected node normally. |
| SQL is ready but replication is not | Local state is not synchronized, wsrep_ready is off, or the node is outside the primary component. |
Do not direct traffic to it; wait for state transfer and confirm the wsrep status variables and service log view. |
Capture the exact server and provider versions, the active option-file path, the full peer list, and relevant log lines when escalating a failure. Galera behavior is version- and packaging-dependent, so a generic command copied from another distribution can conceal the real problem.
Operational checks before production traffic
- Confirm every member has a unique node name and address and sees the expected cluster size.
- Confirm the primary status, synchronized local state, connected status, and ready status on each node.
- Run a controlled write and read test through the intended application path, then verify the row on another member.
- Measure the time and resource impact of an SST in a staging environment before relying on it during an outage.
- Monitor cluster membership, local state, flow-control or replication warnings exposed by your provider, disk space, and service logs.
- Document the exact bootstrap helper, service unit, provider path, SST method, firewall rules, and full-outage recovery owner.
- Keep the database and provider packages on a tested compatibility line; upgrade one node at a time only when the vendor documents the procedure.
MySQL packaging is not uniform
“MySQL Galera” is not one universal installation target. MariaDB’s official Galera reference supplies the most complete option and port details used in this guide, while Galera vendor material also documents wsrep-enabled MySQL servers and systemd bootstrap procedures. Package names, library paths, service units, helper commands, and supported SST implementations vary by release.
Recommended Free Tools
Before applying an example, write down the exact server distribution and version, provider version, service name, option-file include order, bootstrap command, and SST method. Label internal runbooks with those values. This prevents a MariaDB helper from being used against a differently packaged MySQL wsrep build, or a provider path from being copied onto a host where the library has another name.
Final configuration checklist
- Every host runs a wsrep-enabled server and a compatible Galera provider.
wsrep_provider,wsrep_cluster_address,binlog_format=ROW,wsrep_on=ON, anddefault_storage_engine=InnoDBare present and active.- The cluster name and peer list are consistent; node names and advertised addresses are unique and routable.
- Ports 4567, 4568, 4444 when required, and client port 3306 are allowed according to the actual deployment.
- The first node was bootstrapped once with the vendor’s new-cluster procedure.
- All subsequent nodes were started normally and completed IST or SST.
- SQL status and logs show a primary component with the expected synchronized members.
- No empty
gcomm://is stored persistently, and the safe-to-bootstrap recovery procedure is documented for a total outage.
When these checks pass, the cluster is configured rather than merely running several independent database servers. Keep the bootstrap action exceptional, keep package-specific details in the runbook, and verify wsrep membership before every node receives production writes.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
