MariaDB 12.3 LTS: Advances and Building Fault-Tolerant MariaDB Infrastructure at Internet Scale

MariaDB 12.3 is the current long-term support release of MariaDB Community Server. It reached Stable/GA on 28 May 2026 and is maintained until June 2029, making it the first LTS line since MariaDB 11.8. For teams running transactional workloads at internet scale, MariaDB 12.3 is not a routine point upgrade: it rewrites the durability contract between the binary log and InnoDB, adds a full MySQL-compatible optimizer hint framework, and hardens Galera Cluster behaviour under state transfer and write-set conflict. This guide dissects those advancements at engine level and then shows how to compose them into a highly available, fault-tolerant MariaDB infrastructure that survives node, rack, availability-zone and region failure.

Everything below is written from the perspective of database reliability engineering: what changed, why it changes the physics of your write path, what it costs, and how to operationalise it. If you are still on 10.6, 10.11 or 11.4, treat this as an architecture review document rather than a changelog.

Why MariaDB 12.3 Is a Structural Release, Not a Point Upgrade

MariaDB moved to a rolling-plus-LTS cadence several years ago. Rolling releases (12.0, 12.1, 12.2, and now the 13.0 RC line) carry features forward quickly; LTS releases consolidate them into a five-year maintenance window. MariaDB 12.3 is the consolidation point for everything merged since 11.8, which is why the delta looks unusually large.

Three of those changes alter architecture rather than syntax:

1. The binary log can now live inside InnoDB. That removes two-phase commit between the log and the storage engine, collapses the fsync budget of a commit, and makes the binlog crash-safe by inheritance rather than by configuration.
2. The optimizer is now steerable. A comprehensive hint vocabulary lands in the parser, so query plans can be pinned per statement instead of per session or per server.
3. Galera state transfer and conflict handling got cheaper. Incremental State Transfers skip redundant foreign key validation, and write-set application can be retried instead of aborting the applier.

Add the metadata-lock scalability work, the segmented Aria page cache, parallel replication between two Galera clusters, and buffered audit logging, and MariaDB 12.3 becomes the first release in years where the default HA topology should be re-evaluated from first principles.

The Headline Advancement in MariaDB 12.3: InnoDB-Based Binary Log

Historically MariaDB treated the binary log and InnoDB as two independent durable resources. Every commit therefore ran a two-phase commit protocol: prepare in InnoDB, write and sync the binlog, then commit in InnoDB. With sync_binlog=1 and innodb_flush_log_at_trx_commit=1, a durable commit could cost multiple fsync operations and required a recovery-time reconciliation between the two logs after a crash.

From MariaDB 12.3 the binary log can instead be stored in InnoDB-managed, page-structured files that participate in the InnoDB redo log and crash recovery. The files still live on disk as discrete objects with an .ibb extension, but internally they are 16 KB pages with a CRC32 checksum per page, pre-allocated to max_binlog_size (1 GB by default) so that write amplification from file extension disappears.

What actually changes in the commit path

The engine no longer needs to coordinate two logs, so the expensive cross-resource handshake disappears. At innodb_flush_log_at_trx_commit=1 a commit performs a single coordinated fsync instead of the several required by the old protocol. Because the binlog and InnoDB always recover to a mutually consistent state, you can also run with innodb_flush_log_at_trx_commit=0 or 2 and still guarantee that the binary log never diverges from table data after a crash - you are trading durability of the last few commits for throughput, not risking replication divergence.

Two long-standing configuration knobs become obsolete in this mode. sync_binlog is no longer required because crash safety is inherited from InnoDB, and binlog_checksum is unused because every page carries a CRC32 already. If you want integrity on the wire between primary and replica, enable TLS on the replication channel instead.

Positioning becomes GTID-only

The new implementation is GTID-native. There are no .index files, no GTID index files and no .state file. Instead the binary log periodically embeds GTID state records inside itself, by default every 2 MB, and that interval must be a power-of-two multiple of the 16 KB page size. When a replica connects, or when the server restarts, the log is scanned backwards from the most recent state record to recover the correct GTID position.

The practical consequence is that file-and-offset replication coordinates no longer exist on a primary running the InnoDB binlog: SHOW BINLOG EVENTS will generally report offsets of zero and you must navigate by GTID. The status counters binlog_gtid_index_hit and binlog_gtid_index_miss are also retired in this mode.

Backup semantics improve

