各務 洋
kagam****@outwa*****
2015年 10月 19日 (月) 11:48:48 JST
お世話になります、各務です。 ご返答ありがとうございます。 >>> これは、まだMroonga側にそのケースに対応するコードが入ってい >>> ないからです。 >> >> という事は、Mroonga側の対応を待ってからの方が良さそうですね？ > > 開発者側としては一気に確認してもらうより、1つずつ確認しても > らった方が助かります。理由はどの変更が効果があったかがはっき > りするからです。 了解しました。では、 > 「更新中にクラッシュした場合に > ユニークキーにしたカラムが重複したレコードが登録される可能性 > がある」という挙動はリリース版と変わっていないという点です。 Mroonga 側のこちらを留意して、 > 注意してほしい点は、この修正では、「削除しながらレコードを追 > 加するとプライマリーキーが同じレコードが複数見える可能性があ > る」という問題が直る この点を確認してみます。 > 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がクラッシュしてデータベースが壊れてしまっ > たときに復旧できる運用にしてください。 これは是非ともドキュメントに記述が欲しい点だと思いました。 上記はストレージモードの事だと思うのですが、ラッパーモードではいかがで しょうか？ 但し、私の環境では今までの所、 A.unique index を外した table schema をコピーして、INSERT INTO SELECT で流し込んだ後に、unique index を張りなおす。 Duplicate のエラーがでたら除外する。 解決できたら table を rename して差し替える。 B.ALTER TABLE テーブル名 ENGINE Mroonga を実行する。 Duplicate が出たらA.と同じ このいずれかの方法（といっても同じような事ですが）で実運用上で復旧可能 でした。 （あと、最悪 Mroonga テーブルが全損しても Innodb テーブルから再構築で きる形にはしてあります。……時間は読めませんが。） 別件ですが、今回確認していてまったく復旧できない事がありました。 grndb recover の実行と disk full 状態が共に発生した際に、 grndb recover groonga で接続 mysql で use disk full を解消しても、いずれの方法でも全て応答が無くなる現象が発生し ました。（完全に復旧不能だったのはこれが初めてです） レアケースだと思いますが、ご報告まで。 ---- 各務 kagam****@outwa*****
