6.2.1. 障害時のサービス継続性
本構成で障害が発生した場合のサービス継続性は 、障害が発生する場所が、スタンバイサーバかアクティブサーバ によって、障害時の復旧方法が異なります。なお、障害時において、コミット済みのデータは PostgreSQL の持つ耐障害 性（WAL によるクラッシュリカバリ）によりデータは保全されますが、コミットされていないトランザクションは失われます。
まず、スタンバイサーバに障害が発生した場合は、DRBD によるスタンバイサーバとのコネクションが切断され、デー タ同期を停止します。その際、提供しているサービスは数秒接続ができなくなる可能性がありますが、自動的に復帰しま す。（図 6.2）
次に、アクティブサーバに障害が発生した場合は、スタンバイサーバの障害と同様に、DRBD によるスタンバイサーバ とのコネクションが切れ、データ同期を停止します。アクティブサーバを切り離した後、スタンバイサーバを新アクティブ サーバに昇格させサービスを継続させます。昇格には、新アクティブサーバの DRBD をprimaryに切り替えて、DRBD 領域をマウントした後、PostgreSQL サーバを起動します。起動には通常の PostgreSQL サーバ起動コマンドで行いま す。（図 6.3）
なお、HA クラスタソフトウェアなどの各種ツールを使用しない場合は、サーバやサービスの障害検知やフェイルオーバ といった切り替えを全て手動で行う必要があるため、サービスの停止は長期化します。
50/135 © 2014 PostgreSQL Enterprise Consortium
図 6.2: スタンバイサーバ障害時の挙動 PostgreSQL
アクティブサーバ
（プライマリ）
スタンバイサーバ
参照 更新
アプリケーション
DRBD
ブロック データ
PostgreSQL
DRBD
ブロック
✕
データ障害発生
（停止中）
アクティブサーバ
（プライマリ）
スタンバイサーバ
参照 更新
アプリケーション
DRBD
障害発生 レプリケーションが停止した際、
一時的に切断する可能性がある
PostgreSQL DRBD
ブロック データ
PostgreSQL
（停止中）
要求されるサービスレベルによって自動化が必要になりますが、自動化を行う場合のHA クラスタソフトウェアの説明は、
5 章で行ったため割愛します。HA クラスタソフトウェアと組み合わせた構成で障害が発生すると、図 6.4 のように自動 的にフェイルオーバします。
本構成におけるフェイルオーバの注意点として、5 章と同様に、HA クラスタソフトウェアを使用する場合には、スプリッ トブレインを発生させないために、死活監視を行うハートビート通信用のネットワークを多重化するなどして、信頼性を 高めておく必要があります。
図 6.3: アクティブサーバ障害時の挙動 PostgreSQL
アクティブサーバ スタンバイサーバ
（セカンダリ）
参照 更新
アプリケーション
DRBD
ブロック データ
PostgreSQL
DRBD
ブロック
✕
データ障害発生
新アクティブサーバに昇格
PostgreSQL
旧アクティブサーバ 新アクティブサーバ
（プライマリ）
参照 更新
アプリケーション
DRBD
PostgreSQL DRBD
障害発生
（停止中）
ブロック データ
（停止）
図 6.4: アクティブサーバ障害時の自動切換え PostgreSQL
アクティブサーバ スタンバイサーバ
（セカンダリ）
参照 更新
アプリケーション
DRBD
ブロック データ
PostgreSQL
DRBD
ブロック
✕
データ障害発生
新アクティブサーバに昇格
PostgreSQL
旧アクティブサーバ 新アクティブサーバ
（プライマリ）
参照 更新
アプリケーション
DRBD
PostgreSQL DRBD
障害発生
Pacemaker Heartbeat
Pacemaker Heartbeat
ハートビート 通信
Pacemaker Heartbeat
Pacemaker Heartbeat
ハートビート 通信
（停止中） （停止）
ブロック データ
6.2.2. 障害復旧時の運用性
元の状態に戻す（フェイルバック）には、スタンバイサーバ障害、アクティブサーバ障害のいずれの場合も、発生した障 害を取り除き、DRBD プロセスを起動します。プロセス起動すると、自動的にノード間の接続が再確立され、停止中に更 新された変更内容が全て同期されます。（図 6.5、図 6.6）
アクティブサーバ障害の復旧の場合は、図 6.6にあるようにアクティブサーバとスタンバイサーバが本来の状態と逆 になっているため、本来の状態に戻さないといけません。そのために、新アクティブサーバをdrbdadm secondaryでス タンバイサーバに降格させた後、新スタンバイサーバをdrbdadm primaryでアクティブサーバとして昇格させます。こ れらの手続きをすることで本来の状態に復旧できます。（図 6.7）
52/135 © 2014 PostgreSQL Enterprise Consortium
図 6.5: スタンバイサーバ障害時の復旧 PostgreSQL
アクティブサーバ
（プライマリ）
スタンバイサーバ
参照 更新
アプリケーション
DRBD
ブロック データ
PostgreSQL
DRBD
（停止中）
PostgreSQL
アクティブサーバ
（プライマリ）
スタンバイサーバ
（セカンダリ）
参照 更新
アプリケーション
DRBD
ブロック データ
PostgreSQL
DRBD
ブロック データ
（停止中）
DRBDプロセス 起動
図 6.6: アクティブサーバ障害時の復旧
ブロック
データ ブロック
データ DRBDプロセス
起動
PostgreSQL
旧アクティブサーバ 新アクティブサーバ
（プライマリ）
参照 更新
アプリケーション
DRBD
PostgreSQL DRBD
（停止）
PostgreSQL
新スタンバイサーバ
（セカンダリ）
新アクティブサーバ
（プライマリ）
参照 更新
アプリケーション
DRBD
PostgreSQL DRBD
（停止）
ブロック データ
障害復旧するに当たり、元の構成に戻すための時間はサービスが停止するため、注意が必要です。
本構成におけるフェイルバックに関する注意点として、ハードディスクを交換した場合には、再度drbdadm create-mdコマンドでメタデータを作成した後、再接続する必要があります。