Because the binlog is now InnoDB data, mariadb-backup includes it in a transactionally consistent way by default. That resolves a long-standing gap where physical backups and binary logs were captured by different mechanisms with slightly different consistency points, which is exactly the seam where point-in-time recovery used to fail during real incidents.

When you should not enable it

The InnoDB-based binary log is not a universal default. Stay on the traditional implementation if any of the following apply to your MariaDB 12.3 deployment:

• You run Galera Cluster. Synchronous multi-master requires the classic binlog implementation.
• Applications or tooling depend on filename/offset replication positions rather than GTIDs.
• Third-party CDC pipelines, such as change-data-capture connectors, parse binlog files directly from disk.
• Your replicas are still below MariaDB 12.3. Upgrade replicas first, then switch the primary.

Note also that the relay log on replicas is unchanged and still uses the traditional format, so the improvement applies to the write path of the primary, not to the apply path of the replica.

Optimizer Advancements in MariaDB 12.3

The second structural change in MariaDB 12.3 is that query plans became controllable at statement granularity. Until now, plan stability on MariaDB was largely a matter of session variables, optimizer_switch bitmasks and index hints. That is a blunt instrument in a multi-tenant fleet where one report can destabilise an OLTP workload.

A complete optimizer hint vocabulary

MariaDB 12.3 ships a MySQL-compatible hint framework covering access methods, join strategy, join order, subquery handling and execution limits:

• Access and algorithm hints: NO_RANGE_OPTIMIZATION, NO_ICP, MRR / NO_MRR, BKA / NO_BKA, BNL / NO_BNL, [NO_]ROWID_FILTER, [NO_]INDEX_MERGE.
• Index hints: [NO_]INDEX, [NO_]JOIN_INDEX, [NO_]GROUP_INDEX, [NO_]ORDER_INDEX.
• Join order hints: JOIN_FIXED_ORDER, JOIN_ORDER, JOIN_PREFIX, JOIN_SUFFIX.
• Subquery hints: SEMIJOIN, SUBQUERY, [NO_]SPLIT_MATERIALIZED, [NO_]DERIVED_CONDITION_PUSHDOWN, [NO_]MERGE.
• Guardrails: MAX_EXECUTION_TIME, plus QB_NAME and implicit query block names so hints can target a specific block of a nested statement.

-- Pin a report query without touching global optimizer_switch
SELECT /*+ QB_NAME(agg) MAX_EXECUTION_TIME(4000) NO_BNL(o) JOIN_PREFIX(c, o) */
       c.region, SUM(o.amount)
FROM   customers c
JOIN   orders o ON o.customer_id = c.id
WHERE  o.created_at >= NOW() - INTERVAL 1 DAY
GROUP  BY c.region;

For internet-scale fleets this is the difference between a plan regression that pages an on-call engineer and one that is contained inside a single statement. Combine it with the extended optimizer trace, which in MariaDB 12.3 can record table and view definitions via optimizer_record_context, and post-incident plan forensics becomes reproducible.

Reverse-ordered scans and DESC key parts

Several optimizations that previously fired only on forward scans now work in reverse order. Rowid filtering and Index Condition Pushdown both apply to reverse-ordered scans, and the loose index scan used for GROUP BY can now exploit indexes with DESC key parts. Descending-order pagination on time-series tables - the classic ORDER BY created_at DESC LIMIT n pattern - is the workload that benefits most. Optimizations for GROUP BY and ORDER BY can also use indexes defined on virtual columns, which finally makes generated-column indexing a first-class tuning technique. For a deeper treatment of join planning, see our analysis of the MariaDB join optimizer.

Engine-level throughput work

Metadata lock scalability was reworked, which matters on servers with tens of thousands of tables and aggressive DDL. The Aria storage engine gained a segmented key cache controlled by aria_pagecache_segments (default 1, maximum 128), reducing mutex contention on internal and temporary tables. Vector distance calculation was accelerated through extrapolation, which is relevant if you are using MariaDB as a vector store; we covered the storage layout in understanding vector indexes in MariaDB.

Replication and Galera Cluster Improvements in MariaDB 12.3

Asynchronous replication between two Galera clusters can now use parallel replication, governed by slave_parallel_threads. This is the topology most large deployments actually run: a synchronous cluster per region, stitched together asynchronously across regions. Until now, the cross-region channel was effectively single-threaded and became the ceiling on write throughput for the whole estate. Removing that ceiling changes regional DR from best-effort to viable.

