[groonga-dev,03583] Re: Mroonga_で_data_truncated_for_primary_key_column: <id> が発生する

Back to archive index

Kouhei Sutou kou****@clear*****
2015年 10月 20日 (火) 19:25:14 JST


須藤です。

In <20151****@domai*****>
  "[groonga-dev,03579] Re: Mroonga_で_data_truncated_for_primary_key_column: <id> が発生する" on Mon, 19 Oct 2015 11:48:48 +0900,
  各務 洋 <kagam****@outwa*****> wrote:

>>> という事は、Mroonga側の対応を待ってからの方が良さそうですね?
>> 
>> 開発者側としては一気に確認してもらうより、1つずつ確認しても
>> らった方が助かります。理由はどの変更が効果があったかがはっき
>> りするからです。
> 
> 了解しました。では、
> 
>> 「更新中にクラッシュした場合に
>> ユニークキーにしたカラムが重複したレコードが登録される可能性
>> がある」という挙動はリリース版と変わっていないという点です。
> 
> Mroonga 側のこちらを留意して、
> 
>> 注意してほしい点は、この修正では、「削除しながらレコードを追
>> 加するとプライマリーキーが同じレコードが複数見える可能性があ
>> る」という問題が直る
> 
> この点を確認してみます。

ありがとうございます!

>> Mroonga側にも対応を入れてみました。
>>   http://packages.groonga.org/tmp/mysql-community-mroonga-5.09-2.el6.x86_64.rpm
> 
> その後、↑を適用すると、留意していた点も解消しているという想定でよろし
> いでしょうか?

はい。

>> 念のため、改めて書きますが、これはInnoDBのようにどんなときに
>> クラッシュしてもレカバリーできるものでは「ありません」。新規
>> レコード作成中とレコード削除中にクラッシュしたときにリカバリー
>> できる「可能性が増える」だけです。
>> 
>> たとえば、Groongaレベルでの更新処理中にクラッシュして、デー
>> タが入っているテーブルにロックが残ったときはリカバリーできま
>> せん。
>> 
>> なにがあってもなくなってはいけないデータを扱うときは、バック
>> アップをとったり(mysqldumpでもいいですし、レプリケーション
>> で別マシンに随時コピーでもいいです)、元データを保存しておい
>> たりして、Mroongaがクラッシュしてデータベースが壊れてしまっ
>> たときに復旧できる運用にしてください。
> 
> これは是非ともドキュメントに記述が欲しい点だと思いました。

私は12月頭くらいまで手が回らなそうな気がするので、だれか、
Qiitaなり見つけやすい場所に書いておいてもらえないでしょう
か。。。公式ドキュメントに入れるように頑張るのは敷居が高いと
思うので、自分が書きやすい場所で樹分だと思います。

> 上記はストレージモードの事だと思うのですが、ラッパーモードではいかがで
> しょうか?

ラッパーモードの場合でもいつでもリカバリーできるわけではあり
ません。可能性が増えるだけです。たとえば、DB自体が開けないく
らい壊れている場合はリカバリーできません。

インデックスが壊れているだけなら自動でリカバリーします。

> 但し、私の環境では今までの所、
> 
> A.unique index を外した table schema をコピーして、INSERT INTO SELECT 
>   で流し込んだ後に、unique index を張りなおす。
>   Duplicate のエラーがでたら除外する。
>   解決できたら table を rename して差し替える。
> 
> B.ALTER TABLE テーブル名 ENGINE Mroonga を実行する。
>   Duplicate が出たらA.と同じ
> 
> このいずれかの方法(といっても同じような事ですが)で実運用上で復旧可能
> でした。

情報共有ありがとうございます。
このケースでは一連の変更でDuplicateはでなくなると思います。

> (あと、最悪 Mroonga テーブルが全損しても Innodb テーブルから再構築で
> きる形にはしてあります。……時間は読めませんが。)

データをロードした後にインデックスを構築するようにするとロー
ド時間は短くなると思います。

> 別件ですが、今回確認していてまったく復旧できない事がありました。
> grndb recover の実行と disk full 状態が共に発生した際に、
> 
> grndb recover 
> groonga で接続
> mysql で use 
> 
> disk full を解消しても、いずれの方法でも全て応答が無くなる現象が発生し
> ました。(完全に復旧不能だったのはこれが初めてです)
> レアケースだと思いますが、ご報告まで。

ありがとうございます。
ディスクフルになったら復旧は無理だと思ったほうがよいと思いま
す。中途半端に書き込まれたデータがいろんな所にでている可能性
がかなり高いからです。

-- 
須藤 功平 <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/




groonga-dev メーリングリストの案内
Back to archive index