数据库的备份和恢复
实验：
mysql忘记密码该如何操作呢？
skip-grant-tables
备份：完全备份 增量备份
完全备份：将整个数据库完整的进行备份
增量备份：在完全备份的基础之上，对后续新增的内容进行备份
备份的需求：
- 在我们的生产环境中，数据的安全至关重要，任何数据的丢失都可能产生非常严重的后果
- 数据为什么会丢失？可能是程序操作，运算错误，磁盘故障，不可预期的事件（地震之类），人为操作
冷备份：关机备份，停止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 root@192.168.233.110:/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