MariaDB Xpand Parallel Replication Architecture
This page is part of MariaDB's Documentation.
The parent of this page is: Replication for MariaDB Xpand
Topics on this page:
Overview
MariaDB Xpand 6 provides parallel replication for applications that require extremely scalable replication between Xpand clusters:
Parallel replication minimizes latency and slave lag
Multiple Xpand nodes stream and apply events independently in parallel
Xpand ensures transactional consistency and commits transactions in the same order as the replication primary
Parallel replication can only be used when replicating from another MariaDB Xpand cluster
Parallel replication is supported with MariaDB Xpand 6
Xpand requires row-based replication (RBR) for parallel replication
For parallel replication, all replicated tables should have primary keys
This page explains the architecture related to parallel replication with MariaDB Xpand.
For information on how to configure parallel replication with MariaDB Xpand, see "Configure Parallel Replication with MariaDB Xpand".
Compatibility
MariaDB Xpand 6
Extremely Scalable Replication
With MariaDB Xpand 6, parallel replication provides extremely scalable replication.
When parallel replication is configured on a slave Xpand cluster, the level of parallelism is set using CREATE SLAVE .. SLICES = n
, where n
is the number of Slave Event Readers / Applicators that the Xpand cluster should create.
When Xpand creates the specified number of Slave Event Readers / Applicators, Xpand uses the consistent hashing algorithm to uniformly distribute the Slave Event Readers / Applicators between all of the nodes. The Slave Event Readers / Applicators on each node independently perform work in parallel:
Each Slave Event Reader / Applicator independently streams binary log events from the primary server. Since multiple nodes are streaming data in parallel, Xpand uses network resources more efficiently, and the cluster's total network throughput increases.
Each Slave Event Reader / Applicator independently applies binary log events. Since multiple nodes are applying replicated changes in parallel, Xpand uses system resources more efficiently, and the system's total IOPS increases.
Since each Slave Event Reader / Applicator operates independently in parallel, the full power of the cluster is used without any choke points. When compared to serial replication, Xpand's parallel replication is more effective at keeping up with high write rates while reducing latency and slave lag.
Transactional Consistency and Ordering
When parallel replication is used, MariaDB Xpand ensures transactional consistency and commits transactions in the same order as the replication primary.
Xpand is able to achieve very high throughput while preserving consistency due to Xpand's use of MVCC. The Slave Event Readers / Applicators are continuously applying changes to the database, but the changes are initially buffered without being fully committed. While the changes are in an uncommitted state, Xpand's MVCC isolates the changes from concurrent transactions, so that concurrent transactions don't see the uncommitted changes.
Xpand regularly commits the transactions applied by the Slave Event Readers / Applicators in a batch. The batch commits are handled on a regular interval by a single Slave Coordinator. By default, the interval is 3 seconds, but a different interval can be configured using CREATE SLAVE .. BATCH_SIZE_MS = n
, where n
is the number of milliseconds to wait between batch commits.
Special Cases
Slave Xpand Cluster
MariaDB Xpand's parallel replication can only be used with a slave Xpand cluster.
Row-Based Replication
MariaDB Xpand requires row-based replication (RBR) for parallel replication, so the binary log should not be created in the statement-based replication (SBR) format.
On the primary Xpand cluster, the binary log can be created in the row-based replication (RBR) format using CREATE BINLOG .. FORMAT='ROW'
.
Primary Keys
Since MariaDB Xpand's parallel replication requires row-based replication (RBR), all replicated tables should have a Primary Key.
For row-based replication, Xpand uses the table's Primary Key to find the specific row referenced in each binlog event. If any tables do not have a Primary Key, Xpand must scan the table for the row, which can have a negative impact on performance.
Foreign Keys
MariaDB Xpand does not support foreign keys with parallel replication.
Primary Keys and Unique Indexes
In many cases when a table has both a Primary Key and a Unique index, Xpand can force the table to use serial replication instead of parallel replication.
When using Xpand's parallel replication, MariaDB does not recommend creating tables that have both a Primary Key and a Unique index.