Other replication-layer changes with operational weight:

• Row events larger than max_packet_size are now fragmented rather than failing the channel - the historical cause of stalled replication on wide BLOB writes.
• Defaults for MASTER_SSL_* are configurable, so TLS on replication channels can be enforced fleet-wide instead of per CHANGE MASTER statement.
• Temporary table behaviour in replication is now predictable and controlled by create_tmp_table_binlog_formats.
• show_slave_auth_info and replicate_same_server_id are proper system variables rather than start-up options only, and the server reports whether it started with skip-slave-start.

On the Galera side, Incremental State Transfers no longer perform needless foreign key checks, which materially shortens the window during which a rejoining node loads the cluster. Write-set application can be retried instead of aborting, controlled by wsrep_applier_retry_count, which reduces spurious node evictions under hot-row contention. Packaging also changed: the Galera dependency has been removed from the server packages, so Galera is now an explicit install rather than an implicit one. If you operate Galera in production, our field notes on troubleshooting writes in Galera Cluster and MariaDB Galera Cluster monitoring pair directly with these changes.

Security, Compatibility and Developer Surface in MariaDB 12.3

Security work in MariaDB 12.3 is focused on key material and identity. Passphrase-protected TLS keys are supported through the new ssl_passphrase system variable, the file key management plugin for transparent data encryption supports SHA-256 on Linux, and SET SESSION AUTHORIZATION allows a privileged session to execute as another user - a cleaner primitive for connection-pool multiplexing and for auditing than credential sharing.

DROP USER now warns when the account still has live sessions, and fails outright in Oracle mode. The audit plugin gained buffered logging via server_audit_file_buffer_size, records the client host and port rather than host alone, and reports the negotiated TLS version. That combination makes audit logging viable on high-QPS nodes where it was previously too expensive; see our guide to MariaDB user activity logging.

The compatibility surface widened significantly. MariaDB 12.3 adds the caching_sha2_password authentication plugin for MySQL clients, Oracle-style TO_DATE(), TO_NUMBER() and TRUNC(), the Oracle (+) outer-join operator in Oracle mode, associative arrays through DECLARE TYPE ... TABLE OF ... INDEX BY, weak SYS_REFCURSOR support with a max_open_cursors ceiling, cursors on prepared statements, the SQL standard SET PATH statement and IS JSON predicate, a basic XML data type, and the ability for UPDATE and DELETE to read from a CTE. Triggers can now fire on multiple events, foreign key constraint names only need to be unique per table, and the 32-level depth limit on JSON functions is gone. Nine new GIS functions improve MySQL 8 parity.

Six CVEs were fixed in the 12.3.2 GA build, the most severe carrying a CVSS v3.1 base score of 8.0. That alone justifies scheduling the upgrade rather than deferring it.

Reference Architecture: Highly Available MariaDB 12.3 at Internet Scale

Availability is not a feature you enable; it is a property that emerges from how you arrange failure domains. The architecture below is the pattern MinervaDB deploys for workloads that must tolerate the loss of a node, a rack, an availability zone or an entire region without data loss and without a maintenance window. It layers synchronous replication inside a region for zero-RPO, asynchronous GTID replication across regions for geographic survivability, and a routing tier that makes failover invisible to the application.

Tier 0 — Enumerate failure domains before choosing technology

Design starts by writing down what can fail and what each failure must cost you. A useful matrix for MariaDB 12.3 deployments looks like this:

Notice that only two rows are solved by replication. The rest are solved by backups, delayed replicas and process discipline. Teams that equate high availability with clustering discover this during their first bad migration.

Tier 1 — Synchronous replication inside the region

Inside a region, use a three-node MariaDB 12.3 Galera cluster with exactly one node per availability zone. Three nodes is the minimum that tolerates the loss of one while retaining a majority; five nodes buys tolerance of two failures at the cost of higher certification latency, because every transaction must be replicated to every node before commit returns.

The parameters that decide whether the cluster is stable under load are not the ones people usually tune. Size gcache.size to cover the longest plausible node outage so a rejoining node can use an Incremental State Transfer rather than a full State Snapshot Transfer; a full SST on a multi-terabyte dataset is a self-inflicted outage. Set wsrep_sst_method=mariabackup so donors remain readable.

Use gmcast.segment so that inter-AZ traffic is not multiplied by the number of nodes. Tune gcs.fc_limit deliberately: flow control is Galera telling you the slowest node cannot keep up, and raising the limit hides the symptom while increasing the amount of data at risk. Finally, keep wsrep_slave_threads aligned with the number of independently writable tables rather than with CPU count.

