Mysql（二）Mysql的主从复制和基于GTID的主从复制

介绍主从复制前，应该先明白一个概念，就是数据备份
数据备份是一种古老而有效的数据保护手段，早期的数据备份手段主要是数据冷备，即定期将数据复制到某种存储介质(磁带，光盘...)上并物理存档保管，如果系统存储损坏，那么就从冷备的存储中恢复数据冷备的优点是简单和廉价，成本和技术难度都较低，缺点是不能保证数据最终一致，由于数据是定期复制，所以不具有实施时性，所以备份的数据比系统中的数据陈旧。

        假若系统数据丢失，那么这中间还有一段数据也就消失了，即备份中的数据就不完整。也不能保证数据的可用性，从冷备存储中恢数据需要较长的时间，而这段时间无法访问数据，系统也不可用。

所以，具有时实行的一种数据备份系统迫在眉睫，此时引入Mysql的备份机制。

然后Mysql的备份机制还有好多种，这篇博客先介绍最基础的主从复制，异步复制。

一、主从复制

 来由：通俗来讲，如果对数据库的读和写都在同一个数据库服务器中操作，业务系统性能会降低。
为了提升业务系统性能，优化用户体验，可以通过做主从复制（读写分离）来减轻主数据库的负载。
而且如果主数据库宕机，可快速将业务系统切换到从数据库上，可避免数据丢失。

（1）逻辑上

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

（2）技术上

主库将事务 Binlog 事件写入到 Binlog 文件中，此时主库只会通知一下 Dump 线程发送这些新的 Binlog，然后主库就会继续处理提交操作，而此时不会保证这些 Binlog 传到任何一个从库节点上。

 随着业务的增长，一台数据库服务器以满足不了需求了，负载过重，这时候就需要减压，实现负载均衡读写分离，一主一从或一主多从
主服务器只管写，从服务器管读，从而提高效率减轻压力。
主从复制分类：
主从同步：当用户写数据主服务器必须和从服务器同步一致了才告诉用户写入成功，等待时间太长
主从异步：只要用户访问写数据主服务器写入立马返回给用户成功
主从半步同步：当用户访问写数据主服务器写入并同步其中一个从服务器就返回给用户成功
备注：通常都是使用的主从异步，根据环境需求来选择，想要数据更安全选择半步同步

二、主从复制的原理

原理：

如上图所示，主服务器上面的任何修改都会保存在二进制日志Binary log里面，从服务器上面启动一个I/O thread（实际上就是一个主服务器的客户端进程），连接到主服务器上面请求读取二进制日志，然后把读取到的二进制日志写到本地的一个Realy log里面。从服务器上面开启一个SQL thread定时检查Realy log，如果发现有更改立即把更改的内容在本机上面执行一遍。

复制的过程：

1. Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容。
2. Master接收到来自Slave的IO进程的请求后，负责复制的IO进程会根据请求信息读取日志指定位置之后的日志信息，返回给Slave的 IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置。
3. Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master从何处开始读取日志。
4. Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。

三、主从复制的实现

实验准备：master    server1   172.25.58.1

                    master     server2   172.25.58.2

在server1上进行操作：

1)下载mysql的rpm包
tar xf mysql-5.7.24-1.el7.x86_64.rpm-bundle.tar

2)安装需要的包
yum install -y mysql-community-client-5.7.24-1.el7.x86_64.rpm mysql-community-common-5.7.24-1.el7.x86_64.rpm mysql-community-libs-5.7.24-1.el7.x86_64.rpm mysql-community-libs-compat-5.7.24-1.el7.x86_64.rpm mysql-community-server-5.7.24-1.el7.x86_64.rpm

#如果安装过mariadeb安装后会替换mariadb相关的库文件

3)修改配置文件，配合官方文档看

负责在主、从服务器传输各种修改动作的媒介是主服务器的二进制变更日志，这个日志记载着需要传输给从服务器的各种修改动作。因此，主服务器必须激活二进制日志功能。从服务器必须具备足以让它连接主服务器并请求主服务器把二进制变更日志传输给它的权限。

vim /etc/my.cnf

log-bin=mysql-bin	##文档最后加，二进制日志复制，id号来区分主机
server-id=1

