RDB：冗長化・フェイルオーバー
DBサーバーの冗長化と障害時のフェイルオーバーをサポートしています。
冗長化のタイプは、データ優先 / 性能優先 の２つから選択することができます。
「データ優先」と「性能優先」の違い
| 冗長化タイプ | データ優先 | 性能優先 |
|---|---|---|
| 主な特長 | ・ データ同期 ・ データの冗長性を確保する ※1 |
・ 非同期レプリケーション ・ 待機系はリードレプリカとして生成される ・ 読み取り処理の負荷分散に加え、冗長性を向上させる |
| 待機系へのアクセス | アクセス不可 | 読み取りアクセス可能 |
| 待機系の場所 | 同一ゾーン内 | 同一ゾーン内 |
| 主系への昇格 | 主系障害時に自動で待機系にフェイルオーバーし主系昇格 | 主系障害時に自動でリードレプリカにフェイルオーバーし主系昇格 |
| 切り替え時間 ※2 | 1分程度 | 15秒程度 |
| 待機系の数 | 1 | 1～5 |
| 対応データベース | MySQL、PostgreSQL、MariaDB | MySQL |
※1「データ優先」でも、待機系とは別にリードレプリカを作成することが可能です。ただし、主系からのフェイルオーバー先としては利用できません。
※2 切り替え時間はデータベースの利用のされ方などにより変動します。
冗長化（データ優先）
冗長化機能（データ優先）をオンにすると、自動で別の物理ホストに待機系のDBサーバーが作成されます。
主系から待機系へと同期的にデータが複製されるので、データの冗長性を確保できます。
バックアップ処理（手動によるDBスナップショット・自動バックアップ) を行う際に、冗長化機能（データ優先）がONの場合は待機系からバックアップの取得を行います。バックアップ処理中は、同期的なデータの複製により、IO性能が低下する可能性がありますが、シングル構成と比較してIO性能の低下を軽減することができます。
DBサーバーを作成する際に、冗長化機能（データ優先）をオンにすることができます。
DBサーバーの設定変更を行い、途中から冗長化機能（データ優先）をオンにすることも可能です。
ご注意事項
- 冗長化機能（データ優先）は、2つのDBサービスが並行して起動している類のものではありません。
複製されているのはブロックデバイス単位のデータです。 - 冗長化機能（データ優先）は、読み出し専用のDBサーバーでスケールアウトを行うような用途には利用できません。
また、待機系から読み出し処理を行うこともできません。
読み出し専用のDBサーバーを用意したい場合には、リードレプリカを利用してください。 - 同期的なデータの複製が行われるため、冗長化機能オフの場合に比べ、冗長化機能（データ優先）オンの場合にはレイテンシーが増大する可能性があります。
- 冗長化機能（性能優先）から冗長化機能（データ優先）に変更するには、一度冗長化機能（性能優先）をオフにする必要があります。
- DBサーバータイプとデータ量によって冗長化処理に時間がかかる場合があります。必要に応じてDBサーバータイプのスペックアップ・データ量の削減をご検討ください。
冗長化機能は、ディスクレベルでの主系－待機系間の同期を行うため、フェイルオーバーのタイミングで主系に昇格したDBサーバーはメモリ上にDBデータのキャッシュ（MySQLの場合InnoDBのバッファプールなど、PostgreSQLの場合shared_buffers）を持っていません。お客様でキャッシュのウォームアップを行う必要がありますのでご注意ください。
フェイルオーバー（データ優先）
主系のDBサーバーが停止または利用不可になった場合には、別物理ホストに存在する待機系のDBサーバーへの切り替えが行われます。 この自動フェイルオーバーの仕組みは、IPアドレスを持つ仮想のロードバランサーを利用して実現しています。
定期的なメンテナンスの際にもフェイルオーバーを行って片系ずつ設定を変更するため、DBサーバーの可用性を高めることができます。 単一の物理ホストに障害が起きた場合でも、フェイルオーバーを行うことでデータベースを利用し続けることができます。
フェイルオーバーは自動で行われるため、データベースの利用を再開するまでに複雑な手順を踏む必要はありません。
下記のいずれかの場合に主系から待機系へのフェイルオーバーが発生します。
物理ホストの障害 / 主系 DB サーバーの障害 / DBサーバータイプの変更 / DBサーバーの再起動時に強制フェイルオーバーを指定フェイルオーバーが完了するまでにかかる時間の目安は1分程度ですが、主系のDBサーバーが利用不可になった時、どのくらいデータベースが利用されていたかなどのさまざまな条件に左右されます。また、MySQL・PostgreSQLの場合、フェイルオーバーが完了する前に、クラッシュリカバリーが行われるため、この時間も考慮する必要があります（クラッシュリカバリーにはデータ量が多ければ多いほど時間がかかります）。
冗長化（性能優先）
冗長化機能（性能優先）をオンにすると、自動で別の物理ホストに待機系のDBサーバーが作成されます。
冗長化機能（性能優先）は、DBエンジンがMySQLの場合にのみご利用いただけます。
待機系サーバーはリードレプリカとして作成されます。MySQLのレプリケーション機能を用いたデータ複製がされ、データの冗長性を確保できます。待機系サーバーは読み出し権限でDBサービスを起動している為、参照系のリクエストを待機系サーバーに振り分けて、主系に対する負荷を分散させることができます。
DBサーバーを作成する際に、冗長化機能（性能優先）をオンにすることができます。
DBサーバーの設定変更を行い、途中から冗長化機能（性能優先）をオンにすることも可能です。
ご注意事項
- 自動バックアップを行う際、冗長化構成（性能優先）がONの場合は主系から取得を行うので、IO性能の低下が発生します。
- 主系サーバーがパラメーターエラー状態の場合、一時的に冗長化設定が解除されます。
パラメーターエラーを修正することで、冗長化設定が有効になります。 - 待機系サーバー（リードレプリカ）が１台も存在しない場合、フェイルオーバーを発生させることができません。
リードレプリカを作成することで、フェイルオーバーを行えるようになります。 - フェイルオーバー後は、主系に昇格した元待機系サーバーで、更新系の処理を受け付けるようになります。その為、主系サーバーにも参照系のリクエストを振り分け、待機系サーバーには主系昇格後の更新系処理を受け付けられる余裕を持たせておく構成をお勧めします。
- 2015/4/8 14:00 よりも前に作成したDBサーバーは、途中から冗長化機能（性能優先）をオンにすることはできません。
- 冗長化機能（データ優先）から冗長化機能（性能優先）に変更するには、一度冗長化機能（データ優先）をオフにする必要があります。
- DBサーバータイプとデータ量によって冗長化処理に時間がかかる場合があります。必要に応じてDBサーバータイプのスペックアップ・データ量の削減をご検討ください。
フェイルオーバー（性能優先）
主系のDBサーバーが停止または利用不可になった場合には、別物理ホストに存在する待機系のDBサーバーへの切り替えが行われます。
この自動フェイルオーバーの仕組みは、IPアドレスを持つ仮想のロードバランサーを利用して実現しています。主系の物理ホストに障害が起きた場合でも、フェイルオーバーを行うことでデータベースを利用し続けることができます。
フェイルオーバーは自動で行われるため、データベースの利用を再開するまでに複雑な手順を踏む必要はありません。
下記のいずれかの場合に主系から待機系へのフェイルオーバーが発生します。
物理ホストの障害 / 主系 DB サーバーの障害 / DBサーバーのフェイルオーバーを実行フェイルオーバーが完了するまでにかかる時間の目安は、15秒程度ですが、主系のDBサーバーが利用不可になった時、どのくらいデータベースが利用されていたかなどのさまざまな条件に左右されます。
ご注意事項
- 物理ホストの障害 / 主系DBサーバーの障害のいずれかの理由でフェイルオーバーが行われた場合、待機系のリードレプリカが主系に昇格する為読み出し専用でご利用いただけたリードレプリカの台数が１台少なくなります。
- コントロールパネルからDBサーバーのフェイルオーバーを実行した場合、主系と待機系のサーバーが入れ換わります。フェイルオーバー完了後、待機系サーバーのIPアドレスは変更になります。主系サーバーについては、IPアドレスを持つ仮想のロードバランサーを利用している為、IPアドレスの変更はありません。
- なお、レプリケーション遅延が発生している場合、コントロールパネルからのDBサーバーフェイルオーバーは失敗します。
