Mysql——传统的主从复制和GDIT（异步复制跟半同步复制）

一.什么是mysql的主从复制

数据库是按照数据结构来组织、存储和管理数据的仓库。每个数据库都有一个或多个不同的 API 用于创建，访问，管理，搜索和复制所保存的数据。我们也可以将数据存储在文件中，但是在文件中读写数据速度相对较慢。

MySQL 主从复制概念：

• MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。
• MySQL默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。

Mysql主从复制的原理：

mysql要做到主从复制，其实依靠的是二进制日志。

假设主服务器叫A，从服务器叫B；主从复制就是B跟着A学，A做什么，B就做什么。那么B怎么同步A的动作呢？现在A有一个日志功能，把自己所做的增删改查的动作。全都记录在日志中，B只需要拿到这份日志，照着日志上面的动作施加到自己身上就可以了。这样就实现了主从复制。

MySQL 主从复制主要用途：读写分离

• 在开发工作中，有时候会遇见某个sql语句需要锁表，导致暂时不能使用读的服务，这样就会影响现有业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。

• 数据实时备份，当系统中某个节点发生故障时，可以方便的故障切换

MySQL主从复制涉及到三个线程：一个运行在主节点（log dump thread），其余两个(I/O thread, SQL thread)运行在从节点

主节点 binary log dump 线程：

• 当从节点连接主节点时，主节点会创建一个log dump线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，甚至在发动给从节点之前，锁会被释放。

从节点I/O线程：

• 当从节点上执行start slave命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点binlog dump进程发来的更新之后，保存在本地relay-log中。

从节点SQL线程：

• SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。

对于每一个主从连接，都需要三个进程来完成。当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个binary log dump进程，而每个从节点都有自己的I/O进程，SQL进程。从节点用两个线程将从主库拉取更新和执行分成独立的任务，这样在执行同步数据任务的时候，不会降低读操作的性能。比如，如果从节点没有运行，此时I/O进程可以很快从主节点获取更新，尽管SQL进程还没有执行。如果在SQL进程执行之前从节点服务停止，至少I/O进程已经从主节点拉取到了最新的变更并且保存在本地relay日志中，当服务再次起来之后，就可以完成数据的同步。

复制的基本过程如下：

• 从节点上的I/O 进程连接主节点，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
• 主节点接收到来自从节点的I/O请求后，通过负责复制的I/O进程根据请求信息读取指定日志指定位置之后的日志信息，返回给从节点。返回信息中除了日志所包含的信息之外，还包括本次返回的信息的bin-log file 的以及bin-log position；从节点的I/O进程接收到内容后，将接收到的日志内容更新到本机的relay log中，并将读取到的binary log文件名和位置保存到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我”；
• Slave 的 SQL线程检测到relay-log中新增加了内容后，会将relay-log的内容解析成在祝节点上实际执行过的操作，并在本数据库中执行。

注意：

• 要实施复制，首先必须打开Master 端的binary log（bin-log）功能，否则无法实现。
• 因为整个复制过程实际上就是Slave 从Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。

二.配置Mysql的主从复制（传统的）

第一步：配置主master——安装数据库

在物理机将要所用的安装包发送给主master虚拟机meng1

[root@foundation11 ~]# scp -r  mysql-5.7.24-1.el7.x86_64.rpm-bundle.tar root@172.25.11.1:/mnt

[root@meng1 mnt]# cd /mnt
[root@meng1 mnt]# ls
mysql-5.7.24-1.el7.x86_64.rpm-bundle.tar
[root@meng1 mnt]# tar xf mysql-5.7.24-1.el7.x86_64.rpm-bundle.tar 
将包解开之后，将不用的包删除
[root@meng1 mnt]# yum install -y *.rpm

[root@meng1 mnt]# vim /etc/my.cnf
 29 log-bin=mysql-bin        #开启log-bin日志
 30 server-id=1                #数据库id
[root@meng1 mnt]# systemctl start mysqld
[root@meng1 mnt]# cat /var/log/mysqld.log | grep password      #过滤初始密码

第二步：master——数据库安全初始化，创建用户并授权

对数据库进行安全初始化，修改密码（密码必须要由数字，大小写字母，特殊字母组成，四者缺一不可，且必须大于8位）

[root@meng1 mnt]# mysql_secure_installation    #设置密码为Wsp+123ld

