Replication for MariaDB Xpand

This page is part of MariaDB's Documentation.

The parent of this page is: Other Features for MariaDB Xpand

Overview

MariaDB Xpand provides serial and parallel replication for applications that require disaster recovery or require data to be distributed between different geo-locations:

Inbound replication can be used to replicate to Xpand from another Xpand cluster, MariaDB Server, or MySQL 5.7
Outbound replication can be used to replicate from Xpand to another Xpand cluster, MariaDB Server, or MySQL 5.7
Disaster recovery can be implemented by replicating to an Xpand cluster in a separate region or data center
Data can be globally distributed by replicating to Xpand clusters in different geo-locations
OLTP and OLAP workloads can be split by replicating between dedicated Xpand clusters for each workload
Active-active and active-passive configurations are supported
Parallel replication can be used to minimize latency and provide extremely scalable replication between Xpand clusters:
- 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

This page explains the architecture related to replication with MariaDB Xpand.

For information on how to configure replication for MariaDB Xpand, see "Configure Replication with MariaDB Xpand".

Compatibility

MariaDB Xpand 5.3
MariaDB Xpand 6.0
MariaDB Xpand 6.1

Inbound Replication

MariaDB Xpand supports inbound replication from multiple types of primary servers:

MariaDB Server 10.3 and later
MariaDB Xpand
MySQL 5.7

Outbound Replication

MariaDB Xpand supports outbound replication to multiple types of replica (slave) servers:

MariaDB Server
MariaDB Xpand
MySQL 5.7

Parallel 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 the specified number of slices is considered to be the number of Slave Event Readers / Applicators to create.

Xpand creates the specified number of Slave Event Readers / Applicators and distributes them between all of the nodes to spread out the replication load. The Slave Event Readers / Applicators on each node independently stream binary log events from the primary server and apply the events on the same node.

For additional information, see "MariaDB Xpand Parallel Replication Architecture".

Disaster Recovery

MariaDB Xpand can use replication for disaster recovery.

The active Xpand cluster can replicate to a passive slave Xpand cluster. When the active cluster fails, the slave cluster becomes active. Some MariaDB connectors support connection failover, which can be used by the application to automatically reconnect to the slave cluster when the primary cluster fails.

Geo-Distributed Database

MariaDB Xpand can be used with serial or parallel replication to build a geo-distributed database.

Dedicated Clusters for OLTP and OLAP

MariaDB Xpand 6 supports Columnar indexes, which can improve the performance of analytic or OLAP queries.

When analytic queries are executed on large data sets, the highly parallelized analytic queries can run for a longer duration and potentially consume most of the cluster's compute power. To minimize the impact to OLTP operations, the analytic workload can be isolated from the OLTP workload. The conventional way to isolate the operations would require expensive ETL, data pipelining into a warehouse or data mart and live with analysis on stale data.

Instead, with Xpand's real time continuous replication to another cluster you can deliver near real time analytics without the added complexity of ETL.

Active-Passive

MariaDB Xpand supports serial and parallel replication in an active-passive configuration, which means that changes replicate in one direction (from the master cluster to the slave cluster), and the slave cluster does not accept queries.

Active-Active

MariaDB Xpand supports serial and parallel replication in an active-active configuration, which means that changes replicate in both directions, and both Xpand clusters can accept queries.

Conflicts in Active-Active Configuration

When parallel replication is used with MariaDB Xpand in an active-active configuration, it is possible for conflicts to occur.

Conflicts can occur when both active clusters change the same row. When a conflict occurs, the behavior depends on the value of the slave_exec_mode system variable:

With slave_exec_mode=STRICT, which is the default value, replication fails with an error when the conflict causes the slave cluster to have a different value for a column in the primary key or unique key for the row.
With slave_exec_mode=EXACT, replication fails with an error when the conflict causes the slave cluster to have a different value for any column for the row.

Migrations

MariaDB Xpand's serial replication can be used to migrate to MariaDB Xpand from supported versions of MySQL or MariaDB Server.

Binary Logs

