[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-mariadb-mariadb-replication-and-ha":3,"mdc-j1v3pw-key":31,"related-org-mariadb-mariadb-replication-and-ha":2922,"related-repo-mariadb-mariadb-replication-and-ha":3020},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":20,"repoUrl":21,"updatedAt":22,"license":23,"forks":24,"topics":25,"repo":26,"sourceUrl":29,"mdContent":30},"mariadb-replication-and-ha","configure MariaDB replication and high availability","Best practices for MariaDB replication and high availability — Galera Cluster, GTID replication, semi-synchronous replication, parallel replication, and application patterns for HA environments. Use when setting up replication, designing applications for HA, working with Galera Cluster, asking about MariaDB GTID, handling replication lag in application code, or choosing between replication topologies. IMPORTANT — MariaDB GTID format is incompatible with MySQL GTID, and Galera Cluster needs no server plugin to load but does require the separate galera wsrep provider library (galera-4).",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},"mariadb","MariaDB","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fmariadb.png",[12,16,17],{"name":13,"slug":14,"type":15},"Architecture","architecture","tag",{"name":9,"slug":8,"type":15},{"name":18,"slug":19,"type":15},"Database","database",9,"https:\u002F\u002Fgithub.com\u002FMariaDB\u002Fskills","2026-07-13T06:14:13.989369",null,2,[],{"repoUrl":21,"stars":20,"forks":24,"topics":27,"description":28},[],"MariaDB skills for Claude Code and AI agents - because it is not MySQL","https:\u002F\u002Fgithub.com\u002FMariaDB\u002Fskills\u002Ftree\u002FHEAD\u002Fmariadb-replication-and-ha","---\nname: mariadb-replication-and-ha\ndescription: \"Best practices for MariaDB replication and high availability — Galera Cluster, GTID replication, semi-synchronous replication, parallel replication, and application patterns for HA environments. Use when setting up replication, designing applications for HA, working with Galera Cluster, asking about MariaDB GTID, handling replication lag in application code, or choosing between replication topologies. IMPORTANT — MariaDB GTID format is incompatible with MySQL GTID, and Galera Cluster needs no server plugin to load but does require the separate galera wsrep provider library (galera-4).\"\n---\n\n# MariaDB Replication and High Availability\n\n*Last updated: 2026-06-24*\n\nMariaDB offers three tiers of replication depending on your consistency and availability requirements:\n\n| Approach | Consistency | Failover | Best for |\n|---|---|---|---|\n| **Standard async replication** | Eventual | Manual or tool-assisted | Read scaling, backups, low-latency writes |\n| **Semi-synchronous replication** | Eventual (same as async) | Manual or tool-assisted | Ensuring a replica *received* each commit before the client is acknowledged — bounds failover loss (lossless only with `AFTER_SYNC`) |\n| **Galera Cluster** | Synchronous (multi-primary) | Automatic | Zero-data-loss HA, multi-datacenter writes |\n\n> **Requires:** GTID replication, semi-synchronous replication, and parallel replication (including `optimistic` mode) are all built in and have been available since well before any currently-supported release — assume they are present on the **11.8 LTS** baseline. Current LTS is 11.8 (GA May 2025).\n>\n> **Default context:** Assume MariaDB **11.8 LTS** unless the user states another version. Features marked **12.x** or **13.0** may be suggested when relevant (including as upgrade options), but always state the minimum version — do not present them as available on 11.8.\n\n## What LLMs Get Wrong\n\n| What you might see | What's correct |\n|---|---|\n| `CHANGE REPLICATION SOURCE TO`, `SOURCE_*` connection options | MariaDB has no `CHANGE REPLICATION SOURCE TO` — use `CHANGE MASTER TO` with `MASTER_*` options. Since 10.5.1, `START REPLICA` \u002F `SHOW REPLICA STATUS` are canonical; `START SLAVE` \u002F `SHOW SLAVE STATUS` are legacy aliases |\n| `replica_parallel_type` with values `DATABASE` or `LOGICAL_CLOCK` | MariaDB uses `slave_parallel_mode` (`optimistic` \u002F `conservative` \u002F `aggressive` \u002F `minimal` \u002F `none`) — a different implementation; MySQL's mode settings do not port over. Pool size: `slave_parallel_threads` |\n| MySQL GTID format or `gtid_mode=ON` syntax | MariaDB GTID uses a different format (`domain-server-seq`) and different commands — MySQL and MariaDB GTIDs are **incompatible** |\n| MySQL Group Replication or InnoDB Cluster — `START GROUP_REPLICATION`, `group_replication_*` variables, MySQL Shell `dba.createCluster()` | MariaDB has **no Group Replication and no InnoDB Cluster** — Group Replication is [incompatible with MariaDB](https:\u002F\u002Fmariadb.com\u002Fdocs\u002Frelease-notes\u002Fcommunity-server\u002Fabout\u002Fcompatibility-and-differences\u002Fmariadb-vs-mysql-compatibility). The synchronous multi-primary equivalent is **Galera Cluster** (built in) |\n| \"Install the Galera plugin\" | There is no Galera *plugin* to load — wsrep support is built into the MariaDB server. But a cluster still requires the separate **Galera wsrep provider library** (`galera-4` \u002F `libgalera_smm.so`, set via `wsrep_provider`); on 12.3+ you must install it yourself (see the Galera Cluster section) |\n| Assuming sequential `AUTO_INCREMENT` in Galera | Galera produces gaps in auto-increment sequences across nodes by design — never rely on sequential values |\n| `LOCK TABLES` or `GET_LOCK()` in a Galera environment | Not supported in Galera — use transactions instead |\n| Treating a replica as a backup | Replication is not a backup — a `DROP TABLE` on the primary replicates immediately to all replicas |\n| Tables without primary keys in a Galera cluster | All tables in Galera must have a primary key — `DELETE` fails on keyless tables |\n\n## Standard Async Replication\n\nThe foundation: one primary, one or more replicas. The primary writes to the binary log; replicas apply changes asynchronously.\n\n**GTID-based replication is the default since MariaDB 10.10** (MDEV-19801) and remains so on 10.11 LTS, 11.4 LTS, and 11.8 LTS. On a fresh replica start, a `RESET SLAVE`, or a `CHANGE MASTER TO` that omits `MASTER_USE_GTID`, the replica defaults to `slave_pos` instead of legacy file\u002Fposition. If you have configs that rely on the old behavior, set `MASTER_USE_GTID=no` explicitly.\n\n```sql\n-- On replica (10.10+ — MASTER_USE_GTID is optional, slave_pos is the default):\nCHANGE MASTER TO\n  MASTER_HOST='primary.host',\n  MASTER_USER='repl_user',\n  MASTER_PASSWORD='password',\n  MASTER_USE_GTID = slave_pos;\n\nSTART SLAVE;\n```\n\n**Promoting a replica to primary** — historically `MASTER_USE_GTID=current_pos` was used to include locally-written GTIDs. **`current_pos` is deprecated since 10.10** (MDEV-20122). Use `MASTER_DEMOTE_TO_SLAVE=1` instead: it converts the old primary's `gtid_binlog_pos` into `gtid_slave_pos` so the demoted server can attach to the new primary cleanly without race conditions.\n\n```sql\n-- On the former primary, being demoted to a replica (10.10+):\nCHANGE MASTER TO\n  MASTER_HOST='new_primary.host',\n  ...,\n  MASTER_DEMOTE_TO_SLAVE=1;\nSTART SLAVE;\n```\n\nSince MariaDB 13.0, `CHANGE MASTER` also resets `Master_Server_Id` in `SHOW SLAVES STATUS`. On older versions this field could carry stale values across primary changes — check it explicitly when reconfiguring replication on pre-13.0 servers.\n\n### MariaDB GTID Format\n\nMariaDB GTIDs have three components: `domain_id-server_id-sequence` (e.g., `0-1-247`).\n\nThis is **different from MySQL's** `server_uuid:sequence` format. They are not compatible — a MariaDB primary cannot replicate to a MySQL replica using GTIDs, and vice versa.\n\n**Domain IDs** (`gtid_domain_id`) identify independent replication streams. The rule is about **concurrency of writes, not server count** — a common and damaging mistake is to give every server its own domain ID:\n\n- **Single active primary, including simple failover:** leave `gtid_domain_id = 0` on **all** servers. In an `A → B` pair where `B` is later promoted (so it becomes `B → A`), `A` and `B` **share the same** domain ID — do **not** give them different ones.\n- **Multiple primaries updated concurrently** (multi-source, or multi-primary within one topology): give **each concurrently-updated primary** its own distinct `gtid_domain_id`, so each stream stays independently ordered and automatic GTID replica-switchover works correctly.\n\n```sql\n-- Multi-source \u002F multi-primary ONLY — each concurrently-written primary gets its own domain:\nSET GLOBAL gtid_domain_id = 1;   -- on primary A\nSET GLOBAL gtid_domain_id = 2;   -- on primary B\n```\n\nAssigning a distinct domain ID per server otherwise complicates the GTID position and loses the single ordered binlog stream. See [Global Transaction ID](https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fserver\u002Fha-and-performance\u002Fstandard-replication\u002Fgtid).\n\n**Enable `gtid_strict_mode`** alongside domain ID configuration — it catches out-of-order or mixed-domain GTID mistakes before they corrupt a replica's position:\n\n```ini\n# my.cnf on all servers:\ngtid_strict_mode = ON\n```\n\nWith strict mode ON, a replica stops with an error on a GTID ordering violation rather than silently applying out-of-order transactions. Without it, a domain ID misconfiguration can go undetected until the only fix is a full resync.\n\nIn multi-source replication, replication commands and variables (`START SLAVE`, `SHOW SLAVE STATUS`, …) act on the connection named by `default_master_connection`. It was session-only — you had to `SET SESSION default_master_connection='name'` in each session before issuing commands for that source. Since MariaDB 13.0 ([MDEV-9247](https:\u002F\u002Fmariadb.com\u002Fdocs\u002Frelease-notes\u002Fcommunity-server\u002F13.0\u002Fmariadb-13.0-changes-and-improvements)) it can also be set **globally**, making a chosen named connection the default for all sessions.\n\n### Parallel Replication\n\nBy default, replicas apply events serially — `slave_parallel_threads` defaults to `0`, meaning parallel replication is **off** out of the box regardless of the mode setting. To enable it:\n\n```ini\n# my.cnf on replica:\nslave_parallel_threads = 4          # must be > 0 to enable parallel apply\nslave_parallel_mode = optimistic    # default since 10.5.1 — tries parallel, retries on conflict\n```\n\n`optimistic` mode applies transactions in parallel and retries on conflict. Use `conservative` for stricter workloads where conflict retries are unacceptable.\n\n> **Different from MySQL:** MariaDB's `slave_parallel_mode` (`optimistic`, `conservative`, etc.) is its own implementation — not equivalent to MySQL's `replica_parallel_type` (`DATABASE` \u002F `LOGICAL_CLOCK`). Copy-pasting a MySQL parallel-replication mode config will not work. Pool size is `slave_parallel_threads` (alias `slave_parallel_workers`).\n\nSince MariaDB 12.1, parallel replication also works when **asynchronously replicating between two Galera clusters** (MDEV-20065) — useful for cross-datacenter or DR setups where one Galera cluster is an async replica of another.\n\n### Replication Improvements in 10.7–10.11 LTS\n\n- **Two-phase `ALTER TABLE` replication** (10.8+, MDEV-11675, `binlog_alter_two_phase`) — opt-in: when enabled, a large `ALTER TABLE` can start on the replica while the primary is still executing it, rather than only after, which can reduce replication lag during schema changes. Off by default. Treat as advanced\u002Fexperimental — validate thoroughly before relying on it in production rather than enabling it by default.\n- **GTID-aware `mariadb-binlog`** (10.8+, MDEV-4989) — `--start-position` and `--stop-position` accept GTID lists, so point-in-time replay tools can target GTIDs directly without needing binlog file\u002Foffset pairs. (Separately, `--gtid-strict-mode` — on by default — is only a safeguard: it checks that GTID sequence numbers are monotonic per domain and aborts on out-of-order events; it does not enable GTID targeting.) See [mariadb-binlog](https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fserver\u002Fclients-and-utilities\u002Flogging-tools\u002Fmariadb-binlog).\n- **`slave_max_statement_time`** (10.10+, MDEV-27161) — caps how long a single statement may run on the replica SQL thread. If a replicated statement exceeds it, the SQL thread **stops with an error** ([error 3024](https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fserver\u002Freference\u002Ferror-codes\u002Fmariadb-error-codes-3000-to-3099\u002Fe3024)) so a slow or runaway query surfaces instead of lag growing unnoticed. It does **not** skip the statement and continue — replication halts until you investigate and restart it.\n- **`mariadb-binlog --do-domain-ids` \u002F `--ignore-domain-ids` \u002F `--ignore-server-ids`** (10.9+, MDEV-20119) — domain\u002Fserver filtering when extracting binlog events.\n- **Multi-source replication CHANNEL syntax** (10.7+, MDEV-26307) — MySQL-style `FOR CHANNEL 'name'` clauses now work in `CHANGE MASTER TO`, `START SLAVE`, etc.\n\n### Replication Improvements in 11.4 LTS\n\n- **Global limit on binary log disk space** (11.4+, MDEV-31404) — `max_binlog_total_size` (alias `binlog_space_limit`, default `0` = no limit) triggers binlog purging when the total size of all binlogs exceeds the threshold. Combine with `--slave-connections-needed-for-purge` (default `1`) so purging won't run if a configured replica is disconnected. New status variable `binlog_disk_use` reports current disk usage.\n- **GTID index for the binary log** (11.4+, MDEV-4991) — a new GTID-to-position index lets reconnecting replicas seek straight to their start position without scanning whole binlog files. Controlled by `binlog_gtid_index` (default `ON`), `binlog_gtid_index_page_size`, and `binlog_gtid_index_span_min`. Status variables `binlog_gtid_index_hit` \u002F `binlog_gtid_index_miss` let you confirm it's being used.\n- **`SQL_BEFORE_GTIDS` \u002F `SQL_AFTER_GTIDS` for `START SLAVE UNTIL`** (11.4+, MDEV-27247) — finer-grained stopping for staged failover or PITR replay.\n- **Detailed replication-lag fields** (11.4+, MDEV-29639) — `SHOW REPLICA STATUS` adds `Master_last_event_time`, `Slave_last_event_time`, `Master_Slave_time_diff` for clearer lag interpretation than `Seconds_Behind_Master` alone (the 11.6 update built on this — see below).\n\n### Binlog Performance Improvements in 11.7\n\n- **Large-transaction commit no longer freezes other transactions** (11.7+, MDEV-32014) — previously, committing a very large transaction while `log_bin` was on would stall all other transactions until the binlog write completed. This bottleneck is gone.\n- **Async rollback of prepared transactions during binlog crash recovery** (11.7+, MDEV-33853) — faster startup after a crash with many prepared transactions.\n- **`slave_abort_blocking_timeout`** (11.7+, MDEV-34857) — kill long-running queries on a replica when they block replication progress past a threshold. Useful on read replicas that occasionally run long analytical queries.\n\n### Monitoring Replication Lag\n\n```sql\nSHOW SLAVE STATUS\\G\n-- Key fields:\n-- Seconds_Behind_Master: estimated lag in seconds\n-- Last_SQL_Error: last error stopping the SQL thread\n-- Relay_Log_Pos vs Read_Master_Log_Pos: how far behind the relay log is\n```\n\nAlert when `Seconds_Behind_Master > 5` for latency-sensitive applications. A value of `NULL` means replication is not running. Note: `Seconds_Behind_Master` can be misleading on idle primaries — use heartbeat tools (e.g., `pt-heartbeat`) for accurate measurement.\n\nSince MariaDB 11.6 (MDEV-33856), the definition of `Seconds_Behind_Master` was refined and three new columns were added to `SHOW ALL REPLICAS STATUS` plus a new Information Schema `SLAVE_STATUS` table, providing more nuanced lag visibility (e.g., separate measurements for IO vs SQL thread lag).\n\n## Semi-Synchronous Replication\n\nThe primary writes and fsyncs each transaction to its **own** binary log first — making it durable locally — and only then waits for at least one replica to acknowledge that it has *received* the transaction before reporting the commit complete to the client. The `rpl_semi_sync_master_wait_point` setting controls when that wait happens: with `AFTER_SYNC` the primary waits before the changes become visible, so failover to an acknowledged replica is lossless; with `AFTER_COMMIT` (the MariaDB default) the transaction is already committed and visible before the wait, so a crash in that window can still lose it on failover. See [Semisynchronous Replication](https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fserver\u002Fha-and-performance\u002Fstandard-replication\u002Fsemisynchronous-replication).\n\n```sql\n-- Enable on primary:\nSET GLOBAL rpl_semi_sync_master_enabled = 1;\n\n-- Enable on replica:\nSET GLOBAL rpl_semi_sync_slave_enabled = 1;\n```\n\nIf no replica acknowledges within `rpl_semi_sync_master_timeout` (default 10 seconds), the primary falls back to async. Built-in since MariaDB 10.3 — no plugin needed.\n\nUse when: you want at least one replica to have *received* each transaction before the client's commit returns — e.g. to bound failover data loss (use `AFTER_SYNC`). Note that semi-sync only delays commit completion as seen by the client; it does **not** add durability to the primary's own copy, and a transaction lost before any replica receives it is gone regardless of semi-sync.\n\n## Galera Cluster\n\nMulti-primary synchronous replication — all nodes accept reads and writes, changes are certified across the cluster before committing. No single point of failure. Built into MariaDB.\n\n> **Packaging change (12.3+):** The Galera library is no longer included as a server-package dependency or in the MariaDB repositories by default (MDEV-38744). On 12.3+ you must install `galera-4` (or your distro's equivalent) separately when setting up a Galera node. The MariaDB server still understands Galera natively — only the library distribution changed.\n\n### Developer Constraints\n\nThese will break in Galera if you're not aware of them:\n\n**All tables must have a primary key:**\n```sql\n-- ✗ DELETE fails in Galera on keyless tables:\nCREATE TABLE logs (message TEXT);\n\n-- ✅ Always define a PK:\nCREATE TABLE logs (id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, message TEXT);\n```\n\n**AUTO_INCREMENT values have gaps** — Galera uses `auto_increment_increment` and `auto_increment_offset` per node to avoid conflicts, resulting in non-sequential IDs. Never rely on sequential auto-increment in Galera.\n\n**LOCK TABLES, GET_LOCK(), and `FLUSH TABLES {table list} WITH READ LOCK` are not supported** — use transactions. Note: global `FLUSH TABLES WITH READ LOCK` (no table list) IS supported:\n```sql\n-- ✗ Not supported in Galera:\nLOCK TABLES orders WRITE;\n-- ✅ Use a transaction instead:\nBEGIN;\nSELECT ... FOR UPDATE;\nUPDATE ...;\nCOMMIT;\n```\n\n**InnoDB only** — Galera replicates only InnoDB tables. MyISAM has experimental support via `wsrep_replicate_myisam` but is not recommended for production.\n\n**Transaction size limits** — default caps: 128K rows (`wsrep_max_ws_rows`) and 2GB (`wsrep_max_ws_size`). Extremely large transactions degrade cluster performance significantly and may require config tuning. Note: in MariaDB 13.0+, the default `binlog_row_event_max_size` is 64 KB (up from older 8 KB) — relevant when sizing replication events for write-heavy workloads.\n\n**Binary log must be ROW format** — do not change `binlog_format` at runtime in a Galera cluster.\n\n**Write-set retry on conflict** (12.1+) — `wsrep_applier_retry_count` controls how many times an applier retries a write set before erroring out. Tune this if your workload sees transient certification conflicts on busy clusters.\n\n**Automatic SST user account management** (11.6+, MDEV-31809) — Galera now manages the dedicated SST (State Snapshot Transfer) user account automatically; you no longer have to create and grant it manually on every node.\n\n**IP allowlist for nodes joining the cluster** (10.10+, MDEV-27246) — `wsrep_allowlist` restricts which IPs can make SST\u002FIST requests, reducing the attack surface on a Galera cluster's intra-node traffic.\n\n**Query cache:** The query cache was removed in later MariaDB versions and was not required in Galera since MariaDB 10.1.2. No action needed on modern installations.\n\n### Stale Reads and Consistency\n\nGalera is \"virtually synchronous\" — a committed write on one node may not be immediately visible on another without additional synchronization:\n\n```sql\n-- Force a sync point before reading (performance cost):\nSET SESSION wsrep_sync_wait = 1;\nSELECT * FROM orders WHERE id = 42;\n```\n\nUse `wsrep_sync_wait` only where strict read-after-write consistency is required. For most reads, eventual consistency across nodes (milliseconds) is acceptable.\n\n### Lost Updates in Galera\n\nGalera does not prevent lost updates in read-modify-write patterns. Use `SELECT ... FOR UPDATE` explicitly:\n\n```sql\n-- ✗ Race condition — another node could modify between SELECT and UPDATE:\nSELECT balance FROM accounts WHERE id = 1;\n-- ... application logic ...\nUPDATE accounts SET balance = new_value WHERE id = 1;\n\n-- ✅ Lock the row at read time:\nBEGIN;\nSELECT balance FROM accounts WHERE id = 1 FOR UPDATE;\nUPDATE accounts SET balance = new_value WHERE id = 1;\nCOMMIT;\n```\n\n## Replication is Not a Backup\n\nA `DROP TABLE` or `DELETE FROM table` on the primary replicates to all replicas immediately. Replication protects against hardware failure — not against accidental data changes. Maintain independent backups (`mariadb-dump`, `mariadb-backup`) on a schedule separate from replication.\n\nDelayed replication is one mitigation — intentionally lag a replica by a set time:\n```sql\nCHANGE MASTER TO MASTER_DELAY = 3600;  -- 1 hour lag\n```\n\nThis gives a recovery window for accidental changes, but it is still not a substitute for backups.\n\n**Point-in-time recovery (new in 13.0)** — the `innodb_log_archive` variable ([MDEV-37949](https:\u002F\u002Fmariadb.com\u002Fdocs\u002Frelease-notes\u002Fcommunity-server\u002F13.0\u002Fmariadb-13.0-changes-and-improvements)) makes InnoDB preserve the write-ahead log as a continuous sequence of files instead of overwriting the circular redo log. Combined with a base backup, this is intended to enable PITR and incremental backups without relying on the binary log alone. It is **new in the 13.0 rolling release** (not on the 11.8 LTS baseline) — treat it as recent and validate before depending on it for recovery.\n\n## Failover Tools\n\n- **Built-in (no proxy needed)** — Galera failover is automatic: any surviving node keeps accepting writes. For async\u002FGTID replication, MariaDB does controlled primary switchover natively via GTID and `MASTER_DEMOTE_TO_SLAVE` (see [Standard Async Replication](#standard-async-replication) above), typically driven by your own scripts or an orchestrator.\n- **ProxySQL** — open-source (GPLv3) proxy, widely used for read-write splitting and connection pooling with MariaDB.\n- **MaxScale** — MariaDB Corporation's proxy with automatic failover, read-write splitting, and connection routing (detects primary failure and promotes the most up-to-date replica; requires GTID replication). **Not open source** — recent versions (25.01+) are closed-source commercial, and earlier versions used the source-available Business Source License (BSL), not an OSI open-source license. [mariadb.com\u002Fdocs\u002Fmaxscale](https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fmaxscale)\n\nFor basic Galera HA no proxy is required; ProxySQL or MaxScale add connection routing.\n\n> **Galera load balancing requires cluster-state-aware monitoring.** Do not route to all Galera nodes equally — a node in SST (full data copy) or desynced state may be up and accepting connections but behind by potentially millions of transactions. Check `wsrep_local_state`: only `4` (Synced) is safe to route traffic to. ProxySQL can be configured with health checks that monitor `wsrep_` status variables; MaxScale uses the `galeramon` monitor for this purpose. Without state-aware routing, writes to a donor\u002Fdesynced node produce stale reads or integrity issues.\n\n## Sources\n\n- [Replication Overview — MariaDB Docs](https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fserver\u002Fha-and-performance\u002Fstandard-replication\u002Freplication-overview)\n- [GTID — MariaDB Docs](https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fserver\u002Fha-and-performance\u002Fstandard-replication\u002Fgtid)\n- [Parallel Replication — MariaDB Docs](https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fserver\u002Fha-and-performance\u002Fstandard-replication\u002Fparallel-replication)\n- [Semi-Synchronous Replication — MariaDB Docs](https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fserver\u002Fha-and-performance\u002Fstandard-replication\u002Fsemisynchronous-replication)\n- [Galera Cluster Known Limitations — MariaDB Docs](https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fgalera-cluster\u002Freference\u002Fmariadb-galera-cluster-known-limitations)\n- [Auto-Increments in Galera — mariadb.org](https:\u002F\u002Fmariadb.org\u002Fauto-increments-in-galera\u002F)\n- [Automatic Failover with MariaDB Monitor — MaxScale Docs](https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fmaxscale\u002Fmariadb-maxscale-tutorials\u002Fautomatic-failover-with-mariadb-monitor)\n\n*For topics not covered here, see the official MariaDB documentation at [mariadb.com\u002Fdocs](https:\u002F\u002Fmariadb.com\u002Fdocs).*\n",{"data":32,"body":33},{"name":4,"description":6},{"type":34,"children":35},"root",[36,45,55,60,192,251,258,672,678,683,732,817,872,925,954,961,982,1002,1026,1132,1163,1177,1193,1218,1223,1273,1279,1306,1337,1354,1419,1431,1437,1613,1619,1809,1815,1860,1866,1913,1949,1977,1983,2032,2078,2091,2115,2120,2125,2145,2151,2156,2164,2210,2235,2261,2324,2342,2376,2394,2412,2422,2440,2450,2456,2461,2492,2505,2511,2524,2608,2614,2648,2653,2667,2672,2705,2711,2773,2778,2823,2829,2900,2916],{"type":37,"tag":38,"props":39,"children":41},"element","h1",{"id":40},"mariadb-replication-and-high-availability",[42],{"type":43,"value":44},"text","MariaDB Replication and High Availability",{"type":37,"tag":46,"props":47,"children":48},"p",{},[49],{"type":37,"tag":50,"props":51,"children":52},"em",{},[53],{"type":43,"value":54},"Last updated: 2026-06-24",{"type":37,"tag":46,"props":56,"children":57},{},[58],{"type":43,"value":59},"MariaDB offers three tiers of replication depending on your consistency and availability requirements:",{"type":37,"tag":61,"props":62,"children":63},"table",{},[64,93],{"type":37,"tag":65,"props":66,"children":67},"thead",{},[68],{"type":37,"tag":69,"props":70,"children":71},"tr",{},[72,78,83,88],{"type":37,"tag":73,"props":74,"children":75},"th",{},[76],{"type":43,"value":77},"Approach",{"type":37,"tag":73,"props":79,"children":80},{},[81],{"type":43,"value":82},"Consistency",{"type":37,"tag":73,"props":84,"children":85},{},[86],{"type":43,"value":87},"Failover",{"type":37,"tag":73,"props":89,"children":90},{},[91],{"type":43,"value":92},"Best for",{"type":37,"tag":94,"props":95,"children":96},"tbody",{},[97,125,166],{"type":37,"tag":69,"props":98,"children":99},{},[100,110,115,120],{"type":37,"tag":101,"props":102,"children":103},"td",{},[104],{"type":37,"tag":105,"props":106,"children":107},"strong",{},[108],{"type":43,"value":109},"Standard async replication",{"type":37,"tag":101,"props":111,"children":112},{},[113],{"type":43,"value":114},"Eventual",{"type":37,"tag":101,"props":116,"children":117},{},[118],{"type":43,"value":119},"Manual or tool-assisted",{"type":37,"tag":101,"props":121,"children":122},{},[123],{"type":43,"value":124},"Read scaling, backups, low-latency writes",{"type":37,"tag":69,"props":126,"children":127},{},[128,136,141,145],{"type":37,"tag":101,"props":129,"children":130},{},[131],{"type":37,"tag":105,"props":132,"children":133},{},[134],{"type":43,"value":135},"Semi-synchronous replication",{"type":37,"tag":101,"props":137,"children":138},{},[139],{"type":43,"value":140},"Eventual (same as async)",{"type":37,"tag":101,"props":142,"children":143},{},[144],{"type":43,"value":119},{"type":37,"tag":101,"props":146,"children":147},{},[148,150,155,157,164],{"type":43,"value":149},"Ensuring a replica ",{"type":37,"tag":50,"props":151,"children":152},{},[153],{"type":43,"value":154},"received",{"type":43,"value":156}," each commit before the client is acknowledged — bounds failover loss (lossless only with ",{"type":37,"tag":158,"props":159,"children":161},"code",{"className":160},[],[162],{"type":43,"value":163},"AFTER_SYNC",{"type":43,"value":165},")",{"type":37,"tag":69,"props":167,"children":168},{},[169,177,182,187],{"type":37,"tag":101,"props":170,"children":171},{},[172],{"type":37,"tag":105,"props":173,"children":174},{},[175],{"type":43,"value":176},"Galera Cluster",{"type":37,"tag":101,"props":178,"children":179},{},[180],{"type":43,"value":181},"Synchronous (multi-primary)",{"type":37,"tag":101,"props":183,"children":184},{},[185],{"type":43,"value":186},"Automatic",{"type":37,"tag":101,"props":188,"children":189},{},[190],{"type":43,"value":191},"Zero-data-loss HA, multi-datacenter writes",{"type":37,"tag":193,"props":194,"children":195},"blockquote",{},[196,221],{"type":37,"tag":46,"props":197,"children":198},{},[199,204,206,212,214,219],{"type":37,"tag":105,"props":200,"children":201},{},[202],{"type":43,"value":203},"Requires:",{"type":43,"value":205}," GTID replication, semi-synchronous replication, and parallel replication (including ",{"type":37,"tag":158,"props":207,"children":209},{"className":208},[],[210],{"type":43,"value":211},"optimistic",{"type":43,"value":213}," mode) are all built in and have been available since well before any currently-supported release — assume they are present on the ",{"type":37,"tag":105,"props":215,"children":216},{},[217],{"type":43,"value":218},"11.8 LTS",{"type":43,"value":220}," baseline. Current LTS is 11.8 (GA May 2025).",{"type":37,"tag":46,"props":222,"children":223},{},[224,229,231,235,237,242,244,249],{"type":37,"tag":105,"props":225,"children":226},{},[227],{"type":43,"value":228},"Default context:",{"type":43,"value":230}," Assume MariaDB ",{"type":37,"tag":105,"props":232,"children":233},{},[234],{"type":43,"value":218},{"type":43,"value":236}," unless the user states another version. Features marked ",{"type":37,"tag":105,"props":238,"children":239},{},[240],{"type":43,"value":241},"12.x",{"type":43,"value":243}," or ",{"type":37,"tag":105,"props":245,"children":246},{},[247],{"type":43,"value":248},"13.0",{"type":43,"value":250}," may be suggested when relevant (including as upgrade options), but always state the minimum version — do not present them as available on 11.8.",{"type":37,"tag":252,"props":253,"children":255},"h2",{"id":254},"what-llms-get-wrong",[256],{"type":43,"value":257},"What LLMs Get Wrong",{"type":37,"tag":61,"props":259,"children":260},{},[261,277],{"type":37,"tag":65,"props":262,"children":263},{},[264],{"type":37,"tag":69,"props":265,"children":266},{},[267,272],{"type":37,"tag":73,"props":268,"children":269},{},[270],{"type":43,"value":271},"What you might see",{"type":37,"tag":73,"props":273,"children":274},{},[275],{"type":43,"value":276},"What's correct",{"type":37,"tag":94,"props":278,"children":279},{},[280,361,442,476,534,583,604,630,651],{"type":37,"tag":69,"props":281,"children":282},{},[283,302],{"type":37,"tag":101,"props":284,"children":285},{},[286,292,294,300],{"type":37,"tag":158,"props":287,"children":289},{"className":288},[],[290],{"type":43,"value":291},"CHANGE REPLICATION SOURCE TO",{"type":43,"value":293},", ",{"type":37,"tag":158,"props":295,"children":297},{"className":296},[],[298],{"type":43,"value":299},"SOURCE_*",{"type":43,"value":301}," connection options",{"type":37,"tag":101,"props":303,"children":304},{},[305,307,312,314,320,322,328,330,336,338,344,346,352,353,359],{"type":43,"value":306},"MariaDB has no ",{"type":37,"tag":158,"props":308,"children":310},{"className":309},[],[311],{"type":43,"value":291},{"type":43,"value":313}," — use ",{"type":37,"tag":158,"props":315,"children":317},{"className":316},[],[318],{"type":43,"value":319},"CHANGE MASTER TO",{"type":43,"value":321}," with ",{"type":37,"tag":158,"props":323,"children":325},{"className":324},[],[326],{"type":43,"value":327},"MASTER_*",{"type":43,"value":329}," options. Since 10.5.1, ",{"type":37,"tag":158,"props":331,"children":333},{"className":332},[],[334],{"type":43,"value":335},"START REPLICA",{"type":43,"value":337}," \u002F ",{"type":37,"tag":158,"props":339,"children":341},{"className":340},[],[342],{"type":43,"value":343},"SHOW REPLICA STATUS",{"type":43,"value":345}," are canonical; ",{"type":37,"tag":158,"props":347,"children":349},{"className":348},[],[350],{"type":43,"value":351},"START SLAVE",{"type":43,"value":337},{"type":37,"tag":158,"props":354,"children":356},{"className":355},[],[357],{"type":43,"value":358},"SHOW SLAVE STATUS",{"type":43,"value":360}," are legacy aliases",{"type":37,"tag":69,"props":362,"children":363},{},[364,388],{"type":37,"tag":101,"props":365,"children":366},{},[367,373,375,381,382],{"type":37,"tag":158,"props":368,"children":370},{"className":369},[],[371],{"type":43,"value":372},"replica_parallel_type",{"type":43,"value":374}," with values ",{"type":37,"tag":158,"props":376,"children":378},{"className":377},[],[379],{"type":43,"value":380},"DATABASE",{"type":43,"value":243},{"type":37,"tag":158,"props":383,"children":385},{"className":384},[],[386],{"type":43,"value":387},"LOGICAL_CLOCK",{"type":37,"tag":101,"props":389,"children":390},{},[391,393,399,401,406,407,413,414,420,421,427,428,434,436],{"type":43,"value":392},"MariaDB uses ",{"type":37,"tag":158,"props":394,"children":396},{"className":395},[],[397],{"type":43,"value":398},"slave_parallel_mode",{"type":43,"value":400}," (",{"type":37,"tag":158,"props":402,"children":404},{"className":403},[],[405],{"type":43,"value":211},{"type":43,"value":337},{"type":37,"tag":158,"props":408,"children":410},{"className":409},[],[411],{"type":43,"value":412},"conservative",{"type":43,"value":337},{"type":37,"tag":158,"props":415,"children":417},{"className":416},[],[418],{"type":43,"value":419},"aggressive",{"type":43,"value":337},{"type":37,"tag":158,"props":422,"children":424},{"className":423},[],[425],{"type":43,"value":426},"minimal",{"type":43,"value":337},{"type":37,"tag":158,"props":429,"children":431},{"className":430},[],[432],{"type":43,"value":433},"none",{"type":43,"value":435},") — a different implementation; MySQL's mode settings do not port over. Pool size: ",{"type":37,"tag":158,"props":437,"children":439},{"className":438},[],[440],{"type":43,"value":441},"slave_parallel_threads",{"type":37,"tag":69,"props":443,"children":444},{},[445,458],{"type":37,"tag":101,"props":446,"children":447},{},[448,450,456],{"type":43,"value":449},"MySQL GTID format or ",{"type":37,"tag":158,"props":451,"children":453},{"className":452},[],[454],{"type":43,"value":455},"gtid_mode=ON",{"type":43,"value":457}," syntax",{"type":37,"tag":101,"props":459,"children":460},{},[461,463,469,471],{"type":43,"value":462},"MariaDB GTID uses a different format (",{"type":37,"tag":158,"props":464,"children":466},{"className":465},[],[467],{"type":43,"value":468},"domain-server-seq",{"type":43,"value":470},") and different commands — MySQL and MariaDB GTIDs are ",{"type":37,"tag":105,"props":472,"children":473},{},[474],{"type":43,"value":475},"incompatible",{"type":37,"tag":69,"props":477,"children":478},{},[479,505],{"type":37,"tag":101,"props":480,"children":481},{},[482,484,490,491,497,499],{"type":43,"value":483},"MySQL Group Replication or InnoDB Cluster — ",{"type":37,"tag":158,"props":485,"children":487},{"className":486},[],[488],{"type":43,"value":489},"START GROUP_REPLICATION",{"type":43,"value":293},{"type":37,"tag":158,"props":492,"children":494},{"className":493},[],[495],{"type":43,"value":496},"group_replication_*",{"type":43,"value":498}," variables, MySQL Shell ",{"type":37,"tag":158,"props":500,"children":502},{"className":501},[],[503],{"type":43,"value":504},"dba.createCluster()",{"type":37,"tag":101,"props":506,"children":507},{},[508,510,515,517,526,528,532],{"type":43,"value":509},"MariaDB has ",{"type":37,"tag":105,"props":511,"children":512},{},[513],{"type":43,"value":514},"no Group Replication and no InnoDB Cluster",{"type":43,"value":516}," — Group Replication is ",{"type":37,"tag":518,"props":519,"children":523},"a",{"href":520,"rel":521},"https:\u002F\u002Fmariadb.com\u002Fdocs\u002Frelease-notes\u002Fcommunity-server\u002Fabout\u002Fcompatibility-and-differences\u002Fmariadb-vs-mysql-compatibility",[522],"nofollow",[524],{"type":43,"value":525},"incompatible with MariaDB",{"type":43,"value":527},". The synchronous multi-primary equivalent is ",{"type":37,"tag":105,"props":529,"children":530},{},[531],{"type":43,"value":176},{"type":43,"value":533}," (built in)",{"type":37,"tag":69,"props":535,"children":536},{},[537,542],{"type":37,"tag":101,"props":538,"children":539},{},[540],{"type":43,"value":541},"\"Install the Galera plugin\"",{"type":37,"tag":101,"props":543,"children":544},{},[545,547,552,554,559,560,566,567,573,575,581],{"type":43,"value":546},"There is no Galera ",{"type":37,"tag":50,"props":548,"children":549},{},[550],{"type":43,"value":551},"plugin",{"type":43,"value":553}," to load — wsrep support is built into the MariaDB server. But a cluster still requires the separate ",{"type":37,"tag":105,"props":555,"children":556},{},[557],{"type":43,"value":558},"Galera wsrep provider library",{"type":43,"value":400},{"type":37,"tag":158,"props":561,"children":563},{"className":562},[],[564],{"type":43,"value":565},"galera-4",{"type":43,"value":337},{"type":37,"tag":158,"props":568,"children":570},{"className":569},[],[571],{"type":43,"value":572},"libgalera_smm.so",{"type":43,"value":574},", set via ",{"type":37,"tag":158,"props":576,"children":578},{"className":577},[],[579],{"type":43,"value":580},"wsrep_provider",{"type":43,"value":582},"); on 12.3+ you must install it yourself (see the Galera Cluster section)",{"type":37,"tag":69,"props":584,"children":585},{},[586,599],{"type":37,"tag":101,"props":587,"children":588},{},[589,591,597],{"type":43,"value":590},"Assuming sequential ",{"type":37,"tag":158,"props":592,"children":594},{"className":593},[],[595],{"type":43,"value":596},"AUTO_INCREMENT",{"type":43,"value":598}," in Galera",{"type":37,"tag":101,"props":600,"children":601},{},[602],{"type":43,"value":603},"Galera produces gaps in auto-increment sequences across nodes by design — never rely on sequential values",{"type":37,"tag":69,"props":605,"children":606},{},[607,625],{"type":37,"tag":101,"props":608,"children":609},{},[610,616,617,623],{"type":37,"tag":158,"props":611,"children":613},{"className":612},[],[614],{"type":43,"value":615},"LOCK TABLES",{"type":43,"value":243},{"type":37,"tag":158,"props":618,"children":620},{"className":619},[],[621],{"type":43,"value":622},"GET_LOCK()",{"type":43,"value":624}," in a Galera environment",{"type":37,"tag":101,"props":626,"children":627},{},[628],{"type":43,"value":629},"Not supported in Galera — use transactions instead",{"type":37,"tag":69,"props":631,"children":632},{},[633,638],{"type":37,"tag":101,"props":634,"children":635},{},[636],{"type":43,"value":637},"Treating a replica as a backup",{"type":37,"tag":101,"props":639,"children":640},{},[641,643,649],{"type":43,"value":642},"Replication is not a backup — a ",{"type":37,"tag":158,"props":644,"children":646},{"className":645},[],[647],{"type":43,"value":648},"DROP TABLE",{"type":43,"value":650}," on the primary replicates immediately to all replicas",{"type":37,"tag":69,"props":652,"children":653},{},[654,659],{"type":37,"tag":101,"props":655,"children":656},{},[657],{"type":43,"value":658},"Tables without primary keys in a Galera cluster",{"type":37,"tag":101,"props":660,"children":661},{},[662,664,670],{"type":43,"value":663},"All tables in Galera must have a primary key — ",{"type":37,"tag":158,"props":665,"children":667},{"className":666},[],[668],{"type":43,"value":669},"DELETE",{"type":43,"value":671}," fails on keyless tables",{"type":37,"tag":252,"props":673,"children":675},{"id":674},"standard-async-replication",[676],{"type":43,"value":677},"Standard Async Replication",{"type":37,"tag":46,"props":679,"children":680},{},[681],{"type":43,"value":682},"The foundation: one primary, one or more replicas. The primary writes to the binary log; replicas apply changes asynchronously.",{"type":37,"tag":46,"props":684,"children":685},{},[686,691,693,699,701,706,708,714,716,722,724,730],{"type":37,"tag":105,"props":687,"children":688},{},[689],{"type":43,"value":690},"GTID-based replication is the default since MariaDB 10.10",{"type":43,"value":692}," (MDEV-19801) and remains so on 10.11 LTS, 11.4 LTS, and 11.8 LTS. On a fresh replica start, a ",{"type":37,"tag":158,"props":694,"children":696},{"className":695},[],[697],{"type":43,"value":698},"RESET SLAVE",{"type":43,"value":700},", or a ",{"type":37,"tag":158,"props":702,"children":704},{"className":703},[],[705],{"type":43,"value":319},{"type":43,"value":707}," that omits ",{"type":37,"tag":158,"props":709,"children":711},{"className":710},[],[712],{"type":43,"value":713},"MASTER_USE_GTID",{"type":43,"value":715},", the replica defaults to ",{"type":37,"tag":158,"props":717,"children":719},{"className":718},[],[720],{"type":43,"value":721},"slave_pos",{"type":43,"value":723}," instead of legacy file\u002Fposition. If you have configs that rely on the old behavior, set ",{"type":37,"tag":158,"props":725,"children":727},{"className":726},[],[728],{"type":43,"value":729},"MASTER_USE_GTID=no",{"type":43,"value":731}," explicitly.",{"type":37,"tag":733,"props":734,"children":739},"pre",{"className":735,"code":736,"language":737,"meta":738,"style":738},"language-sql shiki shiki-themes material-theme-lighter material-theme material-theme-palenight","-- On replica (10.10+ — MASTER_USE_GTID is optional, slave_pos is the default):\nCHANGE MASTER TO\n  MASTER_HOST='primary.host',\n  MASTER_USER='repl_user',\n  MASTER_PASSWORD='password',\n  MASTER_USE_GTID = slave_pos;\n\nSTART SLAVE;\n","sql","",[740],{"type":37,"tag":158,"props":741,"children":742},{"__ignoreMap":738},[743,754,762,771,780,789,798,808],{"type":37,"tag":744,"props":745,"children":748},"span",{"class":746,"line":747},"line",1,[749],{"type":37,"tag":744,"props":750,"children":751},{},[752],{"type":43,"value":753},"-- On replica (10.10+ — MASTER_USE_GTID is optional, slave_pos is the default):\n",{"type":37,"tag":744,"props":755,"children":756},{"class":746,"line":24},[757],{"type":37,"tag":744,"props":758,"children":759},{},[760],{"type":43,"value":761},"CHANGE MASTER TO\n",{"type":37,"tag":744,"props":763,"children":765},{"class":746,"line":764},3,[766],{"type":37,"tag":744,"props":767,"children":768},{},[769],{"type":43,"value":770},"  MASTER_HOST='primary.host',\n",{"type":37,"tag":744,"props":772,"children":774},{"class":746,"line":773},4,[775],{"type":37,"tag":744,"props":776,"children":777},{},[778],{"type":43,"value":779},"  MASTER_USER='repl_user',\n",{"type":37,"tag":744,"props":781,"children":783},{"class":746,"line":782},5,[784],{"type":37,"tag":744,"props":785,"children":786},{},[787],{"type":43,"value":788},"  MASTER_PASSWORD='password',\n",{"type":37,"tag":744,"props":790,"children":792},{"class":746,"line":791},6,[793],{"type":37,"tag":744,"props":794,"children":795},{},[796],{"type":43,"value":797},"  MASTER_USE_GTID = slave_pos;\n",{"type":37,"tag":744,"props":799,"children":801},{"class":746,"line":800},7,[802],{"type":37,"tag":744,"props":803,"children":805},{"emptyLinePlaceholder":804},true,[806],{"type":43,"value":807},"\n",{"type":37,"tag":744,"props":809,"children":811},{"class":746,"line":810},8,[812],{"type":37,"tag":744,"props":813,"children":814},{},[815],{"type":43,"value":816},"START SLAVE;\n",{"type":37,"tag":46,"props":818,"children":819},{},[820,825,827,833,835,846,848,854,856,862,864,870],{"type":37,"tag":105,"props":821,"children":822},{},[823],{"type":43,"value":824},"Promoting a replica to primary",{"type":43,"value":826}," — historically ",{"type":37,"tag":158,"props":828,"children":830},{"className":829},[],[831],{"type":43,"value":832},"MASTER_USE_GTID=current_pos",{"type":43,"value":834}," was used to include locally-written GTIDs. ",{"type":37,"tag":105,"props":836,"children":837},{},[838,844],{"type":37,"tag":158,"props":839,"children":841},{"className":840},[],[842],{"type":43,"value":843},"current_pos",{"type":43,"value":845}," is deprecated since 10.10",{"type":43,"value":847}," (MDEV-20122). Use ",{"type":37,"tag":158,"props":849,"children":851},{"className":850},[],[852],{"type":43,"value":853},"MASTER_DEMOTE_TO_SLAVE=1",{"type":43,"value":855}," instead: it converts the old primary's ",{"type":37,"tag":158,"props":857,"children":859},{"className":858},[],[860],{"type":43,"value":861},"gtid_binlog_pos",{"type":43,"value":863}," into ",{"type":37,"tag":158,"props":865,"children":867},{"className":866},[],[868],{"type":43,"value":869},"gtid_slave_pos",{"type":43,"value":871}," so the demoted server can attach to the new primary cleanly without race conditions.",{"type":37,"tag":733,"props":873,"children":875},{"className":735,"code":874,"language":737,"meta":738,"style":738},"-- On the former primary, being demoted to a replica (10.10+):\nCHANGE MASTER TO\n  MASTER_HOST='new_primary.host',\n  ...,\n  MASTER_DEMOTE_TO_SLAVE=1;\nSTART SLAVE;\n",[876],{"type":37,"tag":158,"props":877,"children":878},{"__ignoreMap":738},[879,887,894,902,910,918],{"type":37,"tag":744,"props":880,"children":881},{"class":746,"line":747},[882],{"type":37,"tag":744,"props":883,"children":884},{},[885],{"type":43,"value":886},"-- On the former primary, being demoted to a replica (10.10+):\n",{"type":37,"tag":744,"props":888,"children":889},{"class":746,"line":24},[890],{"type":37,"tag":744,"props":891,"children":892},{},[893],{"type":43,"value":761},{"type":37,"tag":744,"props":895,"children":896},{"class":746,"line":764},[897],{"type":37,"tag":744,"props":898,"children":899},{},[900],{"type":43,"value":901},"  MASTER_HOST='new_primary.host',\n",{"type":37,"tag":744,"props":903,"children":904},{"class":746,"line":773},[905],{"type":37,"tag":744,"props":906,"children":907},{},[908],{"type":43,"value":909},"  ...,\n",{"type":37,"tag":744,"props":911,"children":912},{"class":746,"line":782},[913],{"type":37,"tag":744,"props":914,"children":915},{},[916],{"type":43,"value":917},"  MASTER_DEMOTE_TO_SLAVE=1;\n",{"type":37,"tag":744,"props":919,"children":920},{"class":746,"line":791},[921],{"type":37,"tag":744,"props":922,"children":923},{},[924],{"type":43,"value":816},{"type":37,"tag":46,"props":926,"children":927},{},[928,930,936,938,944,946,952],{"type":43,"value":929},"Since MariaDB 13.0, ",{"type":37,"tag":158,"props":931,"children":933},{"className":932},[],[934],{"type":43,"value":935},"CHANGE MASTER",{"type":43,"value":937}," also resets ",{"type":37,"tag":158,"props":939,"children":941},{"className":940},[],[942],{"type":43,"value":943},"Master_Server_Id",{"type":43,"value":945}," in ",{"type":37,"tag":158,"props":947,"children":949},{"className":948},[],[950],{"type":43,"value":951},"SHOW SLAVES STATUS",{"type":43,"value":953},". On older versions this field could carry stale values across primary changes — check it explicitly when reconfiguring replication on pre-13.0 servers.",{"type":37,"tag":955,"props":956,"children":958},"h3",{"id":957},"mariadb-gtid-format",[959],{"type":43,"value":960},"MariaDB GTID Format",{"type":37,"tag":46,"props":962,"children":963},{},[964,966,972,974,980],{"type":43,"value":965},"MariaDB GTIDs have three components: ",{"type":37,"tag":158,"props":967,"children":969},{"className":968},[],[970],{"type":43,"value":971},"domain_id-server_id-sequence",{"type":43,"value":973}," (e.g., ",{"type":37,"tag":158,"props":975,"children":977},{"className":976},[],[978],{"type":43,"value":979},"0-1-247",{"type":43,"value":981},").",{"type":37,"tag":46,"props":983,"children":984},{},[985,987,992,994,1000],{"type":43,"value":986},"This is ",{"type":37,"tag":105,"props":988,"children":989},{},[990],{"type":43,"value":991},"different from MySQL's",{"type":43,"value":993}," ",{"type":37,"tag":158,"props":995,"children":997},{"className":996},[],[998],{"type":43,"value":999},"server_uuid:sequence",{"type":43,"value":1001}," format. They are not compatible — a MariaDB primary cannot replicate to a MySQL replica using GTIDs, and vice versa.",{"type":37,"tag":46,"props":1003,"children":1004},{},[1005,1010,1011,1017,1019,1024],{"type":37,"tag":105,"props":1006,"children":1007},{},[1008],{"type":43,"value":1009},"Domain IDs",{"type":43,"value":400},{"type":37,"tag":158,"props":1012,"children":1014},{"className":1013},[],[1015],{"type":43,"value":1016},"gtid_domain_id",{"type":43,"value":1018},") identify independent replication streams. The rule is about ",{"type":37,"tag":105,"props":1020,"children":1021},{},[1022],{"type":43,"value":1023},"concurrency of writes, not server count",{"type":43,"value":1025}," — a common and damaging mistake is to give every server its own domain ID:",{"type":37,"tag":1027,"props":1028,"children":1029},"ul",{},[1030,1108],{"type":37,"tag":1031,"props":1032,"children":1033},"li",{},[1034,1039,1041,1047,1049,1054,1056,1062,1064,1070,1072,1078,1080,1086,1088,1093,1094,1099,1101,1106],{"type":37,"tag":105,"props":1035,"children":1036},{},[1037],{"type":43,"value":1038},"Single active primary, including simple failover:",{"type":43,"value":1040}," leave ",{"type":37,"tag":158,"props":1042,"children":1044},{"className":1043},[],[1045],{"type":43,"value":1046},"gtid_domain_id = 0",{"type":43,"value":1048}," on ",{"type":37,"tag":105,"props":1050,"children":1051},{},[1052],{"type":43,"value":1053},"all",{"type":43,"value":1055}," servers. In an ",{"type":37,"tag":158,"props":1057,"children":1059},{"className":1058},[],[1060],{"type":43,"value":1061},"A → B",{"type":43,"value":1063}," pair where ",{"type":37,"tag":158,"props":1065,"children":1067},{"className":1066},[],[1068],{"type":43,"value":1069},"B",{"type":43,"value":1071}," is later promoted (so it becomes ",{"type":37,"tag":158,"props":1073,"children":1075},{"className":1074},[],[1076],{"type":43,"value":1077},"B → A",{"type":43,"value":1079},"), ",{"type":37,"tag":158,"props":1081,"children":1083},{"className":1082},[],[1084],{"type":43,"value":1085},"A",{"type":43,"value":1087}," and ",{"type":37,"tag":158,"props":1089,"children":1091},{"className":1090},[],[1092],{"type":43,"value":1069},{"type":43,"value":993},{"type":37,"tag":105,"props":1095,"children":1096},{},[1097],{"type":43,"value":1098},"share the same",{"type":43,"value":1100}," domain ID — do ",{"type":37,"tag":105,"props":1102,"children":1103},{},[1104],{"type":43,"value":1105},"not",{"type":43,"value":1107}," give them different ones.",{"type":37,"tag":1031,"props":1109,"children":1110},{},[1111,1116,1118,1123,1125,1130],{"type":37,"tag":105,"props":1112,"children":1113},{},[1114],{"type":43,"value":1115},"Multiple primaries updated concurrently",{"type":43,"value":1117}," (multi-source, or multi-primary within one topology): give ",{"type":37,"tag":105,"props":1119,"children":1120},{},[1121],{"type":43,"value":1122},"each concurrently-updated primary",{"type":43,"value":1124}," its own distinct ",{"type":37,"tag":158,"props":1126,"children":1128},{"className":1127},[],[1129],{"type":43,"value":1016},{"type":43,"value":1131},", so each stream stays independently ordered and automatic GTID replica-switchover works correctly.",{"type":37,"tag":733,"props":1133,"children":1135},{"className":735,"code":1134,"language":737,"meta":738,"style":738},"-- Multi-source \u002F multi-primary ONLY — each concurrently-written primary gets its own domain:\nSET GLOBAL gtid_domain_id = 1;   -- on primary A\nSET GLOBAL gtid_domain_id = 2;   -- on primary B\n",[1136],{"type":37,"tag":158,"props":1137,"children":1138},{"__ignoreMap":738},[1139,1147,1155],{"type":37,"tag":744,"props":1140,"children":1141},{"class":746,"line":747},[1142],{"type":37,"tag":744,"props":1143,"children":1144},{},[1145],{"type":43,"value":1146},"-- Multi-source \u002F multi-primary ONLY — each concurrently-written primary gets its own domain:\n",{"type":37,"tag":744,"props":1148,"children":1149},{"class":746,"line":24},[1150],{"type":37,"tag":744,"props":1151,"children":1152},{},[1153],{"type":43,"value":1154},"SET GLOBAL gtid_domain_id = 1;   -- on primary A\n",{"type":37,"tag":744,"props":1156,"children":1157},{"class":746,"line":764},[1158],{"type":37,"tag":744,"props":1159,"children":1160},{},[1161],{"type":43,"value":1162},"SET GLOBAL gtid_domain_id = 2;   -- on primary B\n",{"type":37,"tag":46,"props":1164,"children":1165},{},[1166,1168,1175],{"type":43,"value":1167},"Assigning a distinct domain ID per server otherwise complicates the GTID position and loses the single ordered binlog stream. See ",{"type":37,"tag":518,"props":1169,"children":1172},{"href":1170,"rel":1171},"https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fserver\u002Fha-and-performance\u002Fstandard-replication\u002Fgtid",[522],[1173],{"type":43,"value":1174},"Global Transaction ID",{"type":43,"value":1176},".",{"type":37,"tag":46,"props":1178,"children":1179},{},[1180,1191],{"type":37,"tag":105,"props":1181,"children":1182},{},[1183,1185],{"type":43,"value":1184},"Enable ",{"type":37,"tag":158,"props":1186,"children":1188},{"className":1187},[],[1189],{"type":43,"value":1190},"gtid_strict_mode",{"type":43,"value":1192}," alongside domain ID configuration — it catches out-of-order or mixed-domain GTID mistakes before they corrupt a replica's position:",{"type":37,"tag":733,"props":1194,"children":1198},{"className":1195,"code":1196,"language":1197,"meta":738,"style":738},"language-ini shiki shiki-themes material-theme-lighter material-theme material-theme-palenight","# my.cnf on all servers:\ngtid_strict_mode = ON\n","ini",[1199],{"type":37,"tag":158,"props":1200,"children":1201},{"__ignoreMap":738},[1202,1210],{"type":37,"tag":744,"props":1203,"children":1204},{"class":746,"line":747},[1205],{"type":37,"tag":744,"props":1206,"children":1207},{},[1208],{"type":43,"value":1209},"# my.cnf on all servers:\n",{"type":37,"tag":744,"props":1211,"children":1212},{"class":746,"line":24},[1213],{"type":37,"tag":744,"props":1214,"children":1215},{},[1216],{"type":43,"value":1217},"gtid_strict_mode = ON\n",{"type":37,"tag":46,"props":1219,"children":1220},{},[1221],{"type":43,"value":1222},"With strict mode ON, a replica stops with an error on a GTID ordering violation rather than silently applying out-of-order transactions. Without it, a domain ID misconfiguration can go undetected until the only fix is a full resync.",{"type":37,"tag":46,"props":1224,"children":1225},{},[1226,1228,1233,1234,1239,1241,1247,1249,1255,1257,1264,1266,1271],{"type":43,"value":1227},"In multi-source replication, replication commands and variables (",{"type":37,"tag":158,"props":1229,"children":1231},{"className":1230},[],[1232],{"type":43,"value":351},{"type":43,"value":293},{"type":37,"tag":158,"props":1235,"children":1237},{"className":1236},[],[1238],{"type":43,"value":358},{"type":43,"value":1240},", …) act on the connection named by ",{"type":37,"tag":158,"props":1242,"children":1244},{"className":1243},[],[1245],{"type":43,"value":1246},"default_master_connection",{"type":43,"value":1248},". It was session-only — you had to ",{"type":37,"tag":158,"props":1250,"children":1252},{"className":1251},[],[1253],{"type":43,"value":1254},"SET SESSION default_master_connection='name'",{"type":43,"value":1256}," in each session before issuing commands for that source. Since MariaDB 13.0 (",{"type":37,"tag":518,"props":1258,"children":1261},{"href":1259,"rel":1260},"https:\u002F\u002Fmariadb.com\u002Fdocs\u002Frelease-notes\u002Fcommunity-server\u002F13.0\u002Fmariadb-13.0-changes-and-improvements",[522],[1262],{"type":43,"value":1263},"MDEV-9247",{"type":43,"value":1265},") it can also be set ",{"type":37,"tag":105,"props":1267,"children":1268},{},[1269],{"type":43,"value":1270},"globally",{"type":43,"value":1272},", making a chosen named connection the default for all sessions.",{"type":37,"tag":955,"props":1274,"children":1276},{"id":1275},"parallel-replication",[1277],{"type":43,"value":1278},"Parallel Replication",{"type":37,"tag":46,"props":1280,"children":1281},{},[1282,1284,1289,1291,1297,1299,1304],{"type":43,"value":1283},"By default, replicas apply events serially — ",{"type":37,"tag":158,"props":1285,"children":1287},{"className":1286},[],[1288],{"type":43,"value":441},{"type":43,"value":1290}," defaults to ",{"type":37,"tag":158,"props":1292,"children":1294},{"className":1293},[],[1295],{"type":43,"value":1296},"0",{"type":43,"value":1298},", meaning parallel replication is ",{"type":37,"tag":105,"props":1300,"children":1301},{},[1302],{"type":43,"value":1303},"off",{"type":43,"value":1305}," out of the box regardless of the mode setting. To enable it:",{"type":37,"tag":733,"props":1307,"children":1309},{"className":1195,"code":1308,"language":1197,"meta":738,"style":738},"# my.cnf on replica:\nslave_parallel_threads = 4          # must be > 0 to enable parallel apply\nslave_parallel_mode = optimistic    # default since 10.5.1 — tries parallel, retries on conflict\n",[1310],{"type":37,"tag":158,"props":1311,"children":1312},{"__ignoreMap":738},[1313,1321,1329],{"type":37,"tag":744,"props":1314,"children":1315},{"class":746,"line":747},[1316],{"type":37,"tag":744,"props":1317,"children":1318},{},[1319],{"type":43,"value":1320},"# my.cnf on replica:\n",{"type":37,"tag":744,"props":1322,"children":1323},{"class":746,"line":24},[1324],{"type":37,"tag":744,"props":1325,"children":1326},{},[1327],{"type":43,"value":1328},"slave_parallel_threads = 4          # must be > 0 to enable parallel apply\n",{"type":37,"tag":744,"props":1330,"children":1331},{"class":746,"line":764},[1332],{"type":37,"tag":744,"props":1333,"children":1334},{},[1335],{"type":43,"value":1336},"slave_parallel_mode = optimistic    # default since 10.5.1 — tries parallel, retries on conflict\n",{"type":37,"tag":46,"props":1338,"children":1339},{},[1340,1345,1347,1352],{"type":37,"tag":158,"props":1341,"children":1343},{"className":1342},[],[1344],{"type":43,"value":211},{"type":43,"value":1346}," mode applies transactions in parallel and retries on conflict. Use ",{"type":37,"tag":158,"props":1348,"children":1350},{"className":1349},[],[1351],{"type":43,"value":412},{"type":43,"value":1353}," for stricter workloads where conflict retries are unacceptable.",{"type":37,"tag":193,"props":1355,"children":1356},{},[1357],{"type":37,"tag":46,"props":1358,"children":1359},{},[1360,1365,1367,1372,1373,1378,1379,1384,1386,1391,1392,1397,1398,1403,1405,1410,1412,1418],{"type":37,"tag":105,"props":1361,"children":1362},{},[1363],{"type":43,"value":1364},"Different from MySQL:",{"type":43,"value":1366}," MariaDB's ",{"type":37,"tag":158,"props":1368,"children":1370},{"className":1369},[],[1371],{"type":43,"value":398},{"type":43,"value":400},{"type":37,"tag":158,"props":1374,"children":1376},{"className":1375},[],[1377],{"type":43,"value":211},{"type":43,"value":293},{"type":37,"tag":158,"props":1380,"children":1382},{"className":1381},[],[1383],{"type":43,"value":412},{"type":43,"value":1385},", etc.) is its own implementation — not equivalent to MySQL's ",{"type":37,"tag":158,"props":1387,"children":1389},{"className":1388},[],[1390],{"type":43,"value":372},{"type":43,"value":400},{"type":37,"tag":158,"props":1393,"children":1395},{"className":1394},[],[1396],{"type":43,"value":380},{"type":43,"value":337},{"type":37,"tag":158,"props":1399,"children":1401},{"className":1400},[],[1402],{"type":43,"value":387},{"type":43,"value":1404},"). Copy-pasting a MySQL parallel-replication mode config will not work. Pool size is ",{"type":37,"tag":158,"props":1406,"children":1408},{"className":1407},[],[1409],{"type":43,"value":441},{"type":43,"value":1411}," (alias ",{"type":37,"tag":158,"props":1413,"children":1415},{"className":1414},[],[1416],{"type":43,"value":1417},"slave_parallel_workers",{"type":43,"value":981},{"type":37,"tag":46,"props":1420,"children":1421},{},[1422,1424,1429],{"type":43,"value":1423},"Since MariaDB 12.1, parallel replication also works when ",{"type":37,"tag":105,"props":1425,"children":1426},{},[1427],{"type":43,"value":1428},"asynchronously replicating between two Galera clusters",{"type":43,"value":1430}," (MDEV-20065) — useful for cross-datacenter or DR setups where one Galera cluster is an async replica of another.",{"type":37,"tag":955,"props":1432,"children":1434},{"id":1433},"replication-improvements-in-1071011-lts",[1435],{"type":43,"value":1436},"Replication Improvements in 10.7–10.11 LTS",{"type":37,"tag":1027,"props":1438,"children":1439},{},[1440,1473,1519,1554,1582],{"type":37,"tag":1031,"props":1441,"children":1442},{},[1443,1456,1458,1464,1466,1471],{"type":37,"tag":105,"props":1444,"children":1445},{},[1446,1448,1454],{"type":43,"value":1447},"Two-phase ",{"type":37,"tag":158,"props":1449,"children":1451},{"className":1450},[],[1452],{"type":43,"value":1453},"ALTER TABLE",{"type":43,"value":1455}," replication",{"type":43,"value":1457}," (10.8+, MDEV-11675, ",{"type":37,"tag":158,"props":1459,"children":1461},{"className":1460},[],[1462],{"type":43,"value":1463},"binlog_alter_two_phase",{"type":43,"value":1465},") — opt-in: when enabled, a large ",{"type":37,"tag":158,"props":1467,"children":1469},{"className":1468},[],[1470],{"type":43,"value":1453},{"type":43,"value":1472}," can start on the replica while the primary is still executing it, rather than only after, which can reduce replication lag during schema changes. Off by default. Treat as advanced\u002Fexperimental — validate thoroughly before relying on it in production rather than enabling it by default.",{"type":37,"tag":1031,"props":1474,"children":1475},{},[1476,1487,1489,1495,1496,1502,1504,1510,1512,1518],{"type":37,"tag":105,"props":1477,"children":1478},{},[1479,1481],{"type":43,"value":1480},"GTID-aware ",{"type":37,"tag":158,"props":1482,"children":1484},{"className":1483},[],[1485],{"type":43,"value":1486},"mariadb-binlog",{"type":43,"value":1488}," (10.8+, MDEV-4989) — ",{"type":37,"tag":158,"props":1490,"children":1492},{"className":1491},[],[1493],{"type":43,"value":1494},"--start-position",{"type":43,"value":1087},{"type":37,"tag":158,"props":1497,"children":1499},{"className":1498},[],[1500],{"type":43,"value":1501},"--stop-position",{"type":43,"value":1503}," accept GTID lists, so point-in-time replay tools can target GTIDs directly without needing binlog file\u002Foffset pairs. (Separately, ",{"type":37,"tag":158,"props":1505,"children":1507},{"className":1506},[],[1508],{"type":43,"value":1509},"--gtid-strict-mode",{"type":43,"value":1511}," — on by default — is only a safeguard: it checks that GTID sequence numbers are monotonic per domain and aborts on out-of-order events; it does not enable GTID targeting.) See ",{"type":37,"tag":518,"props":1513,"children":1516},{"href":1514,"rel":1515},"https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fserver\u002Fclients-and-utilities\u002Flogging-tools\u002Fmariadb-binlog",[522],[1517],{"type":43,"value":1486},{"type":43,"value":1176},{"type":37,"tag":1031,"props":1520,"children":1521},{},[1522,1531,1533,1538,1539,1546,1548,1552],{"type":37,"tag":105,"props":1523,"children":1524},{},[1525],{"type":37,"tag":158,"props":1526,"children":1528},{"className":1527},[],[1529],{"type":43,"value":1530},"slave_max_statement_time",{"type":43,"value":1532}," (10.10+, MDEV-27161) — caps how long a single statement may run on the replica SQL thread. If a replicated statement exceeds it, the SQL thread ",{"type":37,"tag":105,"props":1534,"children":1535},{},[1536],{"type":43,"value":1537},"stops with an error",{"type":43,"value":400},{"type":37,"tag":518,"props":1540,"children":1543},{"href":1541,"rel":1542},"https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fserver\u002Freference\u002Ferror-codes\u002Fmariadb-error-codes-3000-to-3099\u002Fe3024",[522],[1544],{"type":43,"value":1545},"error 3024",{"type":43,"value":1547},") so a slow or runaway query surfaces instead of lag growing unnoticed. It does ",{"type":37,"tag":105,"props":1549,"children":1550},{},[1551],{"type":43,"value":1105},{"type":43,"value":1553}," skip the statement and continue — replication halts until you investigate and restart it.",{"type":37,"tag":1031,"props":1555,"children":1556},{},[1557,1580],{"type":37,"tag":105,"props":1558,"children":1559},{},[1560,1566,1567,1573,1574],{"type":37,"tag":158,"props":1561,"children":1563},{"className":1562},[],[1564],{"type":43,"value":1565},"mariadb-binlog --do-domain-ids",{"type":43,"value":337},{"type":37,"tag":158,"props":1568,"children":1570},{"className":1569},[],[1571],{"type":43,"value":1572},"--ignore-domain-ids",{"type":43,"value":337},{"type":37,"tag":158,"props":1575,"children":1577},{"className":1576},[],[1578],{"type":43,"value":1579},"--ignore-server-ids",{"type":43,"value":1581}," (10.9+, MDEV-20119) — domain\u002Fserver filtering when extracting binlog events.",{"type":37,"tag":1031,"props":1583,"children":1584},{},[1585,1590,1592,1598,1600,1605,1606,1611],{"type":37,"tag":105,"props":1586,"children":1587},{},[1588],{"type":43,"value":1589},"Multi-source replication CHANNEL syntax",{"type":43,"value":1591}," (10.7+, MDEV-26307) — MySQL-style ",{"type":37,"tag":158,"props":1593,"children":1595},{"className":1594},[],[1596],{"type":43,"value":1597},"FOR CHANNEL 'name'",{"type":43,"value":1599}," clauses now work in ",{"type":37,"tag":158,"props":1601,"children":1603},{"className":1602},[],[1604],{"type":43,"value":319},{"type":43,"value":293},{"type":37,"tag":158,"props":1607,"children":1609},{"className":1608},[],[1610],{"type":43,"value":351},{"type":43,"value":1612},", etc.",{"type":37,"tag":955,"props":1614,"children":1616},{"id":1615},"replication-improvements-in-114-lts",[1617],{"type":43,"value":1618},"Replication Improvements in 11.4 LTS",{"type":37,"tag":1027,"props":1620,"children":1621},{},[1622,1678,1733,1762],{"type":37,"tag":1031,"props":1623,"children":1624},{},[1625,1630,1632,1638,1639,1645,1647,1652,1654,1660,1662,1668,1670,1676],{"type":37,"tag":105,"props":1626,"children":1627},{},[1628],{"type":43,"value":1629},"Global limit on binary log disk space",{"type":43,"value":1631}," (11.4+, MDEV-31404) — ",{"type":37,"tag":158,"props":1633,"children":1635},{"className":1634},[],[1636],{"type":43,"value":1637},"max_binlog_total_size",{"type":43,"value":1411},{"type":37,"tag":158,"props":1640,"children":1642},{"className":1641},[],[1643],{"type":43,"value":1644},"binlog_space_limit",{"type":43,"value":1646},", default ",{"type":37,"tag":158,"props":1648,"children":1650},{"className":1649},[],[1651],{"type":43,"value":1296},{"type":43,"value":1653}," = no limit) triggers binlog purging when the total size of all binlogs exceeds the threshold. Combine with ",{"type":37,"tag":158,"props":1655,"children":1657},{"className":1656},[],[1658],{"type":43,"value":1659},"--slave-connections-needed-for-purge",{"type":43,"value":1661}," (default ",{"type":37,"tag":158,"props":1663,"children":1665},{"className":1664},[],[1666],{"type":43,"value":1667},"1",{"type":43,"value":1669},") so purging won't run if a configured replica is disconnected. New status variable ",{"type":37,"tag":158,"props":1671,"children":1673},{"className":1672},[],[1674],{"type":43,"value":1675},"binlog_disk_use",{"type":43,"value":1677}," reports current disk usage.",{"type":37,"tag":1031,"props":1679,"children":1680},{},[1681,1686,1688,1694,1695,1701,1702,1708,1710,1716,1718,1724,1725,1731],{"type":37,"tag":105,"props":1682,"children":1683},{},[1684],{"type":43,"value":1685},"GTID index for the binary log",{"type":43,"value":1687}," (11.4+, MDEV-4991) — a new GTID-to-position index lets reconnecting replicas seek straight to their start position without scanning whole binlog files. Controlled by ",{"type":37,"tag":158,"props":1689,"children":1691},{"className":1690},[],[1692],{"type":43,"value":1693},"binlog_gtid_index",{"type":43,"value":1661},{"type":37,"tag":158,"props":1696,"children":1698},{"className":1697},[],[1699],{"type":43,"value":1700},"ON",{"type":43,"value":1079},{"type":37,"tag":158,"props":1703,"children":1705},{"className":1704},[],[1706],{"type":43,"value":1707},"binlog_gtid_index_page_size",{"type":43,"value":1709},", and ",{"type":37,"tag":158,"props":1711,"children":1713},{"className":1712},[],[1714],{"type":43,"value":1715},"binlog_gtid_index_span_min",{"type":43,"value":1717},". Status variables ",{"type":37,"tag":158,"props":1719,"children":1721},{"className":1720},[],[1722],{"type":43,"value":1723},"binlog_gtid_index_hit",{"type":43,"value":337},{"type":37,"tag":158,"props":1726,"children":1728},{"className":1727},[],[1729],{"type":43,"value":1730},"binlog_gtid_index_miss",{"type":43,"value":1732}," let you confirm it's being used.",{"type":37,"tag":1031,"props":1734,"children":1735},{},[1736,1760],{"type":37,"tag":105,"props":1737,"children":1738},{},[1739,1745,1746,1752,1754],{"type":37,"tag":158,"props":1740,"children":1742},{"className":1741},[],[1743],{"type":43,"value":1744},"SQL_BEFORE_GTIDS",{"type":43,"value":337},{"type":37,"tag":158,"props":1747,"children":1749},{"className":1748},[],[1750],{"type":43,"value":1751},"SQL_AFTER_GTIDS",{"type":43,"value":1753}," for ",{"type":37,"tag":158,"props":1755,"children":1757},{"className":1756},[],[1758],{"type":43,"value":1759},"START SLAVE UNTIL",{"type":43,"value":1761}," (11.4+, MDEV-27247) — finer-grained stopping for staged failover or PITR replay.",{"type":37,"tag":1031,"props":1763,"children":1764},{},[1765,1770,1772,1777,1779,1785,1786,1792,1793,1799,1801,1807],{"type":37,"tag":105,"props":1766,"children":1767},{},[1768],{"type":43,"value":1769},"Detailed replication-lag fields",{"type":43,"value":1771}," (11.4+, MDEV-29639) — ",{"type":37,"tag":158,"props":1773,"children":1775},{"className":1774},[],[1776],{"type":43,"value":343},{"type":43,"value":1778}," adds ",{"type":37,"tag":158,"props":1780,"children":1782},{"className":1781},[],[1783],{"type":43,"value":1784},"Master_last_event_time",{"type":43,"value":293},{"type":37,"tag":158,"props":1787,"children":1789},{"className":1788},[],[1790],{"type":43,"value":1791},"Slave_last_event_time",{"type":43,"value":293},{"type":37,"tag":158,"props":1794,"children":1796},{"className":1795},[],[1797],{"type":43,"value":1798},"Master_Slave_time_diff",{"type":43,"value":1800}," for clearer lag interpretation than ",{"type":37,"tag":158,"props":1802,"children":1804},{"className":1803},[],[1805],{"type":43,"value":1806},"Seconds_Behind_Master",{"type":43,"value":1808}," alone (the 11.6 update built on this — see below).",{"type":37,"tag":955,"props":1810,"children":1812},{"id":1811},"binlog-performance-improvements-in-117",[1813],{"type":43,"value":1814},"Binlog Performance Improvements in 11.7",{"type":37,"tag":1027,"props":1816,"children":1817},{},[1818,1836,1846],{"type":37,"tag":1031,"props":1819,"children":1820},{},[1821,1826,1828,1834],{"type":37,"tag":105,"props":1822,"children":1823},{},[1824],{"type":43,"value":1825},"Large-transaction commit no longer freezes other transactions",{"type":43,"value":1827}," (11.7+, MDEV-32014) — previously, committing a very large transaction while ",{"type":37,"tag":158,"props":1829,"children":1831},{"className":1830},[],[1832],{"type":43,"value":1833},"log_bin",{"type":43,"value":1835}," was on would stall all other transactions until the binlog write completed. This bottleneck is gone.",{"type":37,"tag":1031,"props":1837,"children":1838},{},[1839,1844],{"type":37,"tag":105,"props":1840,"children":1841},{},[1842],{"type":43,"value":1843},"Async rollback of prepared transactions during binlog crash recovery",{"type":43,"value":1845}," (11.7+, MDEV-33853) — faster startup after a crash with many prepared transactions.",{"type":37,"tag":1031,"props":1847,"children":1848},{},[1849,1858],{"type":37,"tag":105,"props":1850,"children":1851},{},[1852],{"type":37,"tag":158,"props":1853,"children":1855},{"className":1854},[],[1856],{"type":43,"value":1857},"slave_abort_blocking_timeout",{"type":43,"value":1859}," (11.7+, MDEV-34857) — kill long-running queries on a replica when they block replication progress past a threshold. Useful on read replicas that occasionally run long analytical queries.",{"type":37,"tag":955,"props":1861,"children":1863},{"id":1862},"monitoring-replication-lag",[1864],{"type":43,"value":1865},"Monitoring Replication Lag",{"type":37,"tag":733,"props":1867,"children":1869},{"className":735,"code":1868,"language":737,"meta":738,"style":738},"SHOW SLAVE STATUS\\G\n-- Key fields:\n-- Seconds_Behind_Master: estimated lag in seconds\n-- Last_SQL_Error: last error stopping the SQL thread\n-- Relay_Log_Pos vs Read_Master_Log_Pos: how far behind the relay log is\n",[1870],{"type":37,"tag":158,"props":1871,"children":1872},{"__ignoreMap":738},[1873,1881,1889,1897,1905],{"type":37,"tag":744,"props":1874,"children":1875},{"class":746,"line":747},[1876],{"type":37,"tag":744,"props":1877,"children":1878},{},[1879],{"type":43,"value":1880},"SHOW SLAVE STATUS\\G\n",{"type":37,"tag":744,"props":1882,"children":1883},{"class":746,"line":24},[1884],{"type":37,"tag":744,"props":1885,"children":1886},{},[1887],{"type":43,"value":1888},"-- Key fields:\n",{"type":37,"tag":744,"props":1890,"children":1891},{"class":746,"line":764},[1892],{"type":37,"tag":744,"props":1893,"children":1894},{},[1895],{"type":43,"value":1896},"-- Seconds_Behind_Master: estimated lag in seconds\n",{"type":37,"tag":744,"props":1898,"children":1899},{"class":746,"line":773},[1900],{"type":37,"tag":744,"props":1901,"children":1902},{},[1903],{"type":43,"value":1904},"-- Last_SQL_Error: last error stopping the SQL thread\n",{"type":37,"tag":744,"props":1906,"children":1907},{"class":746,"line":782},[1908],{"type":37,"tag":744,"props":1909,"children":1910},{},[1911],{"type":43,"value":1912},"-- Relay_Log_Pos vs Read_Master_Log_Pos: how far behind the relay log is\n",{"type":37,"tag":46,"props":1914,"children":1915},{},[1916,1918,1924,1926,1932,1934,1939,1941,1947],{"type":43,"value":1917},"Alert when ",{"type":37,"tag":158,"props":1919,"children":1921},{"className":1920},[],[1922],{"type":43,"value":1923},"Seconds_Behind_Master > 5",{"type":43,"value":1925}," for latency-sensitive applications. A value of ",{"type":37,"tag":158,"props":1927,"children":1929},{"className":1928},[],[1930],{"type":43,"value":1931},"NULL",{"type":43,"value":1933}," means replication is not running. Note: ",{"type":37,"tag":158,"props":1935,"children":1937},{"className":1936},[],[1938],{"type":43,"value":1806},{"type":43,"value":1940}," can be misleading on idle primaries — use heartbeat tools (e.g., ",{"type":37,"tag":158,"props":1942,"children":1944},{"className":1943},[],[1945],{"type":43,"value":1946},"pt-heartbeat",{"type":43,"value":1948},") for accurate measurement.",{"type":37,"tag":46,"props":1950,"children":1951},{},[1952,1954,1959,1961,1967,1969,1975],{"type":43,"value":1953},"Since MariaDB 11.6 (MDEV-33856), the definition of ",{"type":37,"tag":158,"props":1955,"children":1957},{"className":1956},[],[1958],{"type":43,"value":1806},{"type":43,"value":1960}," was refined and three new columns were added to ",{"type":37,"tag":158,"props":1962,"children":1964},{"className":1963},[],[1965],{"type":43,"value":1966},"SHOW ALL REPLICAS STATUS",{"type":43,"value":1968}," plus a new Information Schema ",{"type":37,"tag":158,"props":1970,"children":1972},{"className":1971},[],[1973],{"type":43,"value":1974},"SLAVE_STATUS",{"type":43,"value":1976}," table, providing more nuanced lag visibility (e.g., separate measurements for IO vs SQL thread lag).",{"type":37,"tag":252,"props":1978,"children":1980},{"id":1979},"semi-synchronous-replication",[1981],{"type":43,"value":1982},"Semi-Synchronous Replication",{"type":37,"tag":46,"props":1984,"children":1985},{},[1986,1988,1993,1995,1999,2001,2007,2009,2014,2016,2022,2024,2031],{"type":43,"value":1987},"The primary writes and fsyncs each transaction to its ",{"type":37,"tag":105,"props":1989,"children":1990},{},[1991],{"type":43,"value":1992},"own",{"type":43,"value":1994}," binary log first — making it durable locally — and only then waits for at least one replica to acknowledge that it has ",{"type":37,"tag":50,"props":1996,"children":1997},{},[1998],{"type":43,"value":154},{"type":43,"value":2000}," the transaction before reporting the commit complete to the client. The ",{"type":37,"tag":158,"props":2002,"children":2004},{"className":2003},[],[2005],{"type":43,"value":2006},"rpl_semi_sync_master_wait_point",{"type":43,"value":2008}," setting controls when that wait happens: with ",{"type":37,"tag":158,"props":2010,"children":2012},{"className":2011},[],[2013],{"type":43,"value":163},{"type":43,"value":2015}," the primary waits before the changes become visible, so failover to an acknowledged replica is lossless; with ",{"type":37,"tag":158,"props":2017,"children":2019},{"className":2018},[],[2020],{"type":43,"value":2021},"AFTER_COMMIT",{"type":43,"value":2023}," (the MariaDB default) the transaction is already committed and visible before the wait, so a crash in that window can still lose it on failover. See ",{"type":37,"tag":518,"props":2025,"children":2028},{"href":2026,"rel":2027},"https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fserver\u002Fha-and-performance\u002Fstandard-replication\u002Fsemisynchronous-replication",[522],[2029],{"type":43,"value":2030},"Semisynchronous Replication",{"type":43,"value":1176},{"type":37,"tag":733,"props":2033,"children":2035},{"className":735,"code":2034,"language":737,"meta":738,"style":738},"-- Enable on primary:\nSET GLOBAL rpl_semi_sync_master_enabled = 1;\n\n-- Enable on replica:\nSET GLOBAL rpl_semi_sync_slave_enabled = 1;\n",[2036],{"type":37,"tag":158,"props":2037,"children":2038},{"__ignoreMap":738},[2039,2047,2055,2062,2070],{"type":37,"tag":744,"props":2040,"children":2041},{"class":746,"line":747},[2042],{"type":37,"tag":744,"props":2043,"children":2044},{},[2045],{"type":43,"value":2046},"-- Enable on primary:\n",{"type":37,"tag":744,"props":2048,"children":2049},{"class":746,"line":24},[2050],{"type":37,"tag":744,"props":2051,"children":2052},{},[2053],{"type":43,"value":2054},"SET GLOBAL rpl_semi_sync_master_enabled = 1;\n",{"type":37,"tag":744,"props":2056,"children":2057},{"class":746,"line":764},[2058],{"type":37,"tag":744,"props":2059,"children":2060},{"emptyLinePlaceholder":804},[2061],{"type":43,"value":807},{"type":37,"tag":744,"props":2063,"children":2064},{"class":746,"line":773},[2065],{"type":37,"tag":744,"props":2066,"children":2067},{},[2068],{"type":43,"value":2069},"-- Enable on replica:\n",{"type":37,"tag":744,"props":2071,"children":2072},{"class":746,"line":782},[2073],{"type":37,"tag":744,"props":2074,"children":2075},{},[2076],{"type":43,"value":2077},"SET GLOBAL rpl_semi_sync_slave_enabled = 1;\n",{"type":37,"tag":46,"props":2079,"children":2080},{},[2081,2083,2089],{"type":43,"value":2082},"If no replica acknowledges within ",{"type":37,"tag":158,"props":2084,"children":2086},{"className":2085},[],[2087],{"type":43,"value":2088},"rpl_semi_sync_master_timeout",{"type":43,"value":2090}," (default 10 seconds), the primary falls back to async. Built-in since MariaDB 10.3 — no plugin needed.",{"type":37,"tag":46,"props":2092,"children":2093},{},[2094,2096,2100,2102,2107,2109,2113],{"type":43,"value":2095},"Use when: you want at least one replica to have ",{"type":37,"tag":50,"props":2097,"children":2098},{},[2099],{"type":43,"value":154},{"type":43,"value":2101}," each transaction before the client's commit returns — e.g. to bound failover data loss (use ",{"type":37,"tag":158,"props":2103,"children":2105},{"className":2104},[],[2106],{"type":43,"value":163},{"type":43,"value":2108},"). Note that semi-sync only delays commit completion as seen by the client; it does ",{"type":37,"tag":105,"props":2110,"children":2111},{},[2112],{"type":43,"value":1105},{"type":43,"value":2114}," add durability to the primary's own copy, and a transaction lost before any replica receives it is gone regardless of semi-sync.",{"type":37,"tag":252,"props":2116,"children":2118},{"id":2117},"galera-cluster",[2119],{"type":43,"value":176},{"type":37,"tag":46,"props":2121,"children":2122},{},[2123],{"type":43,"value":2124},"Multi-primary synchronous replication — all nodes accept reads and writes, changes are certified across the cluster before committing. No single point of failure. Built into MariaDB.",{"type":37,"tag":193,"props":2126,"children":2127},{},[2128],{"type":37,"tag":46,"props":2129,"children":2130},{},[2131,2136,2138,2143],{"type":37,"tag":105,"props":2132,"children":2133},{},[2134],{"type":43,"value":2135},"Packaging change (12.3+):",{"type":43,"value":2137}," The Galera library is no longer included as a server-package dependency or in the MariaDB repositories by default (MDEV-38744). On 12.3+ you must install ",{"type":37,"tag":158,"props":2139,"children":2141},{"className":2140},[],[2142],{"type":43,"value":565},{"type":43,"value":2144}," (or your distro's equivalent) separately when setting up a Galera node. The MariaDB server still understands Galera natively — only the library distribution changed.",{"type":37,"tag":955,"props":2146,"children":2148},{"id":2147},"developer-constraints",[2149],{"type":43,"value":2150},"Developer Constraints",{"type":37,"tag":46,"props":2152,"children":2153},{},[2154],{"type":43,"value":2155},"These will break in Galera if you're not aware of them:",{"type":37,"tag":46,"props":2157,"children":2158},{},[2159],{"type":37,"tag":105,"props":2160,"children":2161},{},[2162],{"type":43,"value":2163},"All tables must have a primary key:",{"type":37,"tag":733,"props":2165,"children":2167},{"className":735,"code":2166,"language":737,"meta":738,"style":738},"-- ✗ DELETE fails in Galera on keyless tables:\nCREATE TABLE logs (message TEXT);\n\n-- ✅ Always define a PK:\nCREATE TABLE logs (id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, message TEXT);\n",[2168],{"type":37,"tag":158,"props":2169,"children":2170},{"__ignoreMap":738},[2171,2179,2187,2194,2202],{"type":37,"tag":744,"props":2172,"children":2173},{"class":746,"line":747},[2174],{"type":37,"tag":744,"props":2175,"children":2176},{},[2177],{"type":43,"value":2178},"-- ✗ DELETE fails in Galera on keyless tables:\n",{"type":37,"tag":744,"props":2180,"children":2181},{"class":746,"line":24},[2182],{"type":37,"tag":744,"props":2183,"children":2184},{},[2185],{"type":43,"value":2186},"CREATE TABLE logs (message TEXT);\n",{"type":37,"tag":744,"props":2188,"children":2189},{"class":746,"line":764},[2190],{"type":37,"tag":744,"props":2191,"children":2192},{"emptyLinePlaceholder":804},[2193],{"type":43,"value":807},{"type":37,"tag":744,"props":2195,"children":2196},{"class":746,"line":773},[2197],{"type":37,"tag":744,"props":2198,"children":2199},{},[2200],{"type":43,"value":2201},"-- ✅ Always define a PK:\n",{"type":37,"tag":744,"props":2203,"children":2204},{"class":746,"line":782},[2205],{"type":37,"tag":744,"props":2206,"children":2207},{},[2208],{"type":43,"value":2209},"CREATE TABLE logs (id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, message TEXT);\n",{"type":37,"tag":46,"props":2211,"children":2212},{},[2213,2218,2220,2226,2227,2233],{"type":37,"tag":105,"props":2214,"children":2215},{},[2216],{"type":43,"value":2217},"AUTO_INCREMENT values have gaps",{"type":43,"value":2219}," — Galera uses ",{"type":37,"tag":158,"props":2221,"children":2223},{"className":2222},[],[2224],{"type":43,"value":2225},"auto_increment_increment",{"type":43,"value":1087},{"type":37,"tag":158,"props":2228,"children":2230},{"className":2229},[],[2231],{"type":43,"value":2232},"auto_increment_offset",{"type":43,"value":2234}," per node to avoid conflicts, resulting in non-sequential IDs. Never rely on sequential auto-increment in Galera.",{"type":37,"tag":46,"props":2236,"children":2237},{},[2238,2251,2253,2259],{"type":37,"tag":105,"props":2239,"children":2240},{},[2241,2243,2249],{"type":43,"value":2242},"LOCK TABLES, GET_LOCK(), and ",{"type":37,"tag":158,"props":2244,"children":2246},{"className":2245},[],[2247],{"type":43,"value":2248},"FLUSH TABLES {table list} WITH READ LOCK",{"type":43,"value":2250}," are not supported",{"type":43,"value":2252}," — use transactions. Note: global ",{"type":37,"tag":158,"props":2254,"children":2256},{"className":2255},[],[2257],{"type":43,"value":2258},"FLUSH TABLES WITH READ LOCK",{"type":43,"value":2260}," (no table list) IS supported:",{"type":37,"tag":733,"props":2262,"children":2264},{"className":735,"code":2263,"language":737,"meta":738,"style":738},"-- ✗ Not supported in Galera:\nLOCK TABLES orders WRITE;\n-- ✅ Use a transaction instead:\nBEGIN;\nSELECT ... FOR UPDATE;\nUPDATE ...;\nCOMMIT;\n",[2265],{"type":37,"tag":158,"props":2266,"children":2267},{"__ignoreMap":738},[2268,2276,2284,2292,2300,2308,2316],{"type":37,"tag":744,"props":2269,"children":2270},{"class":746,"line":747},[2271],{"type":37,"tag":744,"props":2272,"children":2273},{},[2274],{"type":43,"value":2275},"-- ✗ Not supported in Galera:\n",{"type":37,"tag":744,"props":2277,"children":2278},{"class":746,"line":24},[2279],{"type":37,"tag":744,"props":2280,"children":2281},{},[2282],{"type":43,"value":2283},"LOCK TABLES orders WRITE;\n",{"type":37,"tag":744,"props":2285,"children":2286},{"class":746,"line":764},[2287],{"type":37,"tag":744,"props":2288,"children":2289},{},[2290],{"type":43,"value":2291},"-- ✅ Use a transaction instead:\n",{"type":37,"tag":744,"props":2293,"children":2294},{"class":746,"line":773},[2295],{"type":37,"tag":744,"props":2296,"children":2297},{},[2298],{"type":43,"value":2299},"BEGIN;\n",{"type":37,"tag":744,"props":2301,"children":2302},{"class":746,"line":782},[2303],{"type":37,"tag":744,"props":2304,"children":2305},{},[2306],{"type":43,"value":2307},"SELECT ... FOR UPDATE;\n",{"type":37,"tag":744,"props":2309,"children":2310},{"class":746,"line":791},[2311],{"type":37,"tag":744,"props":2312,"children":2313},{},[2314],{"type":43,"value":2315},"UPDATE ...;\n",{"type":37,"tag":744,"props":2317,"children":2318},{"class":746,"line":800},[2319],{"type":37,"tag":744,"props":2320,"children":2321},{},[2322],{"type":43,"value":2323},"COMMIT;\n",{"type":37,"tag":46,"props":2325,"children":2326},{},[2327,2332,2334,2340],{"type":37,"tag":105,"props":2328,"children":2329},{},[2330],{"type":43,"value":2331},"InnoDB only",{"type":43,"value":2333}," — Galera replicates only InnoDB tables. MyISAM has experimental support via ",{"type":37,"tag":158,"props":2335,"children":2337},{"className":2336},[],[2338],{"type":43,"value":2339},"wsrep_replicate_myisam",{"type":43,"value":2341}," but is not recommended for production.",{"type":37,"tag":46,"props":2343,"children":2344},{},[2345,2350,2352,2358,2360,2366,2368,2374],{"type":37,"tag":105,"props":2346,"children":2347},{},[2348],{"type":43,"value":2349},"Transaction size limits",{"type":43,"value":2351}," — default caps: 128K rows (",{"type":37,"tag":158,"props":2353,"children":2355},{"className":2354},[],[2356],{"type":43,"value":2357},"wsrep_max_ws_rows",{"type":43,"value":2359},") and 2GB (",{"type":37,"tag":158,"props":2361,"children":2363},{"className":2362},[],[2364],{"type":43,"value":2365},"wsrep_max_ws_size",{"type":43,"value":2367},"). Extremely large transactions degrade cluster performance significantly and may require config tuning. Note: in MariaDB 13.0+, the default ",{"type":37,"tag":158,"props":2369,"children":2371},{"className":2370},[],[2372],{"type":43,"value":2373},"binlog_row_event_max_size",{"type":43,"value":2375}," is 64 KB (up from older 8 KB) — relevant when sizing replication events for write-heavy workloads.",{"type":37,"tag":46,"props":2377,"children":2378},{},[2379,2384,2386,2392],{"type":37,"tag":105,"props":2380,"children":2381},{},[2382],{"type":43,"value":2383},"Binary log must be ROW format",{"type":43,"value":2385}," — do not change ",{"type":37,"tag":158,"props":2387,"children":2389},{"className":2388},[],[2390],{"type":43,"value":2391},"binlog_format",{"type":43,"value":2393}," at runtime in a Galera cluster.",{"type":37,"tag":46,"props":2395,"children":2396},{},[2397,2402,2404,2410],{"type":37,"tag":105,"props":2398,"children":2399},{},[2400],{"type":43,"value":2401},"Write-set retry on conflict",{"type":43,"value":2403}," (12.1+) — ",{"type":37,"tag":158,"props":2405,"children":2407},{"className":2406},[],[2408],{"type":43,"value":2409},"wsrep_applier_retry_count",{"type":43,"value":2411}," controls how many times an applier retries a write set before erroring out. Tune this if your workload sees transient certification conflicts on busy clusters.",{"type":37,"tag":46,"props":2413,"children":2414},{},[2415,2420],{"type":37,"tag":105,"props":2416,"children":2417},{},[2418],{"type":43,"value":2419},"Automatic SST user account management",{"type":43,"value":2421}," (11.6+, MDEV-31809) — Galera now manages the dedicated SST (State Snapshot Transfer) user account automatically; you no longer have to create and grant it manually on every node.",{"type":37,"tag":46,"props":2423,"children":2424},{},[2425,2430,2432,2438],{"type":37,"tag":105,"props":2426,"children":2427},{},[2428],{"type":43,"value":2429},"IP allowlist for nodes joining the cluster",{"type":43,"value":2431}," (10.10+, MDEV-27246) — ",{"type":37,"tag":158,"props":2433,"children":2435},{"className":2434},[],[2436],{"type":43,"value":2437},"wsrep_allowlist",{"type":43,"value":2439}," restricts which IPs can make SST\u002FIST requests, reducing the attack surface on a Galera cluster's intra-node traffic.",{"type":37,"tag":46,"props":2441,"children":2442},{},[2443,2448],{"type":37,"tag":105,"props":2444,"children":2445},{},[2446],{"type":43,"value":2447},"Query cache:",{"type":43,"value":2449}," The query cache was removed in later MariaDB versions and was not required in Galera since MariaDB 10.1.2. No action needed on modern installations.",{"type":37,"tag":955,"props":2451,"children":2453},{"id":2452},"stale-reads-and-consistency",[2454],{"type":43,"value":2455},"Stale Reads and Consistency",{"type":37,"tag":46,"props":2457,"children":2458},{},[2459],{"type":43,"value":2460},"Galera is \"virtually synchronous\" — a committed write on one node may not be immediately visible on another without additional synchronization:",{"type":37,"tag":733,"props":2462,"children":2464},{"className":735,"code":2463,"language":737,"meta":738,"style":738},"-- Force a sync point before reading (performance cost):\nSET SESSION wsrep_sync_wait = 1;\nSELECT * FROM orders WHERE id = 42;\n",[2465],{"type":37,"tag":158,"props":2466,"children":2467},{"__ignoreMap":738},[2468,2476,2484],{"type":37,"tag":744,"props":2469,"children":2470},{"class":746,"line":747},[2471],{"type":37,"tag":744,"props":2472,"children":2473},{},[2474],{"type":43,"value":2475},"-- Force a sync point before reading (performance cost):\n",{"type":37,"tag":744,"props":2477,"children":2478},{"class":746,"line":24},[2479],{"type":37,"tag":744,"props":2480,"children":2481},{},[2482],{"type":43,"value":2483},"SET SESSION wsrep_sync_wait = 1;\n",{"type":37,"tag":744,"props":2485,"children":2486},{"class":746,"line":764},[2487],{"type":37,"tag":744,"props":2488,"children":2489},{},[2490],{"type":43,"value":2491},"SELECT * FROM orders WHERE id = 42;\n",{"type":37,"tag":46,"props":2493,"children":2494},{},[2495,2497,2503],{"type":43,"value":2496},"Use ",{"type":37,"tag":158,"props":2498,"children":2500},{"className":2499},[],[2501],{"type":43,"value":2502},"wsrep_sync_wait",{"type":43,"value":2504}," only where strict read-after-write consistency is required. For most reads, eventual consistency across nodes (milliseconds) is acceptable.",{"type":37,"tag":955,"props":2506,"children":2508},{"id":2507},"lost-updates-in-galera",[2509],{"type":43,"value":2510},"Lost Updates in Galera",{"type":37,"tag":46,"props":2512,"children":2513},{},[2514,2516,2522],{"type":43,"value":2515},"Galera does not prevent lost updates in read-modify-write patterns. Use ",{"type":37,"tag":158,"props":2517,"children":2519},{"className":2518},[],[2520],{"type":43,"value":2521},"SELECT ... FOR UPDATE",{"type":43,"value":2523}," explicitly:",{"type":37,"tag":733,"props":2525,"children":2527},{"className":735,"code":2526,"language":737,"meta":738,"style":738},"-- ✗ Race condition — another node could modify between SELECT and UPDATE:\nSELECT balance FROM accounts WHERE id = 1;\n-- ... application logic ...\nUPDATE accounts SET balance = new_value WHERE id = 1;\n\n-- ✅ Lock the row at read time:\nBEGIN;\nSELECT balance FROM accounts WHERE id = 1 FOR UPDATE;\nUPDATE accounts SET balance = new_value WHERE id = 1;\nCOMMIT;\n",[2528],{"type":37,"tag":158,"props":2529,"children":2530},{"__ignoreMap":738},[2531,2539,2547,2555,2563,2570,2578,2585,2593,2600],{"type":37,"tag":744,"props":2532,"children":2533},{"class":746,"line":747},[2534],{"type":37,"tag":744,"props":2535,"children":2536},{},[2537],{"type":43,"value":2538},"-- ✗ Race condition — another node could modify between SELECT and UPDATE:\n",{"type":37,"tag":744,"props":2540,"children":2541},{"class":746,"line":24},[2542],{"type":37,"tag":744,"props":2543,"children":2544},{},[2545],{"type":43,"value":2546},"SELECT balance FROM accounts WHERE id = 1;\n",{"type":37,"tag":744,"props":2548,"children":2549},{"class":746,"line":764},[2550],{"type":37,"tag":744,"props":2551,"children":2552},{},[2553],{"type":43,"value":2554},"-- ... application logic ...\n",{"type":37,"tag":744,"props":2556,"children":2557},{"class":746,"line":773},[2558],{"type":37,"tag":744,"props":2559,"children":2560},{},[2561],{"type":43,"value":2562},"UPDATE accounts SET balance = new_value WHERE id = 1;\n",{"type":37,"tag":744,"props":2564,"children":2565},{"class":746,"line":782},[2566],{"type":37,"tag":744,"props":2567,"children":2568},{"emptyLinePlaceholder":804},[2569],{"type":43,"value":807},{"type":37,"tag":744,"props":2571,"children":2572},{"class":746,"line":791},[2573],{"type":37,"tag":744,"props":2574,"children":2575},{},[2576],{"type":43,"value":2577},"-- ✅ Lock the row at read time:\n",{"type":37,"tag":744,"props":2579,"children":2580},{"class":746,"line":800},[2581],{"type":37,"tag":744,"props":2582,"children":2583},{},[2584],{"type":43,"value":2299},{"type":37,"tag":744,"props":2586,"children":2587},{"class":746,"line":810},[2588],{"type":37,"tag":744,"props":2589,"children":2590},{},[2591],{"type":43,"value":2592},"SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;\n",{"type":37,"tag":744,"props":2594,"children":2595},{"class":746,"line":20},[2596],{"type":37,"tag":744,"props":2597,"children":2598},{},[2599],{"type":43,"value":2562},{"type":37,"tag":744,"props":2601,"children":2603},{"class":746,"line":2602},10,[2604],{"type":37,"tag":744,"props":2605,"children":2606},{},[2607],{"type":43,"value":2323},{"type":37,"tag":252,"props":2609,"children":2611},{"id":2610},"replication-is-not-a-backup",[2612],{"type":43,"value":2613},"Replication is Not a Backup",{"type":37,"tag":46,"props":2615,"children":2616},{},[2617,2619,2624,2625,2631,2633,2639,2640,2646],{"type":43,"value":2618},"A ",{"type":37,"tag":158,"props":2620,"children":2622},{"className":2621},[],[2623],{"type":43,"value":648},{"type":43,"value":243},{"type":37,"tag":158,"props":2626,"children":2628},{"className":2627},[],[2629],{"type":43,"value":2630},"DELETE FROM table",{"type":43,"value":2632}," on the primary replicates to all replicas immediately. Replication protects against hardware failure — not against accidental data changes. Maintain independent backups (",{"type":37,"tag":158,"props":2634,"children":2636},{"className":2635},[],[2637],{"type":43,"value":2638},"mariadb-dump",{"type":43,"value":293},{"type":37,"tag":158,"props":2641,"children":2643},{"className":2642},[],[2644],{"type":43,"value":2645},"mariadb-backup",{"type":43,"value":2647},") on a schedule separate from replication.",{"type":37,"tag":46,"props":2649,"children":2650},{},[2651],{"type":43,"value":2652},"Delayed replication is one mitigation — intentionally lag a replica by a set time:",{"type":37,"tag":733,"props":2654,"children":2656},{"className":735,"code":2655,"language":737,"meta":738,"style":738},"CHANGE MASTER TO MASTER_DELAY = 3600;  -- 1 hour lag\n",[2657],{"type":37,"tag":158,"props":2658,"children":2659},{"__ignoreMap":738},[2660],{"type":37,"tag":744,"props":2661,"children":2662},{"class":746,"line":747},[2663],{"type":37,"tag":744,"props":2664,"children":2665},{},[2666],{"type":43,"value":2655},{"type":37,"tag":46,"props":2668,"children":2669},{},[2670],{"type":43,"value":2671},"This gives a recovery window for accidental changes, but it is still not a substitute for backups.",{"type":37,"tag":46,"props":2673,"children":2674},{},[2675,2680,2682,2688,2690,2696,2698,2703],{"type":37,"tag":105,"props":2676,"children":2677},{},[2678],{"type":43,"value":2679},"Point-in-time recovery (new in 13.0)",{"type":43,"value":2681}," — the ",{"type":37,"tag":158,"props":2683,"children":2685},{"className":2684},[],[2686],{"type":43,"value":2687},"innodb_log_archive",{"type":43,"value":2689}," variable (",{"type":37,"tag":518,"props":2691,"children":2693},{"href":1259,"rel":2692},[522],[2694],{"type":43,"value":2695},"MDEV-37949",{"type":43,"value":2697},") makes InnoDB preserve the write-ahead log as a continuous sequence of files instead of overwriting the circular redo log. Combined with a base backup, this is intended to enable PITR and incremental backups without relying on the binary log alone. It is ",{"type":37,"tag":105,"props":2699,"children":2700},{},[2701],{"type":43,"value":2702},"new in the 13.0 rolling release",{"type":43,"value":2704}," (not on the 11.8 LTS baseline) — treat it as recent and validate before depending on it for recovery.",{"type":37,"tag":252,"props":2706,"children":2708},{"id":2707},"failover-tools",[2709],{"type":43,"value":2710},"Failover Tools",{"type":37,"tag":1027,"props":2712,"children":2713},{},[2714,2739,2749],{"type":37,"tag":1031,"props":2715,"children":2716},{},[2717,2722,2724,2730,2732,2737],{"type":37,"tag":105,"props":2718,"children":2719},{},[2720],{"type":43,"value":2721},"Built-in (no proxy needed)",{"type":43,"value":2723}," — Galera failover is automatic: any surviving node keeps accepting writes. For async\u002FGTID replication, MariaDB does controlled primary switchover natively via GTID and ",{"type":37,"tag":158,"props":2725,"children":2727},{"className":2726},[],[2728],{"type":43,"value":2729},"MASTER_DEMOTE_TO_SLAVE",{"type":43,"value":2731}," (see ",{"type":37,"tag":518,"props":2733,"children":2735},{"href":2734},"#standard-async-replication",[2736],{"type":43,"value":677},{"type":43,"value":2738}," above), typically driven by your own scripts or an orchestrator.",{"type":37,"tag":1031,"props":2740,"children":2741},{},[2742,2747],{"type":37,"tag":105,"props":2743,"children":2744},{},[2745],{"type":43,"value":2746},"ProxySQL",{"type":43,"value":2748}," — open-source (GPLv3) proxy, widely used for read-write splitting and connection pooling with MariaDB.",{"type":37,"tag":1031,"props":2750,"children":2751},{},[2752,2757,2759,2764,2766],{"type":37,"tag":105,"props":2753,"children":2754},{},[2755],{"type":43,"value":2756},"MaxScale",{"type":43,"value":2758}," — MariaDB Corporation's proxy with automatic failover, read-write splitting, and connection routing (detects primary failure and promotes the most up-to-date replica; requires GTID replication). ",{"type":37,"tag":105,"props":2760,"children":2761},{},[2762],{"type":43,"value":2763},"Not open source",{"type":43,"value":2765}," — recent versions (25.01+) are closed-source commercial, and earlier versions used the source-available Business Source License (BSL), not an OSI open-source license. ",{"type":37,"tag":518,"props":2767,"children":2770},{"href":2768,"rel":2769},"https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fmaxscale",[522],[2771],{"type":43,"value":2772},"mariadb.com\u002Fdocs\u002Fmaxscale",{"type":37,"tag":46,"props":2774,"children":2775},{},[2776],{"type":43,"value":2777},"For basic Galera HA no proxy is required; ProxySQL or MaxScale add connection routing.",{"type":37,"tag":193,"props":2779,"children":2780},{},[2781],{"type":37,"tag":46,"props":2782,"children":2783},{},[2784,2789,2791,2797,2799,2805,2807,2813,2815,2821],{"type":37,"tag":105,"props":2785,"children":2786},{},[2787],{"type":43,"value":2788},"Galera load balancing requires cluster-state-aware monitoring.",{"type":43,"value":2790}," Do not route to all Galera nodes equally — a node in SST (full data copy) or desynced state may be up and accepting connections but behind by potentially millions of transactions. Check ",{"type":37,"tag":158,"props":2792,"children":2794},{"className":2793},[],[2795],{"type":43,"value":2796},"wsrep_local_state",{"type":43,"value":2798},": only ",{"type":37,"tag":158,"props":2800,"children":2802},{"className":2801},[],[2803],{"type":43,"value":2804},"4",{"type":43,"value":2806}," (Synced) is safe to route traffic to. ProxySQL can be configured with health checks that monitor ",{"type":37,"tag":158,"props":2808,"children":2810},{"className":2809},[],[2811],{"type":43,"value":2812},"wsrep_",{"type":43,"value":2814}," status variables; MaxScale uses the ",{"type":37,"tag":158,"props":2816,"children":2818},{"className":2817},[],[2819],{"type":43,"value":2820},"galeramon",{"type":43,"value":2822}," monitor for this purpose. Without state-aware routing, writes to a donor\u002Fdesynced node produce stale reads or integrity issues.",{"type":37,"tag":252,"props":2824,"children":2826},{"id":2825},"sources",[2827],{"type":43,"value":2828},"Sources",{"type":37,"tag":1027,"props":2830,"children":2831},{},[2832,2842,2851,2861,2870,2880,2890],{"type":37,"tag":1031,"props":2833,"children":2834},{},[2835],{"type":37,"tag":518,"props":2836,"children":2839},{"href":2837,"rel":2838},"https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fserver\u002Fha-and-performance\u002Fstandard-replication\u002Freplication-overview",[522],[2840],{"type":43,"value":2841},"Replication Overview — MariaDB Docs",{"type":37,"tag":1031,"props":2843,"children":2844},{},[2845],{"type":37,"tag":518,"props":2846,"children":2848},{"href":1170,"rel":2847},[522],[2849],{"type":43,"value":2850},"GTID — MariaDB Docs",{"type":37,"tag":1031,"props":2852,"children":2853},{},[2854],{"type":37,"tag":518,"props":2855,"children":2858},{"href":2856,"rel":2857},"https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fserver\u002Fha-and-performance\u002Fstandard-replication\u002Fparallel-replication",[522],[2859],{"type":43,"value":2860},"Parallel Replication — MariaDB Docs",{"type":37,"tag":1031,"props":2862,"children":2863},{},[2864],{"type":37,"tag":518,"props":2865,"children":2867},{"href":2026,"rel":2866},[522],[2868],{"type":43,"value":2869},"Semi-Synchronous Replication — MariaDB Docs",{"type":37,"tag":1031,"props":2871,"children":2872},{},[2873],{"type":37,"tag":518,"props":2874,"children":2877},{"href":2875,"rel":2876},"https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fgalera-cluster\u002Freference\u002Fmariadb-galera-cluster-known-limitations",[522],[2878],{"type":43,"value":2879},"Galera Cluster Known Limitations — MariaDB Docs",{"type":37,"tag":1031,"props":2881,"children":2882},{},[2883],{"type":37,"tag":518,"props":2884,"children":2887},{"href":2885,"rel":2886},"https:\u002F\u002Fmariadb.org\u002Fauto-increments-in-galera\u002F",[522],[2888],{"type":43,"value":2889},"Auto-Increments in Galera — mariadb.org",{"type":37,"tag":1031,"props":2891,"children":2892},{},[2893],{"type":37,"tag":518,"props":2894,"children":2897},{"href":2895,"rel":2896},"https:\u002F\u002Fmariadb.com\u002Fdocs\u002Fmaxscale\u002Fmariadb-maxscale-tutorials\u002Fautomatic-failover-with-mariadb-monitor",[522],[2898],{"type":43,"value":2899},"Automatic Failover with MariaDB Monitor — MaxScale Docs",{"type":37,"tag":46,"props":2901,"children":2902},{},[2903],{"type":37,"tag":50,"props":2904,"children":2905},{},[2906,2908,2915],{"type":43,"value":2907},"For topics not covered here, see the official MariaDB documentation at ",{"type":37,"tag":518,"props":2909,"children":2912},{"href":2910,"rel":2911},"https:\u002F\u002Fmariadb.com\u002Fdocs",[522],[2913],{"type":43,"value":2914},"mariadb.com\u002Fdocs",{"type":43,"value":1176},{"type":37,"tag":2917,"props":2918,"children":2919},"style",{},[2920],{"type":43,"value":2921},"html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"items":2923,"total":810},[2924,2938,2950,2961,2967,2985,2997,3010],{"slug":2925,"name":2925,"fn":2926,"description":2927,"org":2928,"tags":2929,"stars":20,"repoUrl":21,"updatedAt":2937},"mariadb-features","optimize and manage MariaDB databases","MariaDB-specific features and capabilities that go beyond standard MySQL. Use when evaluating MariaDB, optimizing an existing MariaDB application, reviewing code or schema for MariaDB improvements, asking what MariaDB can do that other databases cannot, or migrating from Oracle to MariaDB. Also use when the user asks what could be improved in how a codebase uses MariaDB, or asks about MariaDB advantages over MySQL or PostgreSQL.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2930,2931,2932,2935],{"name":18,"slug":19,"type":15},{"name":9,"slug":8,"type":15},{"name":2933,"slug":2934,"type":15},"Performance","performance",{"name":2936,"slug":737,"type":15},"SQL","2026-07-16T06:01:55.988338",{"slug":2939,"name":2939,"fn":2940,"description":2941,"org":2942,"tags":2943,"stars":20,"repoUrl":21,"updatedAt":2949},"mariadb-mcp","connect AI agents to MariaDB","How to connect AI agents to MariaDB using the Model Context Protocol (MCP). Use when setting up MCP with MariaDB, connecting Claude Code, Cursor, or other AI tools to a MariaDB database, enabling natural language database queries, or building AI applications that need live database access. The MariaDB MCP Server lets agents query schemas, run read-only SQL, and perform semantic search against MariaDB.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2944,2945,2946],{"name":18,"slug":19,"type":15},{"name":9,"slug":8,"type":15},{"name":2947,"slug":2948,"type":15},"MCP","mcp","2026-07-13T06:14:00.682655",{"slug":2951,"name":2951,"fn":2952,"description":2953,"org":2954,"tags":2955,"stars":20,"repoUrl":21,"updatedAt":2960},"mariadb-query-optimization","optimize MariaDB database queries","Best practices for query optimization in MariaDB — indexing strategies, EXPLAIN analysis, pagination, histogram statistics, and MariaDB-specific optimizer settings. Use when diagnosing slow queries, designing indexes, reviewing schema or query performance, or when queries involve large tables, pagination, GROUP BY, or ORDER BY. Also use when the user asks about MariaDB query performance, EXPLAIN output, or optimizer behavior.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2956,2957,2958,2959],{"name":18,"slug":19,"type":15},{"name":9,"slug":8,"type":15},{"name":2933,"slug":2934,"type":15},{"name":2936,"slug":737,"type":15},"2026-07-13T06:14:12.656074",{"slug":4,"name":4,"fn":5,"description":6,"org":2962,"tags":2963,"stars":20,"repoUrl":21,"updatedAt":22},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2964,2965,2966],{"name":13,"slug":14,"type":15},{"name":18,"slug":19,"type":15},{"name":9,"slug":8,"type":15},{"slug":2968,"name":2968,"fn":2969,"description":2970,"org":2971,"tags":2972,"stars":20,"repoUrl":21,"updatedAt":2984},"mariadb-system-versioned-tables","implement MariaDB system-versioned tables","Best practices for MariaDB system-versioned (temporal) tables — automatic row history built into the database. Use when tracking data changes over time, implementing audit trails, meeting GDPR or compliance requirements, doing point-in-time queries, or when the user asks about row history, data versioning, temporal tables, or querying past data states in MariaDB. This feature is unique to MariaDB among MySQL-compatible databases.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2973,2976,2979,2980,2983],{"name":2974,"slug":2975,"type":15},"Audit","audit",{"name":2977,"slug":2978,"type":15},"Compliance","compliance",{"name":18,"slug":19,"type":15},{"name":2981,"slug":2982,"type":15},"GDPR","gdpr",{"name":9,"slug":8,"type":15},"2026-07-13T06:14:16.779878",{"slug":2986,"name":2986,"fn":2987,"description":2988,"org":2989,"tags":2990,"stars":20,"repoUrl":21,"updatedAt":2996},"mariadb-vector","build semantic search with MariaDB vectors","Best practices for using vectors and AI with MariaDB. Use when writing SQL involving VECTOR columns, building RAG or semantic search with MariaDB, choosing embedding models, designing vector indexes, or integrating MariaDB with AI frameworks like LangChain, LlamaIndex, or Spring AI. Also use when the user mentions MariaDB and any of: vectors, embeddings, similarity search, nearest neighbor, AI, RAG, or LLM. IMPORTANT — MariaDB has native built-in vector support since version 11.7; it is NOT a plugin or extension (unlike pgvector for PostgreSQL). Do not recommend installing any extension.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2991,2992,2993],{"name":18,"slug":19,"type":15},{"name":9,"slug":8,"type":15},{"name":2994,"slug":2995,"type":15},"Migration","migration","2026-07-13T06:14:01.939479",{"slug":2998,"name":2998,"fn":2999,"description":3000,"org":3001,"tags":3002,"stars":20,"repoUrl":21,"updatedAt":3009},"mysql-to-mariadb","migrate applications from MySQL to MariaDB","Compatibility guide for developers moving from MySQL to MariaDB, and for developers with MySQL experience working with MariaDB. Use when migrating a MySQL application to MariaDB, when MySQL syntax or habits cause unexpected behavior in MariaDB, when asking about MySQL\u002FMariaDB compatibility, or when adapting code written for MySQL to run on MariaDB. IMPORTANT — MariaDB diverges significantly from MySQL 8.0 and is not a simple drop-in replacement for modern MySQL. Authentication plugins, JSON handling, GTID replication, and several SQL features differ in important ways.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[3003,3004,3005,3006],{"name":18,"slug":19,"type":15},{"name":9,"slug":8,"type":15},{"name":2994,"slug":2995,"type":15},{"name":3007,"slug":3008,"type":15},"MySQL","mysql","2026-07-13T06:14:08.675338",{"slug":3011,"name":3011,"fn":3012,"description":3013,"org":3014,"tags":3015,"stars":20,"repoUrl":21,"updatedAt":3019},"oracle-to-mariadb","migrate Oracle databases to MariaDB","Compatibility guide for developers migrating from Oracle Database to MariaDB. Use when migrating Oracle schemas, PL\u002FSQL procedures, or applications to MariaDB, when Oracle syntax causes unexpected behavior in MariaDB, or when evaluating MariaDB as an Oracle replacement. MariaDB is the only open source database with native PL\u002FSQL compatibility — MariaDB's sql_mode=ORACLE enables migration of approximately 80% of Oracle code without rewrites.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[3016,3017,3018],{"name":18,"slug":19,"type":15},{"name":9,"slug":8,"type":15},{"name":2994,"slug":2995,"type":15},"2026-07-13T06:14:11.069809",{"items":3021,"total":810},[3022,3029,3035,3042,3048,3056,3062],{"slug":2925,"name":2925,"fn":2926,"description":2927,"org":3023,"tags":3024,"stars":20,"repoUrl":21,"updatedAt":2937},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[3025,3026,3027,3028],{"name":18,"slug":19,"type":15},{"name":9,"slug":8,"type":15},{"name":2933,"slug":2934,"type":15},{"name":2936,"slug":737,"type":15},{"slug":2939,"name":2939,"fn":2940,"description":2941,"org":3030,"tags":3031,"stars":20,"repoUrl":21,"updatedAt":2949},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[3032,3033,3034],{"name":18,"slug":19,"type":15},{"name":9,"slug":8,"type":15},{"name":2947,"slug":2948,"type":15},{"slug":2951,"name":2951,"fn":2952,"description":2953,"org":3036,"tags":3037,"stars":20,"repoUrl":21,"updatedAt":2960},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[3038,3039,3040,3041],{"name":18,"slug":19,"type":15},{"name":9,"slug":8,"type":15},{"name":2933,"slug":2934,"type":15},{"name":2936,"slug":737,"type":15},{"slug":4,"name":4,"fn":5,"description":6,"org":3043,"tags":3044,"stars":20,"repoUrl":21,"updatedAt":22},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[3045,3046,3047],{"name":13,"slug":14,"type":15},{"name":18,"slug":19,"type":15},{"name":9,"slug":8,"type":15},{"slug":2968,"name":2968,"fn":2969,"description":2970,"org":3049,"tags":3050,"stars":20,"repoUrl":21,"updatedAt":2984},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[3051,3052,3053,3054,3055],{"name":2974,"slug":2975,"type":15},{"name":2977,"slug":2978,"type":15},{"name":18,"slug":19,"type":15},{"name":2981,"slug":2982,"type":15},{"name":9,"slug":8,"type":15},{"slug":2986,"name":2986,"fn":2987,"description":2988,"org":3057,"tags":3058,"stars":20,"repoUrl":21,"updatedAt":2996},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[3059,3060,3061],{"name":18,"slug":19,"type":15},{"name":9,"slug":8,"type":15},{"name":2994,"slug":2995,"type":15},{"slug":2998,"name":2998,"fn":2999,"description":3000,"org":3063,"tags":3064,"stars":20,"repoUrl":21,"updatedAt":3009},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[3065,3066,3067,3068],{"name":18,"slug":19,"type":15},{"name":9,"slug":8,"type":15},{"name":2994,"slug":2995,"type":15},{"name":3007,"slug":3008,"type":15}]