mysql备份恢复

MYSQL备份恢复

MySQL备份一般采取全库备份加日志备份的方式.

1、binlog

mysql的二进制日志记录着该数据库的所有增删改的操作日志, 可以使用mysqlbinlog命令来查看。

默认关闭的 在/etc/my.conf 开启 重启

指定路径

Binlog的用途 主从同步 恢复数据库

查看产生的binary log 注：查看binlog内容是为了恢复数据
bin-log因为是二进制文件，不能通过文件内容查看命令直接打开查看，mysql提供两种方式查看方式，我们先对数据库进行一下增删改的操作，否则log里边数据有点空。

重启开始一个新日志

查看MySQL Server上的二进制日志

查看二进制日志信息的命令：

语法格式：SHOW BINLOG EVENTS[IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]

查看指定二进制日志事件

SLAVE复制线程。

查看到文件中具体的内容并应于恢复场景还得借助mysqlbinlog这个工具。

语法格式： mysqlbinlog [options] log_file ...

mysqlbinlog的可用选项可参考man手册。

二进制日志文件的格式包含行模式、语句模式和混合模式，基于语句的日志中事件信息包含执行的语句等，基于行的日志中事件信息包含的是行的变化信息等。

2 方便查询SQL语句使用mysqlbinlog工具 -v （--verbose）选项，想看到更详细的信息可以将该选项给两次如-vv

先切换到binlog所在的目录下

查看mysqlbinlog 000001目录

mysqlbinlog和可以通过--read-from-remote-server选项从远程服务器读取二进制日志文件，这时需要一些而外的连接参数，如-h，-P，-p，-u等，这些参数仅在指定了--read-from-remote-server后有效。

无论是行模式、语句模式还是混合模式的二进制日志文件，被mysqlbinlog工具解析后都可直接应用与MySQL Server进行基于时间点、位置或数据库的恢复。

可以看出delete事件发生position是287，事件结束position是416

恢复流程：直接用bin-log日志将数据库恢复到删除位置287前,然后跳过故障点,再进行恢复

由于之前没有做过全库备份，所以要使用所有binlog日志恢复，所以生产环境中需要很长时间恢复，导出相关binlog文件

删除test数据库

利用binlog恢复数据

恢复成功

--start-datetime

从二进制日志中读取指定时间戳或者本地计算机时间之后的日志事件。

--stop-datetime

从二进制日志中读取指定时间戳或者本地计算机时间之前的日志事件。

--start-position

从二进制日志中读取指定position 事件位置作为开始。

--stop-position

从二进制日志中读取指定position 事件位置作为事件截至。

mysqldump介绍

mysqldump一般在数据量很小的时候（几个G）可以用于备份。当数据量比较大的情况下，就不建议用mysqldump工具进行备份了。

2）mysqldump可以针对单个表、多个表、单个数据库、多个数据库、所有数据库进行导出的操作

#mysqldump [options] db_name [tbl_name ...] //导出指定数据库或单个表

#mysqldump [options] --databases db_name ... //导出多个数据库

#mysqldump [options] --all-databases //导出所有

导出数据库test

完整备份 重新开启新binlog

数据库导入

实现mysqldum全库备份和binlog数据恢复

检查开启binlog 创建原始数据

方案：mysqldump全库备份+binlog还原

1、mysqldump备份方案：

每周一凌晨1点全库备份

2、备份步骤

模拟一个完整全库备份

备份mysqldump全库备份之前的binlog日志文件

模拟失误删除数据

创建tom3

刚才删除的数据（id=2）恢复回来了，但备份后产生的数据却丢失了所以还得利用binlog进一步还原因为删除是在全库备份后发生的，而mysqldump全库备份时使用--flush-logs选项，所以只需要分析全库备份后的binlog即mysql-bin.000002。

查看 log_bin 事件 可以看到删除日志

数据恢复删除之前

数据恢复删除之后

查看最终恢复结果