数据库的备份和恢复

数据库的备份和恢复

实验：

mysql忘记密码该如何操作呢？

skip-grant-tables

备份：完全备份  增量备份

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

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

备份的需求：

1. 在我们的生产环境中，数据的安全至关重要，任何数据的丢失都可能产生非常严重的后果
2. 数据为什么会丢失？可能是程序操作，运算错误，磁盘故障，不可预期的事件（地震之类），人为操作

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

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

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

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

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

优点：操作简单

缺点：数据库文件占用量是很大的（1、占用空间太大2、备份和恢复的时间都很长3、需要暂定数据库服务）

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

面试题：

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

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

dts工具支持热迁移

热备份当中的逻辑备份

这是mysql自带的工具：

mysqldump

备份单个库：mysqldump -u root -p --databases kgc > /opt/test.sql

备份多个库：mysqldump -u root -p123456 --databases kgc kgc1 > /opt/test1.sql

备份所有库mysqldump -u root -p123456 --all-databases > /opt/test3.sql

mysql -u root -p123456 -e ‘show databases;’

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

删除root用户里面的kgc表：mysql -u root -p123456 -e ‘drop databases kgc;’

恢复数据库：mysql -u root -p < /opt/kgc.sql

备份多个表：mysqldump -u root -p kgc info1 info2 > /opt/kgc_info1-2.sql

恢复单个表：mysql -u root -p kgc1 < /opt/kgc_info1.sql

删除多个库：mysql -u root -p -e ‘drop table info1;’

mysql -u root -p -e ‘drop table info2;’

恢复数据表：mysql -u root -p < /opt/kgc_info1-2.sql

实验：

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

主机1：mysqldump -u root -p --all-databases > /opt/all.sql

主机2：scp [email protected]:/opt/all.sql /opt/

物理冷备份和热备份

特点：简单

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

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

特点：方便，简单。但是只能基于逻辑上的表结构和表数据恢复。物理删除之后再用逻辑恢复会报错。并且他也可以作为数据迁移。占用大空间。比较物理备份，相对来说占的空间要小得多

全量，库，表

增量备份：

mysqldump支持增量备份

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

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

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

增量备份的过程：

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

二进制文件怎么来的？

修改配置文件：

vim /etc/my.cnf

在那个=1后面添加两行

log-bin=mysql-bin

binlog_format = MIXED

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

1、STATEMNET：基于sql语句

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

2、ROW：基于行

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

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

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

查看备份的二进制文件的内容：mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000002

刷新命令：mysqladmin

断点：mysqladmin -u root -p flush-logs

基于位置点来进行恢复：

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

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

总结：

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

我们只需要对binlog文件进行备份，随时可以进行备份和恢复

查看通用查询日志是否开启：show variables like 'general%';

查看二进制日志是否开启：show variables like 'log_bin%';

查看慢查询日功能是否开启：show variables like '%slow%';

查看慢查询时间设置：show variables like 'long_query_time';

在数据库中设置开启慢查询的方法：set global slow_query_log=ON;

数据库迁移上云：

1、整体备份

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

3、增量备份，位置节点和时间点，注意一下断点

4、一个工具：xtrabackup

5、使用工具，要有完整的流程，从安装 使用 备份 结果 报错记录下来，形成文档

yum -y install xz

查看备份的二进制日志文件全部信息：mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000002

还原备份日志文件的内容：mysqlbinlog --no-defaults mysql-bin.000001 | mysql -u root -p