Aurora MySQL: Конфигурация Parameter Groups для CDC

Если вы прошли Модуль 12, вы знаете, как настроить community MySQL для CDC: отредактировать /etc/my.cnf, добавить binlog_format=ROW, перезапустить MySQL, установить retention через SET PERSIST binlog_expire_logs_seconds=604800. Aurora MySQL работает совершенно иначе.

Aurora — это managed database service от AWS. Вы не имеете прямого доступа к файловой системе и не можете редактировать my.cnf. Вместо этого Aurora использует parameter groups — механизм конфигурации через AWS API/Console.

В этом уроке мы разберём фундаментальные различия между community MySQL и Aurora MySQL конфигурацией, научимся создавать custom parameter groups, настраивать binlog retention через Aurora-specific stored procedures и избегать критических ошибок с reboot requirements.

Managed Service Model: Что это значит для CDC?

Разберём, как Aurora абстрагирует конфигурацию MySQL.

Community MySQL: Direct Access

# Community MySQL — полный контроль
ssh mysql-server

# Редактируем конфигурацию напрямую
sudo vim /etc/my.cnf

# /etc/my.cnf
[mysqld]
server-id=1
log-bin=mysql-bin
binlog_format=ROW
binlog_row_image=FULL
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_expire_logs_seconds=604800  # 7 дней

# Перезапускаем MySQL
sudo systemctl restart mysql

# Проверяем
mysql -e "SHOW VARIABLES LIKE 'binlog_format'"

Прямой контроль над всем процессом.

Aurora MySQL: Parameter Groups Abstraction

┌────────────────────────────────────────────────────────────┐
│                  AWS Management Layer                      │
│  (Console / CLI / CloudFormation / Terraform)              │
└────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌────────────────────────────────────────────────────────────┐
│               DB Cluster Parameter Group                   │
│  (cluster-wide settings: binlog_format, GTID, etc.)        │
└────────────────────────────────────────────────────────────┘
                            │
        ┌───────────────────┼───────────────────┐
        ▼                   ▼                   ▼
┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  Writer      │    │  Reader 1    │    │  Reader 2    │
│  Instance    │    │  Instance    │    │  Instance    │
│              │    │              │    │              │
│  DB Param    │    │  DB Param    │    │  DB Param    │
│  Group       │    │  Group       │    │  Group       │
│  (instance)  │    │  (instance)  │    │  (instance)  │
└──────────────┘    └──────────────┘    └──────────────┘

Вы не имеете:

• SSH доступа к Aurora instances
• Доступа к файловой системе (/etc/my.cnf не существует для вас)
• Возможности напрямую перезапустить mysqld процесс

Вы управляете через:

• AWS Management Console
• AWS CLI (aws rds modify-db-cluster-parameter-group)
• AWS SDKs (boto3, AWS SDK for Java, etc.)
• Infrastructure-as-Code (CloudFormation, Terraform)

Parameter Group Types: Cluster vs Instance

Aurora MySQL имеет два уровня parameter groups. Понимание их различий критично для CDC конфигурации.

DB Cluster Parameter Group

Scope: Cluster-wide (применяется к writer и всем reader instances)

Для чего используется:

• Replication параметры (binlog, GTID)
• Cluster-level features (Aurora Enhanced Binlog, backtrack)
• Character sets и collations

Примеры параметров:

Как создать:

# AWS CLI команда
aws rds create-db-cluster-parameter-group \
  --db-cluster-parameter-group-name debezium-aurora-mysql-80 \
  --db-parameter-group-family aurora-mysql8.0 \
  --description "Aurora MySQL 8.0 cluster parameter group for Debezium CDC"

DB Parameter Group (Instance-level)

Scope: Individual instance (writer или specific reader)

Для чего используется:

• Performance tuning (буферы, кэши)
• Connection limits
• Instance-specific timeouts

Примеры параметров:

Как создать:

aws rds create-db-parameter-group \
  --db-parameter-group-name debezium-aurora-instance-pg \
  --db-parameter-group-family aurora-mysql8.0 \
  --description "Aurora MySQL 8.0 instance parameter group for Debezium"

Критическая таблица: Где настраивать CDC параметры

Правило:

• Всё, что касается binlog, replication, GTID → DB Cluster Parameter Group
• Всё, что касается performance, connections → DB Parameter Group

