MariaDB 10.6 to MySQL Aurora 8.0 Migration Guide — 5-Part Series
- Part 1: Pre-Migration Requirements (You Are Here)
- Part 2: AWS DMS Infrastructure Setup
- Part 3: Schema and User Migration
- Part 4: DMS Endpoints, Task Configuration, and Assessments
- Part 5: Execution, Validation, Cutover, and Cleanup
Migrating from a self-managed or RDS-hosted MariaDB 10.6 instance to Amazon Aurora MySQL 8.0 is a cross-engine migration, not a simple version upgrade. MariaDB and MySQL diverged significantly after MySQL 5.5, accumulating differences in storage engines, replication protocol, SQL syntax, data types, and system tables. AWS Database Migration Service (DMS) bridges the data movement, but getting the source and target correctly configured before the first byte moves is what makes or breaks the migration.
This guide is based on a production migration from an RDS-hosted MariaDB 10.6 instance to Amazon Aurora MySQL 8.0 using AWS DMS with CDC (Change Data Capture) for a near-zero downtime cutover.
Scope: This series covers RDS-hosted MariaDB as the source. Self-managed MariaDB on EC2 follows the same steps, but binary logging configuration differs — you set log_bin in the parameter group rather than enabling automated backups.
Why Migrate from MariaDB to Amazon Aurora MySQL?
The two most common drivers for this migration are:
- Aurora's performance and reliability tier — Aurora MySQL uses a distributed, fault-tolerant storage layer with automatic replication across 3 AZs and 6 storage copies. It eliminates most of the operational overhead of managing replication manually.
- Ecosystem alignment — Aurora MySQL is wire-compatible with MySQL 8.0, meaning it integrates cleanly with MySQL-native tooling (Percona Toolkit, ProxySQL, MySQL Shell, MySQL Workbench) and avoids MariaDB-specific extensions that can cause portability friction.
The primary trade-off is that MariaDB-specific syntax and functions must be identified and remediated before the migration. Part 3 of this series covers schema compatibility in detail.
Migration Approach Overview
AWS DMS is the recommended approach for this type of cross-engine migration because it handles protocol translation between MariaDB's binlog format and Aurora MySQL's replication stream. The overall process runs in two phases:
| Phase | What Happens | Covered In |
|---|---|---|
| Schema Migration | Export schema from MariaDB, clean incompatible syntax, import to Aurora | Part 3 |
| Full Load | DMS copies all existing rows from source to target | Part 5 |
| CDC (Change Data Capture) | DMS continuously applies changes from MariaDB binlog to Aurora while applications still write to the source | Part 5 |
| Cutover | Stop writes to source, wait for CDC lag to reach zero, redirect application | Part 5 |
Pre-Migration Requirements: MariaDB (Source)
DMS reads changes from MariaDB using binary log replication. These settings must be in place before creating DMS endpoints or starting any task.
Timeout Settings
Set net_read_timeout, net_write_timeout, and wait_timeout to at least 300 seconds. Without this, long-running DMS operations — particularly during full load of large tables — will hit disconnect errors mid-transfer.
SHOW VARIABLES LIKE 'net_read_timeout';
SHOW VARIABLES LIKE 'net_write_timeout';
SHOW VARIABLES LIKE 'wait_timeout';
If the values are below 300, update them in the RDS parameter group for your MariaDB instance. For RDS, changes to dynamic parameters apply immediately; static parameters require a reboot.
Binary Log Format
DMS requires binlog_format=ROW. Statement-based logging does not provide the row-level change detail that DMS needs for reliable CDC replication.
SHOW VARIABLES LIKE 'binlog_format';
The expected output is ROW. If it shows MIXED or STATEMENT, update the parameter group. For RDS MariaDB, this is a static parameter requiring an instance reboot.
Binary Log Row Image
Set binlog_row_image to FULL. This ensures the binlog captures the complete before and after image of every changed row. The MINIMAL setting, which only logs changed columns, is not supported by DMS.
SHOW VARIABLES LIKE 'binlog_row_image';
Binary Logging Enabled
On RDS MariaDB, binary logging is enabled by turning on automated backups at the instance level. Verify binary logging is active:
SHOW VARIABLES LIKE 'log_bin';
The output must show ON. If automated backups are disabled on the instance, enable them through the RDS console (a brief outage may occur).
Binary Log Retention
DMS reads from the binary log continuously. If the log is purged before DMS can read it, the task fails and must restart from a full load. Increase the retention window to at least 26 hours to provide a buffer during maintenance windows or replication lag events:
CALL mysql.rds_set_configuration('binlog retention hours', 26);
Storage impact: Increasing binlog retention increases storage consumption on the RDS instance proportionally to the write throughput of your workload. Monitor the FreeStorageSpace CloudWatch metric after making this change and ensure you have sufficient headroom.
Pre-Migration Requirements: Aurora MySQL (Target)
The Aurora MySQL target also requires specific configuration. These settings are applied through the Aurora cluster's parameter group.
Binary Log Format (Aurora)
If you plan to use CDC replication (keeping Aurora in sync with MariaDB during the migration), set binlog_format=ROW on the Aurora cluster parameter group as well. This is required if you intend to use Aurora as a replication source for any downstream systems post-migration.
SHOW VARIABLES LIKE 'binlog_format';
Timezone Alignment
Ensure the Aurora instance is configured in the same timezone as the MariaDB source. Timezone mismatches cause silent data corruption on DATETIME and TIMESTAMP columns — DMS does not convert timestamps between timezones.
SHOW VARIABLES LIKE 'time_zone';
Compare the output on both the MariaDB source and Aurora target. They must match.
Local Infile
AWS DMS uses LOAD DATA LOCAL INFILE for bulk data loading during the full load phase. This requires local_infile=1 on the target.
SHOW VARIABLES LIKE 'local_infile';
Set this in the Aurora cluster parameter group if it shows OFF.
Pre-Migration Requirements Checklist
| Requirement | Database | Check Command | Required Value |
|---|---|---|---|
net_read_timeout | MariaDB | SHOW VARIABLES LIKE 'net_read_timeout' | ≥ 300 |
net_write_timeout | MariaDB | SHOW VARIABLES LIKE 'net_write_timeout' | ≥ 300 |
wait_timeout | MariaDB | SHOW VARIABLES LIKE 'wait_timeout' | ≥ 300 |
binlog_format | MariaDB | SHOW VARIABLES LIKE 'binlog_format' | ROW |
binlog_row_image | MariaDB | SHOW VARIABLES LIKE 'binlog_row_image' | FULL |
log_bin | MariaDB | SHOW VARIABLES LIKE 'log_bin' | ON |
| Binlog retention hours | MariaDB | CALL mysql.rds_show_configuration() | ≥ 26 |
binlog_format | Aurora MySQL | SHOW VARIABLES LIKE 'binlog_format' | ROW |
time_zone | Both | SHOW VARIABLES LIKE 'time_zone' | Identical on both |
local_infile | Aurora MySQL | SHOW VARIABLES LIKE 'local_infile' | ON |
With all pre-migration requirements verified, proceed to Part 2 to set up the AWS DMS infrastructure.