Aurora MySQL Binlog 副本级联复制

iX.

19 12月, 2025

概述

在企业级数据库架构中，经常需要将 Aurora MySQL 的数据变更实时同步到外部系统，例如通过 binlog 订阅实现数据变更捕获（CDC）驱动下游数据处理管道。

当数据库存在过多的 binlog 下游应用（通过 MySQL replication protocol 直接从主库读取 binlog）时，每个下游应用定期执行SHOW BINARY LOGS命令，造成短暂的 binlog 锁定，当业务 DML 操作需要写入 binlog，就会被频繁的 binlog 锁阻塞，导致 DML Latency 异常升高。

解决方案：

Aurora MySQL Binlog Replica 通过创建一个特殊的只读副本，将 Aurora 的内部变更日志转换为标准 MySQL binlog 格式。这使得：

外部 MySQL 实例可以作为从库连接到 Binlog Replica
CDC 工具可以订阅标准 binlog 进行数据变更捕获
保持 Aurora 高性能的同时，实现与传统 MySQL 生态的无缝集成

与其他方案对比：

方案	优势	劣势	适用场景
Binlog Replica 级联	• 隔离主库压力 • 成本低 • 易实施	• 增加延迟（0.5-2秒） • 异步复制	大量 CDC 下游，可接受秒级延迟
Aurora Global Database	• 延迟极低（< 1秒） • 跨区域高可用	• 成本高 • 不支持同区域 • 不生成 binlog	跨区域灾备，需要低延迟
减少下游数量	• 无架构变更 • 无延迟	• 业务受限 • 不可持续	下游数量可控（< 10个）
升级主库规格	• 简单直接	• 成本高 • 治标不治本	临时缓解，非长期方案

本文将详细介绍如何创建和配置 Aurora MySQL Binlog Replica，实现级联复制架构。

技术原理

什么是 Binlog Replica？

Binlog Replica 是 Aurora MySQL 的一种特殊类型的只读副本（Read Replica），它使用 MySQL 原生的 binlog 复制机制，而不是 Aurora 的存储层复制。

技术架构：

核心特性：

使用 MySQL binlog 异步复制
- 基于 MySQL 原生的 binlog 复制协议
- 异步复制：即使在同一个 AZ 也是异步的，必然存在复制延迟
- 不支持半同步或同步复制
Binlog Replica 集群的 Primary Instance
- 虽然称为"只读副本集群"，但集群内有 Primary Instance（IsClusterWriter: true）
- 功能：接收主库 binlog → 应用事务 → 生成自己的 binlog
- 不接受业务写入：只接受通过复制传来的数据
- 生成 binlog：继承主库的 binlog 配置（binlog_format 等参数）
- 下游连接点：所有下游应用连接到这个 Primary Instance 读取 binlog
支持级联复制
- 既是复制的目标（从主库接收 binlog）
- 也是复制的源（下游从它读取 binlog）
- 可以构建多级复制架构
独立的集群
- Binlog Replica 是一个独立的 Aurora 集群
- 有自己的集群端点和实例端点
- 可以独立扩展和管理
- 可以在集群内添加 Aurora Replica 用于读查询分流（可选）

实施步骤

前置条件检查

确认主库 binlog 已启用

# 检查集群参数组
aws rds describe-db-clusters \
  --db-cluster-identifier aws-tk-contract \
  --region ap-northeast-1 \
  --query 'DBClusters[0].DBClusterParameterGroup'

# 检查参数组中的 binlog_format
aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name <parameter-group-name> \
  --region ap-northeast-1 \
  --query "Parameters[?ParameterName=='binlog_format']"

如果未启用 binlog，需要创建自定义参数组启用 binlog_format 参数，应用参数组到集群并重启实例使参数生效。

注意：重启会造成短暂的服务中断（通常 1-3 分钟），建议在维护窗口执行。

获取主库信息

# 获取主库集群 ARN
aws rds describe-db-clusters \
  --db-cluster-identifier aws-tk-contract \
  --region ap-northeast-1 \
  --query 'DBClusters[0].DBClusterArn'

确认下游应用清单
- 列出所有 70 个读取 binlog 的下游应用
- 确认它们的连接配置可以修改

步骤 1：创建 Binlog Replica 集群

注意：必须使用 CLI 创建同区域 Binlog Replica，Console 只能创建跨区域副本。

# 1. 创建 Binlog Replica 集群
aws rds create-db-cluster \
  --db-cluster-identifier aws-tk-contract-binlog-replica \
  --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.10.2 \
  --region ap-northeast-1 \
  --replication-source-identifier arn:aws:rds:ap-northeast-1:990224085921:cluster:aws-tk-contract

