こんにちは！中島です。
今回はAurora For MySQLのクラスター間レプリケーション方法について記載します！
※RDS for MySQLにも応用効くかと！

# はじめに
Aurora For MySQLは基本的に一つのクラスターである程度の可用性は担保できます。
現在携わっている案件でも１クラスター(1リーダインスタンス)の構成で運用しております。

今回現在使用中のエンジンバージョンのEOLが近いということもありバージョンアップを計画。
その際にいつでも切り戻し可能なように現バージョンでのクラスターを一つ複製しておきたいなと。
(スナップショット/dump復元などのダウンタイムは極力排除が望ましいタイミングでしたのでレプリケーションを検討)
※AuroraForMySQLでは仕様上binlogを用いた直接のデータ復旧はできませんが(スーパユーザ権限のあるユーザを作成できない為),binlogを用いたレプリケーションはMySQL同様に設定可能です！

実際に実施した手順を記載していきます！

**※Aurora For MySQL EOL**

- V1(MySQL5.6互換) 2023/02/28
- V2(MySQL5.7互換) 2024/02/29 予定

# クラスター間レプリケーション手順
クローンを用いてレプリケーション設定を行います。

## 1.クラスターパラーメータグループの設定
1.クラスター用のカスタムパラメータグループでバイナリーログを有効化します。
　binlog_format:MIXED設定
　※静的パラメータの為、適用には再起動が必須です。
　![パラメータ変更](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/38598b4e-0db4-43b6-89e5-009fccc33f47.webp)
2.適用確認
DB接続を行い、以下クエリでバイナリログが有効化されていることを確認。
```
show global variables like 'log_bin';
⇨ON
show global variables like 'binlog_format';
⇨MIXED
show binary logs;
⇨ログファイル名が表示されること
```
![適用確認](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/cf1e257f-3a6a-4ed1-bd61-c237fa8a5255.webp)

## 2.レプリケーション実行用ユーザの作成
1.下記クエリでレプリケーション用ユーザを作成する。
```
#ユーザ作成
CREATE USER 'repl_user'@'%' IDENTIFIED BY '任意パスワード'
#権限付与
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'%' IDENTIFIED BY '任意パスワード';
```
※ユーザ名も任意です。

## 3.クローン作成
1.クラスターを選択し右上アクションより「クローンの作成」。
![クローン作成](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/8ab51c91-f88e-46ae-a216-5db8834f2b63.webp)
2.クローンのライターインスタンスの「ログとイベント」タブより、ログファイルとポジションを確認する。
![ファイルポジション](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/40dd7226-8a3d-458a-a09b-4b0693319034.webp)
※添付では以下の通り
ログファイル：mysql-bin-changelog.000002
ポジション：1182

## レプリケーション設定
1.クローン側のライターインスタンスへログイン。
2.下記クエリでレプリケーションを開始する。
```
# レプリケーション設定
CALL mysql.rds_set_external_master ('<レプリケーション元の Aurora WRITER エンドポイント>', 3306, 'repl_user', '<パスワード>', '確認したファイル名', ポジション, 0);

# レプリケーション開始
CALL mysql.rds_start_replication;

# SLAVE 状態確認
SHOW SLAVE STATUS\G
⇨Seconds_Behind_Masterが0になるまで確認
```
## 4.レプリケーション確認
1.レプリケーション元DBでテーブルを更新してみます。
![レプリケーション元](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/732c07af-c3a2-49ca-a569-6e99c6e6caf0.webp)
2.クローン側で更新を確認してみます。
![クローン側](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/a329d40b-d366-4ba7-b19b-c75024946a73.webp)

レプリケーション元への更新が無事反映さているのでレプリケーション設定完了です！

## その他クエリ
```
#レプリケーション停止
CALL mysql.rds_stop_replication;
#レプリケーションエラーのスキップ
CALL mysql.rds_skip_repl_error;
```

# おわりに
以上がAurora For MySQLにおけるクラスター間レプリケーションの開始方法でした。
例えばV2⇨V3へインプレースアップグレード(エンドポイント変更のないアップグレード)を行う際のコンテンジェンシープラン等に有用かなと思います！

中島試した際はアップグレードの際にパラメータ適用がうまくいかず一時的にレプリケーション元のbinlogがOFFになってしまい、レプリケーションに失敗ということが起きましたが、その際もレプリケーション元を正しく修正の上エラーをスキップすれば正しく再開してくれました！

MySQLサーバでレプリケーションを行うよりも、画面上の操作で済むところが多く実施し易い印象でした！
いつか誰かの手助けになりますように。

Amazon RDS