ベースバックアップとWALログを取りましょう！
以上です！ご清聴ありがとうございました！

解説

PostgreSQLを前提に説明します。

システムを構築する際、こんな事を言われませんか？

「万が一の為、DBのバックアップを取っておいてね」

この「バックアップ」って、具体的に何のことでしょう？

非機能要件を確認しよう！

まず確認しないといけないのは、

クライアントがそのバックアップを使って「何を守ろうとしているか」

です。

これは非機能要件定義書に書かれています。

IPAが公開している非機能要求グレードに「データ復旧範囲」というメトリクスが有ります。

これに該当する項目を、非機能要件定義書から探しましょう。

え？

非機能要件定義書が存在しない？

探してください（無慈悲）

バックアップなんて要らねぇんだよ！

データ復旧範囲のメトリクスは３種の定義が有ります。

1. 復旧不要
2. 一部の必要なデータのみ復旧
3. システム内の全データを復旧

1.は正直お目にかかった事が有りません。

これで通るような要件だからそもそも非機能要件定義書が存在しないのかもしれません。

この場合、復旧を目的にしたバックアップは不要です。

バックアップは必要です

2.はIPAが補足を付けています。

一部の必要なデータとは、業務継続性の要求を満たすために必要となるようなデータを想定している。
出典　非機能要求グレード2018 改定情報～初版との差異～

しかし、クライアントによってその基準は変わるでしょう。

2.と3.が具体的にどう違うかの話は宗教学者にお任せするとして、

どちらの場合もバックアップは「全て」取りましょう。

時を戻そう

戻りたいのは、DBがぶっ壊れたその直前の状態です。

よくこういうのを聴きませんか？

「バッチで毎日バックアップを取っています！」

ヨシ！なら安心ですね！

でもちょっと待ってください。

ホントにそれは「直前」に戻れていますか？

夜中の0時にバックアップを取った後、昼の12:00に障害が発生したとしましょう。

復旧作業の依頼が来て、ﾊｲﾜｶﾘﾏｼﾀｰと言ってリストア作業を開始します。

0時時点のバックアップからリストアしたところで、0時時点にしかデータは戻りません。

0時から12時までの更新内容を戻すためのバックアップが必要です。

WALログ

PostgreSQLにはWAL（Write Ahead Log）というログが存在します。

MySQLであればredo logに相当します。

このログにはトランザクションの情報、つまりInsertやUpdate、Deleteといったクエリ単位の操作履歴が残っています。

0時のバックアップデータに加え、0時から12時までのWALログを適用する事で「ほぼ直前」までデータを戻すことができます。

おや？「ほぼ」と付きましたね？
WALログがどのように出力されるか、以下の図を見て下さい。

WALログは、レコードの操作が有った時にすぐに出力される訳ではありません。

一度メモリに格納され、設定ファイルで指定したバッファサイズを超える場合や、その他一定の条件で物理ファイルに出力されます。

発生した障害の内容によっては、
それこそ隕石が落ちてきてサーバー自体がぶっ壊れるような障害の場合は、
物理ファイルに出力出来ていないメモリ上のログは救済できないという訳です。

バックアップは地球の裏側のデータセンターに保存しよう

ん？

サーバーがぶっ壊れたんならWALログだって回収不可能ですって？

そりゃあ、バックアップを同じサーバーに保管してたら無理です。

WALログの出力については、セットアップ時に設定を行う必要が有ります。

# postgresql.conf内


wal_level=replica
archive_mode=on
archive_command= ここが重要！

pg_walディレクトリに出力されたWALログは、archive_modeを設定しない場合ローテートされます。
（つまり古い情報は消えていきます）

archiveの設定を行う事で、分割されたWALアーカイブを定期的に出力する事が出来ます。

この際、archive_commandに指定されたlinuxのコマンドが実行されるので、
それを利用し別のサーバーに送り込むことが可能です。

まとめ

１日１回、ベースバックアップを取ろう！

サーバーの負荷と相談し、出来るだけ細かくWALログを取ろう！

それはそうと

ロジカルスタジオでは、私達と一緒に働いてくれるエンジニアを、
バックアップではなくクラスターとして募集しております！

ぜひ、下記採用サイトからご応募くださいませ！