Mroongaの開発をしている須藤です。
2013年に書かれたgroonga/mroongaの.mrnファイルがlock failedとなった場合の復旧方法 - Y-Ken Studioという記事があるのですが、この記事に書かれているようにclearlockを使ってはいけません！
Mroongaは更新中（INSERT/UPDATE/DELETE中とかスキーマ変更中とか）にクラッシュすると更新の前に獲得しておいたロックがDB中に残留してしまい、再起動後にロック待ちで固まってしまいます。このとき、groonga.logにはlock failedというようなログが残ります。
前述の記事にはこんなときはselect mroonga_command('clearlock')して復旧できると書かれているのですが、基本的にclearlockはしないでください！
ロックが残留しているということは更新処理が中途半端になっている可能性が非常に高いです。これはデータがおかしくなっている可能性が非常に高いということです。clearlockするとこのおかしくなっている状態で使い続けることになるので、使えるようになったと思ってもすぐにまたクラッシュする・検索結果がおかしくなるといったことが発生しやすいです。
では、どうすればよいかというと、一旦MySQLを止めてgrndbコマンドを使います。grndbコマンドはMroongaのDBがどう壊れているかを確認したり、壊れているDBを復旧したりできます。
grndbコマンドはDebian/Ubuntuならgroonga-binパッケージ、CentOSならgroongaパッケージに含まれています。
大事なことなのでもう一度書いておきますが、grndbコマンドを使うときはMySQLを止めてください。MySQLを止めないと誤検知したり、逆にDBを壊してしまうこともあります。
grndbコマンドを使うときは次のことに注意してください。
- MySQLを動かしているユーザーと同じユーザーで実行する。（たとえば
mysqlユーザー。） --log-pathで確実にログを記録しておく。
たとえば、MySQLのデータディレクトリーが/var/lib/mysql/でデータベース名がdbなら次のようにDBがどう破損しているかをチェックできます。どのように破損しているかはgrndb checkの出力あるいはログを確認してください。
$ sudo -u mysql -H grndb check --log-path /tmp/grndb.check.log /var/lib/mysql/db.mrn
自動で復旧できる場合はgrndb recoverで復旧できるというメッセージが残っています。自動で復旧できない場合は手動での復旧方法が残っています。
ざっくりいうと、インデックスのみが壊れている場合は自動で復旧でき、データが壊れている場合はバックアップからの復旧になります。インデックスのみが壊れている場合はどうして自動で復旧できるのかというとインデックスを再構築するためのデータがDB内にあるからです。データが壊れている場合はDB内に正しいデータがないので自動で復旧できないのです。
自動で復旧できる場合はgrndb recoverの実行方法がメッセージとして残っているはずです。次のようなコマンドラインになるはずです。
$ sudo -u mysql -H grndb recover --log-path /tmp/grndb.recover.log /var/lib/mysql/db.mrn
自動で復旧できない場合はバックアップから復旧してください。たとえば、mysqldumpしておいたデータをリストアします。
復旧したらMroongaのissueにクラッシュしたことを報告してください。報告してくれないと開発者（私とか）が問題に気づいていないため、問題が直りません。問題が直らないと再発する可能性があるため運用の負荷が下がりません。
多くの場合、問題を再現できれば数時間から1日くらいで問題を修正できます。問題が収載されれば再発に怯えなくてすみます。（万が一、別の問題でクラッシュしたときのためにバックアップをとることはやめないでください。）
問題を報告するときは次の情報を添付してください。
- MySQLのバージョン
- Mroongaのバージョン
- Groongaのバージョン
- OSの名前
- OSのバージョン
- MySQLのエラーログ（特にバックトレースが見たい）
groonga.log（特にバックトレースが見たい）
必要に応じて追加の情報（たとえば問題が発生するデータ）をお願いすることもありますが、基本的にやりたいことは「問題を再現する」ことです。問題を再現できれば直せるからです。なお、問題を再現できればよいので実際に問題が発生したデータでなくても再現用に作成したテストデータでも大丈夫です。
公開の場で情報を提供できない場合はGroongaサポートサービスの申込みを検討してください。NDAを結んだ上での情報提供が可能になりますし、優先して修正します。
できるだけ安心してMroongaを使えるように日々開発を進めています。たとえば、先日リリースしたGroonga 11.0.3でもクラッシュにつながる問題を1つ修正しています。この問題は、Mroongaを使っているユーザーに報告してもらい、再現できたので修正できました。次のMroonga 11.04ではクラッシュ時の悪影響が大きいmroonga_enable_operations_recordingがデフォルトで無効になる予定です。今年の後半には、クラッシュ時にデータが壊れた場合でもできるだけ自動で復旧できるような機能を実装する予定です。Mroongaをより安心して使えるようにするためにユーザーのみなさんに協力してもらえると助かります！
ところで、今日リリースしたMroonga 11.03以降へのアップグレードは重大な注意点があるので、必ずアップグレード前に確認してください！！！（11.02以前から11.04とかへのアップグレードでも影響があります。）