Creating Custom Parameter Group for CDC

Default parameter groups в Aurora нельзя модифицировать. Вы должны создать custom parameter group.

Step 1: Create DB Cluster Parameter Group

# Создать custom parameter group
aws rds create-db-cluster-parameter-group \
  --db-cluster-parameter-group-name debezium-aurora-cdc \
  --db-parameter-group-family aurora-mysql8.0 \
  --description "Aurora MySQL 8.0 for Debezium CDC - binlog enabled"

# Проверить создание
aws rds describe-db-cluster-parameter-groups \
  --db-cluster-parameter-group-name debezium-aurora-cdc

Вывод:

{
  "DBClusterParameterGroups": [
    {
      "DBClusterParameterGroupName": "debezium-aurora-cdc",
      "DBParameterGroupFamily": "aurora-mysql8.0",
      "Description": "Aurora MySQL 8.0 for Debezium CDC - binlog enabled",
      "DBClusterParameterGroupArn": "arn:aws:rds:us-east-1:123456789012:cluster-pg:debezium-aurora-cdc"
    }
  ]
}

Step 2: Modify Binlog Parameters

Важно: MySQL 8.0.34+ по умолчанию использует binlog_format=ROW. Aurora MySQL 8.0.40 основан на MySQL 8.0.40, поэтому default уже ROW. Но явная установка рекомендуется для ясности и защиты от будущих изменений defaults.

# Установить binlog_format=ROW (явно)
aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name debezium-aurora-cdc \
  --parameters "ParameterName=binlog_format,ParameterValue=ROW,ApplyMethod=pending-reboot"

# Установить binlog_row_image=FULL (рекомендуется для CDC)
aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name debezium-aurora-cdc \
  --parameters "ParameterName=binlog_row_image,ParameterValue=FULL,ApplyMethod=pending-reboot"

# Включить GTID mode (для production failover support)
aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name debezium-aurora-cdc \
  --parameters "ParameterName=gtid_mode,ParameterValue=ON,ApplyMethod=pending-reboot"

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name debezium-aurora-cdc \
  --parameters "ParameterName=enforce_gtid_consistency,ParameterValue=ON,ApplyMethod=pending-reboot"

Можно объединить в один вызов:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name debezium-aurora-cdc \
  --parameters \
    ParameterName=binlog_format,ParameterValue=ROW,ApplyMethod=pending-reboot \
    ParameterName=binlog_row_image,ParameterValue=FULL,ApplyMethod=pending-reboot \
    ParameterName=gtid_mode,ParameterValue=ON,ApplyMethod=pending-reboot \
    ParameterName=enforce_gtid_consistency,ParameterValue=ON,ApplyMethod=pending-reboot

Step 3: Verify Parameter Changes

# Проверить параметры в parameter group
aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name debezium-aurora-cdc \
  --query "Parameters[?ParameterName=='binlog_format' || ParameterName=='gtid_mode']"

Ожидаемый вывод:

[
  {
    "ParameterName": "binlog_format",
    "ParameterValue": "ROW",
    "ApplyType": "static",
    "DataType": "string",
    "IsModifiable": true,
    "ApplyMethod": "pending-reboot"
  },
  {
    "ParameterName": "gtid_mode",
    "ParameterValue": "ON",
    "ApplyType": "static",
    "DataType": "string",
    "IsModifiable": true,
    "ApplyMethod": "pending-reboot"
  }
]

Associating Parameter Group with Aurora Cluster

После создания custom parameter group, его нужно привязать к Aurora cluster.

Modify Cluster to Use Custom Parameter Group

# Привязать parameter group к cluster
aws rds modify-db-cluster \
  --db-cluster-identifier my-aurora-cluster \
  --db-cluster-parameter-group-name debezium-aurora-cdc \
  --apply-immediately

# Проверить статус
aws rds describe-db-clusters \
  --db-cluster-identifier my-aurora-cluster \
  --query "DBClusters[0].DBClusterParameterGroup"

Вывод:

"debezium-aurora-cdc"

Важно: Привязка parameter group НЕ применяет изменения немедленно. Для static параметров (binlog_format, gtid_mode) требуется reboot.

Check Parameter Group Status

