はじめに

一般に、災害などによるサイト障害からデータベースを保護するために、
対策としてスタンバイ用のデータベースを遠隔地に用意する方法があります。
今回はVerticaが対応しているディザスタリカバリの方法とベストプラクティスをご紹介します。

ディザスタリカバリの要件

データベース本番機が設置されたサイトに災害が発生した場合には、
スタンバイ・データベースに切り替える事でサービスを継続する事ができます。

ディザスタリカバリの方法を検討する際には、2つの要因(RPO、RTO)を検討します。
お使いのアプリケーションの要件と合わせてこれらを決定します。
・RPO(Recovery Point Objective)
目標復旧時点。
災害発生時に、どれくらいのデータ損失を許容するか。

・RTO(Recovery Time Objective)
目標復旧時間。
災害発生時に、どれくらい素早く復旧するか。
RPOとRTOが決定したら、後述のディザスタリカバリ方法を選択します。

ディザスタリカバリの方法

Verticaでディザスタリカバリを実装するには3つの方法があります。

1. 二重のデータロード

ETLを使って、2つのDB(本番データベースとスタンバイ・データベース)のそれぞれに同時にロードする

2. copyclusterを使ったレプリケーション

Verticaの機能であるcopyclusterを使って定期的にデータベースをレプリケーションする

<参考情報>
copyclusterを使ったレプリケーション方法については、こちらをご参照ください。

3. ストレージ機能を使ったレプリケーション

SANストレージのレプリケーション機能を使ってデータベースをコピーする


上記の3つのディザスタリカバリ方法について、RPOとRTO、およびメリットとデメリットをまとめたものを以下に記載します。

 二重のデータロードcopyclusterによるレプリケーションストレージ・レプリケーション
RPOCSVデータの正確さに依存直近のバックアップ状態まで復旧可正確に復旧
RTO常に有効常に有効
ただし、copyclusterの実行中を除く
常に有効
メリット・スタンバイ・データベースに異なる設定が可能・ビルトインのスクリプトで実装可能
・圧縮されたファイルを転送する事による高速化
データベースへの透過性
デメリット・ETLのライセンスが必要
・サイト障害発生時のエラーをハンドリングするためにアプリケーションのロジックが必要
本番機と同一構成のスタンバイ機が必要・コストが高価になる
・メディア障害も複製される


検証バージョンについて

この記事の内容はVertica 7.2で確認しています。