# 2. 等待集群创建完成（约 5-10 分钟）
aws rds wait db-cluster-available \
  --db-cluster-identifier aws-tk-contract-binlog-replica \
  --region ap-northeast-1

# 3. 创建 Binlog Replica 实例
aws rds create-db-instance \
  --db-cluster-identifier aws-tk-contract-binlog-replica \
  --db-instance-identifier aws-tk-contract-binlog-replica-instance-1 \
  --db-instance-class db.r6g.4xlarge \
  --engine aurora-mysql \
  --region ap-northeast-1

# 4. 等待实例创建完成（约 10-15 分钟）
aws rds wait db-instance-available \
  --db-instance-identifier aws-tk-contract-binlog-replica-instance-1 \
  --region ap-northeast-1

参数说明：

--replication-source-identifier：主库集群的 ARN（格式：arn:aws:rds:region:account-id:cluster:cluster-name）
--db-instance-class：建议与主库相同或更高配置，以承载 70 个下游连接
--engine-version：必须与主库版本一致

步骤 2：验证 Binlog Replica 状态

# 1. 检查集群状态和复制关系
aws rds describe-db-clusters \
  --db-cluster-identifier aws-tk-contract-binlog-replica \
  --region ap-northeast-1 \
  --query 'DBClusters[0].[Status,ReplicationSourceIdentifier,DBClusterMembers[0].DBClusterParameterGroupStatus]'

# 2. 验证源集群识别到 Binlog Replica
aws rds describe-db-clusters \
  --db-cluster-identifier aws-tk-contract \
  --region ap-northeast-1 \
  --query 'DBClusters[0].ReadReplicaIdentifiers'

# 3. 获取 Binlog Replica 连接端点
aws rds describe-db-clusters \
  --db-cluster-identifier aws-tk-contract-binlog-replica \
  --region ap-northeast-1 \
  --query 'DBClusters[0].[Endpoint,ReaderEndpoint]'

# 4. 检查实例状态
aws rds describe-db-instances \
  --db-instance-identifier aws-tk-contract-binlog-replica-instance-1 \
  --region ap-northeast-1 \
  --query 'DBInstances[0].[DBInstanceStatus,DBInstanceClass,AvailabilityZone]'

验证标准：

集群状态：available
ReplicationSourceIdentifier：指向主库集群 ARN
源集群的 ReadReplicaIdentifiers：包含 Binlog Replica 集群 ARN
实例状态：available
DBClusterParameterGroupStatus：in-sync

预计耗时：

集群创建：约 8-10 分钟
实例创建：约 8-10 分钟
总计：约 18-20 分钟

步骤 3：配置 Binlog Replica

-- 连接到 Binlog Replica 执行

-- 1. 设置 binlog 保留时间（根据下游需求调整，建议 72 小时）
CALL mysql.rds_set_configuration('binlog retention hours', 72);

-- 2. 验证配置
CALL mysql.rds_show_configuration();

-- 3. 检查 binlog 状态
SHOW BINARY LOGS;
SHOW MASTER STATUS;

步骤 4：迁移下游应用（分批进行）

迁移策略：采用分批迁移降低风险

第一批：试点迁移

选择 5-10 个非关键下游应用

修改连接配置：

# 原配置
host: aws-tk-contract-instance-1.xxxxx.ap-northeast-1.rds.amazonaws.com
port: 3306

# 新配置
host: aws-tk-contract-binlog-replica.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com
port: 3306

重启下游应用
观察 24 小时，监控以下指标：
- 主库 DMLLatency 是否下降
- Binlog Replica 复制延迟
- 下游应用数据同步正常

第二批：扩大迁移

确认第一批无问题后，迁移 20-30 个下游
观察 24 小时

第三批：完成迁移（剩余下游）

迁移所有剩余下游应用
持续监控 48 小时

步骤 5：监控和验证

主库监控（期望改善）

CloudWatch 指标：

# DMLLatency（期望降至 2ms 以下）
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name DMLLatency \
  --dimensions Name=DBInstanceIdentifier,Value=aws-tk-contract-instance-1 \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 300 \
  --statistics Average \
  --region ap-northeast-1

# DBLoad（期望降至 8 以下）
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name DBLoad \
  --dimensions Name=DBInstanceIdentifier,Value=aws-tk-contract-instance-1 \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 300 \
  --statistics Average \
  --region ap-northeast-1

Performance Insights：

等待事件 synch/cond/sql/MYSQL_BIN_LOG::COND_done 应显著减少

Binlog Replica 监控（确保健康）

监控复制延迟

# 复制延迟
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name AuroraReplicaLag \
  --dimensions Name=DBClusterIdentifier,Value=aws-tk-contract-binlog-replica \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 300 \
  --statistics Average,Maximum \
  --region ap-northeast-1