[root@meng1 mnt]# mysql -uroot -pWsp+123ld
mysql>show databases;
mysql> CREATE USER 'repl'@'172.25.11.%'  IDENTIFIED BY 'Wsp+123ld';       #创建用户repl，可以在172.25.11这个网段通过密码登陆数据库
ysql> GRANT REPLICATION  SLAVE ON *.* TO 'repl'@'172.25.11.%';      #replication 表示授权复制的权限，*.*表示所有从数据库可以进行同步，通过repl这个用户
mysql> flush privileges;             #刷新MySQL的系统权限相关表
mysql> show variables like 'log_%';   #查看日志文件的状态
mysql> show master status;         #显示master状态

在物理机使用repl用户可以登陆数据库：

第三步：配置hang3虚拟机——slave

将1上面的数据库的rpm包复制过来并安装

[root@meng3 ~]# scp meng1:/mnt/*.rpm .
[root@meng3 ~]# ls
[root@meng3 ~]# yum install -y *

[root@meng3 ~]# vim /etc/my.cnf
server-id=2      
[root@meng3 ~]# systemctl start mysqld
[root@meng3 ~]# cat /var/log/mysqld.log | grep password

[root@meng3 ~]# mysql -uroot -pWsp+123ld
mysql> change master to
    -> master_host='172.25.11.1',
    -> master_user='repl',
    -> master_password='Wsp+123ld',
    -> master_log_file='mysql-bin.000002',       #二进制文件
    -> master_log_pos=1323;        #二进制文件此时的position

mysql> start slave;   #停止复制是stop  slave;
mysql> show slave status\G      #查看slave的状态

第四步：测试

meng1的数据库操作（master）：

mysql> create database westos;
mysql> use westos;

mysql> create table usertb (
    -> username varchar(10) not null,
    -> password varchar(20) not null);

mysql> desc usertb;

在meng3查看：

mysql> show databases;
mysql> use westos;
mysql> show tables;

在meng1插入

mysql> insert into usertb values ('haha','1323')
mysql> select * from usertb;

在meng3查看：

mysql> select * from usertb;

二.配置基于GDIT主从复制

• 在传统的复制里面，当发生故障，需要主从切换，需要找到binlog和pos点，然后将主节点指向新的主节点，相对来说比较麻烦，也容易出错。mysql数据库从5.6.5开始新增一种基于GDIT的复制方式。GTID (Global Transaction ID)是对于一个已提交事务的编号，并且是一个全局唯一的编号。 在MySQL5.6里面，不用再找binlog和pos点，我们只需要知道主节点的ip，端口，以及账号密码就行，因为复制是自动的，MySQL会通过内部机制GTID自动找点同步。GTID实际上 是由 UUID+TID 组成的。其中 UUID 是一个 MySQL 实例的唯一标识。
• mySQL5.6增加了GTID复制,GTID就是类似于pos的一个作用,不过它是整个mysql复制架构全局通用的,就是说在这整个mysql冗余架构中,它们的日志文件里事件的GTID值是一致的
• 主从复制：默认是通过pos复制(postion),就是说在日志文档里,将用户进行的每一项操作都进行编号(pos),每一个event都有一个起始编号,一个终止编号,我们在配置主从复制时从节点时,要输入master的log_pos值就是这个原因,要求它从哪个pos开始同步数据库里的数据,这也是传统复制技术。

多线程复制（基于库），在MySQL 5.6以前的版本，slave的复制是单线程的。一个事件一个事件的读取应用。而master是并发写入的，所以延时是避免不了的。唯一有效的方法是把多个库放在多台slave，这样又有点浪费服务器。在MySQL 5.6里面，我们可以把多个表放在多个库，这样就可以使用多线程复制。

通过GDIT保证每个主库上提交的事务在集群中有一个唯一的ID.这种方式强化了数据库的主备一致性，故障恢复以及容错能力。

基于GTID复制实现的工作原理：

• 主节点更新数据时，会在事务前产生GTID，一起记录到binlog日志中。
• 从节点的I/O线程将变更的bin log，写入到本地的relay log中。
• SQL线程从relay log中获取GTID，然后对比本地binlog是否有记录（所以MySQL从节点必须要开启binary log）。如果有记录，说明该GTID的事务已经执行，从节点会忽略。如果没有记录，从节点就会从relay log中执行该GTID的事务，并记录到bin log。

在解析过程中会判断是否有主键，如果没有就用二级索引，如果有就用全部扫描。

pos与GTID有什么区别?

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

这个实验是在传统的基础上做的。

第一步：主master的配置

[root@meng1 mnt]# vim /etc/my.cnf
 29 log-bin=mysql-bin
 30 server-id=1
 32 gtid_mode=ON       #开启gtid模式
 33 enforce-gtid-consistency=true    #强制gtid一直性，用于保证启动gitd后事务的安全
[root@meng1 mnt]# systemctl restart mysqld

第二步：配置slave

