MySQL备份详解

最新推荐文章于 2024-08-26 19:47:37 发布

ღ᭄小艾ヅ࿐

最新推荐文章于 2024-08-26 19:47:37 发布

阅读量1.1k

点赞数

文章标签： mysql linux

本文链接：https://blog.csdn.net/qq_44944641/article/details/117047376

版权

一、MySQL备份概述：

1.备份和冗余的区别：

备份：能够防止由于机械故障以及人为误操作带来的数据丢失，例如将数据库文件保存在了其他地方
冗余：数据有多份冗余，但不等于备份，只能防止机械故障带来的数据丢失，例如主备模式，数据库集群

2.备份什么：

数据库：一堆物理文件的集合；日志文件（二进制日志）+数据文件+配置文件
①.数据文件
②.配置文件=>my.cnf
③.日志文件（主要是二进制日志文件）

扩展：MySQL体系结构（MySQL=>DBMS软件到底是由哪些层构成的）

1).存储引擎层(myisam与innodb引擎)：

存储引擎层：简单来说，就是数据的存储方式。在MySQL中，我们可以使用show engines 查看当前数据库版本支持哪些引擎，常见的数据存储引擎：innodb，myisam，ndb等等
常见面试题：请简述mysql的myisam引擎与innodb引擎的区别：
答：①.myisam引擎擅长数据的查询，支持全文索引
②.innodb引擎支持事务处理，行级锁，支持外键

2).存储层(数据文件与日志文件)：

①.myisam引擎：

问题：存储引擎到底是如何保存数据文件的？（myisam引擎）
先创建一个全新的数据库
在创建一个数据表
查看mysql目录下的data目录

*.frm：框架文件，定义数据表结构
*.MYI：index索引，主要用于存放索引文件
*.MYD：数据文件

②.innodb引擎：

这次我们用innodb引擎创建另一个数据表

*.frm：框架文件，定义数据表结构
*.ibd：索引文件+数据文件
其实innodb引擎不仅仅产生以上两个文件，其在外部data目录中也会产生一个文件（确切来说不能叫做产生文件，而应该叫做共享文件）

所以由此可见，innodb引擎的数据备份不能简简单单的通过拷贝方式实现，必须使用专业的备份工具

3).日志文件（MySQL中我们需要了解哪些日志）

日志类型	写入日志的信息
error错误日志	存放数据库的启动，停止，或运行时的错误信息（找ERROR）
binlog二进制日志	数据库的所有更改操作，不包含select或者show这类语句

①.error错误日志：

error错误日志的命令规则与存放的目录：/data目录下+主机名称.err
更改错误日志的存放位置：

在这文件的最后一行加入log_error=目录/日志名称

②.binlog二进制日志：

binlog二进制日志应用场景：
用于主从复制中，master主服务器将二进制日志中的更改操作发送给slave服务器，从服务器执行这些更改操作是和主服务器的更改相同
用于数据的恢复操作

binlog二进制日志如何开启？
默认binlog日志是关闭的，可以通过修改配置文件完成开启：

然后将数据库重启一下（service mysql restart）

3.备份过程须考虑的因素：

必须制定详细的备份计划（策略）（备份频率，时间点，周期）
备份数据应该放在非数据库本地并建议有多份副本
必须做好数据恢复的演练（每隔一段时间，对备份的数据在测试环境中进行模拟恢复，保证当出现数据灾难的时候能够及时恢复数据）
根据数据应用的场合，特点选择正确的备份工具
数据的一致性
服务的可用性

4.备份类型：

1).逻辑备份：

备份的是建表，建库，插入等操作所执行的SQL语句（DDL，DML，DCL）
适用于中小型数据库，效率相对较低。一般在数据库正常提供服务的前提下进行，如mysqldump,mydumper,into outfile（表的导出导入）等
备份实质：就是把要备份的数据导出成 .sql或 .txt文件

2).物理备份：

直接复制数据库文件
适用于大型数据库环境，不受存储引擎的限制，但不能恢复到不同的MySQL版本
一般是在数据库彻底关闭或者不能完成正常提供服务的前提下进行的备份，如：tar，cp，xtrabackup（数据库可以正常提供服务），lvm snapshot，rsync等等
备份的实质：对数据文件+配置文件+日志文件进行拷贝操作

3).在线热备（数据冗余，AB复制，主从复制）

