Fujitsu Cloud Direct当社が提供するサービスを法人のお客様へ直接販売するサイトです。

この記事は、ニフクラブログで2019-09-11に公開された記事を移転したものです。

こんにちは、ニフクラテクニカルアカウントチームです。

ニフクラのRDBは、コントロールパネルから2台のDBサーバーを異なるホストへ配置して、冗長化のためのアクティブ・スタンバイ構成を簡単に構築することができます。その際、データ優先と性能優先の２つのタイプから選択可能です。

そのRDBの冗長化機能について、「RDBの障害時の挙動や復旧時の手順などがわからない」と言ったお問い合わせをいただくことがあります。

そこで、本記事ではニフクラのクラウドユーザーガイドに掲載されている「冗長化構成でフェイルオーバー発生時の対処 」をベースにし、コントロールパネル上での状態・画面遷移、復旧手順を紹介します。

前提条件

本記事は、以下の前提知識がある方を想定しています。

• ニフクラの基本的なコントロールパネルの操作
• RDBの基礎的な知識

利用リソース

本検証で利用したニフクラのリソース情報を以下に記載します。

データ優先

性能優先

環境構築

データ優先と性能優先の環境は以下の画像の通りです。

構築は RDB：DBサーバーの作成 に記載されている方法で行いました。

データ優先

性能優先

「02 基本設定」の「冗長化」の項目でデータ優先、性能優先を選択することで、それぞれのタイプで冗長化したDBサーバーを作成できます。

また、イベントが通知されるためにイベント通知を作成する必要があります。 イベント通知については、RDB：イベント通知作成 を参照し作成してください。

検証内容

データ優先、性能優先での検証項目は下記の表の通りです。

データ優先

性能優先

これよりこれらの検証項目について以下の点を紹介します。

• 障害発生前の状態
• 想定障害
• 障害発生時の状態
• 通知されるイベント
• 復旧手順

データ優先

まずはデータ優先で冗長構成にしていたときに障害が発生した場合について紹介します。

障害発生前の主系のDBサーバー状態は次のようになっています。 冗長化の項目が「冗長化構成（データ優先）」になっています。

主系に障害が発生し、待機系が主系に昇格した状況を想定します。

この障害によるフェイルオーバーの後は、主系に昇格した待機系によるシングル構成になります。

また、下記の２つの状況についてはデータ優先その他の想定障害で紹介します。

• 主系に障害が発生したのち、主系が待機系として復帰できる状況
• 待機系に障害が発生した状況

障害が発生した後の DB サーバーのステータスは下記の図のようになります。 冗長化の項目が「シングル構成」に変更されています。

このときに通知されるイベントは下記の図のようになります。 主系に障害が発生し、冗長化が無効になった旨のイベントが通知されます。

この障害からの復旧手順の概要は以下になります。

1. 1.待機系の再作成
   • ・冗長化構成に戻したいDBサーバーをチェック
   • ・プルダウンから「設定変更」を選択
2. 2.作成のときの設定
   • ・基本設定の冗長化 を「冗長構成(データ優先)」にする
   • ・「確認へ」をクリック
   • ・何も変更せず「設定変更」をクリック
   • ・ステータスが設定変更中になる
3. 3.復旧の確認
   • ・DBサーバーの状態の冗長化が「冗長化構成(データ優先)」になっているのを確認
   • ・イベントを確認

これよりこれらの手順について紹介します。

1. 待機系の再作成

冗長化構成に戻したいDBサーバーをチェックをします。

プルダウンから「設定変更」を選択します。

2. 作成のときの設定

基本設定の冗長化の項目を「シングル構成」から「冗長構成（データ優先）」にします。

「確認へ」をクリックします。

「設定変更」をクリックします。

ステータスが設定変更中になります。

3. 復旧の確認

冗長化の項目が「冗長化構成(データ優先)」になっているのを確認します。

「DBサーバーの冗長化構成を有効にしています。」というイベントが通知されています。

さきほどの手順では、主系に障害が発生した状況を想定しましたが、これより以下の２つの障害が起きた際の復旧手順を紹介します。

• 主系に障害が発生したのち、主系が待機系として復帰できる状況
• 待機系に障害が発生した状況

主系に障害が発生したのち、主系が待機系として復帰できる状況

