Docker初识：mysql8主从复制（单向）- 主从搭建扩展知识
主从服务（master-slave）新学习到的知识。
1、全库同步与部分同步
上回书说到Docker初识：mysql8主从复制（单向）的配置都是针对全库配置的。但是实际上并不需要针对全库做备份，只需要对一些特别重要的库或者表来进行同步。例如information_schema等。
可以通过配置文件中的一些属性指定需要针对哪些库或者哪些表记录binlog。
Master配置：
#需要同步的二进制数据库名
binlog-do-db=masterdemo
#只保留7天的二进制日志，以防磁盘被日志占满(可选)
expire-logs-days = 7
#不备份的数据库
binlog-ignore-db=information_schema
binlog-ignore-db=performation_schema
binlog-ignore-db=sysSlave配置：
#如果salve库名称与master库名相同，使用本配置
replicate-do-db = masterdemo
#如果master库名[mastdemo]与salve库名[mastdemo01]不同，使用以下配置[需要做映射]
replicate-rewrite-db = masterdemo -> masterdemo01
#如果不是要全部同步[默认全部同步]，则指定需要同步的表
replicate-wild-do-table=masterdemo01.t_dict
replicate-wild-do-table=masterdemo01.t_num置完成了之后，在show master status指令中，就可以看到Binlog_Do_DB和Binlog_Ignore_DB两个参数的作用了。
2、读写分离配置
为了保证数据一致，通常会需要保证数据只在主服务上写，而从服务只进行数据读取。注意，mysql主从本身是无法提供读写分离的服务的，需要由业务自己来实现。
如果需要限制用户写数据，我们可以在从服务中将read_only参数的值设 为1( set global read_only=1; )。这样就可以限制用户写入数据。设置read_only=1设置的只读模式，有两点注意点
- 会影响slave同步复制的功能
通过 "show slave status\G" 命令查看salve状态，可以看到salve仍然会读取master上的日 志，并且在slave库中应用日志，保证主从数据库同步一致；
- 只影响普通用户进行数据修改的操 作，但不会限定具有super权限的用户的数据修改操作。
普通的应用用户进行insert、update、delete等会 产生数据变化的DML操作时，都会报出数据库处于只读模式不能发生数 据变化的错误，但具有super权限的用户。
例如在本地或远程通过root用 户登录到数据库，还是可以进行数据变化的DML操作； 如果需要限定 super权限的用户写数据，可以设置super_read_only=0。另外 如果要 想连super权限用户的写操作也禁止，就使用"flush tables with read lock;"，这样设置也会阻止主从同步复制！
3、其他集群方式
在实际环境中，通常会以一主一从主从同步集群为基础，进行扩展，搭建更大更复杂的集群。
- 为了提高整个集群的读能力，可能扩展出一主多从；
- 为了减轻主节点进行数据同步的压力，可以继续扩展出多级从的主从集群；
- 为了提高整个集群的高可用能力，可以扩展出多主的集群。
- 也可以扩展出互为主从的互主集群甚至是环形的主从集群，实现MySQL多活
部署。
4、GTID同步方式
这种模式是从MySQL5.6版本引入的。相较于传统的集群搭建方式而言，还有一种搭建主从同步的方式，即GTID搭建方式。上回书，包括之前书搭建方式都是基于Binlog日志记录点的方式来搭建的。配置文件种可以看到有一个Executed_Grid_Set列，暂时还没有用上。
GTID的本质也是基于Binlog来实现主从同步，只是他会基于一个全局的事务ID来标识同步进度。GTID即全局事务ID，全局唯一并且趋势递增，他可以保证为每一个在主节点上提交的事务在复制集群中可以生成一个唯一的ID 。
在基于GTID的复制中，首先从服务器会告诉主服务器已经在从服务器执行完了哪些事务的GTID值，然后主库会有把所有没有在从库上执行的事务，发送到从库上进行执行，并且使用GTID的复制可以保证同一个事务只在指定的从库上执行一次，这样可以避免由于偏移量的问题造成数据不一致。
配置如下：
Master配置：
gtid_mode=on
enforce_gtid_consistency=on
log_bin=on
server_id=单独设置一个
binlog_format=rowSlave配置：
gtid_mode=on
enforce_gtid_consistency=on
log_slave_updates=1
server_id=单独设置一个然后重启即可。
5、集群扩容需要数据备份
如果集群是已经运行过一段时间，这时候如果要扩展新的从节点就有一个问题，之前的数据没办法从binlog来恢复了。这时候在扩展新的slave节点时，就需要增加一个数据复制的操作。
MySQL的数据备份恢复操作相对比较简单，可以通过SQL语句直接来完成。具体
操作可以使用mysql的bin目录下的mysqldump工具。
mysqldump -u root -p --all-databases > backup.sql
#输入密码通过这个指令，就可以将整个数据库的所有数据导出成backup.sql，然后把这个backup.sql分发到新的MySQL服务器上，并执行下面的指令将数据全部导入到新的MySQL服务中。
mysql -u root -p < backup.sql
#输入密码这样新的MySQL服务就已经有了所有的历史数据，然后就可以再按照上面的步骤，配置Slave从服务的数据同步了。
6、主从的数据延迟问题
读写分离后，主服务写数据，从服务读数据。这就可能出现明明刚写入了数据，但是却查不出来，这就是因主从复制延迟导致的。一般来说，大型集群中更容易出现这种情况。
出现这个问题的原因就在于主服务数据都是多线程并发写入，而从服务则是单线程拉取binlog。所以解决这个问题就是让从服务也多线程并行复制binlog数据即可。
MySQL自5,7开始就已经支持并行复制数据了。可以在从服务设置。
slave_parallel_workers=大于0的数
slave_parallel_type=LOGICAL_CLOCK未完，正在学习中，待续 。。。