MySQL的replication架构，如M-S | M-S-S | M-M-S等等
实时在线备份

5.备份工具：

1).社区版安装包中的备份工具：

在这里插入图片描述

2).企业版安装包中的备份工具：

3).第三方备份工具：

6.备份方法：

完全备份（全备）
增量备份（增量备份基于全量备份）

二、MySQL逻辑备份：

1.mysqldump基本备份：

mysqldump基本备份：
本质：导出的是sql语句；
优点：无论是什么存储引擎，都可以用mysqldump备成sql语句；
缺点：速度较慢，导入时可能会出现格式不兼容的突发状况，无法直接做增量备份；
提供三种级别的备份，表级，库级和全库级

mysqldump基本语法：

1).mysqldump表级备份与还原：

案例：把db_lin数据库中的tb_student数据表进行备份！（备份到/tmp/sql.bak）

案例：还原数据表，先在数据库中删除原先表！

然后数据表就回来了
第二种还原方式:
在进入mysql中，用source+.sql文件位置来进行还原
就可以了

2).mysqldump库级备份与还原：

案例：把db_lin数据库进行备份!

案例：还原db_lin数据库！

第二种还原方式:

3).mysqldump全库级备份：

在MySQL中，如果想使用mysqldump进行全库级备份，必须开启二进制日志！！

mysqldump高级选项说明：

–master-data参数其他说明：
1.恢复时会执行，默认是1
2.需要RELOAD privilege必须打开二进制文件
3.这个选项会自动打开–lock-all-tables，关闭–lock-tables

4).mysqldump总结：

2.逻辑导入导出（了解）：

无论是什么存储引擎，以下方式本身是一种数据导出的方法，同时可以用来辅助备份，它可以对一个表的其中一列或者某几列做备份。备份的是数据记录

1).导出（数据备份）：

案例：把tb_student数据表中的数据记录进行逻辑导出

出现以上问题的主要原因在于我们没有指定MySQL逻辑导出时指定的路径
解决方法：

这样子就成功导出数据了

2).导入（数据还原）：

使用方法2的时候，要求导出的文件必须和数据表名称完全一致！！！

3).数据导入案例（导入规则的文本文件）：

案例：把/etc/passwd文件中的数据导入到passwd数据表中
第一步：创建一个passwd数据表

第二步：把/etc/passwd拷贝到/tmp取名为passwd.txt

第三步：导入数据
选项说明：
fields-terminated-by：指定导出文件的分隔符为冒号
liness-terminated-by：指定每一行的结尾使用的符号，\n代表换行符

三、mysqldump+binlog实现增量备份：

1.什么是增量备份：

要有全量备份
继续增删改数据
再次需要备份的时候，不需要进行全量备份，只需要备份binlog日志文件即可（因为binlog日志记录了增删改操作的所有SQL语句）

2.增量备份实验步骤：

第一步：准备数据（前提）
第二步：开启二进制，然后做全量备份（全库备份）
第三步：继续对数据库进行增删改操作
第四步：假设发生了硬件故障导致数据丢失
第五步：恢复全量备份导出的数据（不完整，90%左右）
第六步：备份二进制日志，根据其信息（导入剩余的部分数据）

3.增量备份实践：

进行全库备份后，咱们再继续进行增删改操作！
我在这里插入了一条信息和删除了一条信息
模拟突然间发生故障，数据库丢失了！

开始进行数据恢复，马上把最新的二进制文件进行备份
得确保这个二进制文件有内容

先进行全库的备份！

这个时候数据库是恢复了，但是我还增加了一条记录，和删除了一条记录，但是这两条记录就没有显示出来了

通过binlog增量备份还原数据到100%（在此之间，必须学会怎么读二进制文件）
mysqlbinlog --start-position=4 --stop-position=636 /tmp/sql.bak/binlog.000002 | mysql -uroot -p

1).读二进制日志文件：

必须通过专业工具
mysqlbinlog /tmp/sql.bak/binlog.000002 ==> 重点找事故的临界点！！，确认at的位置

四、MySQL的物理备份：

1.xtrabackup备份介绍：

1).xtrabackup优缺点：

优点：
1.备份过程快速，可靠（因为是物理备份）
2.支持增量备份，更为灵活
3.备份过程不会打断正在执行的事务
4.能够基于压缩等功能节约磁盘空间和流量
5.自动实现备份检验
6.还原速度快