障害が起きた主系が待機系として復帰してくる場合があります。この場合は、コントロールパネルによる復旧手順は不要です。

この際に通知されるイベントは、下記画像のようにフェイルオーバー後もDBサーバーにアクセスできる旨を示すものになっています。

待機系に障害が発生した状況

主系ではなく待機系に障害が発生した際は、下記画像のように待機系に障害が起きたことを表すイベントが通知されます。

この主系ではなく待機系に障害が発生した場合においても、上記のデータ優先冗長化復旧手順に沿って復旧を行います。

性能優先

次に性能優先で冗長構成にしていたときに障害が発生した場合について紹介します。

障害発生前の主系のDBサーバー状態は次のようになっています。 冗長化の項目が「冗長化構成（性能優先）」になっています。 また、リードレプリカの項目にはリードレプリカのサーバー名が記載されています。

冗長化の項目が「冗長化構成（性能優先）」になっています。

リードレプリカの状態は次のようになっています。

本検証では、リードレプリカに障害が発生し、主系がシングル構成になった障害を想定します。

また、下記の状況については性能優先その他の想定障害で紹介しています。

• 主系に障害が発生した状況

主系のDBサーバーのステータスに変化はありません。 リードレプリカの項目も障害前から変化していません。

リードレプリカのステータスがエラーになります。

このときに通知されるイベントは下記の図のようになっています。 リードレプリカに障害が発生した旨のイベントが通知されます。

この障害からの復旧手順の概要は以下になります。

1. 1.エラーになったリードレプリカの削除
   • ・削除したいリードレプリカにチェックをつける
   • ・プルダウンから「DBサーバー削除」を選択
   • ・「削除する」をチェック
   • ・「OK」をクリック
   • ・主系が「設定変更中」、リードレプリカが「削除中」になる
   • ・主系が「稼働中」、リードレプリカが一覧から削除される
2. 2.リードレプリカの作成
   • ・リードレプリカを作成したい主系をチェック
   • ・プルダウンから「リードレプリカ作成」をクリック
   • ・レプリカの名前、DBサーバータイプ、ディスクタイプを設定
   • ・「作成する」をクリック
   • ・主系が「設定変更中」、リードレプリカが「作成中」になる
   • ・主系が「稼働中」、リードレプリカが作成される
3. 3.復旧の確認
   • ・主系、リードレプリカの状態

1. エラーになったリードレプリカの削除

まずは、エラーとなったリードレプリカを削除します。 削除したいリードレプリカにチェックをつけます。

プルダウンから「DBサーバー削除」を選択します。

「削除する」をチェックします。

「OK」をクリックします。

主系が「設定変更中」になりリードレプリカが「削除中」になります。

しばらくすると待つと、リードレプリカが削除されます。

2. リードレプリカの作成

続いて主系に紐付いたリードレプリカを新たに作成する方法を紹介します。 まずは、リードレプリカを作成したい主系をチェックします。

プルダウンから「リードレプリカ作成」をクリックします。

リードレプリカ作成画面からレプリカの名前、DBサーバータイプ、ディスクタイプを設定します。

「作成」をクリックします。

主系が「設定変更中」、リードレプリカが「作成中」になります。

3. 復旧の確認

しばらくすると作成が完了して、主系ならびにリードレプリカのステータスがともに正常になっていることを確認します。

さきほどの手順では、リードレプリカに障害が発生した状況を想定しましたが、これより主系に障害が発生した際の復旧手順を紹介します。

主系に障害が発生した際は、下記画像のようにリードレプリカの１つが主系に昇格します。 この挙動は主系に紐付いたリードレプリカの数が１つでも複数でも同様になります。

この際、通知されるイベントは下記画像のようにリードレプリカの１つが主系に昇格した内容になっています。

復旧手順は性能優先冗長化復旧手順から「1. エラーになったリードレプリカの削除」を除いた手順となります。

まとめ

RDBのDBサーバーの２つのタイプで障害が発生した際の挙動と、そこからの復旧手順を紹介しました。ニフクラではRDBの構成要素に障害が発生してもコントロールパネルからの操作のみで簡単に復旧することができます。

RDBを利用した運用を検討する際の参考にしていただけると幸いです。