はじめに

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

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

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

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

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

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

1. 二重のデータロード

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

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

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

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

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

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


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

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

検証バージョンについて

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