GitBucketのH2データベースがまた壊れた

便利に使わせていただいております。

批判だなんてとんでもないこってす。そんな意図は毛頭ございませんので念のため。

私が悪いんです。

前置きです。

久しぶりにGitBucketを更新する衝動にかられました。

4.31.2から4.36.2です。

過去の例から絶対何か起きるな、という確信がありました。

だから、全然ちっとも悔しくなんかないんだもん。

今回は4.36.2にwarを置き換えたとたんにこんな感じです。

19:12:49.124 [main] ERROR com.zaxxer.hikari.pool.HikariPool - HikariPool-1 - Exception during pool initialization.

org.h2.jdbc.JdbcSQLException: テーブル "REPOSITORY" が見つかりません

で。4.31.2に戻しても

Caused by: 

com.zaxxer.hikari.pool.HikariPool$PoolInitializationException: Failed to initialize pool: テーブル "REPOSITORY" が見つかりません

だそうで。

4.36.2がテーブルをぶっ壊してくれるみたいですね。
そのため、4.31.2に戻しても後の祭りと。

すげえなあ。後方互換などには目もくれぬ未来しか見つめない設計思想。まさに聖帝サウザーばりですね。「ひかぬ。媚びぬ。顧みぬ。」でしたっけ。

多分4.31.2からリリース順にリプレース/起動/停止を繰り返してアップグレードすれば問題ないんでしょうね。思いついたときにドーンと更新した私が悪うございます。

この事例は以前もありましたので、もうこれ使うのやめたいなあと思っていながら惰性で使い続けたのも自業自得。

使うのをやめるつもりだったので、GitBucket専用の設定ファイル類のバックアップはとってませんでした。これも自業自得です。

ところで、タイトルにはH2データベースが壊れた、としましたが、この様子だと、GitBucketさんはH2データベースを信頼性がない云々で目の敵にしておいでですが、H2だから壊れたんじゃなくてGitBucketさん自身がぶっ壊しているようにしか見えません。
まあ、私が確認した範囲内ではH2データベースが壊れたのでタイトルはそのままにしておきます。

まあ、さっき新規プロジェクトをコミットしたばっかなので、その辺復旧できるなら復旧したいなあということで、試みてみました。
この際、懸案だったGitBucketから別のシステムに移行する手間か、単純にこの場は復旧だけしておいて済ませるか、多少考えないではありませんでしたが、結局やっつけで済ませられるほうを選びました。

まず、H2データベースのダンプを試みます。

H2公式から1.4.200をダウンロードしてみたところ、ファイルポインタがどうのこうのでさっぱり使えません。

何を言ってるのかわからないので早速検索をしたところ、199を使わないとダメなんだそうで。

なんなんだそろいもそろってjava業界って・・・未来しか見えてないのね。

ちゃっちゃとおわらそう。

java -cp h2-1.4.199.jar org.h2.tools.Shell -url  jdbc:h2:file:data -user sa -password sa

で中身をのぞこうとしても

「org.h2.jdbc.JdbcSQLException: テーブル "REPOSITORY" が見つかりません」

この段階でDB全体の整合性が整っていることが必要なのね。

ウームと唸って、さらに探すとRecoverというツールがあるらしいので助かりました。
カレントディレクトリにdata.mv.dbがある前提で

java -cp h2-1.4.199.jar org.h2.tools.Recover

と実行すると、data.h2.sql とdata.h2.txtという2ファイルが生成されました。

そこで、data.h2.sql をさっそくのぞいてみると、O_??(数値)というあからさまにテンポラリな名前のテーブルがいくつか作られていました。

そして、そのテーブルに対してINSERTが発行されています。

さて、このO_で始まるテーブルは何なのかな？と思って、よくよく調べてみると、スクリプトの後半で本来のテーブルと思しきテーブルにinsert from selectしてました。

なるほど、制約条件の整合性対策なんだろうな、と納得した次第です。

で、確かに、テーブル "REPOSITORY"はありません。

その代わり、REPOSITORY_COPY_3_3っちゅーのが見つかりました。

なーんだかよくわかんないですけど、こーゆー名前のつけかたって、多分、ver3.3のころにアップグレード処理を入れた名残なんでしょうかね。

あれ?でも、これ、insert文にさっきgitにcommitしたばかりのはずのリポジトリ名も入ってる・・・

わけわかんないけど、これに対してinsertしているのをテーブル "REPOSITORY"に向けなおしときました。

ついでに、カラムが追加されてるテーブルがあり、insert文が通りませんでした。
そこで、4.36.2で新規作成した空のデータベースファイルをダンプして比較したところ、create table文にカラムが追加されており、default trueとか書いてあったのでinsert文の該当カラムにtrueを追記しておきました。

そして、それらテーブル名とカラムの追加を行ったinsert文をh2-1.4.199.jarではなくGitBucketの管理コンソールの「Database viewer」なる機能から流し込んでみたところ、見た目は復旧出来たっぽいのでもう終わりにします。

H2公式ツールを使わなかった理由は、二つあります。

いくら公式だからってh2-1.4.199で読めてh2-1.4.200で読めなくなるようないい加減なツールなんかおっかなくて使いたくないし、GitBucket自身が何を使ってんのか知らないのでこのプログラム自身が使ってるライブラリでDBをいじらないとまた七面倒なことが起きそうだと思った次第です。

ま。こんな感じです。

更に次回、やっぱり惰性で使い続けて似たようなことが起きた場合に備えて忘備録としたいと思い記録しました。なお、cronでバックアップする元をリポジトリ以外にGitBucketの設定定義体も念のため加えておきました。GitBucketを廃止したらこれを忘れずに除去しなくてはならないのが今からおっくうです。

こんな戯言にお付き合いいただき、誠にありがとうございました。