数据的备份和恢复

数据的备份和恢复

备份：完全备份 增量备份

完全备份：将整个数据库完整的进行备份

增量备份：在完全备份的基础之上，对后续新增的内容进行备份

备份的需求

1、在生产环境中，数据的安全至关重要、任何数据的丢失都可能产生非常严重的后果

2、数据为什么会丢失，程序操作，运算错我，磁盘故障，不可预期的时间（地震之类），人为操作

冷备份：关机备份，要停止mysql服务，然后进行备份

热备份：开机备份，无需关闭mysql服务然后进行备份

物理备份和逻辑备份

物理备份：对数据系统的物理文件（数据文件，日志文件）进行备份

逻辑备份：只是对数据库的逻辑组件进行备份（表结构）以sql语句的形式把库、表结构、表数据进行备份保存（直接在数据库系统中，删除全部文件，逻辑备份无法恢复）

物理备份：采用完全备份，对整个数据库进行完整的打包备份

优点：操作简单

缺点：数据库文件占用量是很大的，占用空间太大，备份和恢复的时间都很长，而且需要暂停数据库服务。

打包备份最好是把服务关掉，避免有新的数据进入，被覆盖，也可能会导致恢复失败

面试题

如何把本地的数据库迁移上云？

开放式问题，除了上课演示的之外

dis支持热迁移

热备份当中的逻辑备份

这是mysql自带的工具

mysqldump

mysqldump -u root -p123456 --databases kgc > /opt/kgc.sql

mysqldump -u root -p123456 --databases kgc kgc1 > /opt/kgc1.sql

mysqldump -u root -p123456 --all-databases > /opt/kgc3.sql

mysql -u root -p123456 -e 'show database';

-e：指定连接mysql之后执行完命令，自动退出

mysql1的全部数据库的逻辑备份文件，导入到mysql2，那么有有重名库是否会覆盖，不重名的库

会不会被覆盖掉

物理冷备份和物理热备份

：特点，简单

数据量，占用的备份空间比较大。

mysqldump：这是mysql自带的备份文件的命令

特点：方便，简单 但是只能基于逻辑上的表结构和数据恢复。物理删除之后再用逻辑回复会报错

他也可以作为数据迁移，占用大空间。比较物理备份想读来说站的空间要小的多。

全量 库 表

增量备份

mysqldump：支持增量备份

没有重复数据，备份量小，时间短

mysqldump增量备份恢复表数据期间，表会锁定

缺点 ：备份时锁表，必然会响应业务。超过10G，必然耗时比较长，导致服务不可用

增量备份的过程

1、mysql提供的二进制日志间接的实现增量备份

二进制文件怎么来

修改配置文件:

mysql二进制日志记录格式有三种

1、STAEMNET:基于sql语句

记录修改的sql语句，高并发情况下，记录sql语句时候的顺序可能会出错，恢复数据时可能会导致丢失和误差，效率比较高

2、ROW:基于行

精确记录每一行的数据，准确率高，但是恢复的时效率低

3、MIXED：即可以根据sql语句，也可以根据行

在正常情况下使用STATEMENT 一旦发生高并发，会只能自动切换到ROW行

mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000002

基于位置点来进行恢复

从某一点开始，恢复到最后

mysqlbinlog --no-defaults --start-position='位置点' 文件名 | mysql -u root -p

从开头一直恢复到某个位置

mysqlbinlog --no-defaults --stop-position='位置点' 文件名 | mysql -u root -p

指定点到指定结束点

mysqlbinlog --no-defaults --start-position='位置点' stop-position='位置点' 文件名 | mysql -u root -p

基于时间点进行恢复、

1、从某个时间点开始

mysqlbinlog --no-defaults --start-datetime='时间点' 文件 | mysql -u root -p

2、从开头，到指定的结尾的时间点

mysqlbinlog --no-defaults --stop-datetime='时间点' 文件 | mysql -u root -p

3、指定时间范围

mysqlbinlog --no-defaults --start-datetime='时间点' 文件 -stop-datetime='时间点' 文件 | mysql -u root -p

mysqlbinlog --no-defaults --start-datetime='23-11-06 17:48:38' 文件 -stop-datetime='' 文件 | mysql -u root -p

时间点是不能打错的

总结：

在生产中，通过binlog进行增量恢复时非常好用的方法

在工作中，我们能只需要对binlog文件进行备份 随时可以进行备份恢复

数据库迁移上云： 1、整体备份

mysqldump -u root -p --all-databases > /opt/all_database.sql

sz all_database.sql

云服务器

mysql -u root -p < /opt/all_database.sql

2、sql文件 如果复制到另外一个库，不是重名命的库，是否会被覆盖，相同的表名会不会覆盖，相同的库名会不会覆盖

mysqldump -u root -p --all-databases > /opt/all_database.sql

scp - r [email protected]:/opt/all_database.sql /opt

mysql -u root -p < /opt/all_database.sql

会被覆盖