💾
Misskeyの自鯖を破壊してDBロールバックして復旧することになった話
経緯
前提
- 構成はWindows11上のHyper-V VM→Ubuntu 22.04→MicroK8s
- 本Misskeyインスタンスと同一のVM上にMicroK8sのクラスタを用意して、移行しようとした
- もともとはWindows11上のHyper-V VM→Ubuntu 22.04→docker(compose)で稼働していた。移行作業中は停止
事故当時の状況
- 行き先がローカルのストレージになるPersistentVolumeを設定し、PostgreSQLクラスタのデータ保存先にした
- そこに対してkubectlの機能を使ってport-forwardしたうえで、pg_restoreしてDBの復元を実行した
pg_restore -h 127.0.0.1 -U misskey -d misskey -Ft ./db/231230-0726.tar
起きたこと
- pg_restoreから下記のようなエラーが出た(一部)
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 4653; 1259 22037 INDEX IDX_171e64971c780ebd23fae140bb misskey
pg_restore: error: could not execute query: ERROR: invalid page in block 6273 of relation base/16385/17439
- VMからの応答がなくなる
- Hyper-V管理画面からも状態が
オフ-重大
となり、仮想マシンの構成記憶域に接続できなくなった
- 同時に、当該VMの仮想HDDが配置されていた物理SSDにもアクセスができなくなった
- ホストPCの再起動後、当該SSDへのアクセスは復活したが、VMは変わらず起動しないままであった
試したこと
当該VMに接続されていた仮想HDDを別のVMにアタッチし、復元を目指す
当該VMのチェックポイントには、8月17日時点の1つが存在していた
最新のデータが入っていたavhdx
をアタッチし、復活を試みる
- ファイルシステムが破損していたため、fsckでの復活を目指す
- 移行時に使用したダンプファイルが取り出せたため、こちらを利用したdbリストアを試すも、ファイル自体も破損していたのか失敗した
チェックポイントが取られた時点でのvhdx
をアタッチし、復活を試みる(解決)
- ファイルシステムに問題はなかったため、dbコンテナの起動とダンプをした
- デプロイ対象VMからscpコマンドを利用してダンプファイルを転送した
- デプロイ対象VMでdbコンテナを上げ、手動で下記のようにしてリストアし、成功した
\i /path/to/your/dumpfile.sql
対策
定期バックアップ
当然中の当然のこと、いい加減やります、、、
また、ダンプファイルがVMと物理的に同じディスクにあるのもマズいので、rcloneか何かでWasabiに上げるようにする
チェックポイント作成
今回これに救われた
定期的に取るようにする
Kubernetesクラスタはそれ専用にマシン用意する
多分これもある
あれこれ兼用するとdockerコンテナ立ち上げるたびにクラスタ内のpod全滅したり全滅したりします(すでに怪しい
Discussion