# Проверить, применены ли изменения
aws rds describe-db-clusters \
  --db-cluster-identifier my-aurora-cluster \
  --query "DBClusters[0].[DBClusterParameterGroup, DBClusterMembers[*].[DBInstanceIdentifier, DBClusterParameterGroupStatus]]"

Вывод (до reboot):

[
  "debezium-aurora-cdc",
  [
    ["my-aurora-instance-1", "pending-reboot"],
    ["my-aurora-instance-2-reader", "pending-reboot"]
  ]
]

Status pending-reboot означает, что parameter group привязан, но параметры ещё не активны.

Reboot Requirements: Aurora 2.10+ Critical Change

Это одна из самых коварных ошибок конфигурации Aurora MySQL для CDC.

Problem Scenario

# 1. Вы rebooted только writer instance
aws rds reboot-db-instance --db-instance-identifier my-aurora-instance-1

# 2. Проверяете binlog_format на writer
mysql -h my-aurora-cluster.cluster-abc123.us-east-1.rds.amazonaws.com -u admin -p

mysql> SHOW VARIABLES LIKE 'binlog_format';
# +-----------------+-------+
# | Variable_name   | Value |
# +-----------------+-------+
# | binlog_format   | ROW   |
# +-----------------+-------+

Вы думаете: “Всё работает! ROW формат активен.”

# 3. Но подключение к reader instance показывает:
mysql -h my-aurora-instance-2-reader.abc123.us-east-1.rds.amazonaws.com -u admin -p

mysql> SHOW VARIABLES LIKE 'binlog_format';
# +-----------------+-------+
# | Variable_name   | Value |
# +-----------------+-------+
# | binlog_format   | MIXED |  ← СТАРОЕ ЗНАЧЕНИЕ!
# +-----------------+-------+

Проблема: Reader instance всё ещё использует старый parameter group default.

Aurora Version Detection

-- Проверить версию Aurora MySQL
SELECT AURORA_VERSION();
-- Вывод: 3.09.0 (соответствует MySQL 8.0.40)

-- Или через AWS CLI
aws rds describe-db-clusters \
  --db-cluster-identifier my-aurora-cluster \
  --query "DBClusters[0].EngineVersion"
-- Вывод: "8.0.mysql_aurora.3.09.0"

Mapping Aurora версий:

Вывод: Если вы используете Aurora MySQL 8.0.40 (Aurora 3.09.0), вам необходимо вручную reboot каждый reader instance.

Correct Reboot Procedure

# Step 1: Reboot writer instance
aws rds reboot-db-instance \
  --db-instance-identifier my-aurora-instance-1

# Дождаться завершения (можно мониторить через describe-db-instances)
aws rds wait db-instance-available \
  --db-instance-identifier my-aurora-instance-1

# Step 2: Reboot КАЖДЫЙ reader instance вручную (Aurora 2.10+)
aws rds reboot-db-instance \
  --db-instance-identifier my-aurora-instance-2-reader

aws rds wait db-instance-available \
  --db-instance-identifier my-aurora-instance-2-reader

# Если есть ещё reader instances, reboot их тоже
aws rds reboot-db-instance \
  --db-instance-identifier my-aurora-instance-3-reader

Verification After Reboot

# Проверить, что все instances используют новые параметры
aws rds describe-db-clusters \
  --db-cluster-identifier my-aurora-cluster \
  --query "DBClusters[0].DBClusterMembers[*].[DBInstanceIdentifier, DBClusterParameterGroupStatus]"

Ожидаемый вывод (после reboot):

[
  ["my-aurora-instance-1", "in-sync"],
  ["my-aurora-instance-2-reader", "in-sync"],
  ["my-aurora-instance-3-reader", "in-sync"]
]

Status in-sync означает, что parameter group полностью применён.

SQL verification:

-- На writer instance
SHOW VARIABLES LIKE 'binlog_format';
-- binlog_format | ROW

-- На reader instance
SHOW VARIABLES LIKE 'binlog_format';
-- binlog_format | ROW

-- Оба должны показывать одинаковые значения

Binlog Retention via Stored Procedures

Community MySQL использует binlog_expire_logs_seconds для управления retention. Aurora MySQL НЕ поддерживает этот параметр.

Вместо этого Aurora предоставляет stored procedures для конфигурации binlog retention.

