アクセラと+αな生活
アクセラとα350と共に過ごす気まぐれ日記です。
Firefox ブラウザ無料ダウンロード
2017年06月
≪05月  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30    07月≫
スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
PostgreSQL の可用性を高めてみる。(その3)でオンラインバックアップの採取ができました。

では、オンラインバックアップからのリカバリの検証をしてます。
今回は PostgreSQL のデータベースクラスタのディスクに障害が発生したと仮定し、障害発生時点までのリカバリを検証します。

リカバリは以下の流れで検証します。
【リカバリの検証作業】
○オンラインバックアップ実行
○データ更新
 オンラインバックアップ後に更新されたデータがリカバリするかを確認するため。
○PostgreSQL の停止、データベースクラスタの削除
 データベースクラスタのディスク障害が発生したと仮定し、PostgreSQL を停止させる。
 ※ここで障害が発生したことになるので、以降がリカバリ作業となる。
○現在の WAL の退避
○データベースクラスタのファイルリカバリ
○アーカイブログ、WALのファイルリカバリ
○PostgreSQL の起動
 起動時に、PostgreSQL が自動的にアーカイブログ、WALをデータベースに対して適用する。。。はず。


【オンラインバックアップ実行】
PostgreSQL の可用性を高めてみる。(その3)で作成したシェルを実行します。
※万が一に備え、フルバックアップしておくことをお勧めします。

【データ更新】
テスト用のデータを作成します。
WAL はセグメントファイルが16MB(デフォルト時)を超えた時、または指定時間を越えた時に、「postgresql.conf」 の「archive_command」 に指定されたコマンド(アーカイブログログの作成)を行います。
ですので、16MBを超えるようなデータ更新を行うと、より効果的ですね。

【PostgreSQL の停止、データベースクラスタの削除】
ディスク障害と仮定して、以下のコマンドで PostgreSQL を停止し、データベースクラスタを削除します。

※WAL がデータベースクラスタと同じディスクに保存していると、データベースクラスタの削除(つまり、データベースクラスタの保存されたディスクの障害)が発生した時点でリカバリが不可能になってしまいます。
実際の運用を考えると、アーカイブ、WAL はデータベースクラスタと別ディスクに保存すべきですね。

# /etc/rc.d/init.d/postgresql stop
Stopping postgresql service: [ OK ]
# cd /var/lib/pgsql/
# rm -rf data


うう~、これで後戻りができない。。。><;

【現在の WAL の退避】
うちの環境の場合、WAL は「/var/archives/pg_xlog/」に保存しています。
WALのセグメント上にオンラインバックアップ後のデータ更新情報が残っていますので、WAL を退避(コピー)させます。
# cp -rp /var/archives/pg_xlog /var/archives/pg_xlog_recent


【データベースクラスタのファイルリカバリ】
うちの環境の場合、オンラインバックアップは「/mnt/backup/pg_data」に保存しています。
またバックアップ領域は、通常時アンマウントされているので、バックアップ領域をマウントし、データベースクラスタのファイルを復旧させます。
# mount /dev/hdd1 /mnt/backup/
# cp -rp /mnt/backup/pg_data/data /var/lib/pgsql/


※データベースが大きい場合、時間が掛かりますので、コピーが完了するまで、ひたすら待ちます。

【アーカイブログ、WALのファイルリカバリ】
アーカイブログと先ほど退避しておいた最新の WAL を復旧させます。
重複したファイルがある場合は最新の WAL のファイルに置換しておきます。
# rm -rf /var/archives/pg_xlog/*
# cp -rp /var/archives/pg_xlog_back/* pg_xlog/
# cp -rp /var/archives/pg_xlog_recent/* pg_xlog/

cp: `pg_xlog/000000010000000000000007.00C642FC.backup' を
 上書きしてもよろしいですか(yes/no)? y


【PostgreSQL の起動】
PostgreSQL のマニュアル上では、「recovery.conf」が必要のようですが、WAL を全適用するのであれば、「recovery.conf」がなくても自動で適用されます。
WAL の適用を時間指定(Point In Time Recovery)する場合や特別なリカバリをするのであれば、「recovery.conf」で設定しておかなければなりませんが、障害発生時点へのリカバリであれば、「recovery.conf」は不要のようです。
(PostgreSQL はデータベースクラスタの状態と、WAL の状態を確認し、自動でWALの更新情報をデータベースクラスタに適用してくれるようです)

以下のコマンドで PostgrSQL を起動します。
# /etc/rc.d/init.d/postgresql start
Starting postgresql service: [ OK ]



後は、オンラインバックアップ後に更新したデータを確認です。
オンラインバックアップ後に更新したデータが反映されていれば、アーカイブログが適用されたことになり、障害発生時点へリカバリできたことになります。

【おまけ】
今回はデータベースクラスタが保存されているディスクの障害を仮定してリカバリ検証を行いました。

WAL、アーカイブが保存されているディスクの障害もWAL、アーカイブがオンラインバックアップで取得していれば、オンラインバックアップ時点までのリカバリは可能になります。
方法としては、【アーカイブログ、WALのファイルリカバリ】でリカバリするファイルをオンラインバックアップ時のものにすれば大丈夫です。

コメント
この記事へのコメント
URL :
コメント :
パスワード :
管理者にだけ表示を許可する
 
トラックバック
この記事のトラックバックURL
Template designed by アクセラと+αな生活

Powered by .
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。