ディザスタリカバリのためのベストプラクティス

はじめに

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

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

ディザスタリカバリの方法を検討する際には、2つの要因(RPO、RTO)を検討します。
お使いのアプリケーションの要件と合わせてこれらを決定します。

・RPO(Recovery Point Objective)
目標復旧時点。
災害発生時に、どれくらいのデータ損失を許容するか。

・RTO(Recovery Time Objective)
目標復旧時間。
災害発生時に、どれくらい素早く復旧するか。

RPOとRTOが決定したら、後述のディザスタリカバリ方法を選択します。

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

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

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

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

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

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

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

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