MySQL数据库日志总结(二)中，有哪些可以提出？
摘要：日志信息滚动切割 在应用binlog日志过程中，经常需要对日志文件进行日志切割（滚动更新），可以有效避免日志文件数据量过大问题； 在某些场景中，如果需要对binlog日志文件进行备份操作时，也可以对原有使用的binlog日志文件进行滚动更新
日志信息滚动切割
在应用binlog日志过程中，经常需要对日志文件进行日志切割（滚动更新），可以有效避免日志文件数据量过大问题；
在某些场景中，如果需要对binlog日志文件进行备份操作时，也可以对原有使用的binlog日志文件进行滚动更新；
常用的日志滚动更新方法：
# 方法一：
mysql> flush logs;
-- 滚动更新前的日志文件就会处于静止状态，不会在进行数据信息的更新
# 方式二：
[root@cheng ~ ]# mysql -uroot -p123456 flush-logs
# 方式三：
mysql> restart;
-- mysql 8.0之后支持的数据库中重启服务；之前的版本只支持shutdown关闭数据库；
[root@cheng ~ ]# /etc/init.d/mysqld restart
# 方式四：
mysql> select @@max_binlog_size;
+--------------------------+
| @@max_binlog_size |
+--------------------------+
| 1073741824 |
+--------------------------+
-- 配置binlog日志最大数据存储量，默认大小为1G，到达最大日志存储量也会进行自动切割；
日志信息清理方法
在系统中日志信息，随着时间的推移将会越来越多，将严重占用磁盘空间，因此需要对日志做相应清理工作；
对于日志信息常用的清理方式有两种：
方式一：进行日志信息自动清理
mysql> show variables like '%expire%';
+-------------------------------------+-----------+
| Variable_name | Value |
+-------------------------------------+-----------+
| binlog_expire_logs_seconds | 2592000 |
| expire_logs_days | 0 |
+-------------------------------------+-----------+
3 rows in set (0.00 sec)
-- 在最新数据库8.0中，可以以秒为单位进行日志信息清理，默认是30天进行日志清理，或者也可以以天为单位进行清理；
-- 在最先数据库8.0前，主要是以天为单位进行清理，但默认清理功能并未激活；
-- 在企业实战环境中，建议过期时间最少保留一轮全备周期以上，有条件最好是保留两轮+1；
方式二：进行日志信息手工清理
mysql> help purge binary logs;
-- 获取清理日志命令帮助信息
mysql> purge binary logs to 'mysql-bin.010'
-- 删除到指定日志文件前结束
mysql> PURGE BINARY LOGS BEFORE '2025-12-02 22:46:26';
-- 可以基于日志时间点信息进行日志清理
说明：在对数据库服务日志信息进行清理时，最好使用数据库服务自带的清理工具进行清理，不建议使用rm做日志清理；
日志信息远程备份：
可以实现将数据库中（特别是主库）生成的binlog日志文件，及时备份保存到专门的日志备份服务器中，并且整个备份操作都是在线的；
[root@cheng-01 ~]# mkdir -p /binlog_backup
[root@cheng-01 ~]# cd /binlog_backup/
[root@cheng-01 binlog_backup]# mysqlbinlog -R --host=192.168.30.101 --user=root --password=123456 --raw --stop-never binlog.000008 &
-- 备份过程可以放后台一直运行，但是需要注意当连接的数据库服务器停止或重启了，也会导致备份中断；
# 数据库服务多实例情况binlog日志备份
mysqlbinlog -R --host=10.0.0.51 -P 3306 --user=root --password=123456 --raw --stop-never binlog.000002 &
mysqlbinlog -R --host=10.0.0.51 -P 3307 --user=root --password=123456 --raw --stop-never binlog.000002 &
-- 需要考虑备份后日志文件名称一样的覆盖问题
远程备份命令参数说明：
参数信息
官方说明
解释说明
-R
--read-from-remote-server
Read binary logs from a MySQL server.
读取binlog日志文件从数据库服务端
-h
--host
Get the binlog from server
指定binlog日志文件存储服务器地址
-u
--user=name
Connect to the remote server as username
指定binlog日志服务器连接用户信息
-p
--password[=name]
Password to connect to remote server.
指定binlog日志服务器连接密码信息
--raw
Requires -R. Output raw binlog data instead of SQL statements, output is to log files
指定binlog日志信息记录二进制信息
--stop-never
Wait for more data from the server instead of stopping at the end of the last log
指定binlog日志信息将会一直备份记录
binlog.000008
代表从哪个binlog日志开始进行备份
分类日志信息配置：慢日志（slow_log）
慢日志主要是用于以文本形式记录数据库服务运行过程中，执行过程较慢的语句；
利用慢日志信息生成的信息，可以在日常巡检过程中，通过日志定位SQL语句性能问题；
1_1 日志信息基本配置
mysql> select @@slow_query_log;
+-------------------------+
| @@slow_query_log |
+-------------------------+
| 0 |
+-------------------------+
1 row in set (0.00 sec)
-- 此参数配置信息，表示是否激活启动慢日志记录功能，默认处于关闭状态
mysql> select @@slow_query_log_file;
+--------------------------------------------+
| @@slow_query_log_file |
+--------------------------------------------+
| /data/3306/data/wenC-01-slow.log |
+--------------------------------------------+
1 row in set (0.00 sec)
-- 此参数配置信息，表示慢日志文件保存的路径信息；建议日志文件路径与数据存放路径进行分离；
mysql> select @@long_query_time;
+---------------------------+
| @@long_query_time |
+---------------------------+
| 10.000000 |
+---------------------------+
1 row in set (0.00 sec)
-- 此参数信息配置，表示记录慢日志的条件，默认是大于10s执行的语句，就会记录为慢查询语句；(建议时间为0.01~0.1)
mysql> select @@log_queries_not_using_indexes;
+---------------------------------------------+
| @@log_queries_not_using_indexes |
+---------------------------------------------+
| 0 |
+---------------------------------------------+
1 row in set (0.00 sec)
-- 此参数信息配置，表示慢日志中会记录没有使用索引的语句信息；
# 修改日志默认状态（激活日志）：
mysql> set global slow_query_log=1;
mysql> set global long_query_time=0.01;
mysql> set global log_queries_not_using_indexes=1;
-- 可以对以上参数信息进行在线调整，也可以将以上参数编写到数据库my.cnf配置文件中，作为永久配置；
1_2 日志应用配置核实
mysql> use cheng;
mysql> show index from t100w;
mysql> alter table t100w drop index idx;
-- 删除数据表中索引信息
mysql> select * from t100w limit 100;
mysql> select * from t100w where id=10;
mysql> select * from t100w where id=20;
mysql> select count(*) from t100w group by num limit 10;
...
-- 模拟执行慢查询的操作语句
# 查看核实慢日志文件是否生成
[root@cheng-01 ~]# ll /data/3306/data/wenC-01-slow.log
-rw-r----- 1 mysql mysql 6842 11月 22 23:54 /data/3306/data/wenC-01-slow.log
[root@cheng-01 ~]# cat /data/3306/data/wenC-01-slow.log
/usr/local/mysql/bin/mysqld, Version: 8.0.26 (MySQL Community Server - GPL). started with:
Tcp port: 3306 Unix socket: /tmp/mysql.sock
Time Id Command Argument
# Time: 2022-11-22T15:41:03.849261Z
# User@Host: root[root] @ localhost [] Id: 490
# Query_time: 0.000446 Lock_time: 0.000143 Rows_sent: 100 Rows_examined: 100
use cheng;
SET timestamp=1669131663;
select * from t100w limit 100;
# Time: 2022-11-22T15:41:05.677310Z
# User@Host: root[root] @ localhost [] Id: 490
# Query_time: 0.000282 Lock_time: 0.000083 Rows_sent: 100 Rows_examined: 100
SET timestamp=1669131665;
select * from t100w limit 100;
# Time: 2022-11-22T15:41:06.630012Z
# User@Host: root[root] @ localhost [] Id: 490
# Query_time: 0.000242 Lock_time: 0.000075 Rows_sent: 100 Rows_examined: 100
SET timestamp=1669131666;
select * from t100w limit 100;
-- 会按照执行语句的操作时间顺序，进行慢查询日志信息的记录；
1_3 日志信息分析方法
[root@cheng-01 data]# mysqldumpslow -s c -t 3 /data/3306/data/wenC-01-slow.log
-- 按照慢查询语句的重复执行次数(c)进行排序(-s)，取出其中靠前(t)的前三名慢查询语句
-- 还可以扩展使用pt-query-digest更好的分析慢查询日志，支持图形化展示
-- what to sort by (al, at, ar, c, l, r, t), 'at' is default
al: average lock time
ar: average rows sent
at: average query time
c: count
l: lock time
r: rows sent
t: query time
数据库服务备份恢复
数据库服务备份恢复目的
在企业环境中，无论是安全人员、运维人员、开发人员、数据库管理人员等所有技术人员都有一个共同的职责：
保障数据安全，防止数据库损坏
数据库物理损坏：磁盘、文件系统、数据文件（可以利用主从、高可用、备份+日志恢复数据）
数据库逻辑损坏：drop、truncate、delete、update（可以利用备份+日志、延时从库）
其中对于数据库服务来说，保障数据库服务的数据安全需要考量两个重要的指标：
一定要保障数据不能丢失和泄露；
一定要保障数据存储服务的稳定；（业务7*24）
说明：为了保障数据信息不丢失，最好的处理方案就是做备份，甚至是做多副本备份，多区域备份；就算丢失损坏也能快速复原。
数据库服务备份恢复方式
1 数据库服务备份数据方式：
在企业中实现数据库服务数据备份的方式主要有两种方式：
① 物理方式
采用拷贝物理文件数据进行备份的方式，数据库服务物理数据文件存放路径是：/var/lib/mysql
实现方式：
可以在某个特定时间点停机或停止业务访问，然后利用cp和tar命令将物理数据文件备份或打包；
可以在任意时间节点在不停机不停止业务时，然后利用专业的xtrabackup(Percona Xtrabackup)热备工具进行数据库数据备份；
应用场景：
当企业数据库服务产生的需要备份的数据量在50G以上，可以选择物理备份（xtrabackup）；
② 逻辑方式
可以采用以SQL语句形式把数据库的数据导出保存备份为数据库文件（xxx.sql），文件中会含有大量SQL语句信息；
实现方式：
可以在任意时间节点在不停机不停止业务时，然后利用专业的mysqldump(MDP)逻辑备份工具进行数据备份；
可以在任意时间节点在不停机不停止业务时，然后利用二进制日志binlog文件实现逻辑备份数据操作；
可以在任意时间节点在不停机不停止业务时，然后利用主从数据库架构实现备份数据信息；
应用场景：
当企业数据库服务产生的需要备份的数据量在50G以内，可以选择逻辑备份（mysqldump）；
2 数据库服务备份恢复职责：
设计数据库备份策略：备份数据周期、选择的备份工具、应用的备份方式（全备 增量..）；
定期数据库备份检查：核实是否存在、确认备份文件大小；
安排数据库恢复演练：真实确认备份的数据，是否能够准确的做数据恢复；
真实数据库恢复能力：在数据库服务出现异常情况时，可以将数据库服务修复，并恢复丢失的数据信息；
关于数据库迁移升级：可以采用Mergeing方式（主从架构）、可以单独备份数据信息到新的数据库节点做恢复（逻辑导出）；
数据库服务逻辑备份实践
在进行数据库数据逻辑备份操作过程中，主要会运用mysqldump逻辑备份工具，可以实现本地或远程的数据备份；
利用mysqldump进行逻辑备份数据时，主要的备份逻辑是将建库、建表、数据插入语句信息导出，实现数据的备份操作；
基于mysqldump备份数据的逻辑原理，对于数据量比较小的场景（单表数据行百万以内），mysqldump备份工具做备份会更适合些；
在跨平台或跨版本进行数据库数据信息迁移时，mysqldump备份工具做备份也会比较适合，可以避免物理备份的兼容性问题；
说明：在一般情况下，对数据库进行数据恢复的时间耗费，大约是数据库进行数据备份的时间耗费的3~5倍。
工具命令使用语法：
[root@cheng ~]# mysqldump -u数据库用户 -p数据库密码 [备份参数] > /路径信息/数据库备份文件.sql
-- 在执行mysqldump命令时，也会用到数据库连接登录的基础参数：-u -p -S -h -P
工具命令常用参数：
序号
参数信息
官方说明
解释说明
01
-A
Dump all the databases
表示备份所有库中数据信息
02
-B
Dump several databases.
表示备份指定库中数据信息
03
-F
Flush logs file in server before starting dump
表示在备份启动前自动刷新日志文件
工具命令实践操作：
数据库备份恢复练习环境准备：
[root@cheng ~]# mkdir -p /database_backup
1 数据库全库备份操作练习实践命令：
将数据库中所有数据库全部备份（-A）
[root@cheng ~]# mysqldump -uroot -p123456 -A >/database_backup/all_database.sql
[root@cheng ~]# ll -h /database_backup/all_database.sql
-rw-r--r--. 1 root root 744K 6月 23 23:13 /database_backup/all_database.sql
-- 利用mysqldump命令备份的数据文件是纯文本文件，是可以进行查看或过滤的；***
说明：利用-A创建数据库备份数据时，在备份数据中会含有 create建库语句和use切换库语句，可以直接进行恢复操作即可；
2 数据库部分备份操作练习实践命令：
将数据库中单个数据库进行备份（-B）
# 进行数据库单库备份操作
[root@cheng ~]# mysqldump -uroot -p123456 -B cheng >/database_backup/cheng.sql
[root@cheng ~]# ll -h /databases_backup/cheng.sql
-rw-r--r--. 1 root root 2.0K 6月 23 23:21 /database_backup/cheng.sql
# 过滤部分内容后查看备份数据库文件信息：
[root@cheng ~]# egrep -vi '^-|^/\*|^$|lock' /databases_backup/cheng.sql
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `cheng` /*!40100 DEFAULT CHARACTER SET utf8mb4 */;
USE `cheng`;
DROP TABLE IF EXISTS `stu2`;
CREATE TABLE `stu2` (
`id` int(10) NOT NULL,
`name` varchar(20) NOT NULL,
`age` tinyint(2) NOT NULL DEFAULT '0',
`dept` varchar(16) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
INSERT INTO `stu2` VALUES (1,'cheng',35,'net sec'),(2,'oldgirl',25,'linux');
以上指定数据库备份完毕后，可以模拟删除相应数据，利用备份的数据库文件进行数据库恢复操作：
mysql> use cheng
mysql> show tables;
+------------------------+
| Tables_in_cheng |
+------------------------+
| stu2 |
+------------------------+
1 row in set (0.00 sec)
mysql> drop table stu2;
mysql> show tables;
Empty set (0.00 sec)
-- 模拟删除数据库中数据表信息，造成数据库中数据损坏
# 进行数据库数据复原恢复操作：
# 方式一：在数据库系统中加载数据库备份文件
mysql> source /database_backup/cheng.sql;
# 方式二：在操作系统命令行执行数据恢复命令
[root@cheng ~]# mysql -uroot -p123456 cheng </database_backup/cheng.sql
# 数据信息恢复完毕后检查数据库情况
mysql> show tables;
+------------------------+
| Tables_in_cheng |
+------------------------+
| stu2 |
+------------------------+
1 row in set (0.00 sec)
mysql> select * from stu2;
+----+---------+-----+-----------+
| id | name | age | dept |
+----+---------+-----+-----------+
| 1 | cheng | 35 | net sec |
| 2 | oldgirl | 25 | linux |
+----+---------+-----+-----------+
2 rows in set (0.00 sec)
将数据库中多个数据库进行备份（-B）
[root@cheng ~]# mysqldump -uroot -p123456 -B cheng world >/database_backup/cheng_world.sql
# 过滤部分内容后查看备份数据库文件信息：
[root@cheng ~]# egrep -vi '^-|^/\*|^$|lock' /database_backup/cheng_world.sql
说明：利用-B创建数据库备份数据时，在备份数据中会含有 create建库语句和use切换库语句，可以直接进行恢复操作即可；
3 数据表部分备份操作练习实践命令：
将数据库中单个数据表进行备份
# 备份指定数据库中的单个数据表：
[root@cheng ~]# mysqldump -uroot -pcheng123 cheng stu1 >/databases_backup/cheng_tables_stu1.sql
# 恢复指定数据库中的单个数据表：
[root@cheng ~]# mysql -uroot -pcheng123 cheng </databases_backup/cheng_tables_stu1.sql
将数据库中多个数据表进行备份
# 备份指定数据库中的多个数据表：
[root@cheng ~]# mysqldump -uroot -p123456 world city country >/database_backup/world_tables_city_country.sql
# 恢复指定数据库中的多个数据表：
[root@cheng ~]# mysql -uroot -pcheng123 world </database_backup/world_tables_city_country.sql
说明：数据库单表或多表进行数据备份时，在备份数据中不含有create建库语句和use切换库语句，需要建库并指定库再恢复数据；
数据库逻辑备份进阶参数
上文中已经提到mysqldump命令工具基本的数据库和数据表的备份方式，除了以上说明的参数用法，还有其他备份参数信息；
同样可以实现进阶方式的数据库信息备份保存：
数据库数据备份进阶方式一：利用命令参数 --single-transaction
这个参数的用法作用可以利用一个形象的例子去理解：比如在某个时刻班主任希望统计班级同学的数量情况，那么该如何统计准确呢？
方法一：
形象说明：锁门封闭统计，禁止人员在教室内外随意走动，取班级人数变化的静止状态的学生数量；
真实应用：锁表封闭备份，禁止数据库程序进行数据更新操作，实现静止锁表状态进行数据备份；（一般选择半夜操作）
方法二：
形象说明：瞬时拍照统计，允许人员在教室内外随意走动，但是会根据拍照时刻人员数量进行统计；
真实应用：瞬时节点备份，允许数据库程序进行数据更新操作，只把备份操作瞬间已有数据备份；
因此，利用--single-transaction参数进行数据备份，就等价于在备份的时候给数据库的数据拍了照，备份时候数据库可以继续更新；
命令参数官方信息详细解读：
对于InnoDB存储引擎的表，将会利用MVCC中的一致性快照进行备份；
在备份数据期间不要出现DDL操作语句信息，如果出现DDL操作语句，将会导致备份数据不一致；
--single-transaction
Creates a consistent snapshot by dumping all tables in a single transaction.
通过在单个事务中备份所有表时，会创建一致性快照
Works ONLY for tables stored in storage engines which support multiversioning (currently only InnoDB does);
仅适用于存储在支持多版本控制的存储引擎中的表（目前只有InnoDB）
对于InnoDB，会利用MVCC中一致性快照进行备份；
the dump is NOT guaranteed to be consistent for other storage engines.
这种方式的备份不能保证与其他存储引擎一致
While a --single-transaction dump is in process, to ensure a valid dump file
当--single-transaction参数应用在备份进程中时，确保备份文件的有效性
(correct table contents and binary log position),
含有正确的表内容和binlog日志位置点
no other connection should use the following statements: ALTER TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE, as consistent snapshot is not isolated from them.
在进行备份数据期间，不要出现相关DDL的操作信息，导致备份数据不一致；
Option automatically turns off --lock-tables.
数据库数据备份进阶方式二：利用命令参数 --master-data=2
数据备份痛点：在进行数据库全备+binlog恢复数据时，如何进行binlog的临界点（起点）截取操作？
在备份数据的时候会记录binlog日志位置点到备份文件中，这个位置点是上一次全备之后新增数据的临界点；
在未来数据库服务出现异常时，会先恢复全备的数据信息，然后恢复binlog日志临界点之后的数据信息；
在指定日志位置点进行备份的时候，生成的操作日志语句如下：
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000011', MASTER_LOG_POS=2335;
-- binlog.000011 表示临界点之后的文件信息
-- 2335表示全备进行时的位置点信息 binlog.000001 binlog.000002 binlog00003
命令参数官方信息详细解读：
利用此参数功能，可以实现自动记录位置点信息；
利用此参数功能，可以实现自动添加全局读锁（GRL）功能（在配合--single-transaction参数使用时，可以减少锁时间）；
--master-data[=#]
This option is deprecated and will be removed in a future version. Use source-data instead.
此选项已弃用，将在以后数据库服务的版本中删除，请使用source-data代替此参数使用；
--source-data[=#]
This causes the binary log position and filename to be appended to the output.
这个参数会导致binlog日志位置点信息和文件名信息会附加到输出中，即附件到备份文件中。
If equal to 1, will print it as a CHANGE MASTER command;
如果数值等于1，将输出显示change master的命令信息；
if equal to 2, that command will be prefixed with a comment symbol.
如果数值等于2，该命令将以注释符号作为前缀
This option will turn --lock-all-tables on, unless --single-transaction is specified too
这个参数在使用时，将会自动开启--lock-all-tables参数功能，除非也指定了--single-transaction参数信息；
(in which case a global read lock is only taken a short time at the beginning of the dump;
在这种情况下，全局读锁只在备份开始时占用很短的时间
don't forget to read about --single-transaction below).
不要忘记阅读一下--single-transaction参数功能说明
In all cases, any action on logs will happen at the exact moment of the dump.
在所有情况下，日志上的任何操作都将在备份的确切时刻发生
Option automatically turns --lock-tables off.
参数将自动关闭 --lock-tables参数功能
备份数据进阶方式实践：
# 进阶方式数据备份（不压缩备份）
[root@cheng ~]# mysqldump -uroot -pcheng123 --master-data=2 --single-transaction -A -B >/tmp/bak.sql
-- -B 表示在备份时添加use语句信息
# 进阶方式数据备份（压缩备份）
[root@cheng ~]# mysqldump -uroot -pcheng123 --master-data=2 --single-transaction -A -B|gzip >/tmp/bak.sql.gz
[root@cheng ~]# gzip -d /tmp/bak.sql.gz
-- 压缩数据解压命令
数据库数据备份进阶方式三：利用命令参数 -R -E --triggers
模拟时间-某周周二晚零点，企业数据库管理员进行一次数据库服务数据全备操作**
[root@cheng ~]# mysqldump -uroot -pcheng123 -B mdb --master-data=2 --single-transaction -R -E --triggers >/databases_backup/cheng_`date +%F`.sql
以上mysqldump备份中的特殊参数说明：
序号
参数信息
官方说明
解释说明
01
-R
Dump stored routines (functions and procedures)
表示进行数据库存储过程备份
02
-E
Dump events
表示进行数据库事件信息备份
03
--triggers
Dump triggers for each dumped table.
表示进行触发器信息备份
数据库数据备份进阶方式四：利用命令参数 --max_allowed_packet=64M
此参数表示允许进行传输的数据包大小，在某些时候如果备份的数据为大表数据，需要调整此参数信息；
如果没有正确的设置此参数信息，可能会导致备份大表数据时，会出现数据备份失败的情况；
结合以上参数信息，进行标准化数据备份操作：
# 数据库数据信息备份过程（全备）
[root@cheng-01 ~]# mysqldump -uroot -p123456 -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64M >/database_backup/full_`date +%F`
[root@cheng-01 ~]# ll /database_backup/
-rw-r--r-- 1 root root 51254551 11月 26 00:47 full_2022-11-26
# 数据库数据备份信息查看
[root@cheng-01 ~]# vim /database_backup/full_2022-11-26.sql
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '9d14be39-6423-11ed-bb21-000c2996c4f5:1-6';
-- 表示在进行数据恢复操作时，会将gtid1-6的事件信息删除掉，因为在之前备份数据中已经有了1-6的事件数据信息；
-- 因此，从GTID的编号来看，可以从编号7事件开始进行数据增量恢复；
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000013', MASTER_LOG_POS=1312;
-- 输出信息表示增量数据的临界点在binlog.000013日志文件的1312位置，同时是备份结束时的位置点；
数据库逻辑备份应用案例
项目实战介绍：
模拟企业生产场景，数据库管理人员误删除了数据库数据信息，通过mysqldump全备的部分数据信息，进行部分数据信息恢复；
再结合binlog日志文件增量数据信息，实现数据库增量数据恢复，最终实现数据库全部数据的完整复原。
项目实战背景：
在某某小型企业工作环境时，企业数据库服务数据存储量小于50G，每天会在23点进行前一天数据的全备操作，并已开启binlog功能；
项目故障说明：
在某周周三下午14点左右，由于开发人员连接数据库实例错误，导致企业数据库服务生产数据被误删除了，亟待相关人员解决；
故障发现流程：
用户发现故障问题出现：这种企业的网站业务管理的技术人员实力是极差的；
运营人员故障问题发现：这种企业的运营人员或产品经理必然是企业的核心；
开发人员故障问题发现：这种企业的开发人员必然是整个企业业务的主导者；
运维人员故障问题发现：这种企业的运维人员必然已经通晓玩转企业的架构；
安全人员故障问题发现：这种企业的安全维护团队必然是整个企业精英团队；
故障处理思路：
需要在网站首页或者应用程序首页显示业务端维护页；
检查利用mysqldump命令全备的数据文件、以及查看binlog日志功能是否已经开启；
利用部分全备数据和增量数据完成数据库所有数据复原恢复工作；
数据库数据完整复原恢复进行数据信息核验工作，一般此类工作可以交由相关业务部门进行核验测试；
数据信息核验工作完毕后，可以在此时业务中断状态下，进行一次停机冷备操作，彻底完成一次数据物理备份；
所有相关线上业务进行恢复运行，并进行业务恢复后的功能性测试，一般交由测试人员进行完成；
撤销维护页面通知消息，实现用户可以正常访问。
项目实战模拟：
1 模拟时间-某周周一~周二，正常网站用户访问网站进行数据库信息录入
mysql> flush logs;
-- 将binlog日志文件进行刷新，创建一个新的日志文件
mysql> create database mdb;
mysql> use mdb;
-- 模拟创建用户存储数据的数据库信息
mysql> create table t1 (id int);
mysql> create table t2 (id int);
-- 模拟创建用户存储数据的数据表信息
mysql> insert into t1 values(1),(2),(3);
mysql> insert into t2 values(1),(2),(3);
mysql> commit;
-- 模拟用户向数据表中添加新的数据
mysql> select * from t1;
mysql> select * from t2;
-- 检查用户创建的数据信息是否生成
2 模拟时间-某周周二晚零点，企业数据库管理员进行一次数据库服务数据全备操作
[root@cheng ~]# mysqldump -uroot -p -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64M >/database_backup/full_`date +%F`.sql
以上mysqldump备份中的特殊参数说明：
序号
参数信息
官方说明
解释说明
01
-R
Dump stored routines (functions and procedures)
表示进行数据库存储过程备份
02
-E
Dump events
表示进行数据库事件信息备份
03
--triggers
Dump triggers for each dumped table.
表示进行触发器信息备份
3 模拟时间-某周周二晚零点之后，模拟用户继续访问网站业务产生了增量的数据信息
mysql> use mdb;
mysql> create table t3 (id int);
mysql> insert into t3 values(1),(2),(3);
mysql> insert into t2 values(4),(5),(6);
mysql> commit;
4 模拟时间-某周周三下午14点，模拟系统相关技术人员误删除了数据库，并且已紧急跑路
mysql> drop database mdb;
项目实战复原：
01 修复操作-查看找寻数据库服务全备数据，并进行全备数据恢复
[root@cheng-01 database_backup]# ll
-rw-r--r-- 1 root root 51256606 11月 26 01:53 full_2022-11-26.sql
[root@cheng ~]# mysql -uroot -p123456
mysql> source /database_backup/full_2022-11-26.sql
-- 强调说明 强调说明 强调说明，此步骤操作了解作用后，请在后面进行操作，不要在此步骤就进行数据恢复
mysql> use mdb;
mysql> show tables;
+--------------------+
| Tables_in_mdb |
+--------------------+
| t1 |
| t2 |
+--------------------+
2 rows in set (0.00 sec)
-- 查看全备的数据是否恢复成功
02 修复操作-查看找寻数据库服务增量备份，并进行增量数据恢复
# 检索恢复binlog临界位置
[root@cheng ~]# vim /database_backup/full_2022-11-26.sql
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '9d14be39-6423-11ed-bb21-000c2996c4f5:1-6';
-- 表示在进行数据恢复操作时，会将gtid1-6的事件信息删除掉，因为在之前备份数据中已经有了1-6的事件数据信息；
-- 因此，从GTID的编号来看，可以从编号7事件开始进行数据增量恢复；
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000013', MASTER_LOG_POS=1312;
-- 输出信息表示增量数据的临界点在binlog.000013日志文件的1312位置，同时是备份结束时的位置点；
# 检索查看binlog日志文件获取误删除操作前的GTID
[root@cheng-01 ~]# ll /data/3306/data/binlog.*
-rw-r----- 1 mysql mysql 1833 11月 26 01:55 /data/3306/data/binlog.000013
-rw-r----- 1 mysql mysql 64 11月 26 01:50 /data/3306/data/binlog.index
-- 具体binlog日志是哪个，以企业具体情况而定，不一定是binlog.000013
mysql> show binlog events in 'binlog.000013';
+------------------+-------+------------------+-------------+-----------------+--------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+------------------+-------+------------------+-------------+-----------------+--------------------------------------------------+
| binlog.000013 | 2060 | Gtid | 1 | 2137 | SET @@SESSION.GTID_NEXT= '9d14be39-6423-11ed-bb21-000c2996c4f5:10' |
| binlog.000013 | 2137 | Query | 1 | 2238 | drop database mdb /* xid=840 */ |
+------------------+-------+------------------+-------------+-----------------+--------------------------------------------------+
-- 需要将GTID编号10的误删除数据库事件信息忽略，然后再进行数据信息的恢复
# 移动迁移binlog文件位置
[root@cheng ~]# cp /var/lib/mysql/binlog.* /databases_backup/
# 操作截取binlog文件信息
[root@cheng ~]# mysqlbinlog --skip-gtids --include-gtids='9d14be39-6423-11ed-bb21-000c2996c4f5:7-9' /data/3306/data/binlog.000013 >/database_backup/add_bin.sql
-- include-gtids是指定前面临界位置点，截取之后的日志文件信息
# 增量恢复binlog数据信息
mysql> set sql_log_bin=0;
-- 建议在进行数据日志恢复数据时，将数据恢复时执行的SQL语句信息，不做binlog日志记录；恢复后别忘在改为1；
mysql> source /database_backup/add_bin.sql
-- 完成数据信息的增量恢复
03 修复操作-进行测试核验数据信息是否完全恢复，并进行最终全量备份
# 核验检查恢复后的数据信息
mysql> use mdb;
mysql> show tables;
mysql> select * from t1;
mysql> select * from t2;
mysql> select * from t3;
# 完成核验之后数据完整备份
[root@cheng ~]# mysqldump -uroot -p -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64M >/database_backup/full_`date +%F`.sql
说明：数据库数据修复复原完毕后，别忘让开发人员或测试人员进行业务功能测试，最终让运维人员恢复业务上线。
数据库逻辑备份痛点分析
假设某个企业进行数据库服务的数据备份，将会采用数据库全备方案，每次全备会生成大约50G的数据信息；
并且每次数据库服务进行全备耗时大约15-30分钟，因此如果有需要进行数据恢复时，耗费时间大约3~5小时左右（备份时间的3-5倍）；
但是，在实际生产环境中，只是误删除（误修改）了一个10M大小的数据表，如何进行部分数据信息的快速恢复；
说明：此时需要实现部分单表数据信息恢复时，在实际企业生产环境中，并没有做指定的单表数据信息备份操作；
痛点解决思路：
只能通过已有的全备数据信息，配合已有binlog日志信息，进行指定表数据信息的恢复操作；
基于全备数据信息，可以将指定数据表的建表语句和插入语句提取出来，进行单表数据信息恢复（恢复全备前的数据）；
基于增量日志信息，可以将指定数据表的所有相关事件信息进行截取，进行单表数据信息增量恢复；
处理方法参考：
基于全备数据信息，获取指定数据表的建表语句和插入语句信息：
[root@cheng ~]# sed -e '/./{H;$!d;}' -e 'x;/CREATE TABLE `wenC`/!d;q' /database_backup/full.sql > /database_backup/createtable.sql
-- 获取指定表的建表语句信息；
[root@cheng ~]# grep -i 'INSERT INTO `wenC`' /database_backup/full.sql > /database_backup/data_insert.sql
-- 获取指定表的插入语句信息；
[root@cheng ~]# grep -i 'UPDATE `wenC`' /database_backup/full.sql > /database_backup/data_delete.sql
-- 获取指定表的修改语句信息；
[root@cheng ~]# grep -i 'DELETE FROM `wenC`' /database_backup/full.sql > /database_backup/data_delete.sql
-- 获取指定表的删除语句信息；
基于增量日志信息，获取指定数据表的增量变化的日志数据信息：
[root@cheng ~]# python3 binlog2sql.py -h 10.0.0.101 -P3306 -uroot -p123456 -d 数据库 -t 数据表 --start-file='binlog.00000N'
-- binlog2sql 截取指定单表的binlog数据，进行恢复/分析操作
数据库服务物理备份实践
在数据库服务运行使用过程中，除了上面介绍的逻辑备份数据方法，还可以采用物理方式备份数据信息；
物理备份数据方式又可以细分为冷备份和热备份两种，和逻辑备份相比，它的最大优点是备份和恢复的速度更快；
因为物理备份的原理都是基于文件的cp。
01 物理冷备份
冷备份其实就是停掉数据库服务，cp数据文件的方法；这种方法对MyISAM和InnoDB存储引擎都合适，但是一般很少使用，
因为很多应用是不允许长时间停机的。
进行备份的操作过程：
停掉MySQL服务，在操作系统级别备份MySQL的数据文件和日志文件到备份目录；
进行恢复的操作过程：
停掉MySQL服务，在操作系统级别恢复MySQL的数据文件，然后重启MySQL服务，使用mysqlbinlog工具恢复增量数据日志；
02 物理热备份
在MySQL中，对于不同的存储引擎热备份方法也有所不同，下面主要介绍MyISAM和InnoDB两种最常用的存储引擎的热备份方法；
数据库存储引擎应用：MyISAM
MyISAM存储引擎的热备份有很多方法，本质其实就是将要备份的表加读锁，然后再cp数据文件到备份目录：
方法一：使用mysqlhotcopy工具
mysqlhotcopy是MySQL自带的一个热备份工具，使用方法很简单：
[root@cheng ~]# mysqlhotcopy db_name [/path/to/new_directory]
-- mysqlhotcopy有很多选项，具体可以使用--help查看帮助信息；
参考官方链接说明：https://dev.mysql.com/doc/refman/5.6/en/mysqlhotcopy.html
方法二：手工锁表copy
在mysqlhotcopy使用不熟悉的情况下，可以手工来做热备份，操作步骤如下：
# 对数据库中所有表加读锁：
mysql> flush tables for read;
-- 然后cp数据文件到备份目录即可；
数据库存储引擎应用：InnoDB
ibbackup是Innobase公司的一个热备份工具，专门对InnoDB存储引擎进行物理热备份，此工具是收费的，但可以免费使用1个月；
Innobase公司已经于2005年被Oracle公司所收购。
使用ibbackup备份工具的备份步骤简要说明：
01 编辑用于启动的配置文件my.cnf和用于备份的配置backup-my.cnf
# 配置文件配置参考：my.cnf
[mysqld]
datadir=/data/3306/data
innodb_data_home_dir=/data/3306/data
innodb_data_file_path=ibdata1:100M;ibdata2:200M;ibdata3:500M:autoextend
innodb_log_group_home_dir=/data/3306/data
set-variable=innodb_log_files_in_group=2
set-variable=innodb_log_file_size=20M
# 配置文件配置参考：backup-my.cnf
[mysqld]
datadir=/data/3306/backup
innodb_data_home_dir=/data/3306/backup
innodb_data_file_path=ibdata1:100M;ibdata2:200M;ibdata3:500M:autoextend
innodb_log_group_home_dir=/data/3306/backup
set-variable=innodb_log_files_in_group=2
set-variable=innodb_log_file_size=20M
02 实现数据文件信息热备过程：
[root@cheng ~]# ibbackup /data/3306/my.cnf /data/3306/backup-my.cnf
... 省略部分信息...
-- ibbackup工具不会覆盖任何重名的文件，因此在新的备份开始之前，需要确保备份目录中没有重名文件，否则备份可能会失败
[root@cheng ~]# ll /data/3306/backup
-- 备份成功后，备份目录下包含有数据文件和日志文件等相关数据信息；
Xtrabackup（PXB）是Percona公司CTO Vadim参与开发的一款基于InnoDB的在线热备工具，属于物理备份数据工具；
具有开源、免费、支持在线热备、备份恢复速度快、占用磁盘空间小等特点，并且支持不同情况下的多种备份形式。
官方软件下载链接：https://www.percona.com/downloads/
对于数据库8.0.20版本，需要使用PXB 8.0.12+以上版本，对于数据库8.0.11~8.0.19，可以使用PXB 8.0正式版本；
PXB 8.0只能备份MySQL 8.0版本数据，不能备份低版本数据信息；如果想备份数据库服务低版本程序数据，需要下载使用PXB 2.4版本；
xtrabackup包含两个主要的工具：xtrabackup和innobackupex
xtrabackup 只能备份InnoDB和XtraDB两种类型的数据表，而不能备份MyISAM类型数据表；
innobackupex 是一个封装了xtrabackup的perl脚本，支持同时备份InnoDB和MyISAM，但对MyISAM备份时需要加全局读锁；
由于PXB属于第三方软件工具程序，因此需要进行单独下载安装：
# 进行软件程序上传
[root@cheng ~]# cd /usr/local/
[root@cheng-01 local]# rz -y
[root@cheng-01 local]# ll percona-xtrabackup-80-8.0.13-1.el7.x86_64.rpm
-r-------- 1 root root 13097340 11月 27 02:08 percona-xtrabackup-80-8.0.13-1.el7.x86_64.rpm
# 进行软件程序安装
[root@cheng-01 local]# yum install -y percona-xtrabackup-80-8.0.13-1.el7.x86_64.rpm
-- 利用yum方式安装本地的rpm包程序，可以有效解决软件依赖的问题；
Xtrabackup（PXB）属于物理备份工具（针对数据文件进行备份），具体备份逻辑如下：（支持增量备份数据）
在数据库服务运行期间，通过拷贝数据文件（实质拷贝的是数据页），进而实现数据备份目的；
在进行数据文件拷贝的同时，会将备份期间的变化redo日志信息同时进行备份（拷贝）；
Xtrabackup（PXB）属于物理备份工具（针对数据文件进行备份），具体恢复逻辑如下：
在进行数据恢复时，模拟了InnoDB Crash recovery（CR）的运行过程，需要将备份进行处理，才能进行数据恢复；
在进行数据恢复时，对于备份进行处理操作，特指的就是前滚操作（redo）和回滚操作（undo），从而解决数据恢复一致性问题；
Xtrabackup数据备份方式01：实现全量备份
# 全量备份操作：
[root@cheng-01 ~]# mkdir /data/backup/full -p
-- 进行物理备份的目标目录不能存在数据信息，需要指定一个空目录进行备份
[root@cheng-01 ~]# xtrabackup --defaults-file=/etc/my.cnf --host=192.168.30.101 --user=root --password=123456 --port=3306 --backup --target-dir=/data/backup/full
或者使用参数--datadir替换掉参数--defaults-file
[root@cheng-01 ~]# xtrabackup --datadir=/data/3306/data --user=root --password=123456 --port=3306 --backup --target-dir=/data/backup/full
-- backup参数信息表示进行全备操作
# 物理备份命令执行输出信息说明：
221127 02:46:11 >> log scanned up to (277574297)
-- 记录日志位置点信息，表示进行拷贝数据的checkpoint的SN号码，相当于磁盘当前数据页的SN号码；
Using undo tablespace './undo_001'.
Using undo tablespace './undo_002'.
Opened 2 existing undo tablespaces.
221127 02:46:11 [01] Copying ./ibdata1 to /data/backup/full/ibdata1
221127 02:46:11 [01] ...done
221127 02:46:11 [01] Copying ./sys/sys_config.ibd to /data/backup/full/sys/sys_config.ibd
221127 02:46:11 [01] ...done
221127 02:46:11 [01] Copying ./mysql.ibd to /data/backup/full/mysql.ibd
... 省略部分信息...
-- 进行相关数据文件、日志文件、共享表空间文件、数据表空间文件等文件的拷贝，并且拷贝过程是不会进行锁表操作的；
-- 数据表空间信息备份完毕后，会有提示字段信息，并且此时会锁定binlog日志文件，并将binlog日志文件复制到备份目录；
-- 在进行binlog日志文件备份时，会生成xtrabackup_binlog_info文件信息，用于记录物理备份后的二进制日志位置点；
-- 二进制日志文件备份完毕后，会释放binlog日志文件锁定状态，并再次检查checkpoint的SN号码，确认redo日志是否变化；
[root@cheng-01 backup]# ll /data/backup/full/
-- 可以看到将原有数据库的数据目录信息，已经基本迁移到指定的物理备份目录中；
Xtrabackup数据备份工具在热备操作后产生的特殊数据文件说明：
序号
文件名称
解释说明
01
xtrabackup_binlog_info
表示用于存储备份时的binlog位置点信息
02
xtrabackup_checkpoints
表示用于记录备份时的数据页LSN信息，主要用于接下一次备份，需要保证连续性；
03
xtrabackup_info
表示整体物理备份信息的总览
04
xtrabackup_logfile
表示存储在备份数据期间产生的新的的redo日志的信息；
05
xtrabackup_tablespaces
表示用于存储表空间的其余信息
Xtrabackup数据恢复方式01：全量备份恢复
模拟进行数据库数据破坏性操作：
[root@cheng ~]# pkill mysqld
[root@cheng ~]# rm -rf /data/3306/data/*
[root@cheng ~]# rm -rf /data/3306/logs/*
[root@cheng ~]# rm -rf /data/3306/binlog/*
进行数据库数据恢复的操作过程：
[root@cheng ~]# xtrabackup --prepare --target-dir=/data/backup/full
...忽略部分信息...
Shutdown completed; log sequence number 19214860
221127 16:31:58 completed OK!
-- 表示模拟CR过程，将redo日志进行前滚，undo日志进行回滚，让恢复数据信息保持一致性状态
[root@cheng ~]# xtrabackup --copy-back --target-dir=/data/backup/full
-- 将进行物理备份后的数据，再次进行还原恢复到备份前的目录中（拷贝回数据）
[root@cheng ~]# chown -R mysql.mysql /data/*
[root@cheng ~]# /etc/init.d/mysqld start
-- 重新设置数据目录权限，并重新启动恢复数据库业务
Xtrabackup数据备份方式02：实现增量备份
xtrabackup物理备份数据时，实现增量备份原理分析：
增量备份的实质是，基于上一次备份LSN变化过的数据页，进行相应的备份操作，从而可以不断实现增量备份操作；
在备份同时产生的新的变更，会将redo日志信息备份；
第一次增量备份时依赖于全量备份的，将来的恢复操作也要合并到全备中，再进行统一恢复；
说明：利用XPK增量备份数据，主要目的是减少频繁全备数据的时间开销，可以将每天增量的数据进行更快速的备份
# 增量备份准备：
[root@cheng-01 ~]# mkdir /data/backup/full -p
-- 提前准备好全量备份的目录；
[root@cheng-01 ~]# mkdir /data/backup/inc -p
-- 提前准备好增量备份的目录；
# 进行备份操作：
[root@cheng-01 ~]# xtrabackup --defaults-file=/etc/my.cnf --host=192.168.30.101 --user=root --password=123456 --port=3306 --backup --parallel=4 --target-dir=/data/backup/full
-- 进行全量备份操作，并且开启并发线程备份功能（--parallel=4），从而提高备份效率（建议4~8个）
mysql> create database pxb;
mysql> use pxb
mysql> create table t1(id int);
mysql> insert into t1 values(1),(2),(3);
mysql> commit;
-- 模拟登陆数据库，进行相关操作，实现增量备份的效果
[root@cheng-01 ~]# xtrabackup --defaults-file=/etc/my.cnf --host=192.168.30.101 --user=root --password=123456 --port=3306 --backup --parallel=4 --target-dir=/data/backup/inc --incremental-basedir=/data/backup/full
-- 进行增量备份操作
# 可以进行继续备份操作（了解）
[root@cheng-01 ~]# mkdir /data/backup/inc02 -p
-- 提前准备好增量备份的增量备份目录；
mysql> create database pxb02;
mysql> use pxb02
mysql> create table t1(id int);
mysql> insert into t1 values(1),(2),(3);
mysql> commit;
-- 模拟登陆数据库，进行相关操作，实现增量备份的效果
[root@cheng-01 ~]# xtrabackup --defaults-file=/etc/my.cnf --host=192.168.30.101 --user=root --password=123456 --port=3306 --backup --parallel=4 --target-dir=/data/backup/inc02 --incremental-basedir=/data/backup/inc
-- 进行增量备份操作的下一次增量备份
Xtrabackup数据恢复方式02：增量备份恢复
模拟进行数据库数据破坏性操作：
[root@cheng ~]# pkill mysqld
[root@cheng ~]# rm -rf /data/3306/data/*
[root@cheng ~]# rm -rf /data/3306/logs/*
[root@cheng ~]# rm -rf /data/3306/binlog/*
进行数据库数据恢复的操作过程：
# 准备相关备份日志信息
[root@cheng ~]# xtrabackup --prepare --apply-log-only --target-dir=/data/backup/full
-- 准备全量备份的日志；
[root@cheng ~]# xtrabackup --prepare --apply-log-only --target-dir=/data/backup/full --incremental-dir=/data/backup/inc
-- 准备增量备份的日志，并且将增量备份合并到全量备份中；
[root@cheng ~]# xtrabackup --prepare --target-dir=/data/backup/full
-- 在全量和增量数据合并后，在整体做日志信息的准备；
# 进行数据备份拷回操作
[root@cheng ~]# xtrabackup --datadir=/data/3306/data --copy-back --target-dir=/data/backup/full
或者
[root@cheng ~]# xtrabackup --copy-back --target-dir=/data/backup/full
-- 将进行物理备份后的数据，再次进行还原恢复到备份前的目录中（拷贝回数据）
# 重新启动恢复业务功能
[root@cheng ~]# chown -R mysql.mysql /data/*
[root@cheng ~]# /etc/init.d/mysqld start
-- 重新设置数据目录权限，并重新启动恢复数据库业务