MariaDB 12.3 improves two of the worst Galera failure modes directly. Incremental State Transfers no longer waste time re-validating foreign keys, so rejoin time drops on schemas with heavy referential integrity. And wsrep_applier_retry_count lets a node retry a conflicting write-set instead of dropping out of the cluster, which is exactly the behaviour you want on hot counters and sequence-like rows.

Tier 2 — Asynchronous replication across regions

Synchronous replication across a wide-area link is an availability anti-pattern: it converts network latency into commit latency and a partition into an outage. Instead, replicate asynchronously from the active regional cluster to a standby cluster using GTIDs.

This is where MariaDB 12.3 changes the calculus. Asynchronous replication between two Galera clusters can now apply in parallel using slave_parallel_threads, so the cross-region channel no longer serialises the write throughput of an entire region. Combine it with slave_parallel_mode=optimistic, GTID-based CHANGE MASTER TO ... master_use_gtid=slave_pos, and enforced TLS defaults on the channel. Add a semi-synchronous acknowledgement with rpl_semi_sync_master_wait_point=AFTER_SYNC only if your RPO requirement is stricter than the replication lag you can actually sustain, and always configure a wait timeout so the primary degrades to asynchronous rather than stalling when the standby is unreachable. Our guide on horizontally scaling MariaDB covers the read-scaling side of this topology.

Tier 3 — The routing tier is what the application actually sees

Applications should never hold a connection to a database node. They connect to MaxScale, which owns topology knowledge and failure detection. Deploy at least two MaxScale instances behind a virtual IP or a Kubernetes service, configure the readwritesplit router, enable transaction replay so in-flight transactions survive a backend failover, and enable causal reads so a read issued immediately after a write is routed to a node that has applied it. Set max_slave_replication_lag to keep stale replicas out of the read pool.

MariaDB 12.3 also carries a connection redirection mechanism in the client/server protocol, which lets a proxy hand a client off to the correct node instead of proxying every packet. For very high connection counts this removes the proxy from the data path once routing is established. ProxySQL remains a valid alternative where query rewriting and fine-grained rule sets matter; see our notes on troubleshooting ProxySQL in high-velocity ingestion.

Tier 4 — Declarative operations on Kubernetes

If you run on Kubernetes, the mariadb-operator expresses this whole topology as custom resources. It supports both asynchronous replication and synchronous Galera topologies, manages MaxScale as a first-class object, performs cluster-aware rolling updates that roll replica pods first and the primary last, and supports blue/green upgrades across two identical clusters so a version change becomes a traffic switch instead of a restart. Physical backups run through mariadb-backup and VolumeSnapshots, and binary log archiving enables point-in-time recovery. Our article on tuning MariaDB for cloud and containerized environments covers the resource-limit and storage-class decisions that make or break this layer.

Tier 5 — Backups are the only true fault tolerance

Replication propagates mistakes at the speed of the network. Backups do not. Run daily full plus hourly incremental mariadb-backup jobs streamed to object storage with versioning and object-lock enabled, replicate the bucket cross-region, and enable InnoDB log archiving so you can replay to a specific log sequence number. Under the InnoDB-based binary log, backups now include binlog files transactionally, which removes the historical seam between a physical backup and the binlog stream.

Then do the part most teams skip: restore automatically on a schedule, into an isolated environment, and measure the restore time against your stated RTO. A backup that has never been restored is a hypothesis. See our reference on transferring backed-up data to a MariaDB replica.

Production Configuration Baselines for MariaDB 12.3

The following is a starting point for a 64-core, 512 GB, NVMe-backed MariaDB 12.3 node participating in a Galera cluster. Treat it as a hypothesis to be validated with your own workload, not a copy-paste answer.

[mariadb]
# --- Durability and memory ---
innodb_buffer_pool_size          = 360G
innodb_buffer_pool_instances     = 16
innodb_log_file_size             = 16G
innodb_flush_log_at_trx_commit   = 1
innodb_flush_method              = O_DIRECT
innodb_io_capacity               = 20000
innodb_io_capacity_max           = 40000
innodb_read_io_threads           = 16
innodb_write_io_threads          = 16
innodb_adaptive_hash_index       = OFF

