先日、朝メールをチェックすると以下のような見慣れないメールが来ていました。
** Health check alert! **
-- バックアップが取れていません 2020-02-22 --From: を見るとEY-Officeで開発、メンテナンスしているECサイトからです。思いおこすと、バックアップが出来ているかチェックする機能を作ったような気がします。コードを見ると確かに、1年くらい前に作りました。
バックアップ作成チェック機能
クラウドでもサーバーは故障します。大規模なサイトであれば、サーバーやデータベースを複数用意して冗長化し、サーバー等の故障が起きても運用できるような構成にすると思います。
しかし小規模なサイトは冗長化されてはいませんので、サーバーが故障した際の復旧にはバックアップが生命線です。
クラウドなのでリージョン全体が故障してなければ、サーバーを新規に作成し、バックアップからデータベースやその他を復旧すれば、バックアップ時点の状態に戻れます。
しかしバックアップが取れてなかったら・・・
ECサイトなので、商品や在庫の情報は運営会社のシステム等から復帰できます(場合によっては完全には戻らないかも知れませんし、古い情報に戻ってしまうかも知れません)が、登録されたお客様情報は無くなってしまいます。過去の販売情報なども無くなってしまいます。
実は1年前バックアップスクリプトを少し変更してから、数日間バックアップが取れて無かった事がありました。たまたま S3 にあるバックアップを見て最新のバックアップファイルが無い事に気が付き、血の気が引きました。
そこで定期的にS3にバックアップがあるかを確認するコードを追加しました。それが1年後に、バックアップが無いのを発見しアラートを送ってきたのでした。
なぜアラートが発生したのか
なぜアラートが発生したのか？
データベースには PostgreSQL9.5 を使っています(古いですね…バージョンアップしないとね)。バックアップは pg_dumpall コマンドでDB内容をダンプし、圧縮してから aws コマンドで S3 に転送しています。
バックアップのログを見ると 以下のようなエラーが出ていました。
/usr/bin/pg_dumpall -U postgres
server version: 9.5.18; pg_dumpall version: 9.3.20
aborting because of server version mismatchデータベースサーバーのバージョン 9.5 なのに、 9.3バージョン用の pg_dumpall が実行されています !!
調べてみると、
$ ls -l /usr/bin/pg_dumpall
lrwxrwxrwx 1 root root 37 7月 17 2018 /usr/bin/pg_dumpall ->
../share/postgresql-common/pg_wrapperpg_dumpall(pg_dump, pg_restore等も)コマンドは perlで書かれた pg_wrapper を経由して /usr/lib/postgresql/9.5/bin/pg_dumpall 等のバージョン毎のコマンドを起動しています。
なぜか、現在は /usr/bin/pg_dumpall を実行すると /usr/lib/postgresql/9.3/bin/pg_dumpall が実行されています！
pg_wrapper の中では色々な設定ファイルや環境変数等をチェックしながら実行するコマンドを調査しています。昨日 2時間程度コードを読んだ時点では、なぜ 9.3 バージョンが選択されてしまうのか判りませんでした。
本番サーバーは昔 9.3 から 9.5 にバージョンアップしたので 9.3 も残っています。本番サーバーで手荒な事は出来ないのですが、スーテージングサーバーには 9.5 か入ってないので再現事件が出来ません。
バックアップが取れないのは困るので、バックアップスクリプトは /usr/lib/postgresql/9.5/bin/pg_dumpall を起動するように書き換えてバックアップは取れるようにしました。
問題解決のためには、作戦を考えて、アクセスの少ない時間に調査・対応したいと思います。