4)启动mysql
systemctl start mysqld

5)会生成一个临时密码

cat /var/log/mysqld.log | grep password

2019-02-23T07:39:25.392617Z 1 [Note] A temporary password is generated for root@localhost: N7Nn<KkJsa!a

该临时密码虽然可以登陆MYsql但是不可以查看数据库，所以进行初始化

6)安全初始化
mysql_secure_installation
密码要求有大小写，数字，特殊字符，其他全选y
完成后可以登录数据库

7)创建并授权用来做复制的用户
在Master的数据库中建立一个备份帐户：每个slave使用标准的MySQL用户名和密码连接master。进行复制操作的用户会授予REPLICATION SLAVE权限。用户名的密码都会存储在文本文件master.info中

mysql> grant replication slave on *.* to repl@'172.25.58.%' identified by 'Wsp+123ld';

#即  网段为172.25.58的主机，均可以作为slave节点

mysql> show plugins;	     ##查看插件，因为有密码插件，所以密码必须设置为复杂的

mysql> show master status;	##查看master状态

对server2进行的操作：同对server1的操作步骤  1 -->  6

注意：步骤3中：只需给/etc/my.cnf文件末尾添加：

server-id=2 即可，不需要开启Binlog日志。
1)配置master信息

mysql> change master to master_host='172.25.58.1', master_user='repl', master_password='Wsp+123ld', master_log_file='mysql-bin.000002', master_log_pos=1004;


mysql> start slave;

mysql> show slave status\G    ##查看主从复制状态
Slave_IO_Running: Yes
Slave_SQL_Running: Yes        ##这两个参数是Yes，表示成功

注意：MASTER_LOG_POS 它是日志的开始位置,需要登陆master的mysql查看master的状态，来查看日志的结尾位置。

   其中master_log_file和maMASTER_LOG_POS的值为0，因为它是日志的开始位置ster_log_pos写在server1上执行show master status看到的信息

实验结果验证：

在master上进行创建数据库，然后再slave上检验，看是否同步过来了：

注意：写操作只能在master节点上做，因为master节点不会去同步slave节点的内容

mysql> create database westos;	##在server2上发现也能看到westos库
mysql> use westos
mysql> create table usertb (
    -> username varchar(10) not null,
    -> password varchar(15) not null);	##建表

mysql> desc usertb;	##查看表信息

mysql> insert into usertb values ('user1','123');	##插入数据

mysql> select * from usertb;	##查看

此时，在slave上登陆mysql，可以查看到，在master上创建的数据库，主从复制试验成功！！！

四、基于GTID的主从复制

什么是GTID呢？

   全称Global transaction identifiers:包含两部分，一部分为服务的UUid（保存在mysql数据目录的auto.cnf文件中）； 另一部分为事物ID。在整个复制架构中，GTID是不会变化的，即是在多个连环主从中也不会变。

引入GTID复制的原因：

在传统的复制里面，主从复制默认是通过pos（position）复制，就是说在日志文档里，将用户进行的每一项操作都进行编号（pos），每一个事件都有一个起始编号，一个终止编号，在配置主从复制节点时，要求其从master的pos开始同步数据库里面的数据，这也称作传统复制技术。当发生故障，需要主从切换，需要找到binlog和pos点，然后将主节点指向新的主节点，相对来说比较麻烦，也容易出错。

    在MySQL 5.6里面，不用再找binlog和pos点，我们只需要知道主节点的ip，端口，以及账号密码就行，因为复制是自动的，MySQL会通过内部机制GTID自动找点同步

即每次都要在master中查看这个position的值：

mysql> show master status;##查看master状态
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000002 |      691 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

    gtid（global transaction id 全局事物id）是对于一个已提交事务的编号,并且是一个全局唯一的编号。gtid实际上是由uuid+tid组成的，其中uuid是mysql实例的一个标识，tid则代表了该实例上交的事务数量，并且随着事务的提交单调递增。

    gtid就是类似pos的作用，不过它是整个mysql复制架构全局通用的，即在整个mysql冗余架构中，它们的日志文件里面事件的gtid的数值是一致的。

pos与gtid的区别:

两者都是日志文件里的一个标志，如果将整个mysql集群看作一个整体，pos就是局部的，gtid就是全局的。