Why Parameter Doesn’t Work

-- Community MySQL (работает)
SET PERSIST binlog_expire_logs_seconds = 604800;  -- 7 дней

-- Aurora MySQL (НЕ работает)
SET GLOBAL binlog_expire_logs_seconds = 604800;
-- ERROR 1238 (HY000): Variable 'binlog_expire_logs_seconds' is a read only variable

Причина: Aurora управляет binlog файлами на storage layer, который вы не контролируете. Retention настраивается через Aurora-specific stored procedures.

Aurora Stored Procedures for Binlog Retention

Aurora MySQL предоставляет процедуру mysql.rds_set_configuration для управления binlog retention.

-- Подключиться к writer instance (только writer может выполнять это)
mysql -h my-aurora-cluster.cluster-abc123.us-east-1.rds.amazonaws.com -u admin -p

-- Установить retention на 7 дней (168 часов)
CALL mysql.rds_set_configuration('binlog retention hours', 168);

Вывод:

Query OK, 0 rows affected (0.01 sec)

Maximum Retention Values

-- Для Aurora 3.x можно установить до 90 дней
CALL mysql.rds_set_configuration('binlog retention hours', 2160);  -- 90 дней

Для Phase 14 labs: Используем 168 hours (7 дней), как в Phase 12 decision [12-01].

CALL mysql.rds_set_configuration('binlog retention hours', 168);

Verify Retention Configuration

-- Проверить текущую конфигурацию retention
CALL mysql.rds_show_configuration;

Вывод:

+------------------------+-------+----------------------------------------------------------------------+
| name                   | value | description                                                          |
+------------------------+-------+----------------------------------------------------------------------+
| binlog retention hours | 168   | binlog retention hours specifies the duration in hours before...     |
+------------------------+-------+----------------------------------------------------------------------+
1 row in set (0.00 sec)

Проверить фактические binlog файлы:

SHOW BINARY LOGS;

Вывод:

+---------------------------+-----------+
| Log_name                  | File_size |
+---------------------------+-----------+
| mysql-bin-changelog.000001| 177       |
| mysql-bin-changelog.000002| 154       |
| mysql-bin-changelog.000003| 201       |
| mysql-bin-changelog.000004| 189       |
| mysql-bin-changelog.000005| 234       |
+---------------------------+-----------+
5 rows in set (0.00 sec)

Если retention работает корректно:

• Старые файлы (более 7 дней назад) автоматически удалены
• Новые файлы присутствуют и доступны для Debezium

Pitfall: Backup Retention Affects Binlog Retention

Проверить backup retention:

aws rds describe-db-clusters \
  --db-cluster-identifier my-aurora-cluster \
  --query "DBClusters[0].BackupRetentionPeriod"

Вывод:

7

Значение: 7 дней (минимум для production). Aurora по умолчанию использует 7 дней backup retention.

Если backup retention < binlog retention:

# Увеличить backup retention до соответствия binlog retention
aws rds modify-db-cluster \
  --db-cluster-identifier my-aurora-cluster \
  --backup-retention-period 7 \
  --apply-immediately

Правило: backup_retention_period >= binlog retention hours / 24

Verification Checklist

После всех изменений, выполните полную проверку конфигурации.

1. Parameter Group Applied

# Проверить, что cluster использует custom parameter group
aws rds describe-db-clusters \
  --db-cluster-identifier my-aurora-cluster \
  --query "DBClusters[0].DBClusterParameterGroup"

# Ожидается: "debezium-aurora-cdc"

2. All Instances In-Sync

# Проверить status всех instances
aws rds describe-db-clusters \
  --db-cluster-identifier my-aurora-cluster \
  --query "DBClusters[0].DBClusterMembers[*].[DBInstanceIdentifier, DBClusterParameterGroupStatus]"

# Ожидается: все instances в status "in-sync"

3. Binlog Format on Writer

-- Подключиться к writer endpoint
mysql -h my-aurora-cluster.cluster-abc123.us-east-1.rds.amazonaws.com -u admin -p

SHOW VARIABLES LIKE 'binlog_format';
-- binlog_format | ROW

4. Binlog Format on Reader

-- Подключиться к reader endpoint (если есть)
mysql -h my-aurora-cluster.cluster-ro-abc123.us-east-1.rds.amazonaws.com -u admin -p

