MySQL数据复制，备份与恢复（仅介绍相关概念，原理。不涉及具体操作）_直接修改文件系统结构和复制出数据两种方式各有什么优势-CSDN博客

本文链接：https://blog.csdn.net/m0_37628958/article/details/105311388

MySQL数据复制，备份与恢复

前言：本来是想写Redis相关的文章的。但是想了下Redis现在虽说现在比较火，但是MySQL（或者另外两个数据库）才是基础。Redis就相当于是糕点，虽然能带来好处，但是相对来说，MySQL才是主食。没有Redis项目还能跑，不用数据库的项目，很少见。（但其实我特别想写Redis相关的文章，主要是内容少，就那么点）。因为Redis很多特性对比MySQL来理解其实比较容易。
因为想写篇Redis的持久化，主从复制的文章。先写MySQL的复制，备份与恢复，有很多知识点可以对比理解。

MySQL数据复制备份和恢复

1. 复制

1.1 复制概述

复制是MySQL内建的功能
本质是为了使一台服务器与其他服务器保持同步
构建基于MySQL的大规模，高性能应用的基础
是高可用性，可扩展性，灾难恢复，备份以及数据恢复的基础
有两种复制方式（基于行的复制与基于语句的复制）
复制可以扩展读，不能扩展写操作

1.2 解决问题

分布式数据存储：数据存储在不同的机器
负载均衡：将读操作放到不同的机器上处理，减少一台机器的压力
备份（要注意复制和备份是不一样的：我吃饭是为了活着，但是我活着不仅仅为了吃饭，而且吃饭也可以是为了享受美食）
高可用和故障切换
测试：一般用于预发布环境的测试，普通测试环境是不可以拿到生产环境的数据的

1.3 实现原理

1.3.1 复制实现

通过二进制日志文件（binary log）实现，有两种方式：
基于语句的复制：将语句写到bin log文件中，然后备库通过重放语句来实现复制。例如updata employee set chinese = '五更依旧朝花落' where id =258,日志文件直接记录这个语句。（类似Redis的AOF）
基于行的复制：根据行记录内容记录日志，例如某个记录被多次更新，基于行的复制就是根据复制时候行的内容来生产SQL脚本（类似Redis的AOF重写）

两者对比：
1.基于行的复制日志文件一般比基于语句复制的要小，因为基于语句复制可能某一调记录有十几次更新语句，基于语句的复制这些语句都要执行，基于行的复制只会有改行对应的一条语句；2.基于行的复制效率就更高；3.但是也不绝对，如果是update employee set salarydate = '2019-04-04' where id <300这种语句，你看基于语句的就一条语句，但是基于行的复制，就有300条语句（关于这一点，Redis里AOF重写没有这个缺点，因为Redis是非关系型数据库，而且是Hash索引的，一次只能更新一条数据）。

白嫖：

Redis的AOF: 将Redis语句存储到日志中
AOF重写：根据Redis中的内容，重写日志，使其更精简
Redis是K-V结构，索引是基于Hash的。单条数据操作很方便，但是没办法进行范围操作的
MySQL是关系数据库，索引基于B+树，范围查找很方便
当然Redis单条数据操作很快，O（1）嘛，而且为还存在内存中。但是如果是海量数据，首先一点，Redis是基于内存的，哪来这么多空间存，而且数据如果多了，就会有很多hash冲突。这个时候还得靠传统的关系数据库，存在磁盘，成本低些。而且查找效率还可以。

1.3.2 工作过程

1.主库将数据更改记录到二进制日志（bin log）中
2.备库将主库的日志复制到中继日志（Relay log）
3.备库读取中继日志，回放脚本

MySQL数据库是主库和备库，Redis里面叫主从。感觉就是叫法不一样
注意看第二步骤：是备库从主库复制获取数据，主要资源消耗大头在备库，对应的概念是：推模式（push）和拉模式（poll），可以回顾下Kafka。

1.4 其他

具体操作：咱不是DBA，咱也没干过。只能具体干的时候再去找，理论知识好，但这种还是需要下水才能学会游泳。
配置文件：在MySQL安装目录的data目录下找
拓扑结构：

基本原则：1. 一个主库可以有多个备库；2.一个备库只能有一个主库（确保数据一致性）3. 备库可以充当其他数据库的主库（允许多层结构）

