MySQL实现主从复制及MySQL的半同步复制

前言：

(1)什么是主从复制

主从复制，是用来建立一个和数据库未完全一样的数据库环境，称为从数据库，主数据库

一般是准时的业务数据库。

 

(2)为什么要作主从复制

1、作数据的热备，作为后备数据库，主数据库服务器发生故障后，可以切换到从数据库继

续进行工作，避免数据丢失。

2、架构的扩张，业务量越来越大，IO访问频率过高，单机无法满足，此时作多库的存储，

降低磁盘I/O访问的频率，提高单个机器的I/O性能。

3、实现读写分离时数据库能支撑更大的并发，在报表中尤其重要，由于部分报表sql语句非

常的慢，导致报表影响前台的服务，如果前台使用master,报表使用slave，那么报表sql将不

会造成前台锁，保证前台的速度。

 

(3)主从复制的原理？

1、数据库有个bin-log二进制文件，记录了所有的sql语句

2、我们的目标就是把主数据库的bin-log文件的sql语句复制过来。

3、让其在从数据的relay-log重做日志文件中再执行一下sql语句即可。

4、下面的主从配置就是围绕这个原理进行的配置

5、具体需要三个线程来进行操作：

1、 binlog输出线程：每当有从库连接到主库的时候，主库都会创建一个

线程然后发送binlog内容到从库，在从库里，当复制开始的时候，从库

就会创建两个线程进行处理。

2、从库I/O线程：当START SLAVE语句在库开始执行后，从库创建一个I/O

线程，该线程连接到主库并请求主库发送binlog里面的跟新记录到从库上，

从库I/O线程读取主库binlog。输出线程发送的更新并且拷贝这些更新到

本地文件，其中包括relay log 文件

3、从库的SQL线程：从库创建一个SQL线程，这个线程读取从库I/O线程

写道relay log更新事件并执行。

可以知道，对以每一个主从复制的连接，都有三个线程，拥有多个从库的主库

为每一个连接到主库的从库创建一个binlog输出线程，每一个都有它自己的I/O

线程和SQL线程。

 

(4)主从复制的过程？

1、主数据库（Master）将更新信息写入二进制日志文件中，这里

需要注意的是四版本的MYSQL数据库默认是不开二进制日志的，强烈

建议在安装数据库启动之前一定先检查一下二进制文件是否开启，即

使不做主从复制架构也要开启，否则当数据库启动之后再开启二进制

日志时需要重新加载数据库。

2、从数据库（Slave）开启一个I/O工作线程，通过该I/O线程与主数据库

建立一个普通客户端连接，主数据库会启动一个二进制日志传输线程，从数据库

的I/O线程通过这个传输线程读取主库上的变更时间，并将变更时间记录到中继

日志中（relay_lop），如果从数据库的IO线程读取速度追赶上主库的时间变更，

在没有得到跟新的通知时，IO线程会进入Sleep状态。

3、从数据库还会开启一个SQL Thread线程，这个线程从中继日志（relay_log）

中读取变更事件，并将变更同步到从数据库中，同时，可以通过配置选项，除了

将变更存储到数据库中，也可以将变更时间同时存储在从数据库的二进制日志中

 

(5)mysql主从复制存在的问题：

主库宕机后，数据可能发生丢失

从库只有一个sql Thread 主库写压力大，复制很可能延时

 

正文：

进行环境的配置：

master主库：server1(172.25.68.1)

salve从库    :  server2(172.25.68.2)

 

一、进行数据库的安装

(1)master机和slave机都安装mysql

这里我们使用：mysql-5.7.24-1.el7.x86_64.rpm-bundle.tar(可以进行官网的下载)

tar xf mysql-5.7.24-1.el7.x86_64.rpm-bundle.tar   ###进行压缩包的解压

(2)在server1和server2上进行软件的安装

yum install mysql-community-client-5.7.24-1.el7.x86_64.rpm  mysql-community-common-5.7.24-1.el7.x86_64.rpm  mysql-community-devel-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
  ###进行软件的安装

 

 

(3)在server1和server2上进行服务的启动

systemctl start mysqld      ###进行服务的启动

 

(4)进行数据库的初始化

server1同server2相同

cat /var/log/mysql.log  | grep password      ###进行初始化密码的查询
mysql_secure_installation                    ###进行数据库初始化

server1:

 

server2上：

 

二、主从异步复制的基本配置

master配置(server1)

1、进行配置文件的修改，并且重启动数据库

vim /etc/my.cnf          ###进行配置文件的编辑
systemctl restart mysqld  ###进行服务的重新启动

 

2、在server2上的从数据库的配置文件中进行配置

vim /etc/my.cnf          ###进行配置文件的编辑
systemctl restart mysqld  ###进行服务的重新启动

 

3、进入从数据库配置文件进行配置

mysql -p                   ###进入到数据库
mysql> grant replication slave on *.* to user@'172.25.68.%' identified by 'Wps+123dl';               ###建立用户并授权
show master status;        ###进行主库状态的查询

 

 

slave上(server2)

进行配置文件的修改；

vim /etc/my.cnf          ###进行配置文件的编辑
systemctl restart mysqld  ###进行服务的重新启动

 

进入数据库并进行配置

mysql -p       ###进入到数据库
change master to master_host='172.25.68.1',master_user='repl',master_password='Wps+123dl',master_log_file='mysql-bin.000001',master_log_pos=447;    ###和master建立认证联系
start slave;   ###开启slave
show slave status\G；  ###进行状态的查看

 

 

 

