■
Here are three key variables that you need to set to achieve maximum performance with multi-threaded slaves:
binlog-format=STATEMENT
relay-log-info-repository=TABLE
master-info-repository=TABLE
he variable slave_parallel_workers should be set to equal the number of schemas that you have
■うん。。
MySQLのレプリケーションを担当しているスレッドは、IOスレッドとSQLスレッドの2つだった。IOスレッドがマスタからバイナリログをとってきて、SQLスレッドがバイナリログ内に記録されたSQL文を実行しデータを反映していくのが従来の動作だった。新しいマルチスレッドレプリケーションでは、このIOスレッドとSQLスレッドの間に新しくSQLスレッドコーディネータを置く。
さらにSQLスレッドは、workerとして複数のスレッドに分割される。SQLスレッドコーディネータはSQLスレッドからバイナリログを受け取り、どのデータベースに対する更新なのかを判断して、それぞれのデータベースを担当するworkerに振り分ける。workerは受け取ったSQLを実行し、データベースを更新していく。
Interaction between Coordinator and Workers follow to the
producer-consumer model.
MTS is configurable with just few options:
--slave-parallel-workers=#
Number of worker threads for executing events in parallel
--slave-checkpoint-period=#(default:300)
Gather worker activities to Update progress status of
Multi-threaded slave and flush the relay log info to disk
after every #th milli-seconds;
--slave-checkpoint-group=#(default:512)
Maximum number of processed transactions by
Multi-threaded slave before a checkpoint operation is
called to update progress status;
Multi-threaded slave and flush the relay log info to disk
＝＝＞
The second and third options checkpoint period and group count provide
a control for how often to update `mysql`.`slave_relay_log_info` by
Coordinator thread.
--slave-pending-jobs-size-max=#(default:16M)
Max size of Slave Worker queues holding yet not applied
events.The least possible value must be not less than the
master side max_allowed_packet;
＝＝＝＞The fourth simply constraints RAM usage to not consume
memory with replication events over some threshold.
■できない時、 MTS temporarily
switches to the sequential applying
自動的に変更する
START SLAVE MTS_UNTIL_AFTER_GAPS
select * `mysql.slave_worker_info`