# CPU 使用率
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name CPUUtilization \
  --dimensions Name=DBInstanceIdentifier,Value=aws-tk-contract-binlog-replica-instance-1 \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 300 \
  --statistics Average \
  --region ap-northeast-1

# 网络吞吐量
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name NetworkThroughput \
  --dimensions Name=DBInstanceIdentifier,Value=aws-tk-contract-binlog-replica-instance-1 \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 300 \
  --statistics Average \
  --region ap-northeast-1

健康标准：

AuroraReplicaLag < 5 秒
CPUUtilization < 70%
无异常错误日志

成本估算

额外成本

Binlog Replica 实例成本：
- db.r6g.4xlarge：约 $1.088/小时（按需定价）
- 每月约：$1.088 × 24 × 30 = $784
存储成本：
- Aurora 存储：$0.10/GB-月
- Binlog 存储（72 小时保留）：根据实际大小
数据传输成本：
- 同区域复制：无额外费用

成本优化

使用预留实例可节省约 30-40%
根据实际负载调整实例规格
Graviton 实例如 db.r6g.large 性价比更高，相比 x86 实例节省约 20% 成本

注意事项

Binlog 必须预先启用

错误信息：Source cluster doesn't have binlogs enabled
必须在创建 Binlog Replica 之前启用源集群的 binlog
需要重启实例使参数生效（1-3 分钟中断）

参数组自动继承

Binlog Replica 自动继承源集群的参数组配置
包括 binlog_format 等 binlog 相关参数
无需单独配置 Binlog Replica 的参数组

同区域复制

同区域复制延迟更低，成本更低
必须使用 CLI 创建
Console 只支持跨区域 Binlog Replica

复制关系双向可见

源集群的 ReadReplicaIdentifiers 包含 Binlog Replica ARN
Binlog Replica 的 ReplicationSourceIdentifier 指向源集群 ARN
可通过这两个字段验证复制关系

复制延迟特性

使用 MySQL binlog 异步复制，必然存在延迟
同区域延迟通常 0.5-2 秒
需要监控 AuroraReplicaLag 指标

ARN 格式

集群 ARN 格式：arn:aws:rds:region:account-id:cluster:cluster-name
不是 db:instance-name（实例 ARN 格式）

对下游应用的影响：

下游应用获取的数据会比主库晚 0.5-2 秒（同区域）
这是累加的延迟：原本从主库读取的延迟 + Binlog Replica 的复制延迟
大多数 CDC 场景（数据仓库、分析、审计）可以接受
实时性要求高的场景（实时风控、实时推荐）需要评估

实施检查清单

前置准备

确认主库 binlog 已启用
如需启用 binlog，确认维护窗口时间
获取主库集群 ARN
准备下游应用清单（70 个）
确认下游应用支持配置变更

Binlog Replica 创建

（如需要）启用 binlog_format 参数
创建 Binlog Replica 集群
等待集群可用（8-10 分钟）
创建 Binlog Replica 实例
等待实例可用（8-10 分钟）

验证

验证 Binlog Replica 集群状态为 available
验证 Binlog Replica 实例状态为 available
验证复制关系（源集群 ReadReplicaIdentifiers）
验证参数组状态为 in-sync
获取 Binlog Replica 连接端点
配置 Binlog Replica binlog 保留时间

常见问题

Q1: Binlog Replica 和普通 Aurora Replica 有什么区别？

A：主要区别：

复制机制：普通 Aurora Replica 使用存储层复制（共享存储），Binlog Replica 使用 MySQL binlog 复制
延迟：普通 Aurora Replica 几乎无延迟（毫秒级），Binlog Replica 有秒级延迟
集群结构：普通 Aurora Replica 是同一集群内的只读实例，Binlog Replica 是独立的集群，有自己的 Primary Instance
生成 binlog：普通 Aurora Replica 不生成 binlog，Binlog Replica 集群的 Primary Instance 生成 binlog
用途：普通 Aurora Replica 用于读查询分流，Binlog Replica 用于级联复制和 CDC 下游分流

Binlog Replica vs 普通 Aurora Replica

特性	普通 Aurora Replica	Binlog Replica 集群
复制机制	Aurora 存储层复制（共享存储）	MySQL binlog 异步复制
复制延迟	几乎为 0（毫秒级）	存在延迟（秒级）
数据一致性	强一致性	最终一致性
集群结构	同一集群内的只读实例	独立的集群，有自己的 Primary Instance
Primary Instance	❌ 无（共享 Writer）	✅ 有（`IsClusterWriter: true`）
接受业务写入	❌ 不接受	❌ 不接受（只接受复制的数据）
生成 binlog	❌ 不生成	✅ Primary Instance 生成
下游可读取 binlog	❌ 不可以	✅ 可以从 Primary Instance 读取
用途	读查询分流、高可用	级联复制、CDC 下游分流
创建方式	Console/CLI	CLI（同区域必须用 CLI）
最大数量	15 个/集群	5 个/源集群