三、进行测试

在主数据库上(server1上)

create databases westos;           ###进行库的建立
show databases;                    ###进行库的查看
create tables uertb;               ###进行表的建立
insert into uertb values('westos','123');   ###进行表内容的添加
use westos;                        ###进入到指定的库
select * from uertb;               ###进行uertb表的查看

 

在从数据库上(server2)

show databases:                 ###进行库的查看
use westos;                     ###进入到westos库中
select * from uertb             ###进行uertn表内容的查看

 

总结：可以看到主库中新添加的数据在从库中同样可以完整的查看，实现了主

从复制及数据的一致性。

 

四、基于GTID的主从复制

GTID概念全局事务标示符(GTID)是一个唯一的标示符，它的创建并与原始服务器

(主服务器)上提交的每个事务关联，此标示符不仅对其发起的服务器是唯一的，

而且在给定复制设置中的所有服务器上都是唯一的，所有交易和所有的GTID之间，

存在一对一的映射。

 

msyql 是靠什么同步？

主从复制，默认是通过pos复制(postion),就是说在日志文档里，将用户的每一项操作

都进行编号(pos)，每一个event都有一个起始编号，一个终止编号，我们在配置主从

复制时从节点时，要输入master的log_pos值就是这个原因，要求他从那个pos开始进行

同步数据库里的数据，这一就是传统的复制技术，Mysql5.6增加了GTID复制，GTID

就是类似pos的一个作用，不过它是整个mysql复制结构全局通用的，就是说在整个

mysql冗余架构中,它们的日志文件里事件的GTID值是一致的。

 

从节点怎么知道要从那块进行同步？

上面也说到了,一开始自己设置的节点从主节点的日志文件里面的pos开始复制，

以后就自己去读上一次同步到那一块，接着同步。

 

pos与GTID有什么区别？

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

局部的，GTID就是全局的。

 

为什么会有这个区分呢？

大家知道，这整个集群架构的节点，通常情况下是master在工作，其他两个节点作为

备份，而且，各个节点的机器，性能不可能完全一致，所以在作备份时，备份的速度

就不一样，当master突然crash掉之后，马上开启从节点机器，接管master的工作，当

有多个从节点时，选择备份日志文件最接近(master)的那个节点，现在就出现情况了，

当slave1变成主节点时，那slave2就应该从slave1获取日志文件，进行同步。

如果使用的是pos，三者的pos不一致，slave2怎么去获取它同步的事件在slave1里的

pos,所有就有了GTID全局的，将所有节点对于同一个event的标记完全一致，当master

 crash 掉之后，slave2根据同一个GTID直接去读取slave1的日志文件，进行同步。

进行GTID的配置

 

1、在主节点上(server1)上进行配置文件的编辑

vim /etc/my.cnf     ###进行配置文件的编辑
gtid_mode=ON        ###设定自动开启
enforce-gtid-consistency=true
systemctl restart mysqld     ###进行服务的重启

 

2、在从库中(server2)上进行配置文件的编辑

vim /etc/my.cnf     ###进行配置文件的编辑
gtid_mode=ON        ###设定自动开启
enforce-gtid-consistency=true
systemctl restart mysqld     ###进行服务的重启

 

3、在server1上进行主库状态的查看(position位置会发生改变)

mysql -p                 ###进行数据库的的登陆
show master status;      ###进行主库的状态的查看

 

4、在server2上进行从库的设定

mysql -p                ###进行数据库的登陆
stop slave;             ###关闭之前的slave服务
change master master_host='172.25.68.1',master_user='repl',master_password''Wps+123dl',master_auto_position=1;        ###设定gtid模式
start slave;           ###开启slave服务
show slave status;     ###进行从库服务的查询

 

5、进行测试：

在主数据库中(server1)：

use westos;                                 ###进入到westos库中
insert into uertb values('hello','123');    ###进行新数据的插入
select * from uertb;                        ###进行表中信息的查看

在server2中进行数据的查看

 

五、MySQL半同步复制的搭建和配置原理

半同步复制：

什么是半同步复制？我们知道在默认情况下，MySQL的复制是异步的，

这意味着主服务器和从服务器之间是独立的，异步复制可以提供最佳

的性能，以名为主服务器在将更新的数据写入他的二进制日志(binlog)

文件中后，无需等待验证更新数据是否已经复制到从服务器中，就可

以自由处理其他进入的事务处理请求，但这也同时带来很高的风险性，

如果在主服务器或者从服务器发生故障，会造成主从数据的不一致，

甚至在恢复时造成数据丢失，半同步复制是MySQL5.5开始引入了一种

半同步复制功能该功能可以确保主服务器和访问链中从服务器之间的数

据一致性和冗余，在这种配置结构中，一台服务器和许多从服务器都进

行了配置，这样在复制拓扑中，至少有一台从服务器在父主服务器进行

事务处理前，必须确认更新已经收到并写入了其中丞日志(relay log)。当

出现超时，主服务器必须暂时切换到异步复制模式重新复制，知道至少有

一台设置为半同步复制模式的从服务器及时收到信息。

进行MySQL的半同步复制的配置：

1、在主库中进行配置(server1)

 

2、在从库中进行相关的配置(server2)

 

3、进行测试：

在主库上(server1)

 

在从库上(server2)

在从库上(server2)上

当STOP SLAVE IO_THREAD时;

在主库上进行相关的测试

 

在从库上进行查看：