结构：

一主库多备库：备库之间没有交互，仅链接到同一数据库（最常用）用途：①读写分离②把一份备库当做代用主库（故障转移）③备库放到远程数据仓库，用作灾难备份（故障转移主要是提高可用性，一般都在两个库在一个地方，灾难备份主要是备份，例如地震，放在一起岂不是全坏）
主库-分发主库-备库：上面一种的升级，主要是为了避免一个主库对应太多备库，影响主库性能（虽然复制性能消耗大头在备库，但还是有一点，你要一个主库对应10个备库可能看不出来消耗，但是你要是对应100个备库，那消耗也挺大），毕竟主库还要提供写操作
其他，没有上面常见，就不说了

层次越多，越不好管理，而且出错可能性更大（传悄悄话应该都了解，第一个人知道说的什么，传到最后一个人耳朵了就不知道是什么了）
主库提供写服务，而且只能主库提供写服务 想下基本原则就清除了
复制是有延迟的（主库的数据不会马上更新到备库），延迟要求越高（要求小延迟），成本就越大。保证最终一致性
复制会“浪费”很多空间，毕竟数据都是同一份复制了许多份。但是为了达到一些目的，这些成本是有必要花的

2. 备份与恢复

备份和复制是不一样的，复制可以是备份的一种手段。备份也可以有其他手段，例如基于快照的备份，这个效率要高不少。备份的目的是为了恢复

2.1 备份目的

备份的目的是为了恢复。所以能够恢复的备份（我之前就备份过备份过一些数据，没有试试能不能恢复，结果后面需要恢复的时候发现文件被损坏，不可用）才有效，需要测试的。一般来可以分为以下场景

灾难恢复
回退：数据删除了，但是后面因为某些场景需要这些数据（员工删库跑路了解下）
预发布测试
存档：例如支付宝不会将用户3年前的转账数据删除，虽然现在也不用

2.2 备份需求

备份要考虑目的，要求越高，成本越大，可以从以下方面考虑

可接受的恢复数据时间
需要恢复什么？整个数据库？单个表？还是先恢复热点数据
在后果不严重的情况下，可以忍受多少数据丢失

2.3 备份方案

在线备份与离线备份：备份是需要成本的，在线备份指的是数据库还在提供服务的时候进行备份，离线备份是停止服务（连续Java的STP），进行备份。离线备份事少，比较容易操作，但是对于24H提供服务的机器来说，停止服务不太可能。在线备份就需要考虑脏数据问题，而且要考虑系统的负载
逻辑备份与物理备份：逻辑备份是将数据导出成MySQL能够识别的文件，物理备份就是直接复制硬盘上的文件。物理备份执行起来最简单高效。但是如果只是恢复部分数据，物理备份是做不到的，物理备份只能全恢复

备份建议：

物理备份（基于快照）与逻辑备份（基于日志）：物理备份恢复更快，但是对于小库来说逻辑备份更好。而且基于日志的备份可以只恢复一部分数据，大多数时候都是恢复数据的某一部分，想那种全库都要恢复的情况很少（要是经常需要这种事，公司还开得下去吗）。物理备份做保险，逻辑备份用来小故障恢复
多个备份集（鸡蛋不能放在一个篮子）
演练备份是否有效（花了几个T空间，牺牲了并发来备份数据，结果发现无法用来恢复就搞笑了）

3. 小结

我们需要的是可以用来恢复的备份

复制的目的（故障转移，读写分离，备份）
复制实现原理（bin log）
复制工作过程（主写log，备拉log，备重放log）
备份目的（恢复）
备份方案（物理备份与逻辑备份）

仅简单描述了下，还有好多东西没写具体些 最终一致性，CAP，增量与差异备份，逻辑备份文件的两种类型，物理备份的种类，备份的恢复过程，崩溃恢复

每次写到最后感觉多了好多东西，而且还有好多东西没写进去。还是范围没控制。我目的是，每篇博客控制在3000字左右，少了没内容，多了内容太杂

															王师北定中原日，家祭无忘告乃翁
															博主：五更依旧朝花落
															发布时间：2020年4月4日20:55:59
															最后更改时间：2020年4月4日21:43:57（忘记上上传脑图了）