各務 洋
kagam****@outwa*****
2015年 5月 15日 (金) 13:43:47 JST
お世話になります、各務です。
> warningになるものがerrorになるといえばsql_mode= 'STRICT_ALL_TABLES'あたりが有名で、
>
> * マスターではsql_mode != 'STRICT_ALL_TABLES'
> かつ
> * スレーブのSQLスレッドでsql_mode= 'STRICT_TRANS_TABLES'
>
> だとこういう動作になりそうな気がしなくもないんですが、
> マスターで更新した時に「その時のsql_mode」も一緒にバイナリーログに記録するため、
> マスター/スレーブ間でsql_modeの設定が違ってもこういう風にはならないはずです。
> ので、手元では再現していません(´・ω・｀)
ふむふむ。
>
> Mroongaがトランザクション非対応なあたりで、
> マスターでsql_modeをガリガリ書き換えながら更新をかけると混ざったりするのかなぁと思ったり思わなかったりしています。
> どうなんだろう。
こちらの環境では一切行っていないのです。
重いと分かっている処理だと、session 変数を先に投げたいなぁと思っている程度です。
> 再現環境下でのSHOW SLAVE STATUSのIPアドレス以外のまるまるの出力と、
> エラーが起こったイベントの前後1イベントくらいずつのマスターのバイナリーログと
> スレーブのリレーログとかもらえると深追いできるかも知れません。
おぉ、ありがとうございます。
最初のテストはサービスの検証環境でしたので、ちょっと取り出すのが困難なのです。
須藤さんがお持ちであれば助かるのですが。
難しいようでしたら、本番環境とは全然違う、無茶苦茶小さい検証環境を準備したので、
こちらで再テストする事も可能です。
>>> この際、スレーブ側へのレコード登録は「0000-01-01 00:00:00」で成功するが、
>>> レプリケーションは切断される。
>>>
>>> Error 'Data truncated for column 't_date' at row 1' on query. Default database: 'db_test'.
>>> Query: 'INSERT INTO tbl_test_pat_0001 (t_key, t_date) VALUES ('test1', '0000-00-00')'
>
> スレーブにレコードの登録が成功する、というのがまたわからないんですよねぇ。。
> Mroongaはトランザクション非対応なので、Mroonga側で書き込みが終わったあとに
> Handlerのどこかがエラーになるならそうなりそうですけども。。
当てずっぽうですが、年も「0000」を「1000」に変換すると回避できるとかだ
と良いのですが。
>> my.cnf で何か変更している点があるならば、
>>
>> transaction_isolation = READ-COMMITTED
>> slave_exec_mode = idempotent
>>
>> ここらへんを変えていますが、関係ありそうでしょうか？
>
> binlog_formatは指定していませんか？ (暗黙のデフォルトはSTATEMENT)
> であれば、関係ないと思います（MIXEDの場合、READ-COMMITTEDだとRBRに変わる）
後だしになってしまって申し訳ないです、
binlog_format=mixed
です。
> ところで、slave_exec_modeってNDBCLUSTER(MySQL Cluster)用のパラメーターなんですが、
> NDBCLUSTERのmysqldを使ってたりします？
おぉ、そうなのですね。まったく使っていないです。
外した方が良さそうでしょうか？
これは、Dump & Restore のフルメンテナンス直後に、10分持たずに replication
が切れ続けた時の名残りです。
（master 側も入れ直したりして、予定のメンテ時間を完全に使いきった……
後にやりました。）
>> >>> collisions(xxxxxxxx/xxxxxxx): lock failed 1000 times
>> >>> が頻発するのも気になっていますが。
>> >>
>> >> これ、どういうときに発生しているかわかりますか？
>
> ウチでも更新トラフィックが多い時間帯はたまに出てます。
これが連続して発生している時は、
SELECT できる
↓
DELETE / INSERT もできる（行単位）。
↓
DELETE / INSERT が待ち状態。
↓
SELECT が 不安定になる（主キーでは出来るが、それ以外の 単一 Unique キーで出来ない等）
↓
SELECT の応答もなくなる
のような進行具合で何かが起きています。
DELETE / INSERT が待ち状態で、clearlock すると、
1.解放される。（対象レコードの状態は不明、次の実行時に INSERT は処理対象になるはず）
2.mysql server gone away で、mysqld が自動再起動しているが、以降は問題ない。
3.やっぱり壊れている。
で、待ち時間が短いときは1側、長い時は3側が多くなる傾向があります。
>> MySQLって書き込み回数とかの統計情報ってとれるんでしたっけ。
>> とれるなら書き込み頻度を確認すると更新頻度が影響してそうかわ
>> かりそうだなぁと思いました。
>
> Handler_writeとかHandler_updateはどうですか？
>
Global 変数ですよね。これでよければ仕込んでみます。
x分毎などの取得タイミングはどれくらいが良いでしょうか？。
----
各務
kagam****@outwa*****