RDB:リードレプリカ
MySQL、PostgreSQLに組み込まれたレプリケーション機能によるリードレプリカを作成することが可能です。(冗長化とは別機能です。)
これにより、読み出しの負荷が高く1台のDBサーバーでは限界に達してしまうような場合でも、柔軟なスケールアウトを行うことができます。
1度、リードレプリカを作成してしまえば、リードレプリカ元のDBサーバーのデータベースを更新すると、MySQLの場合は非同期レプリケーション、PostgreSQLの場合はストリーミングレプリケーション(非同期レプリケーション)によりリードレプリカにも反映が行われるようになります。
利用シーン
以下のような場合が、リードレプリカの利用に適しています。
読み出しの負荷が非常に高い場合 | 1台のDBサーバーではさばき切れない負荷を複数台に分散することができます。 |
リードレプリカ元のマスターDBサーバーが利用できない場合 | 読み出しの処理だけをリードレプリカに向けることができます。 リードレプリカ元のマスターDBサーバーに対してDBスナップショットを行っているときや計画メンテナンスを行っているときに有効です。 マスターDBサーバーが利用できない状態のため、リードレプリカの持つデータは古い可能性があることに注意してください。 |
業務レポートや解析に利用するデータの収集 | 本番環境の重要なDBサーバーでデータ取得用のクエリを実行しなくてすみます。 |
リードレプリカの状態
リードレプリカのステータスはコントロールパネルまたは DescribeDBInstances APIで確認することができます。ステータスは下記の2種類です。
コントロールパネルでの表示 | API | 説明 |
---|---|---|
レプリケーション中 | replicating | レプリケーションは正常動作しています。 |
エラー | error | レプリケーションにエラーが発生しました。コントロールパネルのDBサーバー詳細タブまたはイベント一覧ページで、エラーの内容を確認してください。 |
MySQLエンジンの場合
レプリケーションでエラーの状態が続くと、下記のような不具合につながりますのでご注意ください。
- binlogにエラーメッセージが大量に書き込まれてサイズが大きくなり、ストレージを圧迫する
- 大量に存在するbinlogを処理しなければならないため、クラッシュリカバリーの時間が長くなる
レプリケーションの遅延については、下記でご確認いただけます。
- mysqlコマンド
SHOW SLAVE STATUS \G
出力結果の
Seconds_Behind_Master
- モニタリングのレプリケーション遅延時間
レプリケーション遅延が頻発する場合は、下記を実施していただくことでレプリケーションの速度が改善する場合があります。
- 一度リードレプリカを削除し再作成する
- リードレプリカのDBサーバータイプをよりスペックの良いものに変更する
PostgreSQLエンジンの場合
レプリケーションでエラーの状態が続くと、下記のような不具合につながりますのでご注意ください。
- 大量に存在するWALファイルを処理しなければならないため、クラッシュリカバリーの時間が長くなる
正確なレプリケーションの遅延時間を取得することはできませんが、リードレプリカ側で下記コマンドを実行することにより、最後の更新日時を確認することができます。
ただし、マスターDBサーバー側で更新がなかった場合には日時は更新されません。
SELECT pg_last_xact_replay_timestamp();
また、マスターDBサーバーへのデータ更新が大量に行われると、レプリケーションが追いつかなくなり、エラーとなってしまう場合があります。
このような場合、マスターDBサーバーのwal_keep_segmentsの値(デフォルト値:100)を増やし、WALファイルの保持数を増やすことで改善を行うことができます。DBエンジンバージョンが13以降の場合は、マスターDBサーバーのwal_keep_sizeの値 (デフォルト値:1600) を増やし、WALファイルの保持サイズを増やすことで改善を行うことができます。
リードレプリカの作成
- 1台のDB サーバーに対して、最大5台のリードレプリカを作成できます。
- 作成の際にはレプリケーションのマスターとなるDBサーバーの名前を指定する必要があります。
- リードレプリカはマスターに指定したDBサーバーと同じゾーンに作成されます。
最新のDBスナップショットからリードオンリーのDBサーバーを作成するという処理が行われます。 - モニタリング機能で監視することができます。
- リードレプリカへのデータ更新は、DBエンジンのレプリケーション機能の制約により、遅延する場合がありますのでご注意ください。
- 効果的なレプリケーションを行うために、リードレプリカはマスターと同じDBサーバータイプ・ディスク容量に設定することを推奨します。
- リードレプリカ元のDBサーバーとは別の新しいIPアドレス(プライベート・グローバル)が発行されます。
- リードレプリカは、コントロールパネルでは、DB種別に「リードレプリカ(リードレプリカ元のDBサーバーの名前)」のように表示されます。
- リードレプリカ作成処理において組み込み先となるマスターDBサーバー及びスレーブDBサーバーに性能影響はありません。
ただし、リードレプリカの台数の増加に伴いマスターDBサーバーへのレプリケーション負荷が増加する場合があります。
MySQLエンジンの場合
- 作成されたリードレプリカは、読み出し専用(書き込み不可)の状態となっており、DBパラメーターグループで、read_onlyが1に設定されます。
- リードレプリカ元のDBサーバーのバイナリログのサイズによっては、リードレプリカの作成に時間のかかる場合があります。
PostgreSQLエンジンの場合
- リードレプリカ元のDBサーバーのWALファイルのサイズによっては、リードレプリカの作成に時間のかかる場合があります。
リードレプリカの削除
リードレプリカは通常の DB サーバーと同じ操作で削除することができます。
リードレプリカのマスターとなっているDBサーバーを削除することはできません。 すべてのリードレプリカを削除してからマスターDBサーバーを削除してください。
リードレプリカへの更新
リードレプリカを更新可能に設定することはできません。
冗長化機能との関係
冗長化機能のオン・オフに関わらず、DBサーバーからリードレプリカを作成することができます。
冗長化機能によって継続性・可用性を高めることはできますが、冗長化機能(データ優先)で作成された待機系サーバーはリードレプリカ(MySQL)のようには読み出しクエリを受け付けることはできませんのでご注意ください。
冗長化機能(データ優先)がオンのDBサーバーにリードレプリカを作成した場合、フェイルオーバーで主系から待機系への切り替わりが発生すると、リードレプリカはレプリケーション先を待機系の DB サーバーに切り替えます。
冗長化機能(性能優先)のマスタDBサーバーとレプリケーションしているリードレプリカの場合、フェイルオーバー動作時にマスタDBサーバーに昇格します。
冗長化構成との仕様比較
冗長化(性能優先) | シングル構成+リードレプリカ | |
---|---|---|
自動フェイルオーバー | あり | なし |
選択可能なDBタイプ | MySQL | MySQL、PostgreSQL |
MySQLエンジン使用中の障害時にbinlogのイベントがフラッシュされていなかった場合
このレプリケーション先の切り替えがうまくいかない場合があります。
そのような場合には、一度リードレプリカを削除した上で再作成してください。
MySQL 5.5の場合 | DBパラメーターを sync-binlog=1、innodb_support_xa=1に設定することでこれを回避することができますが、パフォーマンスが下がる可能性があるのでテストを行った上で本番環境へ適用してください。 |
MySQL 5.6の場合 | ニフクラ RDBにて、DBパラメーターをsync-binlog=1、innodb_support_xa=1に設定しており、お客様はこの値を変更することはできません。 |
MySQL 5.7の場合 | ニフクラ RDBにて、DBパラメーターをsync-binlog=1、innodb_support_xa=1に設定しており、お客様はこの値を変更することはできません。 |
自動バックアップ機能との関係
自動バックアップ機能が無効のDBサーバーにはリードレプリカが作成できません。
また、自動バックアップ機能が有効であっても、初回の自動バックアップが作成されていない場合にはリードレプリカを作成できません。
既存のDBサーバーに対してリードレプリカを作成したい場合には、あらかじめ自動バックアップ機能を有効にした上で、初回の自動バックアップが終わるまで待つ必要があります。
自動バックアップが有効なDBサーバーを作成した場合にも同様に、初回の自動バックアップが作成されてから、リードレプリカを作成してください。
なお、リードレプリカのマスターとなっているDBサーバーの自動バックアップ機能は無効にできません。リードレプリカを削除した上で自動バックアップ機能を無効にしてください。
※有効な自動バックアップが作成されていない場合、自動バックアップを取得してからリードレプリカ作成を行います。
PostgreSQLエンジンでリードレプリカを利用する際の注意事項
PostgreSQLエンジンでリードレプリカを利用する際には、下記にご注意ください。
リードレプリカ作成時の制限
- マスターとする予定のDBサーバーより、DBサーバータイプのスペックが低いリードレプリカを作成することはできません。
また、マスターのサーバータイプを変更中の場合は、変更前と変更後でスペックが高い方のサーバータイプが比較の基準となります。
DBサーバー設定変更時の制限
- リードレプリカのDBパラメーターグループを変更することはできません。
- リードレプリカのDBサーバー設定変更で、DBサーバータイプをマスターよりスペックの低いものに変更することはできません。
- リードレプリカのマスターとなっているDBサーバーのDBパラメーターグループの変更を行うことはできません。
- リードレプリカのマスターとなっているDBサーバーのDBサーバータイプを、リードレプリカよりスペックの高いものに変更することはできません。
DBパラメーターグループ編集時の制限
- リードレプリカおよびそのマスターとなっているDBサーバーに適用された、DBパラメーターグループの「max_connections/max_prepared_transactions/max_locks_per_transaction」の値を変更することはできません。
DBパラメーターグループリセット時の制限
- リードレプリカおよびそのマスターとなっているDBサーバーに適用された、DBパラメーターグループをリセットすることはできません。