Similar to MariaDB Server and MySQL, MariaDB Xpand uses binary logs for replication. Xpand also uses the same protocol as MariaDB Server and MySQL to stream binary log events from the primary server to the slave. As a result, Xpand can replicate to or from supported versions of MariaDB Server and MySQL, and Xpand also supports many of the same replication-related tools and services as MariaDB Server and MySQL, including AWS DMS.

Binary Log Storage

MariaDB Xpand stores binary log events as data within the database, which is a different approach than the one taken by MariaDB Server and MySQL, which both store binary logs as ordinary files outside of the database.

Xpand's approach to storing binary logs provides some advantages:

Binary log events can be indexed, just like normal table data
Binary log events are fault-tolerant with the same guarantees as other Xpand tables
Writes to the binary log are transactional, consistent, and durable with a full ACID guarantee
Multiple independent binary logs with can be created and maintained with different scopes
Binary logs can be created and dropped online

Binary Log Scope

MariaDB Xpand supports multiple binary logs, and each binary log can have a different scope:

CREATE BINLOG .. LOG(..) is used to include databases or tables, similar to MariaDB Server's --binlog-do-db option
CREATE BINLOG .. IGNORE(..) is used to exclude databases or tables, similar to MariaDB Server's --binlog-ignore-db option

For additional information, see "Configure Binlog Scope with MariaDB Xpand.

Point-in-Time Restoration (PITR)

MariaDB Xpand uses binary logs for point-in-time restoration (PITR). However, since Xpand stores the binary logs in the database, PITR is only supported if the Xpand cluster is configured to continuously dump the raw binary logs to disk.

Xpand provides the repclient tool to continuously dump raw binary logs to disk.

For additional information, see "MariaDB Xpand Point-in-Time Restoration (PITR).

Special Cases

Row-Based Replication (RBR) and Primary Keys

When row-based replication (RBR) is used with MariaDB Xpand, 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.

MariaDB Server Global Transaction IDs (GTIDs)

MariaDB Xpand does not support replication using MariaDB Server's global transaction IDs (GTIDs), but Xpand can replicate from MariaDB Server 10.2 and later using the binary log file and position.

To enable replication between a primary Xpand cluster and a replica MariaDB Server node:

The normal syntax for creating a binlog can be used to configure Xpand to be a replication master of a replica MariaDB Server node.
For additional information, see "Configure MariaDB Xpand as a Replication Master".

To enable replication between a primary MariaDB Server node and a slave Xpand cluster:

No special configuration is needed.
The normal syntax for creating a replication slave can be used to configure Xpand to be a replication slave of a primary MariaDB Server node.
For additional information, see "Configure MariaDB Xpand as a Replication Slave".

MySQL Global Transaction IDs (GTIDs)

MariaDB Xpand does not support replication using MySQL's global transaction IDs (GTIDs), but Xpand can replicate from MySQL using the binary log file and position.

MySQL produces GTIDs beginning with MySQL 5.6 (optional) and MySQL 5.7 (required).

To enable replication between a primary Xpand cluster and a MySQL 5.7 slave:

The MySQL slave must have the gtid_mode system variable set to OFF, OFF_PERMISSIVE, or ON_PERMISSIVE.
The MySQL slave must have the enforce_gtid_consistency system variable set to OFF.
The normal syntax for creating a binlog can be used to configure Xpand to be a replication master of a MySQL 5.7 slave.
For additional information, see "Configure MariaDB Xpand as a Replication Master".

To enable replication between a MySQL 5.7 master and a slave Xpand cluster:

No special configuration is needed.
Xpand ignores the values of the gtid and server_uuid system variables that it encounters in the binlog.
Similar to a MySQL 5.6 slave with gtid_mode set to OFF, Xpand does not pass replicated GTID events to its binlogs.
The normal syntax for creating a replication slave can be used to configure Xpand to be a replication slave of a MySQL 5.7 master.
For additional information, see "Configure MariaDB Xpand as a Replication Slave".

Ring Topologies

MariaDB Xpand does not support ring replication topologies.

Time Zones

To ensure correct matching of Master and Slave data when replicating between Xpand and a MySQL instance, set both DBMSes to the same time zone. If time zones differ, you risk mismatched data.

Online Schema Changes

For details on how replication interacts with online schema changes, see "Replication Concerns".