续我的上篇博文：https://mp.csdn.net/postedit/87894362
主从复制存在的问题以及解决办法
问题：
1.主库宕机之后，数据可能会丢失
2.从库只有一个sql Thread，主库写压力大，复制很可能延时解决方法：
1.半同步复制--解决数据丢失的问题
2.并行复制--解决从库复制延时的问题1.数据库同步是怎样进行的?
master用户写入数据，生成event记到binary log中.
slave接收master上传来的binlog，然后按顺序应用，重现master上的用户操作。
2.数据库是靠什么同步的? 主从复制,默认是通过pos复制(postion),就是说在日志文档里,将用户进行的每一项操作都进行编号(pos),每一个event都有一个起始编号,一个终止编号,我们在配置主从复制时从节点时,要输入master的log_pos值就是这个原因,要求它从哪个pos开始同步数据库里的数据,这也是传统复制技术,
MySQL5.6增加了GTID复制,GTID就是类似于pos的一个作用,不过它是整个mysql复制架构全局通用的,就是说在这整个mysql冗余架构中,它们的日志文件里事件的GTID值是一致的.
3.从节点怎么知道要从哪块进行同步? 上面也说了,一开始是自己设置的从节点从主节点的日志文件里的pos开始复制,以后就自己去读取上一次同步到哪一块,接着同步.
4:pos与GTID有什么区别? 两者都是日志文件里事件的一个标志,如果将整个mysql集群看作一个整体,pos就是局部的,GTID就是全局的。一.GTID的概念
1、全局事务标识：global transaction identifiers。
2、GTID是一个事务一一对应，并且全局唯一ID。
3、一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
4、GTID用来代替传统复制方法，不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制。而是使用MASTER_AUTO_POSTION=1的方式开始复制。
5、MySQL-5.6.5开始支持的，MySQL-5.6.10后开始完善。二.GTID的组成
GTID = source_id:transaction_id
source_id，用于鉴别原服务器，即mysql服务器唯一的的server_uuid，由于GTID会传递到slave，所以也可以理解为源ID。
transaction_id，为当前服务器上已提交事务的一个序列号，通常从1开始自增长的序列，一个数值对应一个事务。
#示例：
3E11FA47-71CA-11E1-9E33-C80AA9429562:23
前面的一串为服务器的server_uuid，即3E11FA47-71CA-11E1-9E33-C80AA9429562，后面的23为transaction_id三.GTID的优势
1、更简单的实现failover，不用以前那样在需要找log_file和log_pos。
2、更简单的搭建主从复制。
3、比传统的复制更加安全。
4、GTID是连续的没有空洞的，保证数据的一致性，零丢失
5、借助GTID，在发生主备切换的情况下，MySQL的其它Slave可以自动在新主上找到正确的复制位置，这大大简化了复杂复制拓扑下集群的维护，也减少了人为设置复制位置发生误操作的风险。另外，基于GTID的复制可以忽略已经执行过的事务,减少了数据发生不一致的风险。四.GTID的工作原理
1、当一个事务在主库端执行并提交时，产生GTID，一同记录到binlog日志中。
2、binlog传输到slave,并存储到slave的relaylog后，读取这个GTID的这个值设置gtid_next变量，即告诉Slave，下一个要执行的GTID值。
3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有该GTID。
4、如果有记录，说明该GTID的事务已经执行，slave会忽略。
5、如果没有记录，slave就会执行该GTID事务，并记录该GTID到自身的binlog，
在读取执行事务前会先检查其他session持有该GTID，确保不被重复执行。
6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。五.配置GTID
配置server1（主库）
1.修改配置文件（/etc/my.cnf）并重启mysql
[root@server1 mysql]# vim /etc/my.cnf
log-bin=mysql-bin #启动mysql二进制日志,即数据同步语句,从数据库会一条一条的执行这些语句
server-id=1 #服务器唯一标识
gtid_mode=ON #开启gtid模式
enforce-gtid-consistency=true #强制gtid一致性，开启后对于特定create table不被支持
[root@server1 mysql]# systemctl restart mysqld #修改完配置文件之后,重启mysqld服务
2.查看主库状态
[root@server1 ~]# mysql -uroot -pXinjiaojiao+523
mysql> show master status; #查看主库的状态
配置server2（从库）
1.修改配置文件（/etc/my.cnf）并重启mysql
[root@server2 ~]# vim /etc/my.cnf #将上次做的主从复制的一行注释,在最后加入下面两行内容
server-id=2 #服务器唯一标识
#开启gtid模块
gtid_mode=ON #开启gtid模式
enforce-gtid-consistency=true #强制gtid一致性，开启后对于特定create table不被支持
[root@server2 ~]# systemctl restart mysqld #修改完配置文件之后,重启mysqld服务
2.设定从库，将主库与从库连接起来，并开启从库
[root@server2 ~]# mysql -uroot -pXinjiaojiao+623 #登录server2(从库)自己的数据库进行设置
mysql> stop slave; #先关闭slave(在change之前要关闭slave)
mysql> change master to master_host='172.25.83.1',master_user='xin',master_password='Xinjiaojiao+523', master_auto_position=1;
mysql> start slave;
mysql> show slave status\G;
3.查看从库状态
下图记录了gtid的变化
如果Slave_IO_Running和Slave_SQL_Running都为yes，则表示正常
测试：
1.在主库端的数据库westos下的表usertb中，插入信息
[root@server1 ~]# mysql -uroot -pXinjiaojiao+523
在主库上查看gtid号的改变
2.从库端查看是否存在在主库中添加的内容
[root@server2 ~]# mysql -uroot -pXinjiaojiao+623
此时可以在从库上查看gtid号码的改变。
结论：
从库看到的数据和主库看到的数据是一致的，代表基于gtid的主从复制搭建成功