近期公司上线了一套新的架构，架构很简单，台湾和大陆各一套mysql数据库，分别w/r ,架构不是很难做，就是做主主架构，难的是第一跨地域，走内网vpn网路延迟在40ms左右，第二数据量会比较的大，因此基于这点，在忽略网络的情况下
我考虑先对mysql的主主架构做自身的优化，主要就是主库的binlog group commit和从库sql多线程并发执行，查看了很多的文档以及官方文档，理解一二，仅供自己笔记参考，查看者，请自行斟酌可靠性，一切以官方解释为准。
1.主库（mysql 5.7.26）设置binlog的group commit
主要调整参数
#*************** group commit ***************
binlog_group_commit_sync_delay =1
binlog_group_commit_sync_no_delay_count =1000
参数说明：
binlog_group_commit_sync_delay
解释：在将二进制日志文件同步到磁盘之前，控制二进制日志提交等待的微秒数。默认情况下，binlog_group_commit_sync_delay设置为0，这意味着没有延迟。将binlog_group_commit_sync_delay设置为微秒级延迟，可以同时将更多事务同步到磁盘，从而减少提交一组事 务的总时间，因为较大的组需要的每个组的时间单位更少。注意，设置binlog_group_commit_sync_delay会增加服务器上事务的延迟，这可能会影响客户机应用程序。此外，在高度并发的工作负载上，延迟可能会增加争用，从而降低吞吐量。通常，设置延迟的好处大于缺点，但是应该始终进行调优以确定最佳设置。
官方解释：
https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html
binlog_group_commit_sync_no_delay_count
指定的中止当前延迟之前要等待的最大事务数。也就是说在如果 binlog_group_commit_sync_delay=1的时间内，当事务量达到1000个就组提交一次，binlog_group_commit_sync_delay设置为0，则此选项无效。
2.从库设置多sql线程执行主库同步的binlog数据
#*************** muti thread slave ***************
slave_parallel_type =LOGICAL_CLOCK
##使用逻辑时钟，基于组提交实现并行复制，默认是DATABASE
slave_parallel_workers =4
#设置并行线程数，通常和CPU核数一致
master_info_repository =TABLE
#开启MTS后会频繁更新master.info文件，默认为FILE，设置为TABLE减少开销
relay_log_info_repository =TABLE
#如果从库IO线程崩溃，并且relaylog损坏，则放弃所有未执行的relaylog，重新从master获取日志保持完整
slave_parallel_type=LOGICAL_CLOCK
默认database
在主服务器上提交属于同一二进制日志组的事务将在从服务器上并行应用。也就是生效依赖于主库设置了group commit
slave_parallel_workers
#设置并行线程数，通常和CPU核数一致
官方解释：
https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html