# --- Replication (GTID everywhere) ---
log_bin
binlog_format                    = ROW
binlog_row_image                 = MINIMAL
gtid_strict_mode                 = ON
slave_parallel_threads           = 16
slave_parallel_mode              = optimistic
expire_logs_days                 = 7

# --- Galera ---
wsrep_on                         = ON
wsrep_provider                   = /usr/lib/galera/libgalera_smm.so
wsrep_sst_method                 = mariabackup
wsrep_slave_threads              = 16
wsrep_applier_retry_count        = 3
wsrep_provider_options           = "gcache.size=64G; gcs.fc_limit=64; gmcast.segment=0; evs.suspect_timeout=PT10S; evs.inactive_timeout=PT30S"

# --- Aria (internal + temporary tables) ---
aria_pagecache_buffer_size       = 8G
aria_pagecache_segments          = 16

# --- Observability and safety ---
server_audit_file_buffer_size    = 8M
max_execution_time               = 30000
optimizer_record_context         = ON

On a non-Galera MariaDB 12.3 primary that uses GTID replication exclusively, you can additionally enable the InnoDB-based binary log and delete sync_binlog and binlog_checksum from your configuration entirely. Verify replica versions first.

Observability: The SLIs That Actually Predict a MariaDB Outage

Most MariaDB dashboards measure the wrong things. Query counts and buffer pool hit ratios are descriptive; they are rarely predictive. The signals below lead incidents by minutes to hours:

• wsrep_flow_control_paused — the fraction of time the cluster was paused by flow control. Anything sustained above 0.02 means the slowest node is governing your write throughput.
• wsrep_local_recv_queue_avg — a rising average means an applier cannot keep up and a certification failure storm is likely.
• wsrep_cert_deps_distance — the achievable parallelism of your workload; it tells you whether raising wsrep_slave_threads would help at all.
• InnoDB history list length — unbounded growth means purge is behind, and purge lag is the silent precursor to a storage emergency.
• Commit latency p99 and fsync rate — the pair that reveals whether the InnoDB binary log change delivered the throughput it promised.
• Replication lag distribution, not average — cross-region RPO is defined by the tail, never by the mean.

Alert on error-budget burn rate rather than static thresholds, and keep a runbook link in every alert. Our field guide to MariaDB performance monitoring metrics expands each of these into queries and thresholds, and troubleshooting MariaDB performance covers the diagnostic path once an alert fires.

Failure Modes and Anti-Patterns to Avoid

• Two-node Galera clusters. A two-node cluster has no majority; losing either node halts the survivor. Use three, or two plus a garbd arbitrator.
• Writing to all Galera nodes without partitioning. Multi-master is a topology, not a write strategy. Route writes for a given hot table to one node to avoid certification conflicts, even in MariaDB 12.3 where retries soften the impact.
• Raising gcs.fc_limit to silence flow control. You are increasing unreplicated data in flight while hiding the node that is actually slow.
• Enabling the InnoDB binary log on a Galera node. It is unsupported in that topology; verify before you roll a configuration change fleet-wide.
• Relying on Seconds_Behind_Master alone. It reports apply lag, not the transport gap. Use GTID position deltas and a heartbeat table.
• DDL without a plan. Schema changes in Galera can block the entire cluster under Total Order Isolation. Use Rolling Schema Upgrade or an online schema change tool with explicit checks.
• Untested failover. If you have not performed a switchover in the last quarter, your RTO is an estimate, not a commitment. Related reading: MariaDB high availability best practices and MariaDB deadlock troubleshooting.

Upgrading from MariaDB 11.8 to MariaDB 12.3

Because MariaDB 12.3 is the first LTS after 11.8, the upgrade crosses four release boundaries of accumulated change. Three categories of breakage deserve a pre-flight check.

New reserved words. CONVERSION, ST_COLLECT and TO_DATE are now reserved. Any identifier using them must be backtick-quoted. Grep your schema and application SQL before the maintenance window, not during it.

Removed system variables. big_tables, large_page_size and storage_engine were removed in the 12.0 line. If they remain in my.cnf, the server will refuse to start.

A GTID setting regression in 12.3.2. When a replica is upgraded from a pre-12.3 release directly to 12.3.2, the master_use_gtid setting from CHANGE MASTER TO is not carried over and resets to DEFAULT. This is fixed in 12.3.3. If you land on 12.3.2, re-apply master_use_gtid immediately after the upgrade and verify with SHOW REPLICA STATUS. Downgrades are unaffected.

