从 AWS Aurora MySQL 迁移到 MariaDB
Aurora 是 AWS 魔改版，迁出有几个特殊坑——这里讲清
Aurora MySQL ≠ MySQL。Aurora 是 AWS 重写存储层后的产物，与上游 MySQL 在性能、行为、运维工具上都有差异。迁到 MariaDB 时除了 MySQL 8 → MariaDB 的通用步骤外，还要处理以下 Aurora 特有点。
Aurora 特有的"魔改"
| 特性 | Aurora | MariaDB 11 |
|---|---|---|
| 存储 | 6 副本分布式 | 单实例本地 + 复制 |
| 故障转移 | 30s 内自动 | 取决于你的复制方案 |
| Backtrack | 可回退到任意时间点（不用恢复） | 没有，只有 PITR + 备份 |
| Parallel Query | 复杂查询自动并行 | 无（11.x 优化器有部分场景） |
| Global Database | 跨区域副本 | 自管 Galera 或 binlog 复制 |
| Aurora Serverless | 自动扩容 | 没有（按实例规格固定） |
aws_* 函数 | 内置 S3 上传等 | 没有 |
| Performance Insights | 内置 | 用 PMM / 自建 |
出 Aurora 必做的几件事
1. 关掉 backtrack 依赖
Aurora 的 backtrack 是"魔法"。MariaDB 没有等价物。应用层不能依赖"我搞错了能 backtrack 半小时"——必须真做备份。
2. 改写 aws_s3 等专有函数
-- Aurora
SELECT aws_s3.query_export_to_s3(
'SELECT * FROM users',
aws_commons.create_s3_uri('mybucket', 'users.csv', 'us-east-1'),
options := 'format csv'
);
-- MariaDB：自己写脚本
mariadb -e "SELECT * FROM users" --batch | aws s3 cp - s3://mybucket/users.csv或在应用层用 mariadb-dump + aws s3 cp。
3. Parallel Query 重写
Aurora Parallel Query 让某些大查询飞起。MariaDB 没有自动并行，但可以：
- 用 MariaDB ColumnStore（如果是 OLAP）
- 用 MaxScale + 多个读副本 自己分片
- 改写为 partition 查询并行跑
4. Global Database 改成 Galera
Aurora Global Database 跨区域 < 1s 复制。MariaDB 等价方案：
- Galera Cluster 多 region 部署（写延迟敏感）
- MariaDB MaxScale 做读写分离 + 多 region 路由
- binlog 异步复制到远端（最简单，秒级到分钟级延迟）
5. Serverless V2 → 实例规格
Aurora Serverless 按 ACU 计费、自动伸缩。MariaDB 没有"原生 serverless"，可选方案：
- k8s VPA + MariaDB Operator（半自动）
- EC2 spot + 周期重新部署（不推荐生产）
- 接受固定实例规格
6. Performance Insights 替代
# 用 PMM
docker run -d --name pmm-server -p 80:80 percona/pmm-server:2
# 在 MariaDB 实例上
docker run -d --rm --name pmm-client --network host \
-e PMM_SERVER=http://pmm-host \
percona/pmm-client:2
pmm-admin add mysql --query-source=perfschema \
--username=monitor --password=xxx --host=127.0.0.1 --port=3306 mariadb-main详见 运维 → 监控。
数据出 Aurora 的方式
方案 A：DMS（AWS 内推工具）
Aurora MySQL --(DMS)--> MariaDB on EC2 / 自建DMS 支持 MySQL 5.7 / 8 作为 source，MySQL 兼容 的 target 都可选。
- 优点：托管、CDC 自动
- 缺点：贵、限制多、不支持某些 Aurora 特有变更
方案 B：mysqldump + 手动 CDC
# Aurora 创建只读副本，开放 binlog
mysqldump -h aurora-read-replica.region.rds.amazonaws.com \
--single-transaction --routines --triggers \
--master-data=2 --all-databases > dump.sql
# 替换 collation
sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' dump.sql
# 导入 MariaDB
mariadb -h mariadb-host < dump.sql
# 从 dump 里读出 binlog position，用 mysqlbinlog tailing方案 C：Debezium
# Debezium 连 Aurora（开 binlog）
database.hostname: aurora-cluster.cluster-xxx.region.rds.amazonaws.com
database.port: 3306
database.user: debezium
database.password: xxx
database.server.id: 184054
database.include.list: app下游 sink 到 MariaDB。
Aurora 配置项映射
| Aurora 参数组 | MariaDB my.cnf 等价 |
|---|---|
innodb_buffer_pool_size（自动按实例） | 手动设到 RAM 60–70% |
max_connections | 一致 |
aurora_lab_mode | 无 |
binlog_format = MIXED | binlog_format = ROW（推荐） |
aurora_use_key_prefetch | 无 |
性能预期管理
Aurora 在某些场景比 MariaDB 快：
- 大量小事务（存储层并行写）
- 大查询 + Parallel Query
- 多副本读
MariaDB 在某些场景反而更优：
- 单点写吞吐（无网络存储开销）
- 复杂优化器场景（Hash Join）
- 完全开源 + 可定制
建议在迁移前用 sysbench 跑两边对比，确认负载模式。
切流策略
类似 MySQL 8 迁移，加几个 Aurora 特有：
- 关闭 Aurora 自动 minor version upgrade（避免切流期间 source 升级）
- 创建专用只读副本给迁移用（不影响生产）
- 充分利用 Aurora backtrack 做"切错回滚"——这是你最后一次能用它
别迁的场景
- 用了 Aurora Serverless V2 + 强自动扩缩 且业务峰谷剧烈
- 用了 Aurora Global Database + 5 region 同步
- 用了 Aurora Machine Learning 集成 SageMaker
- 用了 Babelfish（Aurora 的 SQL Server 兼容层）
这些场景 MariaDB 没有等价能力，迁过去要重做架构。