十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
一、双机热备的概念简单说一下,就是要保持两个数据库的状态自动同步。对任何一个数据库的操作都自动应用到另外一个数据库,始终保持两个数据库中的数据一致。 这样做有如下几点好处:
创新互联-专业网站定制、快速模板网站建设、高性价比汉阴网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式汉阴网站制作公司更省心,省钱,快速模板网站建设找我们,业务覆盖汉阴地区。费用合理售后完善,10多年实体公司更值得信赖。
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
server-id = n | 给服务器分配一个唯一的ID编号 |
log-bin [= filename] | 把对数据进行修改的所有SQL命令(也就是INSERT、UPDATE和DELETE命令)以二进制格式记入日志(二进制变更日志,binary update log)。这种日志的文件名是filename.n或默认的hostname.n,其中n是一个6位数字的整数(日志文件按顺序编号)。 |
开启服务
修改slave配置文件
server-id = n | 给服务器分配一个唯一的ID编号 |
[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(Global Transaction ID)是对于一个已提交事务的编号,并且是一个全局唯一的编号。GTID实际上是由UUID+TID组成的。其中UUID是一个MySQL实例的唯一标 识,保存在mysql数据目录下的auto.cnf文件里。TID代表了该实例上已经提交的事务数量,并且随着事务提交单调递增。下面是一个GTID的具 体形式:3E11FA47-71CA-11E1-9E33-C80AA9429562:23。
根据GTID可以知道事务最初是在哪个实例上提交的
GTID的存在方便了Replication的Failover
更简单的实现failover,不用以前那样在需要找log_file和log_Pos。
更简单的搭建主从复制。
比传统复制更加安全。
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端--------------------------------------------------------------------