day12-04-Mysql优化-MTS-02-配置与监控
MTS 的开启 生产要想使用MTS特性，版本大于等于MySQL 5.7.19才是安全的
开启enhanced multi-threaded slave其实很简单，只需根据如下设置：
# slave;
# 开启GTID
gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
# slave_parallel_type 默认是 DATABASE，必须改成 LOGICAL_CLOCK
slave-parallel-type=LOGICAL_CLOCK
# 并发回放的线程数，一般是CPU核心个数的50%
slave-parallel-workers=16
# 用于保存尚未应用事件的工作队列的最大内存量（以字节为单位），默认值为16MB，最小值为1024；设置最好是1024倍数。
slave_pending_jobs_size_max = 2147483648
# 设置1，确保事务在副本上的外部化顺序与副本中继日志中出现的顺序相同，并防止从中继日志执行的事务顺序乱序
slave_preserve_commit_order=1
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON
# 查看slave_parallel_type
mysql> show variables like 'slave_parallel_type';
+---------------------+----------+
| Variable_name | Value |
+---------------------+----------+
| slave_parallel_type | DATABASE |
+---------------------+----------+
1 row in set (0.00 sec)
mysql> select @@slave_parallel_type;
+-----------------------+
| @@slave_parallel_type |
+-----------------------+
| DATABASE |
+-----------------------+
1 row in set (0.00 sec)
mysql>
基于WRITESET的并行复制方式
https://blog.csdn.net/baoxianbi9918/article/details/100963640
MTS监控
在使用了MTS后，复制的监控依旧可以通过 SHOW SLAVE STATUS\G ，
但是MySQL 5.7在performance_schema架构下多了以下这些元数据表，用户可以更细力度的进行监控：
mysql> show tables like 'replication%';
+---------------------------------------------+
| Tables_in_performance_schema (replication%) |
+---------------------------------------------+
| replication_applier_configuration |
| replication_applier_status |
| replication_applier_status_by_coordinator |
| replication_applier_status_by_worker |
| replication_connection_configuration |
| replication_connection_status |
| replication_group_member_stats |
| replication_group_members |
+---------------------------------------------+
8 rows in set (0.00 sec)
通过replication_applier_status_by_worker可以看到worker进程的工作情况：
mysql> use performance_schema
mysql> select * from replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+--------------------------------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+--------------------------------------------+-------------------+--------------------+----------------------+
| | 1 | 32 | ON | 0d8513d8-00a4-11e6-a510-f4ce46861268:96604 | 0 | | 0000-00-00 00:00:00 |
| | 2 | 33 | ON | 0d8513d8-00a4-11e6-a510-f4ce46861268:97760 | 0 | | 0000-00-00 00:00:00 |
+--------------+-----------+-----------+---------------+--------------------------------------------+-------------------+--------------------+----------------------+
2 rows in set (0.00 sec)
怎样知道从机MTS的并行程度又是一个难度不小的面试题（至少是P7吧）。
简单的一种方法，可以使用performance_schema库来观察，比如下面这条SQL可以统计每个Worker Thread执行的事务数量，在此基础上再做一个聚合分析就可得出每个MTS的并行度:
SELECT thread_id,count_star
FROM performance_schema.events_transactions_summary_by_thread_by_event_name
WHERE thread_id IN (
SELECT thread_id FROM performance_schema.replication_applier_status_by_worker
);
如果线程并行度太高，不够平均，其实并行效果并不会好，可以试着优化。这种场景下，可以通过调整主服务器上的参数binlog_group_commit_sync_delay、binlog_group_commit_sync_no_delay_count。前者表示延迟多少时间提交事务，后者表示组提交事务凑齐多少个事务再一起提交。总体来说，都是为了增加主服务器组提交的事务比例，从而增大从机MTS的并行度。
虽然MySQL 5.7推出的Enhanced Multi-Threaded Slave在一定程度上解决了困扰MySQL长达数十年的复制延迟问题。然而，目前MTS机制基于组提交实现，简单来说在主上是怎样并行执行的，从服务器上就怎么回放。这里存在一个可能，即若主服务器的并行度不够，则从机的并行机制效果就会大打折扣。MySQL 8.0最新的基于writeset的MTS才是最终的解决之道。即两个事务，只要更新的记录没有重叠（overlap），则在从机上就可并行执行，无需在一个组，即使主服务器单线程执行，从服务器依然可以并行回放。相信这是最完美的解决之道，MTS的最终形态。
最后，如果MySQL 5.7要使用MTS功能，必须使用最新版本，最少升级到5.7.19版本，修复了很多Bug。
