企业 - MySQL主从备份

一、mysql主从备份原理

一、双机热备的概念简单说一下，就是要保持两个数据库的状态自动同步。对任何一个数据库的操作都自动应用到另外一个数据库，始终保持两个数据库中的数据一致。 这样做有如下几点好处：

1. 可以做灾备，其中一个坏了可以切换到另一个。

2. 可以做负载均衡，可以将请求分摊到其中任何一台上，提高网站吞吐量。  对于异地热备，尤其适合灾备。

二、mysql 主从备份工作原理

简单的说就是把 一个服务器上执行过的sql语句在别的服务器上也重复执行一遍， 这样只要两个数据库的初态是一样的，那么它们就能一直同步。

二、实现方式

MYSQL主从同步是在MySQL主从复制（Master-Slave Replication）基础上实现的，通过设置在Master上的binlog，使其处于打开状态；Slave通过一个I/O线程从Master上读取binlog，然后传输到Slave的中继日志中，然后使用SQL线程读取中继日志，并应用到自身数据库中，从而实现主从数据同步功能。

有两个服务器，演示了从一个主服务器（master）把数据同步到从服务器（slave）的过程。

对于一个mysql服务器，一般有两个线程来负责复制和被复制。当开启复制这个开关之后（start slave）

1. 作为主服务器Master，会把自己的每一次改动都记录到 二进制日志 Binarylog 中。 （从服务器会负责来读取这个log，然后在自己那里再执行一遍。）

2. 作为从服务器Slave，会用master上的账号登陆到master上，去读取master的Binarylog,  然后写入到自己的中继日志Relaylog，然后自己的sql线程会负责读取这个中继日志，并执行一遍。到这里主服务器上的更改就同步到从服务器上了。

在mysql上可以查看当前服务器的主，从状态。 其实就是当前服务器的 Binary（作为主服务器角色）状态和位置。以及其RelayLog（作为从服务器）的复制进度。

三、复制的过程

该过程的第一部分就是master记录二进制日志。在每个事务更新数据完成之前，master在二日志记录这些改变。MySQL将事务串行的 写入二进制日志，即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后，master通知存储引擎提交事务。        下一步就是slave将master的binary log拷贝到它自己的中继日志。首先，slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事件，如果已经跟上master，它会睡眠并等待master产生新的事件。I/O线程将这些事件写入中 继日志。        SQL slave thread（SQL从线程）处理该过程的最后一步。SQL线程从中继日志读取事件，并重放其中的事件而更新slave的数据，使其与master中的数 据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。         此外，在master中也有一个工作线程：和其它MySQL的连接一样，slave在master中打开一个连接也会使得master开始一个线程。复制 过程有一个很重要的限制——复制在slave上是串行化的，也就是说master上的并行更新操作不能在slave上并行操作。

实验

实验环境

server2   master

server3   slave

master上下载包

mysql-5.7.17-1.el6.x86_64.rpm-bundle.tar

安装数据库

[root@server2~]# yum install -y mysql-community-client-5.7.17-1.el6.x86_64.rpm mysql-community-common-5.7.17-1.el6.x86_64.rpm mysql-community-libs-5.7.17-1.el6.x86_64.rpm mysql-community-libs-compat-5.7.17-1.el6.x86_64.rpm mysql-community-server-5.7.17-1.el6.x86_64.rpm 

[root@server3 ~]# yum install -y *

修改mysql的配置文件

[root@server2 ~]# vim /etc/my.cnf

开启服务

修改slave配置文件

[root@server3 ~]# vim /etc/my.cnf

开启服务

查看密码

安全配置向导

如下方法修改slave密码

mysql> alter user root@localhost identified by 'LH=redhat123';

master上进行授权

mysql> grant replication slave on *.* to cara@'192.168.122.13' identified by 'LH@redhat123' ；      用户授权

mysql> flush privileges;  刷新

master授权后，slave可以远程登录

master端查看

使 slave 与 master 建立连接，从而同步：
mysql> change master to master_host='192.168.122.12',master_user='cara',master_password='LH=redhat123',master_log_file='mysql-bin.000003',master_log_pos=1706;

slave端  mysql -p 登录

查看

[root@server3 mysql]# pwd
/var/lib/mysql
[root@server3 mysql]# cat master.info

[root@server3 mysql]# cat server3-relay-bin.index

mysql> show slave status\G;  查看slave状态

mysql> start slave;  开启slave

创建库westos,创建表usertb

在表中插入数据

更改密码

删除表中数据

[root@server2 mysql]# mysqlbinlog mysql-bin.000003   可查看master所做的操作

在slave上也可查看master上数据

深入了解复制-全局事务标识符（GTID）

1）什么是GTID

GTID(Global Transaction ID)是对于一个已提交事务的编号，并且是一个全局唯一的编号。GTID实际上是由UUID+TID组成的。其中UUID是一个MySQL实例的唯一标 识，保存在mysql数据目录下的auto.cnf文件里。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增。下面是一个GTID的具 体形式：3E11FA47-71CA-11E1-9E33-C80AA9429562:23。

2）GTID的作用

根据GTID可以知道事务最初是在哪个实例上提交的

GTID的存在方便了Replication的Failover

3）GTID比传统复制的优势

更简单的实现failover，不用以前那样在需要找log_file和log_Pos。

更简单的搭建主从复制。

比传统复制更加安全。

GTID是连续没有空洞的，因此主从库出现数据冲突时，可以用添加空事物的方式进行跳过。

4）GTID的工作原理：

master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。

slave端的i/o线程将变更的binlog，写入到本地的relay log中。

sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。

如果有记录，说明该GTID的事务已经执行，slave会忽略。

如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。

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

先关掉slave

修改配置文件/etc/my.cof

master

slave

重启服务

更录数据库，查看

master

slave

change master to master_host='192.168.122.12',master_user='cara',master_password='LH=redhat123',master_auto_position=1;

     --------------------------------------------------------------------master端--------------------------------------------------------------------

--------------------------------------------------------------------slave端--------------------------------------------------------------------