MariaDB / Advanced: evidence and reliable operations / Lesson 15
Replication, GTIDs and Galera concepts
Compare asynchronous replication with Galera certification and interpret replica health. Design consistency and failover requirements before selecting topology.
On this page
Lesson goals
- Separate event retrieval from event application.
- Explain MariaDB GTIDs and Galera conflicts without promising zero data loss.
A replica receives and applies history
In standard asynchronous replication, the primary writes binary-log events, a replica retrieves them into relay logs and an applier reproduces their effects. Receipt is different from application. A healthy connection can coexist with a stopped applier, and a running applier may still lag a busy primary. Reading a replica immediately after a primary write can therefore return older data. Define whether an endpoint permits stale reads and how a read-your-writes request chooses or waits for an appropriate server.
Read both replication threads
SHOW REPLICA STATUS is a modern synonym; older MariaDB releases also expose SHOW SLAVE STATUS. Field names can retain historical terminology. Inspect Slave_IO_Running, Slave_SQL_Running, Last_IO_Error, Last_SQL_Error and progress positions together. Seconds_Behind_Master is one signal and may be NULL or misleading in some states, so do not certify currency from one number. Monitoring privileges and channel selection vary by release; a permission error is not evidence that replication stopped.
SHOW REPLICA STATUS;
SELECT @@global.gtid_slave_pos, @@global.gtid_binlog_pos;Read-only monitoring examples; actual status is environment-dependent and no healthy output is fabricated.
MariaDB GTIDs have their own meaning
A MariaDB GTID has domain, server and sequence components such as 0-17-42. It identifies an event group in its replication history; it is not interchangeable with MySQL GTID format or semantics. Multiple domains require topology-aware interpretation, not a simple maximum-number comparison. Local writes on a replica can contaminate assumptions about current_pos, which combines history sources differently from slave_pos. Reconfiguration and promotion need a reviewed plan, consistent history and fencing of the old writer.
Certification moves conflicts to commit
Galera uses virtually synchronous write-set replication with certification. Transactions execute locally, then their write sets undergo conflict checking in a global order. Conflicting concurrent transactions can be aborted, so applications still need retry logic. A write accepted on one node does not imply every ordinary read on another node has already observed its application; causal-read settings and routing matter. Healthy quorum and state transfer are operational requirements, and multi-primary capability does not promise unlimited write scaling.
SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status';
SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';
SHOW GLOBAL STATUS LIKE 'wsrep_flow_control_paused';These status names are useful only on a Galera-enabled deployment. Empty or absent results require context.
Choose recovery and consistency deliberately
A three-node Galera design can tolerate some node failures when quorum and connectivity conditions hold, but a logical DELETE can propagate to every node. An asynchronous replica can scale reads but cannot by itself guarantee zero-loss failover. Protect independent backups in either topology. Define promotion authority, application routing, lag thresholds, transaction retry rules and split-brain prevention before an outage. Verify exact MariaDB and provider versions; replication syntax and compatibility are not universal across MariaDB, MySQL and Galera releases.
Common errors and fixes
The replica reads stale data with both threads running
- Why it happens
- Running threads do not prove all primary events are applied.
- How to fix it
- Compare progress and application freshness requirements, then route accordingly.
- Prevent it next time
- Implement a documented stale-read or read-your-writes policy.
Skipping a replication error hides divergence
- Why it happens
- The failed event was bypassed without understanding data history.
- How to fix it
- Preserve diagnostics and investigate conflict or rebuild from a known consistent source.
- Prevent it next time
- Avoid local replica writes and rehearse recovery instead of blind event skipping.
Galera transactions fail during concurrent updates
- Why it happens
- Certification rejected conflicting write sets.
- How to fix it
- Rollback and retry the complete bounded idempotent operation.
- Prevent it next time
- Reduce hot-row contention and include certification failures in capacity tests.
Check your understanding
1. The I/O thread is Yes, SQL thread is No, and Last_SQL_Error names a duplicate key. Is the first action a network restart?
Show worked solution
No. Retrieval is functioning while application failed. Preserve the failing event context and investigate divergent data, local writes or incompatible schema using an authorized runbook. A network restart does not resolve a duplicate-key apply conflict. Do not skip the event simply to make status green; establish a consistent recovery or rebuild decision.
2. Why are three Galera nodes not a substitute for a separate backup after an accidental table deletion?
Show worked solution
A committed logical change can be replicated to all nodes, so every live copy may faithfully contain the mistake. Restore from a protected earlier artifact and, if available, replay a verified log chain only to the last good boundary. High availability addresses node service continuity; historical recovery requires retained independent history.
Key takeaways
- Connection health, apply progress and read freshness are separate facts.
- MariaDB GTIDs and Galera require topology-specific operational reasoning.