はじめに
個人で運営しているMisskeyインスタンスのDBを破壊→リストア、最終的にどうにもならずサービス終了させた話です。
LinuxのCUI操作は3年ほど行っており、Misskeyのインスタンス管理にも慣れてきたと思い込んでしまったのが全ての始まりです。
思い込みから発生した完全な人為的ミスの記録+懺悔をします。
何が起きた？
バックアップスクリプトを再設定中にディレクトリ名を変更
MisskeyをDocker Composeで運用している中でデータベースのバックアップスクリプトを再設定していました。
その過程で、
-
docker compose downしないまま - Misskeyディレクトリ名を変更
してしまいました。
この時点ではまだMisskeyは通常稼働していました。
ディレクトリ名変更後にpg_dumpを実行
ディレクトリ名を変更した状態でPostgreSQLのバックアップ(pg_dump)を実行していました。
ここで今思えば明らかな異変がありました。
スクリプトがいつまで経っても終わらない
しかし当時の私は呑気なもので、ネットワークの不具合で遅いだけだろうと思っていました。
実際に発生していたエラー
WARNING: could not write block 13622 of base/16384/16652
DETAIL: Multiple failures --- write error might be permanent.
pg_dump: error: ERROR: xlog flush request 8/36EE4A40 is not satisfied
このエラーが意味していたこと
単なるバックアップ失敗ではなく、
ログをディスクに書き込もうとしたがOSレベルで書き込みに失敗している状態でした。
この時点で既にDBは既に正常に動作できない状態になっていました。
更に致命的な状況
正常時のバックアップが存在していなかった
正常時のバックアップデータが存在しない状態で一連の作業を行っていたため、
残っていたバックアップは
- エラー発生後に作成したデータのみ
- 復旧直後は一部のデータしか存在しなかった
という状況でした。
その後行ったこと
- 残っているバックアップからの復旧
- PostgreSQLの整合性修復
結果多くのユーザーデータが見える状態までには回復しました。
しかし、
- 一部ユーザーのデータが取得できない
- ユーザーと投稿・リアクションの対応が取れない
- 欠損が特定条件のユーザーに集中している
という致命的な問題が残ってしまいました。
表示不具合ではなく、明らかに整合性が取れない壊れたDBで動いていました。
最終的にサービス終了
Misskeyの運営において、
- 一部ユーザーだけが壊れている
- 管理者が正しい状態を保証できない
- 将来のアップデートで再破損する可能性が高い
この状態での継続運用はリスクでしかないと判断しました。
そのため最終的にインスタンスを終了する判断をしました。
反省
- ディレクトリ名を変更する場合は必ず
docker compose downでコンテナを停止してから行う - 自信を持って行動しすぎない
まだまだ技術的には未熟なので、出来るようになったことも慎重に行うべきだなとかなり反省するやらかしとなりました。
日々勉強をして行動する中でも、確認を怠らず慢心せず行動しましょう。