SHOW VARIABLES LIKE 'binlog_format';
-- binlog_format | ROW (должно совпадать с writer)

5. GTID Mode Active

SHOW VARIABLES LIKE 'gtid_mode';
-- gtid_mode | ON

SHOW VARIABLES LIKE 'enforce_gtid_consistency';
-- enforce_gtid_consistency | ON

6. Binlog Retention Configured

CALL mysql.rds_show_configuration;
-- binlog retention hours | 168

7. Binlog Files Present

SHOW BINARY LOGS;
-- Должны быть видны binlog файлы (mysql-bin-changelog.NNNNNN)

8. Master Status

SHOW MASTER STATUS;

Вывод:

+---------------------------+----------+--------------+------------------+-------------------------------------------+
| File                      | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+---------------------------+----------+--------------+------------------+-------------------------------------------+
| mysql-bin-changelog.000005| 234      |              |                  | 3e11fa47-71ca-11e1-9e33-c80aa9429562:1-27 |
+---------------------------+----------+--------------+------------------+-------------------------------------------+

Если File пустой или GTID пустой:

• Binlog не активирован
• Проверьте parameter group и reboot status

Common Pitfalls

Разберём типичные ошибки при конфигурации Aurora MySQL для CDC.

Pitfall Deep Dive: Connecting to Reader Endpoint

// ❌ НЕПРАВИЛЬНО: Debezium connector config
{
  "database.hostname": "my-aurora-cluster.cluster-ro-abc123.us-east-1.rds.amazonaws.com",  // Reader endpoint!
  "database.port": "3306",
  ...
}

Проблема: Aurora read replicas используют physical replication (storage-level), не binlog replication. Binlog генерируется только на writer instance.

Симптомы:

• Debezium errors: “Could not find binlog file”
• Connector fails to start
• Intermittent failures (если reader promoted to writer)

// ✅ ПРАВИЛЬНО: Use writer (cluster) endpoint
{
  "database.hostname": "my-aurora-cluster.cluster-abc123.us-east-1.rds.amazonaws.com",  // Cluster endpoint (writer)
  "database.port": "3306",
  ...
}

Cluster endpoint: Всегда указывает на current writer instance, даже после failover.

Key Takeaways

1. Aurora MySQL managed service — нет прямого доступа к /etc/my.cnf, конфигурация через parameter groups
2. DB Cluster Parameter Group для binlog — binlog_format, gtid_mode, aurora_enhanced_binlog ТОЛЬКО на cluster level
3. DB Parameter Group для instance tuning — max_connections, innodb_buffer_pool_size на instance level
4. Default parameter groups read-only — создавайте custom parameter group для CDC
5. Reboot required for static params — binlog_format, gtid_mode требуют reboot после изменения
6. Aurora 2.10+ manual reader reboot — readers НЕ rebooted автоматически, reboot каждый reader вручную
7. Binlog retention via stored procedures — mysql.rds_set_configuration('binlog retention hours', N), НЕ через parameter
8. Maximum retention 90 дней (Aurora 3.x) — 168 hours для старых версий, 2160 hours для Aurora >= 2.11.0
9. Backup retention affects binlog — binlog purged если backup retention короче
10. Connect Debezium to writer endpoint — binlog доступен только на writer, не на readers
11. Verify on both writer and readers — проверьте binlog_format на всех instances после reboot
12. ApplyMethod=pending-reboot — для static параметров + explicit reboot

What’s Next?

Мы разобрали конфигурацию Aurora MySQL parameter groups для CDC. Теперь вы знаете:

• Как создать custom DB cluster parameter group
• Как настроить binlog retention через stored procedures
• Как правильно reboot instances (Aurora 2.10+)
• Как избежать типичных ошибок конфигурации

В следующем уроке (08) мы погрузимся в Aurora Enhanced Binlog — архитектуру, которая фундаментально меняет binlog storage:

• Parallel writes (transaction log + binlog simultaneously)
• 99% faster recovery после failovers
• Compute overhead reduction (50% → 13%)
• Критические ограничения (backtrack incompatibility, no cross-region replication)

Enhanced Binlog — это opt-in feature с production tradeoffs. Prepare for deep architectural dive.