GA

2012/11/26

噂どおりの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.

0 件のコメント :

コメントを投稿