各務 洋
kagam****@outwa*****
2015年 11月 9日 (月) 13:48:28 JST
お世話になります、各務です。 >>>> 1.今回のテストパターンで再現可能だと思いますので、破損する根っこを調査 >>>> いただくのは可能でしょうか？ >>> >>> 「再現可能」という「Groongaレベルのロックが残る」ケースのこ >>> とであっていますか？ >>> >>> 「Groongaレベルのロックが残る」ケースがおこるパターンはわかっ >>> ていて、Groongaのテーブル・カラムを更新中にkillされると発生 >>> します。 >>> >> >> 今回のご報告の元々の起点は、mysqld の再起動が行われていない環境で発生 >> しているのです。 > > この「発生」しているものは[groonga-dev,03515](*)で報告しても > らった > >> UPDATE 文発行時に warning で data truncated for primary >> key column: <id> が発生します。 > > のことであっていますか？ > > (*) https://osdn.jp/projects/groonga/lists/archive/dev/2015-September/003518.html > > で、これが発生した時はmysqldはクラッシュしていなかったという > ことであっていますか？ > > > それとも、「発生」しているものは[groonga-dev,03518](*)で報告 > してもらった > >> ・unique 制約のある a_id に 0 が入ったり、10001 が無くても >> duplicate insert と言われる。 > > の方ですか？ > > (*) https://osdn.jp/projects/groonga/lists/archive/dev/2015-September/003521.html 混乱させてしまったら申し訳ないのです。 元々の環境（本番環境）では両方とも起きているのです。 [groonga-dev,03219] 対応後ですので、これの別パターンというか、もう一 つ深いところで index が不整合になるパターンがあり、いずれもそれが理由 で発生しているのかな、という印象なのです。 >>>> 2.復旧できない（テーブルを作りなおすしかない）際は、自動でテーブルを作 >>>> りなおす、復旧の自動処理化は可能でしょうか？ >>> >>> 残念ながらできません。 >>> というのは、復旧処理はケースバイケースだからです。 >> >> 実はここの返答を悩んで何度も書き直しているのです。。。 >> ですので率直に申し上げると。 >> >> これで良くなりそうなので、もうちょっとできないでしょうか？ >> >> なのです。 >> >> 須藤さんは最悪のケースの厳密なところまで考えていただいていると思うので >> すが、現時点ではまだそこまでいかなくても良いのかなと思っています。 > > すみません、Mroongaがやってくれると楽だなぁと思うのは理解で > きるのですが、アプリケーションレベルの情報がないと判断できな > いことをMroongaが「勝手に」やると困るユーザーがでる（もしか > したらデータがもっと壊れるかもしれない）のでそれをMroongaに > 入れることはできないのです。 ご検討いただいてありがとうございます。 了解しました。 私の環境では、須藤さんのお勧めの通りマスターデーターがある状態ですので テーブルが壊れていなければ影響はかなり限定的にできるのです。 （テーブルが更新できなくなれば顛末書とか再発防止策とかぁぅぁぅと……） このようなユーザーもいるとだけ覚えていただければ幸いです。 > ただ、更新しているカラムが複数ある場合は一部のカラムだけが更 > 新されているというケースがあり、そのときはALTER TABLEしても > 中途半端に更新された行（更新されたカラムとそうでないカラムが > まざった行）は復旧できません。 これは future なのですが、壊れたのが分かる処理ができると良いなぁと思う のです。 期待する行結果の hash 値を先に作って、後で評価するとか。 >>>> 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 以外で検出したいのです。 > > SELECTでもこのエラーは発生するので > > SELECT id FROM tbl_test_pat_0005 LIMIT 0; > > でも検出できます。他のプロセスから↑を実行することでどうにか > できないでしょうか？ ありがとうございます、ただこれは 当該 SELECT が auto_repair を発動させ た時だけ返るのではないでしょうか？ SELECT は他のプロセスで常時発生しているので、これだと検知が難しいので す。 ---- 各務 kagam****@outwa*****
