mysql主从复制，基于GTID的主从、半同步复制、并行复制

环境：

实验环境：
rhel6.5 , selinux和iptables均为disabled状态，mysql均为5.7.17，或者slave比master版本高
实验主机：
172.25.254.2 server2:master
172.25.254.3 server3:slave

一.mysql主从复制

*1*mysql主从复制原理:
1.从库生成两个线程，一个i/o线程，一个SQL线程
2.i/o线程去请求主库的binlog，并且得到的binlog日志写道relay log(中继日志)文件中
3.主库会生成一个log dump线程，用来给从库的i/o线程传binlog
4.SQL线程，会读取中继日志文件，并解析成具体的操作执行，这样主从的操作就一致了，而最终的数据也就一直存在了
*2*主从复制用途及条件
1.实时灾备，用于故障切换
2.读写分离，提供查询服务
3.备份，避免影响业务
*3*主从部署的必要条件
1.主库可诶其binlog日志（设置log-bin参数）
2.主从server-id不同
3.从库服务器能连接到主库
*4*主从复制存在的问题及解决方法
问题：
1.主机宕机之后，数据可能会丢失
2.从库只有一个sql Thread,主库写压力大，复制很可能会延时
解决方法：
1.半同步复制解决--解决数据丢失的问题
2.并行复制--解决从库复制延时的问题
&&主从复制分类：
主从复制分为同步复制和异步复制
1.异步复制：异步复制意味着在把数据从一台机器拷贝到另一台机器时有一个延时，最重要的是这意味着当应用系统的事务提交已经确认时数据并不能在同一时刻拷贝（应用）到从机。通常这个延时是由网络宽带、资源可用性和系统负载决定的，然而使用正确的组件并且调优，复制能做到接近瞬间完成。
2.同步复制：同步复制可以定义为数据在同一时可被提交到一台或多台机器，通常这是通过众所周知的“两阶段提交”做到的。虽然这确定给你在多系统中保持一致性，但也由于增加了额外的消息交换而造成性能下降。
（本次实验只介绍异步复制）
主从复制中异步复制的工作原理：
在主节点上执行完命令后生成一个日志文件，然后将日志文件发送给从节点，最后提交，从节点收到日志文件后，开始同步里面的数据（事物），最后得到与主节点一致的数据
实验过程：
在两台主机上安装服务

在server2上

下载安装包，并进行解压与安装

改写配置文件

vim /etc/my.cnf

server-id=1

/etc/init.d/mysqld start ##开启服务

grep password /var/log/mysql.log ##查看mysql的初始密码

mysql_secure_installation ##修改密码，本实验中修改密码为Zhang+007

mysql -p ##登陆数据库，确保密码修改正确

在server3上

下载并安装数据库所需包（与server2一致）

解压并下载

server3也需要更改密码，登陆mysql，检测是否成功

mysql_secure_installation ##更改密码，本实验中更改密码为westos

mysql -p ##登陆，检查是否更改成功

然后编写文件

在server2上

grant replication slave on *.* to zhang@'172.25.254.%' identified by 'Zhang+007' ##设置slave,且设置master（即server2）名称为zhang ,密码为Zhang+007

在server3上mysql -u zhang -p -h 172.25.254.2 ##zhang为master名称，172.25.254.2为master的ip

然后在server3上，mysql -p 登陆自己的数据库

start slave; ##开启slave (若slave开启报错，则要SHOW VARIBLES LIKE 'server_id',查看Value值是否为当初设置的server_id的值，若不是，则说明还不能同步)

（若要重置slave或master,则先stop slave,然后reset slave）

show slave status\G; ##查看slave信息

若 Slave_IO_Running:YES 并且Slave_SQL_Rrunning:YES,则说明master和slave可以同步数据库数据

测试：

在server2上重新添加数据

在server3上就会同步过来

二：基于GTID模式

1.概念：GTID（Global Transaction Identifier）称为全局事务标示符，是由mysql服务器自动管理的在原始master上提交事务时被创建。 GTID需要在全局的主-备拓扑结构中保持唯一性，每一个 GTID 代表一个数据库事务。 GTID由两部分组成： GTID = source_id：transaction_id source_id：用于标示源服务器，用server_uuid来表示 transaction_id：则是根据在源服务器上第几个提交的事务来确定。 transaction_id 是一个从 1 开始的自增计数，表示在这个主库上执行的第 n 个事务。 MySQL 会保证事务与 GTID 之间的 1 : 1 映射。工作原理：前面在slave端配置，进行change master to操作时，使用的是日志号(指定position），当master端的服务down掉了，就会在slave端选择一个日志号与原来的master最接近的作为master，但是，在另一个slave上，并没有指定新的master的信息，因此还要手动去指定，而使用gtid的话，slave通过寻找 next的值，并不用指定master的二进制日志文件和日志号，所以使用gtid更能保证数据的完整性。

1.在server2上，编写文件

重新启动服务

2.在server3中编写文件，并重启服务

在server3中，登陆数据库，修改参数，查看slave

测试：

在server2中，删除某些数据

则在server3中，就会发现数据同步更新了

三：半同步复制（修改IO线程）

MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主机如果crash掉了，此时主机上已经提交的事务可能并没有传到从机上，如果此时，强行将从机提升为主机，可能导致新主机上的数据不完整。

指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

io线程是slave中主要负责将master传过来的数据存放在relay log中的线程，relay log是不断追加内容的。

半同步原理：master和slave本来是异步复制，这样有可能造成两边数据不一致，因为master只负责传数据给slave，而半同步则时在一定时间段中，master传完数据后就会等待slave的回应，这样数据一致性的可能性会更大，若在这段时间段内，master收不到slave的回应，那么会由半同步变为异步。

其中半同步在master中表示为'semi_sync',在slave中表示为'semi'

在master中：设置半同步复制,设置参数，查看半同步状态