The safe rollout order for a Galera plus async topology is: upgrade the DR region first, then read replicas, then the non-primary nodes of the active cluster one at a time, then the primary via a controlled MaxScale switchover. Take a verified mariadb-backup before the first node, run mariadb-upgrade where required, and keep the old binaries installed until you have completed a full business cycle on the new version. Follow the official MariaDB upgrade documentation for platform specifics.

Benchmarking and Capacity Planning for MariaDB 12.3

Do not accept the throughput claims of any release — including this one — without measuring them on your own hardware and workload shape. A defensible benchmark for the MariaDB 12.3 binary log change looks like this:

1. Capture a production workload sample and replay it, rather than running a synthetic uniform-random benchmark that no application resembles.
2. Measure with the traditional binlog at sync_binlog=1, innodb_flush_log_at_trx_commit=1 as your control.
3. Re-measure with the InnoDB-based binlog at innodb_flush_log_at_trx_commit=1. Record commit latency percentiles, not averages, and record device-level fsync counts.
4. Run a third pass at innodb_flush_log_at_trx_commit=2 to quantify what relaxed durability actually buys now that consistency between log and engine is guaranteed regardless.
5. Repeat each pass with a deliberately induced crash to confirm recovery time and GTID continuity.

Capacity planning should then be expressed in headroom rather than utilisation: a cluster running at 70% of measured write capacity has no room to absorb the loss of a node, because the survivors inherit the load and the certification cost of the failure. Size for N-1 in region and N-1 across regions.

Frequently Asked Questions About MariaDB 12.3

Is MariaDB 12.3 a long-term support release?

Yes. MariaDB 12.3 reached Stable/GA on 28 May 2026 and is maintained until June 2029. It is the successor LTS to MariaDB 11.8.

Should I enable the InnoDB-based binary log in MariaDB 12.3?

Enable it on GTID-only replication topologies where you control the tooling and all replicas run MariaDB 12.3 or later. Do not enable it on Galera Cluster nodes, on systems that depend on filename/offset positions, or where third-party tools parse binlog files from disk.

Does MariaDB 12.3 change how Galera Cluster behaves?

Yes, in three ways. Incremental State Transfers skip redundant foreign key checks, write-set application can be retried via wsrep_applier_retry_count, and asynchronous replication between two Galera clusters can now apply in parallel. Galera is also no longer a package dependency of the server, so it must be installed explicitly.

What is the fastest safe upgrade path from MariaDB 10.11 to MariaDB 12.3?

Upgrade in LTS steps — 10.11 to 11.4, 11.4 to 11.8, then 11.8 to MariaDB 12.3 — validating application compatibility at each stop. Skipping LTS boundaries is technically possible but leaves you without a tested rollback point.

How many nodes do I need for a fault-tolerant MariaDB 12.3 cluster?

Three synchronous nodes per region, one per availability zone, plus at least one asynchronous standby cluster in a second region. That combination survives a node failure with zero data loss and a full region failure with sub-second RPO.

Do optimizer hints in MariaDB 12.3 replace query tuning?

No. Hints are a containment tool for plan regressions and a way to protect a fleet from a single pathological statement. Schema design, indexing and statistics remain the durable fix.

Conclusion

MariaDB 12.3 is the most consequential MariaDB release in several years because it changes the cost of durability rather than merely adding syntax. Storing the binary log inside InnoDB collapses the fsync budget of a commit and makes crash safety structural. The optimizer hint framework converts plan stability from a global gamble into a per-statement contract. Galera improvements shorten the rejoin window and reduce spurious evictions. None of that, however, produces availability on its own. Availability comes from arranging those primitives across failure domains: synchronous replication inside a region, asynchronous GTID replication across regions, a routing tier that hides failover from applications, declarative operations, and backups that are restored on a schedule rather than trusted on faith.

If you are planning a MariaDB 12.3 upgrade, a Galera redesign, or a move to multi-region topology, MinervaDB consultative support provides 24x7 engineering for MariaDB, MySQL and PostgreSQL infrastructure at internet scale. You can also review our MariaDB storage and virtualization whitepaper for the infrastructure layer beneath this architecture.

Further reading and authoritative references

• MariaDB 12.3 changes and improvements (official release notes)
• InnoDB-based binary log documentation
• MariaDB Galera Cluster documentation
• MariaDB MaxScale documentation
• Global Transaction ID reference
• Backup and restore, including point-in-time recovery
• Download MariaDB Server from MariaDB Foundation