Kouhei Sutou
kou****@clear*****
2015年 10月 19日 (月) 00:05:29 JST
須藤です。 In <20151****@domai*****> "[groonga-dev,03576] Re: Mroonga_で_data_truncated_for_primary_key_column: <id> が発生する" on Fri, 16 Oct 2015 19:42:09 +0900, 各務 洋 <kagam****@outwa*****> wrote: >> ↓に今のmaster用のRPMを作りました。 >> http://packages.groonga.org/tmp/groonga-libs-5.0.9-1.el6.x86_64.rpm >> >> もし、groonga-libs以外にも使っているパッケージがあれば同じディ >> レクトリーにあるのでファイル名に「5.0.9-1.el6.x86_64」が入っ >> ているファイルを探してください。 > > ありがとうございます！ > >> これは、まだMroonga側にそのケースに対応するコードが入ってい >> ないからです。 > > という事は、Mroonga側の対応を待ってからの方が良さそうですね？ 開発者側としては一気に確認してもらうより、1つずつ確認しても らった方が助かります。理由はどの変更が効果があったかがはっき りするからです。 Mroonga側にも対応を入れてみました。 http://packages.groonga.org/tmp/mysql-community-mroonga-5.09-2.el6.x86_64.rpm クラッシュリカバリーが動いたときはgroonga.logに"Auto repair is done"というログがでるようにしてありますが、手元で試した範 囲では一度も発動しませんでした。あまり効果がないかもしれませ ん。 念のため、改めて書きますが、これはInnoDBのようにどんなときに クラッシュしてもレカバリーできるものでは「ありません」。新規 レコード作成中とレコード削除中にクラッシュしたときにリカバリー できる「可能性が増える」だけです。 たとえば、Groongaレベルでの更新処理中にクラッシュして、デー タが入っているテーブルにロックが残ったときはリカバリーできま せん。 なにがあってもなくなってはいけないデータを扱うときは、バック アップをとったり（mysqldumpでもいいですし、レプリケーション で別マシンに随時コピーでもいいです）、元データを保存しておい たりして、Mroongaがクラッシュしてデータベースが壊れてしまっ たときに復旧できる運用にしてください。 -- 須藤 功平 <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/