gtid主从复制的原理：

（1）slave连接到master之后，把自己执行过的GTID(Executed_Gtid_Set)<SQL线程> 、获取到的GTID(Retrieved_Gtid_Set）<IO线程>发给master，master把slave缺少的GTID及对应的transactions发过去补全即可。

（2）当主服务器挂掉的时候，找出同步最成功的那台从服务器，直接把它提升为主即可。如果硬要指定某一台不是最新的从服务器提升为主， 先change到同步最成功的那台从服务器， 等把GTID全部补全了，就可以把它提升为主了

（3）由于同一事务的GTID在所有节点上的值一致，我们都不需要知道GTID的具体值。 通过gtid保证每个主库上提交的事务在集群中有一个唯一的id。这种方式强化了主备的一致性，故障恢复及其容错能力。

实验步骤如下：

show variables like 'log_%'; #查看二进制日志

1)先在server1上添加配置，#打开GTID模块

vim /etc/my.cnf 

log-bin=mysql-bin	##文档最后加，二进制日志复制，id号来区分主机
server-id=1       

gtid_mode=ON                      #打开GTID模块
enforce-gtid-consistency=true




systemctl restart mysqld    #重启服务


mysql> select * from gtid_executed;   此时在slave上才能看到GTID

 mysqlbinlog mysql-bin.000002    ##在server1上可以看到，之前做的操作都在里面

root@server1 mysql]# cat auto.cnf     ##看到server1的uuid
[auto]
server-uuid=f84e8de1-38a2-11e9-b78c-5254009afece

 

• 如果是基于position的主从复制：将一个事件拆开来复制，如果一个事件进行的过程中出现问题，那么复制也会出现问题
• 如果是基于gtid的主从复制：一个以事件为单位进行复制，如果一个事件进行的过程中出现问题，那么复制也不会出现问题 

2)在server2上配置 （mysql5.6 slave必须开启binlog日志 但是5.7中不是必须的）

gtid_mode=ON(必选)
enforce-gtid-consistency（必选）
log_bin=ON（可选）--高可用切换，最好设置ON
log-slave-updates=ON（可选）--高可用切换，最好设置ON
 

vim /etc/my.cnf         ##在文件最后添加

server-id=2

gtid_mode=ON
enforce-gtid-consistency=true

systemctl restart mysqld    ##重启

#先在server2上查看主从复制状态是否正常
 

[root@server2 mysql]# pwd
/var/lib/mysql
[root@server2 mysql]# cat relay-log.info    #查看relay-log

mysql> stop slave;    ##先停止复制
Query OK, 0 rows affected (0.01 sec)

mysql> CHANGE MASTER TO        ##修改master信息
    -> MASTER_HOST = '172.25.58.1',
    -> MASTER_USER = 'repl',
    -> MASTER_PASSWORD = 'Wsp+123ld',
    -> MASTER_AUTO_POSITION = 1;    ##启用gtid，它是自动的

mysql> start slave;

mysql> show slave status\G；   ##查看状态，可以看到下面两个参数是空的
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:

在server1上插入数据

mysql> insert into usertb values ('user2','123');
Query OK, 1 row affected (0.01 sec)

mysql> insert into usertb values ('user3','123');
Query OK, 1 row affected (0.00 sec)

再在server2上查看状态：

mysql> show slave status\G;
            Retrieved_Gtid_Set: f84e8de1-38a2-11e9-b78c-5254009afece:1-2
            Executed_Gtid_Set: f84e8de1-38a2-11e9-b78c-5254009afece:1-2        ##发现这两个参数变了，从1位置开始复制的
再查看gtid模式复制的起始和结束位置
mysql> use mysql

mysql> select * from gtid_executed;
+--------------------------------------+----------------+--------------+
| source_uuid                          | interval_start | interval_end |
+--------------------------------------+----------------+--------------+
| f84e8de1-38a2-11e9-b78c-5254009afece |              1 |            1 |
| f84e8de1-38a2-11e9-b78c-5254009afece |              2 |            2 |
+--------------------------------------+----------------+--------------+
2 rows in set (0.00 sec)

以上就是完成基于gtid主从复制的整个过程