各務 洋
kagam****@outwa*****
2015年 5月 14日 (木) 12:18:52 JST
お世話になります、各務です。 さっそくのご返答ありがとうございます。 >> となるので、truncate する前の値で index を作成し、削除し損ねているのではないのでしょうか？ > > INSERTするときは'0000-00-00'相当の値で、DELETEするとき > は'0000-01-01'相当の値でインデックスを削除しようとして失敗し > ているような感じでした。 > > INSERTするときもMroongaが認識した値でインデックスに登録する > ようにしておけばよさそう。。。なのかしら。 これだと思います。 > ところで、手元だと > >> Error 'Data truncated for column 't_date' at row 1' on query. Default database: 'db_test'. > > というようにErrorではなくWarning扱いになっていたのですが、レ > プリケーションが切断されるのはエラー扱いになっているから、、、 > だったりするのかしら。 上のメッセージは、SHOW SLAVE STATUS で表示される方なのです。 確かにSQL実行時の方は warning なのですよねぇ。Slave側 でも格納されていますし。 my.cnf で何か変更している点があるならば、 transaction_isolation = READ-COMMITTED slave_exec_mode = idempotent ここらへんを変えていますが、関係ありそうでしょうか？ >> ---------------------------------------------------------------------- >> その他の事項： >> >> 実は、DATETIME型ではなく、TIMESTAMP型 でレプリケーションが切断されるの >> を探していました。index 等は関係なく。 >> （あと、mroonga テーブルの破損……） > > MySQLがクラッシュしたという状況ではないですよね？ レプリケーションの切断はMySQLのクラッシュとは関連性が薄そうです。 mroonga テーブルの破損後だと、MySQLもたまにクラッシュしているようです。 でもクラッシュしない事の方が多いです。 ただ、これだと比較的分かりやすいのですが、多いパターン順だと。 INSERT 出来なくなる。 Unique キーで SELECT 結果が0件になるが、主キーでは SELECT できる。 ↑DELETE も同様。 上記が単体、または組み合わせで発生して、DBの応答待ちや Load Average の 上昇といった事が多いです。 ※ MATCH AGAINST ではなく、= での条件指定がほとんどです。 ※ UPDATE も出来なくなりますが（応答待ち）、通常使用だとこのテーブルは UPDATE しないのです。 >> TIMESTAMP型ではまだ見つかっておりません。 > > これも不正な値（Mroongaが扱えない値）関連なんですかねぇ。 今まで格納された値が不整合というのは記憶にないのです。 新テーブルの schema を作成し、 INSERT INTO 新テーブル SELECT * FROM 旧テーブル; ALTER TABLE RENAME の差し替えで、修復完了しています。 ※ ALTER TABLE 旧テーブル ENGINE mroonga; での修復は怖くてまだ試していません。 なので、報告に上げさせていただいたような Index（Unique とは限らない） 回りで、一緒に何か他の不具合が見つかる事を勝手ながら期待しています。 あと、出来るかぎり他のテストも行ってみます。 >> collisions(xxxxxxxx/xxxxxxx): lock failed 1000 times >> が頻発するのも気になっていますが。 > > これ、どういうときに発生しているかわかりますか？ 更新が少なそうな時間帯には発生しにくい。ぐらいしか分からないのです。 （常時、なんらかの処理が稼働しているので） もっと具体的なログを出す方法があれば、ご教示いただけると助かります。 > もし、複数接続で同時に書き込みしているなら、1接続で順に書き > 込むようにすると解消するかもしれません。さらにロックが競合し > なくてそっちの方が速くなるかもしれません。 処理の直列化も検討したのですが、これで回避可能という確証がないと着手が なかなか難しい所になってしまっています。 確かに複数の接続で処理は行っているのですが、その際も Unique キーの決め うちでの DELETE / INSERT か、日付型での範囲検索での DELETE です。 範囲検索の方は同時実行は行わない……はずです。 こう改めて書いてみると、1行単位で同一の Unique キーでの集中した処理が 多いですね。ちょっとテストパターン考えてみます。 P.S 発生している環境は複数で、いずれもレプリケーション構成。 本番環境がほとんどで、ステージ環境ではまれ。 Cent OS 6 が主で 5 と 7 もある。 MySQL 5.6 が主で 5.5 が 2 構成だけ。 mroonga は 4.01〜。 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ 各務 Email kagam****@outwa***** _/ _/ 郵便番号 819-0022 福岡市西区福重3-36-6 _/ _/ TEL：092-885-1364 FAX：092-885-1459 _/ _/ 月〜金（祝日を除く） 10:00〜19:00 _/ _/ _/ _/ 九州の経済情報サイト「qBiz 西日本新聞経済電子版」 _/ _/ ビジネスマン必須メディア⇒ http://qbiz.jp/ _/ _/ _/ _/ 婚活やめて正解!? 運命の人はキズナ占いで今すぐチェック！ _/ _/ 【無料スマホアプリ】『極上鑑定！キズナ占い』 _/ _/ ⇒http://app.outward.jp/access/?app_id=keiko _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
