mysql学习笔记（四）：备份和主从复制

目录

1备份

1.1备份方式

1.2备份数据库的内容

1.3问题

模拟一下环境，来更加了解备份过程

2.主从复制

1.1为什么需要主从复制？

1.2MySQL 主从复制概念

1.3MySQL 主从复制主要用途

1.4MySQL主从形式

1.5mysql延时备份

1.6MySQL 主从复制原理

1.7MySQL主从复制的过程

1.8MySQL 主从复制模式

1.9主从切换

离线主从复制实验：

在线主从复制

组复制

1.10MySQL的复制机制

1.11 GTID复制模式

1.12 mysql主从同步延时分析

1.13多线程复制MTS

---

1备份

1.1备份方式

裸文件（物理）备份：（授之以鱼）

文件内容是可读的，一般是文本文件。内容一般是由一条条SQL语句，或者是表内实际数据组成。这类方法的好处是可以观察导出文件的内容，一般适用于数据库的升级、迁移等工作。但其缺点是恢复所需要的时间往往较长。

逻辑备份：（授之以渔）

保存以逻辑数据库结构（create database和create table）和内容（insert）表示的信息，文件内容是可读的，一般是文本文件。内容一般是由一条条SQL语句，或者是表内实际数据组成。这类方法的好处是可以观察导出文件的内容，一般适用于数据库的升级、迁移等工作。但其缺点是恢复所需要的时间往往较长。你可以在其中编辑数据的值和表的结构，或者在不同机器架构上重新创建数据。

冷备（cold backup）

关闭mysql服务的情况下，复制相关数据库物理文件即可

热备（hot backup）

数据库运行中直接备份，对数据库操作没有任何影响

最普遍使用的方式

异地备份

scp

mysqldump

rsync（开源且免费，运行在tcp/ip）

Rsync远程同步_张会鑫的博客的博客-CSDN博客_rsync

异地备份的时间：考虑带宽，磁盘io

1.2备份数据库的内容

完全备份：对数据库进行一个完整备份

增量备份：在上一次完全备份的基础上，对更新的部分进行备份

差异备份：

日志备份：是指对MySQL数据库二进制日志的备份，通过对一个完全备份进行二进制日志的重做（replay）来完成数据库的point-in-time的恢复工作。

1.3问题

假设有一天5:30小王进行了全备，7:00的时候数据库被删除了，怎么还原数据库?

根据全备和二进制日志

模拟一下环境，来更加了解备份过程

备份：mysqldump

还原：mysql

查看二进制日志

基于时间点

1.删除所有日志文件
show BINARY LOGS;
reset master;
2，选择一个有数据的库，进行完备
create database meikoko;#建表
use meikoko;
CREATE TABLE PLAYERS(....);#创建有数据的库
insert into meikoko() values();
flush logs;#产生一个新的日志文件
 mysqldump -uroot -p123456 meikoko PLAYERS >/scout/players_backup.sql##进行完备
3.做DMl操作增加或者修改数据
insert into meikoko() values();
4.做删除数据库的表的操作
drop table PLAYERS;
5.恢复全备
mysql -uroot -p123456 meikoko 

2.主从复制

1.1为什么需要主从复制？

1.在业务复杂的系统中，有这么一个情景，有一句sql语句需要锁表，导致暂时不能使用读的服务，那么就很影响运行中的业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。

2.做数据的热备

3.架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。

1.2MySQL 主从复制概念

指使用两个或者多个数据库，数据可以从一个mysql数据库服务器的主节点复制（二进制文件）到一个或者多个节点，mysql默认采用异步复制。

1.3MySQL 主从复制主要用途

读写分离：

即使主库因为事务出现了锁表，也可以读从库来保障业务的正常运行

防止单点故障：

发生单点故障，数据全丢失（备份也可以解决）

高可用HA：

master服务器挂了，slave服务器可以成为主服务器

负载均衡：

单点部署数据库，会导致I/o访问的频率过高，有主从复制，增加了多个数据存储节点，降低了单个服务器的磁盘i/o

1.4MySQL主从形式

1一主一从

2一主多从，提高系统的读性能

3多主一从 （从5.7开始支持）

多主一从可以将多个mysql数据库备份到一台存储性能比较好的服务器上。

4双主复制

双主复制，也就是互做主从复制，每个master即使master，又是另外一台服务器的slave，这样从服务器也可以进行写操作，因为任何一方做变更，都会通过复制应用到另外一方的数据库

5级联复制

级联复制模式下，部分slave的数据同步不连接主节点，而是连接从节点。因为如果主节点有太多的从节点，就会损耗一部分性能用于replication，那么我们可以让3~5个从节点连接主节点，其它从节点作为二级或者三级与从节点连接，这样不仅可以缓解主节点的压力，并且对数据一致性没有负面影响。

log-save-update=on##开启二进制日志

1.5mysql延时备份

延时备份让slave滞后于master一段时间,当你误操作时只要立即停止slave的同步,即可轻松地从延时备份库中找回你误删的数据。

为什么需要延迟备份？

可以快速的恢复数据

比使用全备 + 二进制日志恢复更加快些

stop slave;

change master to master_delay = 20;


start slave;

1.6MySQL 主从复制原理

1.7MySQL主从复制的过程

想要实现主从复制，首先要开启二进制日志（bi_log，默认的是row level二进制文件）功能，因为复制过程就是slave从master段然后再自己身上完全同步二进制文件的操作；

1.当masteer服务器数据发生变化之后就会写到自己的二进制日志里面

2.从库要连接主库，要提供连接用户的条件（user，passwd，port，ip），还有从库要请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；

3.slave节点的i/o线程和主库的dump线程建立连接，通过提供的file名和position（位置）号，io线程想主库发起binlog请求

