Kouhei Sutou
kou****@clear*****
2015年 9月 30日 (水) 22:38:53 JST
須藤です。 In <20150****@domai*****> "[groonga-dev,03518] Re: Mroonga で data truncated for primary key column: <id> が発生する" on Mon, 28 Sep 2015 20:30:00 +0900, 各務 洋 <kagam****@outwa*****> wrote: > いずれにせよ、grndb recover での修復は難しいようでした。 そうですねぇ。UNIQUE KEYのときは（Groongaの）インデックスカ ラムだけでなく（Groongaの）語彙表も作りなおさないといけない のでgrndb recoverでは手に追えないです。grndb recoverはインデッ クスカラムの作りなおししかできないのです。 > （lock_clear するとご教示いただいた通りロック残留が無くなって、 > grndb check で検知できなくなるだけのようです） はい、そうです。 > 検知できたら ALTER ENGINE かなぁと考えていますが、何か他の案もいただけ > ると幸いです。 テーブルの内容を全コピーして作りなおしているということですよね。 UNIQUE KEY以外ならALTER TABLE DISABLE KEYSしてからALTER TABLE ENABLE KEYSすればよいのですが、UNIQUE KEYはその技を使 えないんですよねぇ。 UNIQUE KEYを1つずつALTER TABLE DROP INDEXしてALTER TABLE ADD UNIQUE INDEXしなおしていけば直って、全コピーよりは速いのです が、面倒ではあります。 > 要望： > ・Mronnga が壊れにくくなって欲しい。 > ・壊れても自動復旧して欲しい。 うーん、処理中にクラッシュしたら壊れるので前者はムリです ね。。。 後者は（Groongaレベルではなく）Mroongaレベルで処理の途中でク ラッシュしていたらインデックスを作り直す、というのはできそう です。 Groongaが「ロックが残留しているか」で処理途中かどうかを判断 できるみたいに、Mroongaでも処理のはじめに印を残して、処理が 終わったら印を消す、起動時に印が残っていたら途中でクラッシュ したはず、という仕組みを入れれば壊れていそうかどうかを検出で きそうです。 ロックをするのは性能が落ちそうなのでやりたくないので、内部に 管理用のGroongaのテーブルを用意して、処理を始めるときにレコー ドを追加、処理が終わったら作ったレコードを削除、起動時にその テーブルが空じゃなかったら壊れていそう、とすればいけそうな気 がします。 壊れていそうだったら勝手にインデックスを再構築する処理が走る （データが多いと多少時間がかかりそう）のってアリですか？ -- 須藤 功平 <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/
