噂どおりのslave_parallel_workers

やっとparallelのRとLを間違えなくなった。。

http://dev.mysql.com/doc/refman/5.6/en/replication-options-slave.html#option_mysqld_slave-parallel-workers

個人的にかなり期待していた5.6の新機能ではあるけれど、実際試してみた感想をメモ。


1) 前提条件として、パラレルで動けるのはデータベース単位。
　⇒全部同じデータベースに突っ込んである環境だと効果なし。
　⇒USEステートメントで選んだデフォルトデータベースでなく、
　　ちゃんと実効データベース(--replicate-wild-*-tableみたいな感じ)で判定してくれるっぽい。

2) データベース間をまたぐステートメント(INSERT INTO d1.t1 SELECT * FROM d2.t1とか)は
　2つのデータベースのparallel workを阻害する。
　⇒d1に対する反映とd2に対する反映はそのステートメントが終わるまで待たされる。
　　d3に対する反映は追い越してparallel workできる。

3) パラレルじゃないレプリケーションならリトライできるエラーでも、
　SQL_THREADが止まった上にその更新は適用されず失われる。
　⇒スレーブ側でSELECT .. FOR UPDATEでロックしてlock wait timeout exceededにしたら、
　　SQL_THREADは止まったけどSTART SLAVEしてもその更新は適用されないままさっくり続きのRelay Logを待つ。
　　⇒START SLAVEするたびにWarningで`こういう動作になるよ！'って教えてくれるけど。


うーん。。。
2)は良いとして、1)が問題にならないくらいデータベースがきちんと分かれてないとなぁ。。
レプリケーションの並列度を上げる為に水平分割とか1テーブル1データベース構成とか。。

あと、3)が地味に痛い。
クエリの中身とかはエラーログに吐いてくれるから、START SLAVEする前にそのクエリ手で叩けば良いのかな？

GTIDと並んでいきなり試すには鬼門な感じがする。。


【2012/02/06 10:18】
ちなみにこんなWarning。

slave_transaction_retries is not supported in multi-threaded slave mode. In the event of a transient failure, the slave will not retry the transaction and will stop.