MySQL的备份与还原,非常规备份,全量备份,增量备份

MySQL的备份与还原,非常规备份,全量备份,增量备份,第1张

1:官方百万级别的测试数据库:

官方测试数据库github网址:https://github.com/datacharmer/test_db

下载到目录,解压即可,运行命令

2:自己创建简单测试数据库:

快速随机生成测试语言的网站:https://generatedata.com/

选择sql和想生成的字段,点击生成Generate!生成即可。

在MySQL输入生成的语句即可。

3:测试备份还原时用到的命令

删库跑路测试(先备份好)

还原后查询库的表数据是否完整。

采用复制整个数据存放目录

1:查看数据库数据存放位置

有两种方法:

1):在数据库中用命令 show variables like 'datadir' 查看

2):在配置文件中查看,配置了 datadir 目录的可查看。没有配置的默认为 /var/lib/mysql/ 位置

Linux中查看配置文件

2:复制目录或者目录下某个数据库名

3:还原时直接复制文件夹到数据库目录即可

mysqldump又可叫做全量备份。

参数 --databases 同 -B ,单独一个库,也可省略。

1、备份命令mysqldump格式

格式:mysqldump -h主机名 -P端口 -u用户名 -p密码 database 数据库名 >文件名.sql

备份testDatabase数据库

2、备份MySQL数据库为带删除表的格式

备份MySQL数据库为带删除表的格式,能够让该备份覆盖已有数据库而不需要手动删除原有数据库。

3、直接将MySQL数据库压缩备份

备份并压缩

4、备份MySQL数据库某个(些)表

备份testDatabase中的myTable表,不需要用参数 --databases 或者 -B

5、同时备份多个MySQL数据库

同时备份testDatabase和 employees两个库

6、备份服务器上所有数据库

参数 --all-databases 同 -A

7、还原MySQL数据库的命令

1) 不指定数据名还原,默认生成原数据库名称,还原所有数据库。

2) 指定数据名还原,还原指定单个数据库,需在数据库种预先创建一个testDatabase名称。

3) 还原压缩的MySQL数据库

4) 进入数据库用source导入

增量备份是针对于数据库的bin-log日志进行备份的,增量备份是在全量的基础上进行 *** 作的。增量备份主要是靠mysql记录的bin-log日志。

1:查看是否开启bin-log日志

进入mysql输入命令可查看。

显示如下为开启状态,日志文件在/var/lib/mysql/以binlog.00001的格式保存。

如未开启,需要在配置文件种配置

2:查看目前使用的bin-log日志文件

进入mysql查看命令。

显示如下,目前使用的是binlog.000022文件,所有 *** 作都记录在此文件。

查看当前testDatabase的表myTable数据如下,

3:刷新日志,使用新的日志文件(备份)

在命令端执行命令

日志文件从 binlog.000022 变为 binlog.000023

这时相当与已经备份成功,备份文件即为上次的binlog.000022日志文件。

4:删除数量,从日志还原数据

1) 删除ABC行

查询以及没有ABC行列。

2) 恢复数据ABC行

退出mysql,在命令端用mysqlbinlog命令恢复到binlog.000022日志状态。

进入数据库再次查看数据,ABC已经恢复。

增量备份完成。

通用规律只有使用 --all-databases (-A) 会 ERROR 1356,那就看看他到底备份了什么东西。于是喊上同事一起 less 看了下,上下扫了两眼。突然发现:1. 备份 SQL 文件里 DROP 掉了 mysql.proc;2. 后CREATE了一个新的 mysql.proc;3. LOCK TABLES 和 UNLOCK TABLES 中间居然没有备份 CREATE ROUTINE 任何数据?这不就是相当于每次导入全备都给我一个没有任何 sys schema routines 的全新 mysql.proc 表?那这不就异常的尴尬?

---- Table structure for table `proc`--

---- Dumping data for table `proc`-

真相大白在官方文档【sys-schema-usage】官方文档明确的告诉我们不会备份 sys 库。但在使用 mysqldump 在执行 --all-databases 会清空 mysql.proc 导致 sys 无法正常使用;这是一个 BUG,并且只存在于 MySQL 5.7.x !

1、mysql_upgrade install or upgrade sys schema

这个方案适用于 sys 库已经因为 mysqldump 导入而损坏的情况下使用。

注意:mysql_upgrade 在修理 sys 库的同时,还修理 mysql 库和用户库表(期间加锁且速度一般),有极小可能会误伤;使用 mysql_upgrade 的时候要加上 --upgrade-system-tables,不然会扫描用户库表。

2、全备时同时备份 sys 库

这个方案适用于需要还原的数据库,sys 库也不太正常的情况下使用;在全备后额外再备份一份 sys 库用于修复。

注意:不适用于做主从时使用它。

3、使用 databases 全备

这个方案适用于所有场景的全备需求,100% 安全。

4、使用 mysql-sys 开源代码

如果你的数据库 sys 全部中招了,又是生产库。那你只能用这个方法;

mysql-sys:https://github.com/mysql/mysql-sys

中记录了 sys 库的创建语句将文件下载到本地,然后根据数据库版本,执行以下命令即可。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5910086.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-08
下一篇 2023-03-08

发表评论

登录后才能评论

评论列表(0条)

保存