MySQL数据库的备份与恢复

• mysql数据库的备份与恢复

  • 危机意识

    • 对于数据库要建立起数据一定会丢失，机器一定会坏的危机意识，从而要用各种备份手段提高容错率。

  • 数据库的备份类型

    • 物理角度

      • 冷备份（脱机备份）

        • 在数据库关闭状态下进行操作

      • 热备份（联机备份）

        • 在数据库运行时进行备份，依赖于数据库的日志文件，实际上是导出了一份脚本。

      • 温备份

        • 将数据库表格锁定，只读不能写，在进行备份

    • 逻辑角度

      • 对数据库逻辑组件进行备份（数据库对象）

    • 策略角度

      • 完全备份

        • 对数据进行完整备份，对整个是数据库，结构备份

        • 优点

          • 备份内容完整，是其它备份手段的基础

          • 操作简单方便

        • 缺点

          • 消耗存储资源大，备份时间长

      • 差异备份

        • 备份上次完全备份之后修改的为文件。

          • 例：周二做的差异备份也会把周一做的差异备份的数据包含进去。

        • 优点：

          • 恢复方便，占用存储资源相对较少

        • 缺点

          • 随着差异备份的次数越来越多，备份文件会越来越大。

      • 增量备份

        • 备份上次完全备份或增量备份后的修改的文件才会被备份。

          • 例；周一周二，增量备份只会备份当天的修改的数据，

          • 依赖于二进制事务日志

        • 优点

          • 消耗存储资源最少，能后进行精准恢复

        • 缺点

          • 恢复过程稍微麻烦

      • 策略角度的差异备份与增量备份都是基于完全备份的。

  • 实验操作

    • 因为可以进行多次重复恢复操作，因此可以通过设置主键，唯一索引，来确保数据的唯一性。

    • 冷备份

      • 在进行冷备份的备份和恢复过程中，都需要关闭mysql服务

      • 备份

        • 可以将整个mysql安装目录都做一个tar包

          • tar zcvf /存放目录/mysql_$(date +%F).tar.gz mysql/

            • $（date +%F）：提取纯数字的日期年月日。

          • 然后将原来的安装目录或重命名，删除都行

      • 恢复

        • 将tar包解压移动到原位置即可

    • 热备份

      • 利用mysql自带的mysqldump工具进行备份，不需要关闭程序

      • 备份

        • mysqldump -u用户 -p密码 库名 表名 > 备份文件存放位置与名称，建议以.sql结尾。

          • 导出表

        • mysqldump -u用户 -p密码 库名 > 备份文件存放位置与名称，建议以.sql结尾。

          • 导出库

        • mysqldump -u用户 -p密码 --all-databases > 备份文件存放位置与名称，建议以.sql结尾。

          • 导出所有库

          • 可在密码添加--opt选项加快备份速度

      • 恢复

        • 导入表

          • 如果已存在库，可以将其导入库中的任何一个表

            • mysql -u用户 -p密码 库名 <备份文件存放位置

        • 导入库

          • 需要注意的是导入库需要预先创建出库名才能被导入数据。

            • mysql -u用户 -p密码 库名 <备份文件存放位置

        • 导入所有库

          • 依然要保证这些库都已经存在或被创建出来

            • mysql -u用户 -p密码 <备份文件存放位置

    • 策略角度的备份

      • 备份前奏

        • 开启mysql数据库的二进制日志功能

          • log-bin=mysql-bin

            • 备份后的二进制日志文件的名称前缀

          • server-id=1

            • 服务id，可以为任意数字，但不能相同

          • binlog_format = MIXED

            • 二进制日志模板，

              • MIXED：混合模式

          • 方法二

            • 

          • 重启服务

        • 查看

          • 利用 mysqladmin -u用户 -p密码 flush-logs 命令生成一份二进制日志文件

          • mysqlbinlog --no-defaults 二进制文件名

            • 如果被加密则执行该命令

              • mysqlbinlog --no-defaults --base64-output=DECODE-ROWS 二级制文件名

            • --no-defaults

              • 不读取任何选项文件，其后需要直接跟日志文件，或起始停止位置

        • 测试

          • 插入多条insert语句，每条时间尽量间隔时间长一些，方便后续操作。

            • 模板

              • insert into users values('aaa','123456');

          • 误操作将表内容删除

        • 恢复

          • 常规恢复

            • 先恢复完全备份

              • mysql -u用户 -p密码 （库名，表名） <备份文件位置

                • 利用select * from 表名；可以查看到数据是不完整的。

              • 在进行增量备份的恢复

                • 首先查看要恢复的内容是否是要恢复的

                  • mysqlbinlog --no-defaults 二进制文件名

                • 确认之后在将其恢复

                  • mysqlbinlog --no-defaults 增量备份文件 | mysql -u用户 -p密码

                • 查看恢复结果

        • 精准恢复

          • 先查看二进制文件内容确定恢复位置，

          • • 

              例如；利用at定位起始与结束位置

            • 需要注意的是一次完整的事务过程是包含commit的，因此恢复要恢复到commit部分

          • 在常规增量恢复中添加如下语句

            • mysqlbinlog --no-defaults --start-position='521' --stop-position='729' 增量备份文件 | mysql -u root -p

              • --start-position=：确定了起始at恢复的位置

              • --stop-position=：确定了结束at的位置

            • 也可以利用时间来恢复

            • • 

                需要将年月日的格式修改成x-x-x的格式

              • 将常规增量恢复语句中添加如下语句

                • mysqlbinlog --no-defaults --stop-datetime='2019-03-08 21:01:55' 增量备份文件 | mysql -u root -p

          • 也可以将at 与datetime掺起来用不过意义并不大。

  • 

将以上所有内容复制，拷贝到xmind 即可看到条理性总结，图片可能无法复制，需要手动截取。！！！

将以上所有内容复制，拷贝到xmind 即可看到条理性总结，图片可能无法复制，需要手动截取。！！！

将以上所有内容复制，拷贝到xmind 即可看到条理性总结，图片可能无法复制，需要手动截取。！！！