[root@meng3 mnt]# vim /etc/my.cnf
30 server-id=2
32 gtid_mode=ON
33 enforce-gtid-consistency=true
[root@meng3 mnt]# systemctl restart mysqld

[root@meng3 ~]# mysql -uroot -pWsp+123ld
mysql> stop slave;         # 在从库端先停掉slave，然后重新创建连接
mysql> change master to master_host='172.25.11.1',master_user='repl',master_password='Wsp+123ld',master_auto_position=1;        如果进行change master to时使用MASTER_AUTO_POSITION = 1， slave连接master将使用基于GTID的复制协议
mysql> start slave;        
mysql> show slave status\G

第三步：测试

meng1上面插入数据：

[root@meng1 mnt]# mysql -uroot -pWsp+123ld
mysql> insert into usertb values('meng1','123');
mysql> insert into usertb values('meng2','123');

meng3上面查看：

mysql> use mysql
mysql> select * from usertb;
mysql> select * from gtid_executed;    #查询gtid表的信息

meng1上面查看gtid表的信息：

异步模式：

• MySQL主从复制默认是异步的模式，异步模式主master不管slave是否同步到数据，不需要接受从从节点返回的完成信息，就可以继续执行下一步，这种模式虽然效率高，但是准确性差

半同步模式：

• 半同步模式下master主节点只需要接收到其中一台slave从节点的返回信息，就会进行下一步；如果超过等待时间从节点没有返回信息，半同步模式就会自动切换成异步模式；这样做的目的可以使主从数据库的数据延迟缩小，可以提高数据安全性，确保了事务提交后，binlog至少传输到了一个从节点上，不能保证从节点将此事务更新到db中。性能上会有一定的降低，响应时间会变长。

全同步模式：

• 全同步模式是指主节点接受到所有从节点的返回信息，才会执行了下一步。

三、基于GDIT的半同步模式

第一步：主库安装服务插件，并且开启半同步复制

[root@meng1 mnt]# mysql -uroot -pWsp+123ld
mysql> use mysql
mysql> install plugin rpl_semi_sync_master  soname 'semisync_master.so';       #安装插件

mysql> select plugin_name,plugin_status     #查询是否可用
  -> from information_schema.plugins
  -> where plugin_name  like '%semi%';
+----------------------+---------------+
| plugin_name          | plugin_status |
+----------------------+---------------+
| rpl_semi_sync_master | ACTIVE        |
+----------------------+---------------+
1 row in set (0.00 sec)

mysql> set global rpl_semi_sync_master_enabled=1;    #开启半同步复制

mysql> show variables like 'rpl_semi_sync%';   #环境变量

mysql> show status like '%rpl%';    #状态变量

第二步：配置slave

[root@meng3 ~]# mysql -uroot -pWsp+123ld
mysql> use mysql
mysql> install plugin rpl_semi_sync_slave  soname 'semisync_slave.so';

mysql> select plugin_name,plugin_status
    -> from information_schema.plugins
    -> where plugin_name  like '%semi%';
+---------------------+---------------+
| plugin_name         | plugin_status |
+---------------------+---------------+
| rpl_semi_sync_slave | ACTIVE        |
+---------------------+---------------+
1 row in set (0.00 sec)

mysql> set global rpl_semi_sync_slave_enabled=1;
mysql> stop slave io_thread;            
mysql> start slave io_thread;
mysql> show variables like '%rpl%';

要重启从上的IO线程,如果没有重启，则默认还是异步复制，重启后，slave会在master上注册为半同步复制的slave角色

少了一张安装插件的图，记得安装～

第三步：测试

在meng3这个slave虚拟机上关闭i/o线程

mysql> stop slave io_thread;
Query OK, 0 rows affected (0.01 sec)

meng1上面插入数据

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

10过后变成异步模式，插入速度大大提升（因为不管你slave有没有同步到数据）：

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

mysql> show status like '%rpl%';    #查看状态

此时在主端发现半同步失败次数+2

• （1）Rpl_semi_sync_master_no_tx：表示没有成功接收slave提交的次数，也就是使用半同步失败的次数，10s后没有得到反馈信息，会转为异步复制
• （2）Rpl_semi_sync_master_yes_tx ：使用半同步成功的次数，数据的一致性能提高

meng1

mysql> show processlist;

然后从端会发现没有同步过来，再次打开IO线程后，数据才能同步过来，此时复制过来的是异步复制的结果

meng3

mysql> start slave io_thread;
Query OK, 0 rows affected (0.00 sec)

meng1

mysql> show processlist;

meng3查看，此时是异步复制传输过来的结果

mysql> use westos
mysql> select * from usertb;