DBファイルの破損等の障害が発生した際に慌てるようなことが無いようリカバリ方法を備忘録として残しておく。
H2DatabaseにはPosgreSQLの「VACUUM」のようなDBファイルのお掃除機能がないようなので、本リカバリ手順でそれと同等のことが実現できることから、長期間の運用でDBの肥大化が発生してしまった場合にも使えるものと思われる。
余談ではあるが、H2databaseの「1.4.199」というバージョンではDBファイル破損が発生するようなので、「1.4.199」を使用している人は早急に「1.4.200」へバージョンアップすることをお勧めする。
DBファイル破損の根本原因は不明ではあるが、長期間運用していると、JVMのクラッシュ等を契機にDBファイルの破損が発生することがあるようで、一度DBファイルの破損のエラーが発生してしまうと再びDBへ接続できなくなる症状に陥ってしまう。
但し、「1.4.199」でDBファイルの破損が発生しても、2020年11月時点で最新版となる1.4.200のJDBCを使って接続すると問題無く接続できるといった現象もみられることから、内部的になんらかの不整合が発生しているだけでDBファイルの破損自体は発生していない可能性も考えられる。
リカバリ用スクリプト生成(バックアップ)
リカバリ用のスクリプト(SQL)をファイル自動生成
$ java -cp h2-1.4.200.jar org.h2.tools.Script -url "jdbc:h2:file:./<DBファイル名>" -user sa -password <パスワード> -script recovery.sql
該当のDBファイルが存在しなくても、エラー等出力されずに、うまく処理されたように見えるため、出力後は必ず、recovery.sqlをエディタ等で開いて該当DBファイルのDDL(CREATE文)とDML(INSERT文)が正常に出力されていることを確認する
旧DBファイルの退避
バックアップ対象のDBファイルを任意の場所に退避し、対象のDBファイルを任意の場所に退避する。
$ mv ./<DBファイル名> /tmp/backup
リカバリ実行
$ java -cp h2-1.4.200.jar org.h2.tools.RunScript -url "jdbc:h2:file:./<DBファイル名>" -user sa -password <パスワード> -script recovery.sql -showResults
$ java -cp h2-1.4.200.jar org.h2.tools.RunScript -url "jdbc:h2:tcp://<H2DB-IP>:/./<DBファイル名>" -user sa -password <パスワード> -script recovery.sql -showResults
※「-showResults」を指定すると実行結果を標準出力に出力する
実行後、以下のようにrecovery.sqlの実行結果が表示されば成功
CREATE USER IF NOT EXISTS "SA" SALT 'XXXX・・・' HASH 'XXXX・・・' ADMIN;
CREATE SEQUENCE "PUBLIC"."SYSTEM_SEQUENCE_XXXX・・・" START WITH 385 BELONGS_TO_TABLE;
CREATE SEQUENCE "PUBLIC"."SYSTEM_SEQUENCE_XXXX・・・" START WITH 385 BELONGS_TO_TABLE;
尚、接続先に指定したDBファイルが無い場合、自動的にDBファイルが作成されてしまうので注意が必要