4.主库的dump线程根据从库的请求，将本地的binlog发送过去，里面包含日志信息和返回信息的文件和位置号

5.从io进程接收到后保存到本地的relaylog中，会记录送过来的消息到会记master.info中，以便下次读取的时候可以知道从binlog那个位置开始读

6.从服务器sql进程会readrelay日志的内容，并且将其replay，把应用过的记录到relay-log.info中，已经使用过得replay会自动清除

1.8MySQL 主从复制模式

异步模式（mysql async-mode）

mysql主从复制默认是异步模式，这种模式下，主节点不会主动push binlog到从节点，当slave节点连接的时候，会主动从master处获取binlog文件，并replay

这种情况下，如果发生故障，就可能节点没有同步到主节点最新的信息

半同步模式(mysql semi-sync)

MySQL :: MySQL 5.7 Reference Manual :: 16.3.9.2 Semisynchronous Replication Installation and Configuration

这种模式下，主节点只要接收到一台从节点返回的ACK消息就会commit；否则需要等待直到超时然后切换成异步模式在提交，这样做可以减小主从服务器的延迟，提高安全性

全同步模式

全同步模式是指主节点和从节点全部执行了commit并确认才会向客户端返回成功。

1.9主从切换

1.监控master和slave

2.选举新的master

3.其他的slave马上把master切换到新的master

4app马上写数据到新的master

离线主从复制实验：

参考官方文档MySQL :: MySQL 5.7 Reference Manual :: 16 Replication

1.准备两台服务器安装好mysql服务器，mysql版本一致
2.master上启动二进制日志，并且建立一个权限用户
https://blog.csdn.net/weixin_34246529/article/details/114332773
[root@mysql_fns_ab mysql]# cat /etc/my.cnf
.....
[mysqld]
.....
log_bin
server_id=1

.....
########### 
GRANT SELECT, RELOAD, LOCK TABLES, REPLICATION CLIENT, SHOW VIEW, EVENT, TRIGGER,PROCESS,REPLICATION SLAVE,SUPER ON *.* TO 'repl2'@'%' IDENTIFIED BY '123456';
flush privileges;#刷新权限
FLUSH TABLES WITH READ LOCK;##锁定我的表防止中间发生自动更新
SHOW MASTER STATUS;##看是哪个日志文件和位置号


3,进行数据库全备GRANT  ALL ON *.* TO 'repl2'@'%' IDENTIFIED BY '123456';
mysqldump -urepl -p123456 --all-databases --master-data > /scout/meibddump.db
4.slavel上，指定server id为2，并且将master的备份文件传输过来,并复制主服务器的数据
server_id = 2
#####
service mysqld restart
scp /scout/dbdump.db [email protected]:/root
service mysqld restart
mysql -uroot -pSanchuang123# 

在线主从复制

步骤一样，当不用mysqldump用xtrabackup

难点是要获得mysqldump数据的时候的二进制日志文件和当时的位置号

xtrabackup是一个在线的第三方备份工具，会帮我们记录位置号

组复制

1.10MySQL的复制机制

binlog记录模式

mysql主从复制的法案是有三种：基于mysql语句的复制，基于行的复制和和混合模式复制

1. SQL语句复制 (SBR)就是记录sql语句在bin log中，Mysql 5.1.4 及之前的版本都是使用的这种复制格式。优点是只需要记录会修改数据的sql语句到binlog中，减少了binloh的数量节约了io提高了性能，但缺点主从服务器去执行是一些操作比如now（），会得到不同的值。
2. 行复制(RBR)是mysql master将SQL语句分解为基于Row更改的语句并记录在bin log中，也就是只记录哪条数据被修改了，修改成什么样。优点是不会出现某些特定情况下的存储过程、或者函数、或者trigger的调用或者触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是修改table的时候会让日志暴增,同时增加bin log同步时间。也不能通过bin log解析获取执行过的sql语句，只能看到发生的data变更。
3. 混合模式(MBR)，MySQL NDB cluster 7.3 和7.4 使用的MBR。是以上两种模式的混合，对于一般的复制使用STATEMENT模式保存到binlog，对于STATEMENT模式无法复制的操作则使用ROW模式来保存，MySQL会根据执行的SQL语句选择日志保存方式。

1.11 GTID复制模式

在mysql5.6中不用知道binlog和pos节点了，只要slave和masteer成功连接，会自动复制，基于GTID自动找点同步

GTID复制实现的工作原理

1. 主节点更新数据时，会在事务前产生GTID，一起记录到binlog日志中。
2. 从节点的I/O线程将变更的bin log，写入到本地的relay log中。
3. SQL线程从relay log中获取GTID，然后对比本地binlog是否有记录（所以MySQL从节点必须要开启binary log）。
4. 如果有记录，说明该GTID的事务已经执行，从节点会忽略。
5. 如果没有记录，从节点就会从relay log中执行该GTID的事务，并记录到bin log。
6. 在解析过程中会判断是否有主键，如果没有就用二级索引，如果有就用全部扫描。

1.12 mysql主从同步延时分析

mysql主从复制都是单线程的操作，主服务器将日志写入binlog是顺序写入，效率很高

但是从服务器要去执行sql语句，当主库并发非常高的时候，产生的DMl数量超过了sql thread的处理速度，或者slave中有大型query语句产生了锁等待，延时就产生了

解决方案；

1采用蜂聚架构，mysql业务平行扩张，分散压力

2.单个库读写分离，一主多从，分散压力，主库压力没有这么大，保护主库

3.引入中间层（redis）

4.不同业务放在不同机器上面，分散压力

5.使用比主库更加好的服务器

1.13多线程复制MTS

MySQL并行复制(MTS)原理（完整版） - 孔个个 - 博客园