各務 洋
kagam****@outwa*****
2015年 11月 6日 (金) 18:38:39 JST
お世話になります、各務です。 >> 1.今回のテストパターンで再現可能だと思いますので、破損する根っこを調査 >> いただくのは可能でしょうか？ > > 「再現可能」という「Groongaレベルのロックが残る」ケースのこ > とであっていますか？ > > 「Groongaレベルのロックが残る」ケースがおこるパターンはわかっ > ていて、Groongaのテーブル・カラムを更新中にkillされると発生 > します。 > 今回のご報告の元々の起点は、mysqld の再起動が行われていない環境で発生 しているのです。 kill はあくまでもこの事象に近いと思われるものを手早く起こすために行っ ているもので、それ以上のものではないのです。 残念ながら私の方では実際の環境で起きている事象と kill で発生する事象が 同一かは分からないのですが、「Groongaレベルのロックが残る」という点が 発生しうるパターンは他に何か無いでしょうか？との投げかけだとご理解いた だければと思います。 >> 2.復旧できない（テーブルを作りなおすしかない）際は、自動でテーブルを作 >> りなおす、復旧の自動処理化は可能でしょうか？ > > 残念ながらできません。 > というのは、復旧処理はケースバイケースだからです。 実はここの返答を悩んで何度も書き直しているのです。。。 ですので率直に申し上げると。 これで良くなりそうなので、もうちょっとできないでしょうか？ なのです。 須藤さんは最悪のケースの厳密なところまで考えていただいていると思うので すが、現時点ではまだそこまでいかなくても良いのかなと思っています。 ALTER TABLE で問題なく直ると思うのです〜。 >> 3.復旧できないパターンの際、目印となるログ出力は可能でしょうか？ > > ログではないですが、[groonga-dev,03626]で連絡したバージョン > にはすでに入っていて、接続時に接続エラーになります。 ありがとうございます。 ERROR 145 (HY000) at line 1: mroonga: repair: failed to delete an incomplete record: [56454]: <tbl_test_pat_0005>[207]: <>(-22) でしょうか？ この点、実は 100% 私のわがままが入っています。 元々 INSERT 時に Duplicate が返ってくれば、それをトリガーにすれば良い のですが、PHP でのエラー処理上に若干の（以下、涙で何故か読めない） があり、出来れば PHP 以外で検出したいのです。 >>> 1. このまま。何もしない。エラーが起こったら報告する。 >>> 2. 標準出力に書けなくなったらそこで処理を終わって終了する。 >>> 3. 標準出力に書けなくなったら出力だけやめて処理は全部やって終了する。 >> >> 標準出力で書けなくなっても続行可能な処理というのが思いつかなかったです……。 > > grndb recoverのときは処理の途中経過を標準出力に報告しながら > 復旧処理を進めるので、途中経過を報告しなければ処理は進められ > るのです。 なるほど、では結果良好な可能性があるのであれば 3.かなぁと思いました。 >> あ、でも、もしかしたらこれを直したら変な挙動になりにくくなる >> かも。。。ちゃんとエラーチェックするようにします。 > >エラーチェックするようにしました。 > >ファイル名は同じで↓です。 > http://packages.groonga.org/tmp/mysql-community-mroonga-5.10-1.el6.x86_64.rpm groonga.log 上、io の collisions と [DB Locked] time out が出続けなく なったと思います。 ---- 各務 kagam****@outwa*****
