Kouhei Sutou
kou****@clear*****
2015年 10月 1日 (木) 22:05:33 JST
須藤です。 In <20151****@domai*****> "[groonga-dev,03533] Re: Mroonga で data truncated for primary key column: <id> が発生する" on Thu, 01 Oct 2015 16:50:11 +0900, 各務 洋 <kagam****@outwa*****> wrote: > 状況の再現が難しいのでクラッシュさせていますが、io の collisions の際 > もあやしいのかなぁと思っているのです。 書き込みが集中しているときということですね。 > 回数は少ないのですが、Groonga 上でもまったく同じものが2行入っている > レコードを確認できました。 > >> select --table tbl_test_pat_0005 > [[0,1443683784.70987,0.0669431686401367],[[[2],[["_id","UInt32"],["_key","Int64"],["a_id","Int64"],["id","Int64"],["t1_date","Time"],["t2_date","Time"],["t_text","LongText"]] > ,[1,3918,10002,3918,1443598148.0,0.0,"t10002"],[1,3918,10002,3918,1443598148.0,0.0,"t10002"]]]] あぁ、完全にgrn_patが壊れていますね。。。 森さん、_grn_pat_add()の中でio_lockせずに pat->header->n_entriesとかを変更しているんですが、これって意 図的ですよね？複数スレッド・プロセスから同時にaddすると壊れ ることがありそうな気がしたんですが。。。 >> 後者は（Groongaレベルではなく）Mroongaレベルで処理の途中でク >> ラッシュしていたらインデックスを作り直す、というのはできそう >> です。 >> >> Groongaが「ロックが残留しているか」で処理途中かどうかを判断 >> できるみたいに、Mroongaでも処理のはじめに印を残して、処理が >> 終わったら印を消す、起動時に印が残っていたら途中でクラッシュ >> したはず、という仕組みを入れれば壊れていそうかどうかを検出で >> きそうです。 > > これ、良いと思います。 では、この方向で検討します。 >> ロックをするのは性能が落ちそうなのでやりたくないので、内部に >> 管理用のGroongaのテーブルを用意して、処理を始めるときにレコー >> ドを追加、処理が終わったら作ったレコードを削除、起動時にその >> テーブルが空じゃなかったら壊れていそう、とすればいけそうな気 >> がします。 > > もっと贅沢をいうと、試みて失敗して滞留した内容と、Groonga 上の最後の処 > 理がトランザクションIDのようなもので突合せ可能であれば、レコード単位で > 影響を処理できて、クラッシュリカバリ時のコストが減らせるような気がしま > した。 いやぁ、インデックスがどのくらい壊れているかわからないので インデックスは常に全部再構築になります。 追加中のレコードは削除、 更新中のレコードは復旧不可です。 変更前の値もキープしておけば更新中にクラッシュした場合でも復 旧可能ですが、性能を落としてそこを頑張るかどうか。。。 （どのくらい落ちるかわかりませんが。。。） > で、対象が分からない際は、テーブル単位でざっくりとですねぇ。 > （これは Replication の Slave 側はどのようになるのでしょうか？） マスターがクラッシュした場合ですか？ レプリケーションが切れるだけでスレーブのデータは壊れないと思 います。 -- 須藤 功平 <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/
