Aurora MySQLのレプリケーション
レプリケーションの選択肢
- Aurora レプリカ (DBクラスター参照)
- 別のリージョンにもう1つDBクラスター(とそのレプリカ)を作成する。別々のリージョンに2つのDBクラスター構成
- 同一リージョンに2つのDBクラスターを配置し、MySQLのバイナリログによりレプリケーションを使用する
- マスターとしてRDSのDBインスタンス、とAuroraのDBクラスターにそのレプリカを作成する。これは通常はAuroraへの移行方法として利用される
パフォーマンスに関する考慮事項
- レプリカログの圧縮機能によりレプリケーションメッセージが占めるネットワーク帯域を減らすことができる。メッセージはすべてのレプリカに送信されるため、クラスターの規模が大きいほど効果がある
- 圧縮を行う書き込み役のノード上である程度のCPUのオーバーヘッドがあるので、この機能は8xlargeと16xlargeのインスタンスタイプでのみ使用可能。これらのインスタンスクラスではこの機能はデフォルトで有効になっている
- aurora_enable_replica_log_compression パラメータで無効にすることもできる。書き込み役のノードのCPU負荷が高い場合など
- バイナリログのフィルタリング機能はレプリケーションメッセージが占めるネットワーク帯域を減らすことができる。レプリカはレプリケーションメッセージに含まれるバイナリログの情報を使用しないので、レプリカに送信されるメッセージからはその情報は省かれる
- aurora_enable_repl_bin_log_filtering パラメータでこの機能のオンオフを制御できる。デフォルトはオン。この最適化は透過的なので、レプリケーションに関係する問題の調査やトラブルシューティングのときにだけオフにされることを想定
高可用性に関する考慮事項
- 強制的なアップグレード依頼がときどきあり、ノードを１つずつアップグレードすることができないので、ダウンタイムが発生する（小１時間ぐらい）
- レプリカの数を増やすと可用性が向上する
- 複数のレプリカを持つ場合の難点は、基盤となるDBインスタンスが再起動されるときにレプリカも短時間使用できなくなる。再起動はメンテナンス作業中、あるいはあるレプリカのラグが大きくなりすぎたときにありうる
- レプリカを再起動すると当該のDBインスタンスへの既存の接続は切断される
- クラスターを再起動するとすべてのレプリカが同時に使用できなくなる
- ゼロダウンタイム再起動機能は、レプリカ再起動時の可用性を可能にする。例えばラグが大きくなりすぎたレプリカが再起動する時に、既存の接続を維持する。進行中のトランザクションはロールバックされるのでアプリ側でリトライする必要がある
- この機能を有効にするにはクラスターパラメーターグループでaurora_enable_zdr をオンにする。デフォルトはオフ
レプリケーションのモニタリング
- 読み取りのスケーリングと高可用性はレプリカラグが小さいことを前提としている
- CloudWatchのReplicaLagで確認
- このReplicaLagはプライマリインスタンスのページキャッシュと比べたレプリカのページキャッシュのラグを意味している。クラスターボリュームは同じものを見ているため
- レプリカラグの最も最新の値はmysql.ro_replica_statusテーブルのReplica_lag_in_msec を見る。この値がCloudWatchのReplicaLag に表示されている。INFORMATION_SCHEMA.REPLICA_HOST_STATUSにも表示されている
- モニタリングについてはこのページも参照