Q2: 为什么必须用 CLI 创建同区域 Binlog Replica？

A: AWS Console 目前只支持创建跨区域的 Binlog Replica。同区域的 Binlog Replica 必须通过 CLI 或 API 创建。

Q3: Binlog Replica 会影响主库性能吗？

A: 会有轻微影响，但远小于几十个下游直接连接的影响。Binlog Replica 只是 1 个连接，符合最佳实践。

Q4: 复制延迟多少是正常的？

A:Binlog Replica 使用 MySQL binlog 异步复制，必然存在延迟

同区域同 AZ：通常 0.5-2 秒
同区域跨 AZ：通常 1-3 秒
跨区域：通常 3-10 秒（取决于网络距离）
需要监控 AuroraReplicaLag CloudWatch 指标

Q5: 复制延迟会影响下游应用吗？

A: 会有影响，需要评估：

下游应用获取的数据会比主库晚 0.5-2 秒（同区域）
大多数 CDC 场景可接受：数据仓库、分析系统、审计日志
实时性要求高的场景需要评估：实时风控、实时推荐
权衡：主库性能恢复（业务可用性）vs 下游延迟

Q6: 可以创建多个 Binlog Replica 吗？

A: 可以。Aurora MySQL 支持最多 5 个跨区域 Read Replica（包括 Binlog Replica）。同区域没有明确限制。

Q7: 创建 Binlog Replica 时报错 "doesn't have binlogs enabled" 怎么办？

A: 这是最常见的错误。解决步骤：

创建自定义参数组（如果使用默认参数组）
设置 binlog_format=ROW
应用参数组到源集群
重启实例使参数生效
等待实例可用后再创建 Binlog Replica

详细步骤见"前置条件检查"部分。

Q8: Binlog Replica 的参数组需要单独配置吗？

A: 不需要。Binlog Replica 会自动继承源集群的参数组配置，包括 binlog 相关参数。

Q9: 创建需要多长时间？

集群创建：8-10 分钟
实例创建：8-10 分钟
总计：约 18-20 分钟
如果需要先启用 binlog：额外 5-10 分钟（含重启）

Q10: Binlog Replica 支持同步复制吗？

A: 不支持。Binlog Replica 只支持 MySQL binlog 异步复制，即使在同一个 AZ 也是异步的。不支持半同步（semi-synchronous）或同步复制。

Q11: 下游应用连接到哪里读取 binlog？

A:下游应用连接到 Binlog Replica 集群的 Primary Instance 读取 binlog。

连接端点：

# 使用集群端点（推荐）
aurora-sg-test-binlog-replica.cluster-xxxxx.ap-northeast-1.rds.amazonaws.com

# 或使用实例端点
aurora-sg-test-binlog-replica-instance-1.xxxxx.ap-northeast-1.rds.amazonaws.com

注意：

不能从 Binlog Replica 集群内的普通 Aurora Replica 读取 binlog（如果有的话）
普通 Aurora Replica 不生成 binlog，只能用于读查询分流

Q12: 如果复制延迟过大怎么办？

A:应对措施：

检查 Binlog Replica 资源
- CPU 使用率是否过高（> 80%）
- 网络吞吐量是否达到上限
- 考虑升级实例规格（如从 db.r7g.large 升级到 db.r7g.xlarge）
检查网络连接
- 源集群和 Binlog Replica 之间的网络延迟
- 是否存在网络拥塞
优化复制性能
- 启用多线程复制（Aurora MySQL 3.x 自动启用）
- 检查 replica_parallel_workers 参数
考虑多个 Binlog Replica
- 将多个下游分散到多个 Binlog Replica
- 让延迟敏感的应用直连主库（保持在 5-10 个以下）

参考文档

Aurora MySQL 跨区域复制
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.Creating.html
Aurora MySQL Binlog 复制
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html
设置 Binlog 复制
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html
Binlog 配置存储过程
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/mysql-stored-proc-configuring.html
Aurora MySQL 复制选项
https://docs.aws.amazon.com/prescriptive-guidance/latest/aurora-replication-options/cross-region-aurora-replicas.html
优化 Binlog 复制性能
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/binlog-optimization.html
AWS CLI create-db-cluster 命令参考
https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html
AWS CLI create-db-instance 命令参考
https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html

概述