RDB:冗長化・フェイルオーバー(データ優先)
「データ優先」の特徴
冗長化タイプ | データ優先 |
---|---|
主な特長 | ・ データ同期 ・ データの冗長性を確保する ※1 |
待機系へのアクセス | アクセス不可 |
待機系の場所 | 同一ゾーン内 |
主系への昇格 | 主系障害時に自動で待機系にフェイルオーバーし主系昇格 |
切り替え時間 ※2 | 1分程度 |
待機系の数 | 1 |
対応データベース | MySQL、PostgreSQL |
※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の場合、フェイルオーバーが完了する前に、クラッシュリカバリーが行われるため、この時間も考慮する必要があります(クラッシュリカバリーにはデータ量が多ければ多いほど時間がかかります)。
なお、IPアドレスを持つ仮想のロードバランサーにて自動フェイルオーバー(HA機能)が発生した場合、自動フェイルオーバー(HA機能)の処理時間に加えてDBサービスの起動に最大2分程度の時間がかかります。
自動フェイルオーバー(HA機能)については、 サービスレベル目標(SLO)について の「自動フェイルオーバー」をご参照ください。