缺点：
1.只能对innodb表进行增量备份，myisam表增量备份时是全备
2.innobackupex备份myisam表之前要对全库进行加READ LOCK，阻塞写操作，若备份是在库上进行的话会影响主从同步，造成延迟。对innodb表备份不会阻塞读写

2).xtrabackup备份原理：

innobackupex首先会启动一个xtrabackup_log后台检测的进程，实时检测mysql的redo log的变化，一旦发现redo有新的日志写入，立刻将日志写入到日志文件xtrabackip_log中
物理拷贝innodb的数据文件和系统表空间文件idbdata1到对应的以默认时间戳为备份目录的地方
复制结束后，执行flush table with read lock操作进行全库锁表准备备份非innodb文件
物理复制 .frm， .myd， .myi 等等非innodb引擎文件到备份目录
查看二进制日志的位置
解锁表unlock tables
停止xtrabackup_log进程

3).xtrabackup软件的安装：

第一步：上传软件包及依赖库到linux服务器端

第二步：安装依赖库
rpm -ivh libev-4.15-3.el7.x86_64.rpm
第三步：安装xtrabackup软件
yum install percona-xtrabackup-24-2.4.7-2.el7.x86_64.rpm -y

4).xtrabackup全库备份与恢复：

备份核心思路：

使用innobackupex对数据库中的所有库进行全量备份，备份完成后，其不能立刻进行数据恢复（因为数据不完整）
预备阶段，备份过程中产生xtrabackup_log应用到全量备份集
模拟故障（删除数据）
进行全库恢复
测试验证

第一步：准备数据（准备一个innodb引擎的和一个myisam引擎的）

第二步：专门准备一个数据库备份的账号，开通相应的权限

第三步：使用innobackupex工具进行全库备份：

第一次运行报错：出现以上问题的主要原因在于我们的mysql.sock并不在/var/lib/mysql/mysql.sock这儿。为什么其会自动连接/var/lib/mysql目录下的mysql.sock呢？
答：原因1：可能在/etc目录下还有my.cnf文件，影响了innobackupex的执行。
答：原因2：innobackupex拥有自己的默认配置，默认读取了/var/lib/mysql/mysql.sock文件
解决方案：
方案1：把你的套接字文件创建一个软链接，放置于/var/lib/mysql/mysql.sock这个文件中

方案2：在innobackupex中添加一个-S的选项指定套接字

不管之前那条命令执行成功与否，都会生成文件，咱们先删除

命令执行成功后，在这个目录下就会有这么些文件了

第四步：预备阶段，把备份这段时间内产生的日志整合到全量备份中

第五步：模拟数据库故障
rm -rf /mysql_3306/data/*
pkill mysqld

再删除一次
这下子就啥也没了

第六步：快速的恢复数据库中的数据
rm -rf /mysql_3306/data/* 先清空，以确保没有其他因素的影响

第一次恢复报错：出现以上问题的主要原因在于，innobackupex工具无法找到MySQL中的数据目录
解决方案：把my.cnf配置文件传递给innobackupex，让其自动识别这个文件中的datadir

数据就回来了！！！！但是权限不对

第七步：恢复数据时，一定要记得更改文件拥有者以及所属组权限，否则mysql无法启动

第八步：启动MySQL，测试其是否正常

经过测试，一切正常！

5).xtrabackup增量备份与恢复：

第一步：准备数据
第二步：创建一个账号，专门用于备份
第三步：全量备份
innobackupex --user=admin --password=123456 /full_xtrabackup/
第四步：把全备过程中产生的日志进行整合

选项说明：
–apply-log：表示整合日志
–redo-only：表示只应用已经提交的事务，不回滚未提交的事务
注意：如果已经回滚了未提交的事务，那么就无法再应用增量备份（在某一时间段，产生了很多事务操作，事务处理==>开启事务，成功提交了事务，写入硬盘;失败了回滚事务，不写入硬盘）

第五步：修改数据，使其产生增量数据

第六步：做增量备份

选项说明：
–incremental：增量备份目录
–incremental-basedir：这个增量是相对于哪个全量的

第七步：把增量备份产生的数据以及日志文件整合到全量备份中

顺序不能颠倒！！
第八步：模拟数据库故障
第九步：数据恢复

第十步：更改权限

第十一步：测试验证
这是刚刚添加的两条记录，都备份进来了