待機系を起動はしておくが、データ同期は定期的に行う方式。
ウォームスタンバイとは、待機系(=予備のサーバ)のOSやアプリは起動しておくが、データの同期は定期的に行う二重化の方式です。「常時起動」と「常時同期」のうち、起動だけを済ませておく中間的なやり方です。
身近な例で考えると、休憩中だが制服を着て控えている交代要員に似ています。すぐ動ける格好では待っていますが、最新の引き継ぎメモは数十分おきにしか受け取っていません。いざ交代するときは、その間にたまった連絡事項にひととおり目を通してから持ち場に立つ、というイメージです。
上のツールで▶ボタンを押すと、待機系が起動した状態で定期同期を受け、主系の故障後に差分を反映して追いついてから切り替わる流れを確認できます。
3つの待機方式は、待機系をどこまで準備しておくかで区別されます。準備が手厚いほど切替は速くなりますが、その分コストは上がります。ウォームはちょうど真ん中です。
| 方式 | 待機系の起動 | データ同期 | 切替時間 | コスト |
|---|---|---|---|---|
| ホット | 常時起動 | リアルタイム | 最短 | 高い |
| ウォーム | 起動済み | 定期的 | 中間 | 中間 |
| コールド | 停止 | なし(故障時に復元) | 最長 | 安い |
整理すると、次のようになります。
・ホットスタンバイ:常時起動+常時同期で即切替できるが、コストが高い
・ウォームスタンバイ:起動済みだが定期同期。切替時間もコストもその中間
・コールドスタンバイ:停止していて起動から始めるため切替は遅いが、コストが安い
ウォームスタンバイは、「数分程度の停止なら許せるが、コストはほどほどに抑えたい」システムに向いた、バランス重視の選択肢だと考えると分かりやすいです。
ウォームスタンバイのデータ同期は「定期的」に行われます。常時コピーし続けるリアルタイム同期と違い、一定の間隔ごとにまとめて反映するため、待機系のデータは少し古い状態になります。
同期には、主に次のような方法が使われます。
・定期バックアップ:決まった時間ごとに主系のデータを待機系へコピーする
・レプリケーション:データベースの更新内容を一定間隔で待機系に複製する仕組み
・差分の反映:故障時に、最後の同期以降にたまった更新だけを取り込んで最新に追いつく
ここで大切なのは、最後の同期から故障までの間に主系で起きた更新が、待機系にはまだ反映されていないという点です。だから切替の前に「差分を反映して追いつく」処理が必要になり、これがホットスタンバイより切替時間が長くなる理由です。上のツールのSTEP4で、この追いつき処理を確認できます。