目录
前言
思考：
1. 如果只用redo log或者只用binlog可以吗？
2.xtrabackup实现mysql:全量备份+增量备份
(1)简介：
(2)下载：
(3)官方文档：
(4)源服务器和目标服务器准备：
(5)源服务器备份全量及一次增量数据库文件：
(6)目标服务器还原全量及一次增量数据库文件：
概述
1.binlog日志有两个最重要的使用场景:
2.binlog日志包括两类文件 :
3.数据恢复
（1）查看服务：
（2）配置文件：
（3）开始实验：
前言
- MySQL的二进制日志binlog可以说是MySQL最重要的日志，它记录了所有的DDL(create alter drop)和DML语句（除了数据查询语句select），以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。
思考：
1. 如果只用redo log或者只用binlog可以吗？
要搞清楚这个问题我们首先要了解MySQL服务层的日志都有哪些及更新修改数据的过程：
Type input.information 二进制(binnary)日志 记录了对MySQL数据库执行更改的所有操作 慢查询日志 记录所有执行时间超过 long_query_time 秒的所有查询或不使用索引的查询,这里的参数可以修改 错误日志 记录在启动，运行或停止mysqld时遇到的问题 通用查询日志 记录建立的客户端连接和执行的语句 中继日志 从复制主服务器接收的数据更改
| redolog日志(innodb.redolog) | 记录了更新后待写入磁盘的数据 |
| undolog日志 | 记录了更新修改前的记录 |
结论：mysql中redo log日志使用了一个WAL技术（也就是先写日志再写入磁盘，其中当innodb的更新数据到buffer pool时写入redolog日志时是写入redo buffer中而不是直接写入redo日志文件内）起到一个重要作用就是减少了因为更新修改的数据量过大而造成的磁盘多次i/o成本，并且在数据过大写满时它会将部分数据优先写入磁盘，来扩出新的空间，当出现宕机的情况，我们可以根据之前的redolog记录来进行恢复；binlog日志属于MySQL服务层的操作记录日志，它记录了所有更改的操作，对于数据的恢复起到很大作用；所以当你的MySQL使用的是INNODB引擎时他们两个日志需要一起使用会更好，当你的MySQL不是INNODB引擎时也就不存在redolog所以要看情况去使用。
2.xtrabackup实现mysql:全量备份+增量备份
(1)简介：
Percona XtraBackup是一款基于MySQL的服务器的开源热备份实用程序，备份时不影响数据库的正常读写，它可以备份MySQL5.1，5.5，5.6，5.7，8.0服务器上的InnoDB，XtraDB和MyISAM表的数据，以及带有XtraDB的Percona服务器。
(2)下载：
GitHub：
GitHub - percona/percona-xtrabackup: Open source hot backup tool for InnoDB and XtraDB databasesOpen source hot backup tool for InnoDB and XtraDB databases - GitHub - percona/percona-xtrabackup: Open source hot backup tool for InnoDB and XtraDB databases
https://github.com/percona/percona-xtrabackuppercona：
Percona Software downloads for databasesDownload free, open source software for MySQL including Percona Server, Percona XtraBackup, Percona Toolkit, Percona XtraDB Cluster, and more. Download now!
https://www.percona.com/downloads/
linux系统终端下载安装命令：
wget https://downloads.percona.com/downloads/Percona-XtraBackup-LATEST/Percona-XtraBackup-8.0.27-19/binary/redhat/8/x86_64/percona-xtrabackup-80-8.0.27-19.1.el8.x86_64.rpm
yum -y install percona-xtrabackup-80-8.0.27-19.1.el8.x86_64.rpm(3)官方文档：
Percona XtraBackup - Documentation — Percona XtraBackup 8.0 Documentationhttps://docs.percona.com/percona-xtrabackup/latest/index.html
(4)源服务器和目标服务器准备：
- 主机名修改、关闭防火墙和SELinux、同步时间、安装好MySQL 8.0.26 数据库(server、client)
server
client并且设置为开机自启动时间同步
- 监听端口并设置mysql服务为开机自启动、首次进入无密码然后修改密码并验证登录情况：
- 准备一个用于测试的库，如果有直接导入进去，没有就自己创建一个，这里我是自己创建的
(5)源服务器备份全量及一次增量数据库文件：
- 下载并安装xtrabackup、在源服务器上用xtrabackup完成一次全量的数据库文件备份；第一次修改数据库，并完成第一次增量备份；第二次修改数据库，并完成第二次增量备份；
最后将备份好的全部文件传送给目标服务器
- 一次全量的数据库文件备份直到出现completed OK！
- 查看备份是否存在
- 登录数据库插入两条数据
- 增量备份并查看ceshi文件夹下是否有increment
- 将全量及增量备份文件传送给client
(6)目标服务器还原全量及一次增量数据库文件：
- 下载并安装xtrabackup,关闭mysql服务,在目标服务器上用xtrabackup对源服务器传送过来的备份文件进行预处理，因后面有增量备份需要合并进来
- 在目标服务器上用xtrabackup对源服务器传送过来的备份文件进行预处理
- 因为后面需要合并增量备份处理，所以不做all的回滚
- 当增量备份时需要进行回滚
- 将备份文件copy到/var/lib/mysql下然后修改目录权限给mysql并查看
- 这里需要注意启动client的mysql服务，因为是全量备份了server的数据库所以首次登录的密码是server修改的密码
- 查看test库中ceshi表中数据，至此xtrabackup全量+增量实验结束
概述
1.binlog日志有两个最重要的使用场景:
MySQL主从复制：MySQL Replication在Master端开启binlog，Master把它的二进制日志传递给slaves来达到 master-slave数据一致的目的.
自然就是数据恢复了，通过使用mysqlbinlog工具来使恢复数据。
2.binlog日志包括两类文件 :
- 二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件
- 二进制日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查询语句select)语句事件。
3.数据恢复
- mysql8中的binLog默认是开启的，5.7默认是关闭的，可以通过参数
log_bin控制
（1）查看服务：
- 命令：show variables like '%log_bin%';
（2）配置文件：
- MySQL命令：vim /etc/my.cnf>>>log-bin=mysql-bin 确认是打开状态(mysql-bin 是日志的基本名或前缀名)
- MariaDB命令：vim /etc/mysql/mariadb.conf.d/50-server.cnf>>>log-bin=mysql-bin
- 重启mysqld服务使配置生效:service mysql restart
- 查看log-bin开启状态：show ariables like '%log_%';
（3）开始实验：
- 创建一个数据库test,在test中创建一张log表并插入数据，之后将数据进行全量备份到/tmp下:
- 查看所有binlog日志列表并再重新插入并更新表log内容:
- 然后后面不小心删掉了库test,再赶紧刷新logs形成新的日志让其他事务写入新的log中: flush logs;
- 立即备份记录数据的mysql-bin.000007到/tmp下：
- 查看刷新的日志mysql-bin.000007找到删除的语句行：方法一：mysqlbinlog --no-defaults mysql-bin.000007(这里如果不加--no-defaults会报错因为mysqlbinlog无法识别binlog日志中配置的default-character-set=utf8mb4指令)方法二：登录mysql服务器查看 show binlog events in 'mysql-bin.000007';
- 先将之前完全备份的数据恢复：
- 但是此时并没有恢复后面更新修改的数据：
- 使用binlog完全恢复，首先将/var/lib/mysql下的mysql-bin.000007复制到/tmp中然后将其重定向到000007.sql，再用vim编辑将DROP语句删除，保存后再将000007.sql传到mysql中，至此数据就恢复了：
- 在恢复全备数据之前必须将该binlog文件移出，否则恢复过程中，会继续写入语句到binlog，最终导致增量恢复数据部分变得比较混乱
因为没有将binlog文件移出所以导致了后面增量恢复出错
