MySQL故障处置(一)

故障恢复一时爽，一直恢复一直爽😒…

故障背景

业务背景: 数据采集，采集时间主要集中在凌晨1点以后，上午12点之前，12点后采集任务可全部结束，当日新增数据导出，交由其他业务系统处理。
备份机制: 因机器的硬件资源等限制，未采取mysqldump进行备份，考虑到12点以后基本不会有数据变更，因此采用日终同步机制，备份整个/var/lib/mysql数据库目录。
故障原因: 台式机硬盘出现了坏道，损坏情况比较严重，断电关机以后无法正常启动。

故障发生后，进行了硬盘更换、重装系统等操作，最后一步是MariaDB的数据恢复。

MySQL数据目录

我们先来看看/var/lib/mysql中文件都有哪些:

$ ls -lrt
-rw-rw---- 1 mysql mysql         0 12月 10 23:08 multi-master.info
drwx------ 2 mysql mysql      4096 12月 10 23:33 CookBook
drwx------ 2 mysql mysql      4096 1月  22 22:04 mysql
drwx------ 2 mysql mysql      4096 1月  22 22:04 performance_schema
-rw-rw---- 1 mysql mysql        15 1月  22 22:04 mysql_upgrade_info
drwx------ 2 mysql mysql      4096 1月  22 22:47 dolphinscheduler
-rw-r--r-- 1 root  root          0 4月   9 23:25 debian-10.5.flag
-rw-rw---- 1 mysql mysql      2665 4月  10 16:44 ib_buffer_pool
-rw-rw---- 1 mysql mysql  79691776 4月  10 16:44 ibdata1
-rw-rw---- 1 mysql mysql        52 4月  10 16:44 aria_log_control
-rw-rw---- 1 mysql mysql    212992 4月  10 16:44 aria_log.00000001
-rw-rw---- 1 mysql mysql  12582912 4月  10 16:44 ibtmp1
-rw-rw---- 1 mysql mysql 100663296 4月  10 16:44 ib_logfile0

其中:
1、CookBook和dolphinscheduler为用户创建的两个Database目录;
2、mysql: 存储了MySQL的用户账户和权限信息，一些存储过程、事件的定义信息，一些运行过程中产生的日志信息，一些帮助信息以及时区信息等;
3、performance_schema: 主要保存MySQL服务器运行过程中的一些状态信息，算是对MySQL服务器的一个性能监控。包括统计最近执行了哪些语句，在执行过程的每个阶段都花费了多长时间，内存的使用情况等等信息;
4、multi-master.info: 主要是在Multi-Source Replication时使用;
5、mysql_upgrade_info: mysql_upgrade保存的版本号，用于快速检查是否已为此发行版检查所有表，以便可以跳过表检查;
6、ib_buffer_pool: 从MariaDB 10.0开始，在关闭MySQL时，会把内存中的热数据保存在磁盘里ib_buffer_pool文件中，在启动后，会自动加载热数据到Buffer Pool中;
7、ibdata1: InnoDB使用页为基本单位来管理存储空间，为了更好的管理这些页，InnoDB设计们提出了一个表空间的概念，划分为几种不同的类型:

系统表空间(system tablespace)
独立表空间(file-per-table tablespace)
通用表空间(general tablespace)
undo表空间(undo tablespace)
临时表空间(temporary tablespace)
……

ibdata1就是对应的系统表空间在文件系统上的表示。可以查看配置:

MariaDB [(none)]> show global variables like "innodb_data_file_path";
+-----------------------+------------------------+
| Variable_name         | Value                  |
+-----------------------+------------------------+
| innodb_data_file_path | ibdata1:12M:autoextend |
+-----------------------+------------------------+
1 row in set (0.001 sec)

可以看到ibdata1默认大小为12M，这个文件是自扩展文件，如果不够用会自动扩展。
8、aria_log_control: 与Aira存储引擎有关，其中包含有关Aria设置的信息(当前事务ID，唯一ID，下一个日志文件编号等)
9、aria_log: Aira日志文件(aria_log.%)
10、ibtmp1: MariaDB 10.2中引入的非压缩的innodb临时表的独立表空间，通过innodb_temp_data_file_path参数指定文件的路径，文件名和大小:

MariaDB [(none)]> show global variables like "innodb_temp_data_file_path";
+----------------------------+-----------------------+
| Variable_name              | Value                 |
+----------------------------+-----------------------+
| innodb_temp_data_file_path | ibtmp1:12M:autoextend |
+----------------------------+-----------------------+
1 row in set (0.000 sec)

11、ib_logfile0: Redo Log，InnoDB在崩溃恢复期间使用Redo Log。Redo Log文件的名称类似于ib_logfileN，其中N是整数(从MariaDB 10.5开始，只有一个重做日志，因此该文件将始终被命名ib_logfile0)。

InnoDB恢复模式

InnoDB恢复模式是用于从紧急情况中恢复的模式。正常使用模式0，而模式越高，限制越严格。较高模式合并了较低模式的所有限制。通常，最好从1的恢复模式开始，如果需要，以单个增量增加。具体信息可以查看MariaDB官方文档。

恢复过程

在日终备份的时候，同步的为整个目录，经过恢复测试，不需要将备份的数据目录全部复制。只需要将用户创建的Database和ibdata1备份数据复制到数据目录中。但在复制之前，建议将现有的数据目录另行备份，以防恢复过程中出现意外。

数据复制完成以后，尝试启动失败，此时就需要启用InnoDB恢复模式，在/etc/mysql/mariadb.conf.d/50-server.cnf文件末尾中添加一行:

1	innodb_force_recovery = 1

此时再尝试启动MariaDB，可以看到启动成功，验证用户Database中的表读取等操作正常以后需要关闭MariaDB服务，删除innodb_force_recovery配置行，重启MariaDB即可。

数据库恢复成功以后，就可以恢复业务了。

备份因素

简单说一下为什么使用备份整个数据目录吧，主要有两个因素:

资源因素

这里得看公司情况等，就暂且不提了。

工具因素

1、mysqldump: 采用SQL级别的备份机制，它将数据表导成SQL脚本文件，数据库大时，占用系统资源较多，支持常用的MyISAM，InnoDB引擎。

2、mysqlhotcopy：使用FLUSH TABLES，LOCK TABLES和cp或scp进行数据库备份。这是备份数据库或单个表的快速方法，但是只能在数据库目录所在的同一台计算机上运行，仅支持MyISAM、 ARCHIVE引擎。

另外两个工具有简单看过，但未进行实际测试，后面实际玩过以后再写笔记吧，这里暂时插眼:

xtrabackup: Percona团队基于MySQL服务器的开源热备份实用程序，在备份过程中不会锁定数据库
Mariabackup: MariaDB基于percona xtrabackup开发的备份工具，使用方法基本和xtrabackup相同，只是有些自己的特性

参考