RDS_MYSQL_备份文件恢复启动

这次恢复比较简单,但还是走了弯路

Posted by Elli0t on 2020-11-22

这次给的文件有两个,一个是 RAW 系统备份文件,这个恢复了之后也没有很大用,这个后面说

文件

解压后进入数据库文件夹,发现还是用 xtrabackup 进行备份的。这次比上次好的是,数据库版本和 xtrabackup 的版本都写在了 xtrabackup_info 中了。

整个数据

数据库文件夹中分别有两个最主要的文件:

*.frm 储存表的结构

*.ibd 储存表的数据

要恢复数据库

通过 *.raw 文件进行恢复

VMware 是不认识 raw 文件的,所以 raw to vmdk

qemu-img convert -p -f raw .\xxxxxx.raw -O vmdk .\xxxxxx.vmdk

转换后还是不能直接打开,VMware启动应该还需要一个 vmdx 文件。所以先自己创建一个空的虚拟机,然后再将其导入(注意选择虚拟机文件的时候要记得选择单个文件,因为我们只有单个文件进行替换)

然后打开虚拟机后,重置其 root 密码

进入 recovery mode 模式,然后按 e ,删除 recovery nomodeset,在行尾加 quiet splash rw init=/bin/bash。F10 保存退出即可。开始一直卡在启动界面,后面直接都删除了,删到了 root=UUID=88xxxxxxxxxxxx or再加的 quiet xxx 就可以正常启动修改密码了

root

修改好密码后就是重置 mysql 密码了。在 /etc/my.cnf 中添加 skip-grant-tables 然后无密码进入 mysql ,再修改密码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
mysql> use mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> update mysql.user set authentication_string=password('root_password') where user='root';
Query OK, 1 row affected, 1 warning (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 1

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

mysql> exit

[root@mytestlnx02 ~]# service mysql start
[root@mytestlnx02 ~]#
[root@mytestlnx02 ~]# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.

远程连接数据库,结果搞了半天连不上。原来是 iptable 没有删除规则,修改规则

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
[root@server ~]# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:http

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Notice the last line in chain INPUT. There are now five Rules in that chain.
[root@server ~]# iptables -D INPUT 5
[root@server ~]# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

然后 Navicat 连接后发现数据库是之前的,和我们要恢复的数据库不是同一个时间的。是什么个情况呢,就是他们那边给的 raw 镜像是之前备份的,tar.gz 数据库才是我们要恢复的,但是这个数据库是后面备份的。那我寻思这个 raw 文件不就没用了吗,但是由于 xtrabackup 很要求版本这个特性,拿数据过来的人可能是想给我们一个参考,告诉我们用的服务器是 ubuntu 16.04 之类的。

如果要在 Linux 下恢复的话,流程有两个:

  • 用对应的 xtrabackup 软件将数据库恢复,然后再将要的数据库导出成 .sql 文件
  • 直接放在 mysql 对应的存放数据的地方,替换掉原来数据直接启动(这个在 Linux 下没试过,但是也应该是可以的)。或者你在 my.ini 中修改数据位置也行,但是我怕会有遇到一些文件夹权限的问题

要导出文件的话,这里就涉及到一个 VM 共享文件夹的操作了。我一般在现在的 Linux 系统中共享文件都是可以直接出来的,但是这个没有,应该是系统版本比较早了。需要下载一个软件

apt-get install open-vm-dkms

然后挂载磁盘,一般选择挂载在 /mnt/hgfs/ 目录

vmhgfs-fuse .host:/ /mnt/hgfs/

搞这个的时候,下面的这个思路正好成功了,也就没搞了

直接在 Windows 下打开

本来看到一篇文章说是使用 windows 下的 xtrabackup 恢复数据库,可以这篇文章是很早的而且 windows 下的 xtrabackup 是 beta 版,现在已经找不到了,所以这个思路就停止了。

后面经过搞过这个的人提醒,这个格式的 mysql 数据文件可以直接在 windows 下打开。那我直接下载一个 phpstudy ,使用相应版本的 mysql ,替换掉它的 data 。然后直接启动报错

1
[ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files.

百度了一下,添加参数 innodb_force_recovery=4 重启 mysql 然后成功。直接好家伙……

轻轻跪下

Link

https://blog.csdn.net/jacke121/article/details/80456046?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.control

https://www.cnblogs.com/wuotto/p/9682400.html