クラウド技術仕様（RDB：リードレプリカ）

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に設定しており、お客様はこの値を変更することはできません。