Kouhei Sutou
kou****@clear*****
2015年 11月 2日 (月) 23:08:14 JST
須藤です。 In <20151****@domai*****> "[groonga-dev,03624] Re: Mroonga_で_data_truncated_for_primary_key_column: <id> が発生する" on Mon, 02 Nov 2015 20:06:44 +0900, 各務 洋 <kagam****@outwa*****> wrote: >> また同じファイルでアレなんですが↓を試してもらえないでしょう >> か。 >> >> http://packages.groonga.org/tmp/mysql-community-mroonga-5.10-1.el6.x86_64.rpm >> >> あと、↓も一緒にインストールしてもらえないでしょうか？追加情 >> 報がでるかもしれません。 >> >> http://packages.groonga.org/tmp/mysql-community-mroonga-debuginfo-5.10-1.el6.x86_64.rpm > > 了解です、入れてみました。 ありがとうございます！ > 追加情報、出ているでしょうか？ 残念ですがでていませんでした。。。 そもそもバックトレースがでないような状況だと効果がないのかも 知れません。 > 意図しないクラッシュのタイミングが分かりました。 > grndb check を実行時に、mysqld が死ぬようです。 > 但し、通常時は発生せず、Mroonga 上の何かが詰まると発生するようです。 おぉ。 grndb checkの方が死ぬならわかるんですが、mysqldが死ぬのは妙 ですね。。。grndb checkは参照だけなのでmysqldに都合が悪いこ とはおこさないはずなですよねぇ。。 > auto repair が mysqld のクラッシュを誘発するは誤認で、一旦、grndb check > の挙動だと切り分けたいと思います。いかがでしょうか？ はい、よいと思います！ > grndb check を使わない方法に切り替えてテストしてみました。 > （45秒毎に kill ） > > 今回は、 Auto repair 発動後、 > > io(db_testh4.mrn.0000109) collisions(1000/167): lock failed 1000 times > [DB Locked] time out(30000): io(db_testh4.mrn.0000109) collisions(30000/167) > > で、Connection が張られなくなりました。 > > 以降、SELECT mroonga_command('clearlock'); > を実行するまで状況は変わらずでした。 これは意図通りの挙動です。 Groongaレベルのロックが残っているときは復旧できない（テーブ ルを作りなおすしかない）ときです。なので、このケースは諦めな いと行けないケースです。 > clearlock 後は SELECT id, a_id で > > 2015-11-02 19:15:48 0 0 > > が見えていたのですが、DELETE/INSERT を動かすと見えなくなりました。 この状態でclearlock（lock_clear）を実行した場合、その後の挙 動は不定です。どちらかというと「壊れている」と考えてください。 Mroonga（でもgrndb recoverでも）復旧できるのはこうなっていな いときです。 インデックス関連のテーブル・カラムがこうなる（ロックが残る） ときは復旧可能です。実際に自動で復旧しています。 > この後も続けているとIndex 破損を誘発しやすいのですが、ここで時間切れに > なりましたので、とり急ぎ上記まで。 この後（clearlockした後）も続けた場合はすでになにかが壊れて いる可能性が高く、その状態でおかしくなっても「しょうがないで すね。。。」というものになります。なので、clearlockしないと 再現しないという状態になるのなら十分効果が出ている（最大限の 効果が出ている）と言えそうな気がします。 > ログを下記に貼ります。 > ## groonga.log ありがとうございます！ （意図せずに）ロック獲得に失敗したエラーをちゃんと処理してい ないことに気づいたので非常に役に立ちました。 あ、でも、もしかしたらこれを直したら変な挙動になりにくくなる かも。。。ちゃんとエラーチェックするようにします。 念のため書いておくと、これは自動復旧できるようになるというこ とではありません。ロックを獲得できなくなってしまったらずっと そのままになるということです。今はロックを獲得できなくてもそ の処理をすっ飛ばして次の処理にいっています。これが変な挙動を 誘発しているのではないかという予想です。 > ## mysqld.log mysqldが静かに死んでいっているログしかないので、これは kill -KILLで殺したケースだけだと思います。つまり、Mroongaが クラッシュしていることはないということです。言い方を変えると Auto repairが原因でクラッシュしていないということです。 その状態でユニークなカラムが重複しないとかいうチェックは動い ているので、ちゃんと動いているような気がしてきました。 > P.S > grndb check で mysqld が死に続けるときに、コマンド打ち間違えたら何か出 > てきました……。 > > grndb check /var/lib/mysql/db_testh3.mrn|echo これは、grndb checkの出力が終わる前にパイプ先のプロセスが死 んでしまって、grndb checkの標準出力がなくなってしまったから ですね。 このときはどうするのがいいんでしょうねぇ。個人的には1.でもい いかなぁとは思う（問題が起こったことがわかるから）んですが、 他のやつもすぐにできるやつなので適切な方向が決まったらその方 向で変更するつもりでいます。 1. このまま。何もしない。エラーが起こったら報告する。 2. 標準出力に書けなくなったらそこで処理を終わって終了する。 3. 標準出力に書けなくなったら出力だけやめて処理は全部やって終了する。 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> Groongaベースの全文検索システムを総合サポート: http://groonga.org/ja/support/ パッチ採用 - プログラミングが楽しい人向けの採用プロセス: http://www.clear-code.com/recruitment/ コードリーダー育成支援 - 自然とリーダブルコードを書くチームへ: http://www.clear-code.com/services/code-reader/
