Environment introduction:
CentOS 7.5
Mysql 5.7
percona-xtrabackup-24
Precautions
The data recovery tool Percona XtraBackup has been installed in the operating system. You can download and install it from the official website of Percona XtraBackup.
- MySQL 5.6 and earlier versions need to install Percona XtraBackup 2.3. For installation instructions, please refer to the official document Percona
XtraBackup 2.3. - MySQL 5.7 version requires Percona XtraBackup 2.4 to be installed. For installation instructions, please refer to the official document Percona XtraBackup
2.4. - MySQL 8.0 version requires Percona XtraBackup 8.0 to be installed. For installation instructions, please refer to the official document Percona XtraBackup
8.0.
The self-built MySQL database is installed on a 64-bit Linux system and is the same version as the cloud database MySQL version.
Backup and recovery operation steps
1. Log in to the RDS management console.
2. In the upper left corner of the page, select the instance location.
3. Find the target instance and click the instance ID.
4. Click Backup and Restore in the left navigation bar.
5. Select the data backup tab.
6. Select the time range of the query, and then click Query.
7. In the data backup list, find the data backup you want to download, and click download on the right side of it.
8. In the instance backup file download window, click the copy icon next to the copy external network address to obtain the external network download address of the data backup file.
9. Log in to the server.
10. Execute the following command to download the data backup file.
wget -c'<data backup file download address from Internet>' -O <custom file name>
-c: Enable resumable transfer mode.
-O: Save the downloaded result as a specified file (use the file name suffix .tar.gz, .xb.gz or _qp.xb contained in the URL).
11. The innobackupex decompression command needs to install qpress, download the qpress tool, and then use the following command to install:
Download qpress
[root@test2 ~]# mkdir crmdb
[root@test2 ~]# cd crmdb
[root@test2 ~]# ls crmdb/
hins8537769_data_20200708132950.tar qpress-11-linux-x64.tar
[root@test2 ~]# ll crmdb/
总用量 403196
-rw-r--r-- 1 root root 412790614 7月 9 10:53 hins8537769_data_20200708132950.tar //RDS数据库全备文件
-rw-r--r-- 1 root root 81920 7月 9 14:00 qpress-11-linux-x64.tar
[root@test2 ~]# tar -xvf crmdb/qpress-11-linux-x64.tar
qpress
[root@test2 ~]# chmod 755 qpress
[root@test2 ~]# cp qpress /usr/bin/
12. Execute the following command to decompress the downloaded data backup file.
There are currently 3 formats of physical backup set files:
- tar compressed package (.tar.gz suffix)
- xbstream compressed package (.xb.gz suffix)
- xbstream file package (_qp.xb suffix)
1. For the tar compressed package (.tar.gz suffix), use the command:
tar -izxvf <数据备份文件名>.tar.gz -C <数据库恢复到这个目录>
2. For the xbstream compressed package (.xb.gz suffix), use the command:
gzip -d -c <数据备份文件名>.xb.gz | xbstream -x -v -C <数据库恢复到这个目录>
3. For the xbstream file package (_qp.xb suffix), use the command:
--解包
cat <数据备份文件名>_qp.xb | xbstream -x -v -C <数据库恢复到这个目录>
--MySQL 5.6/5.7解压
innobackupex --decompress --remove-original <数据库恢复到这个目录>
--MySQL 8.0解压
xtrabackup --decompress --remove-original --target-dir=<数据库恢复到这个目录>
note:
Since the Alibaba Cloud RDS database backs up all physical files, it is best to restore the data to the newly installed Mysql database.
-C: Specify the directory where the file is to be decompressed. Optional parameter. If not specified, it will be decompressed to the current directory.
[root@test2 ~]# tar -izxvf crmdb/hins8537769_data_20200708132950.tar -C /var/lib/mysql
crmdb/weixin_textmsg.ibd
crmdb/sys_dept.ibd
crmdb/ybc_recovery.ibd
crmdb/sys_user_qx.ibd
crmdb/imptable.ibd
crmdb/ybc_refund.ibd
crmdb/ybt_type.ibd
crmdb/work_count.ibd
crmdb/ybc_branch.ibd
crmdb/ybc_follow.ibd
crmdb/weixin_command.ibd
crmdb/sys_user.ibd
crmdb/version_message.ibd
crmdb/sys_menu.ibd
crmdb/sys_app_user.ibd
crmdb/vip_visit.ibd
crmdb/ybc_house.ibd
crmdb/ybc_message.ibd
crmdb/sys_dictionaries.ibd
...
[root@test2 ~]# ls -l /var/lib/mysql //查询解压后生成的文件
总用量 324852
-rw-r----- 1 mysql mysql 56 7月 10 16:41 auto.cnf
-rw-rw---- 1 root root 536 7月 8 13:31 backup-my.cnf
-rw------- 1 mysql mysql 1680 7月 10 16:41 ca-key.pem
-rw-r--r-- 1 mysql mysql 1112 7月 10 16:41 ca.pem
-rw-r--r-- 1 mysql mysql 1112 7月 10 16:41 client-cert.pem
-rw------- 1 mysql mysql 1680 7月 10 16:41 client-key.pem
drwxr-xr-x 2 root root 4096 7月 10 16:48 crmdb
drwxr-xr-x 2 root root 4096 7月 10 16:48 crmdb_test
-rw-r----- 1 mysql mysql 425 7月 10 16:41 ib_buffer_pool
-rw-rw---- 1 root root 209715200 7月 8 12:31 ibdata1
-rw-r----- 1 mysql mysql 50331648 7月 10 16:41 ib_logfile0
-rw-r----- 1 mysql mysql 50331648 7月 10 16:41 ib_logfile1
-rw-r----- 1 mysql mysql 12582912 7月 10 16:41 ibtmp1
drwxr-x--- 2 mysql mysql 4096 7月 10 16:48 mysql
srwxrwxrwx 1 mysql mysql 0 7月 10 16:41 mysql.sock
-rw------- 1 mysql mysql 5 7月 10 16:41 mysql.sock.lock
drwxr-x--- 2 mysql mysql 8192 7月 10 16:48 performance_schema
-rw------- 1 mysql mysql 1680 7月 10 16:41 private_key.pem
-rw-r--r-- 1 mysql mysql 452 7月 10 16:41 public_key.pem
-rw-r--r-- 1 mysql mysql 1112 7月 10 16:41 server-cert.pem
-rw------- 1 mysql mysql 1680 7月 10 16:41 server-key.pem
drwxr-x--- 2 mysql mysql 8192 7月 10 16:48 sys
-rw-rw---- 1 root root 119 7月 8 13:31 xtrabackup_binlog_info
-rw-rw---- 1 root root 147 7月 8 13:31 xtrabackup_checkpoints
-rw-rw---- 1 root root 845 7月 8 13:31 xtrabackup_info
-rw-rw---- 1 root root 9566720 7月 8 13:31 xtrabackup_logfile
-rw-rw---- 1 root root 74 7月 8 13:31 xtrabackup_slave_filename_info
-rw-rw---- 1 root root 162 7月 8 13:31 xtrabackup_slave_info
13. Install Percona XtraBackup 2.4 (required by Mysql 5.7) and restore the backup data
[root@test2 ~]# yum -y install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
...
已安装:
percona-release.noarch 0:1.0-21
完毕！
[root@test2 ~]# yum list | grep percona
...
percona-release.noarch 1.0-21 installed
percona-xtrabackup-24.x86_64 2.4.5-1.el7 installed
Percona-Server-55-debuginfo.x86_64 5.5.62-rel38.14.el7 percona-release-x86_64
Percona-Server-56-debuginfo.x86_64 5.6.48-rel88.0.1.el7 percona-release-x86_64
Percona-Server-57-debuginfo.x86_64 5.7.30-33.1.el7 percona-release-x86_64
Percona-Server-80-info.x86_64 8.0-1.el7 percona-release-x86_64
Percona-Server-MongoDB.x86_64 3.0.15-1.10.el7 percona-release-x86_64
Percona-Server-MongoDB-32.x86_64 3.2.22-3.13.el7 percona-release-x86_64
3.2.22-3.13.el7 percona-release-x86_64
Percona-Server-MongoDB-32-mongos.x86_64 3.2.22-3.13.el7 percona-release-x86_64
Percona-Server-MongoDB-32-server.x86_64 3.2.22-3.13.el7 percona-release-x86_64
Percona-Server-MongoDB-32-shell.x86_64 3.2.22-3.13.el7 percona-release-x86_64
Percona-Server-MongoDB-32-tools.x86_64 3.2.22-3.13.el7 percona-release-x86_64
Percona-Server-MongoDB-34.x86_64 3.4.24-3.0.el7 percona-release-x86_64
3.4.24-3.0.el7 percona-release-x86_64
Percona-Server-MongoDB-34-mongos.x86_64 3.4.24-3.0.el7 percona-release-x86_64
...
[root@test2 ~]# yum -y install percona-xtrabackup-24.x86_64
...
已安装:
percona-xtrabackup-24.x86_64 0:2.4.20-1.el7
完毕！
14. To avoid version problems, you need to modify the backup-my.cnf parameter
[root@test2 ~]# vim /var/lib/mysql/backup-my.cnf
[mysqld]
innodb_checksum_algorithm=crc32
#innodb_log_checksum_algorithm=strict_crc32 //注释掉
innodb_data_file_path=ibdata1:200M:autoextend
innodb_log_files_in_group=2
innodb_log_file_size=1048576000
#innodb_fast_checksum=false //注释掉
innodb_page_size=16384
#innodb_log_block_size=512 //注释掉
innodb_undo_directory=./
innodb_undo_tablespaces=0
server_id=2931342899
#redo_log_version=1 //注释掉
#server_uuid=cf7b6786-a55c-11e9-94b7-506b4b231e40 //注释掉
#master_key_id=0 //注释掉
#innodb_encrypt_algorithm=AES_256_CBC //注释掉
15. Execute the following command to restore the decompressed backup file and modify the file owner, and make sure that the file belongs to the MySQL user.
When recovering data in Mysql5.6/5.7/8.0, the backup-my.cnf configuration file is in the directory after decompression of the above RDS backup file (ie, in the folder to be restored), and the data in this article is restored to /var/lib/mysql In /, Mysql 5.7 is a new library just installed without any data.
–MySQL 5.6/5.7–
innobackupex --defaults-file=<directory to restore the database>/backup-my.cnf --apply-log <directory to restore the database>
–MySQL 8.0–
xtrabackup --prepare --target-dir=<directory to which the database is restored>
xtrabackup --datadir=/var/lib/mysql --copy-back --target-dir=<directory where the database is restored>
[root@test2 ~]# chown -R mysql:mysql /var/lib/mysql //修改文件属主属组
[root@test2 ~]# ll /var/lib/mysql
总用量 2278460
-rw-r----- 1 mysql mysql 56 7月 10 16:41 auto.cnf
-rw-rw---- 1 mysql mysql 543 7月 10 16:50 backup-my.cnf
-rw------- 1 mysql mysql 1680 7月 10 16:41 ca-key.pem
-rw-r--r-- 1 mysql mysql 1112 7月 10 16:41 ca.pem
-rw-r--r-- 1 mysql mysql 1112 7月 10 16:41 client-cert.pem
-rw------- 1 mysql mysql 1680 7月 10 16:41 client-key.pem
drwxr-xr-x 2 mysql mysql 4096 7月 10 17:26 crmdb
drwxr-xr-x 2 mysql mysql 4096 7月 10 16:48 crmdb_test
-rw-r----- 1 mysql mysql 425 7月 10 16:41 ib_buffer_pool
-rw-rw---- 1 mysql mysql 209715200 7月 10 17:39 ibdata1
-rw-r----- 1 mysql mysql 1048576000 7月 10 17:39 ib_logfile0
-rw-r----- 1 mysql mysql 1048576000 7月 10 17:39 ib_logfile1
-rw-r----- 1 mysql mysql 12582912 7月 10 17:39 ibtmp1
drwxr-x--- 2 mysql mysql 4096 7月 10 16:48 mysql
srwxrwxrwx 1 mysql mysql 0 7月 10 16:41 mysql.sock
-rw------- 1 mysql mysql 5 7月 10 16:41 mysql.sock.lock
drwxr-x--- 2 mysql mysql 8192 7月 10 16:48 performance_schema
-rw------- 1 mysql mysql 1680 7月 10 16:41 private_key.pem
-rw-r--r-- 1 mysql mysql 452 7月 10 16:41 public_key.pem
-rw-r--r-- 1 mysql mysql 1112 7月 10 16:41 server-cert.pem
-rw------- 1 mysql mysql 1680 7月 10 16:41 server-key.pem
drwxr-x--- 2 mysql mysql 8192 7月 10 16:48 sys
-rw-rw---- 1 mysql mysql 119 7月 8 13:31 xtrabackup_binlog_info
-rw-r--r-- 1 mysql mysql 24 7月 10 17:38 xtrabackup_binlog_pos_innodb
-rw-rw---- 1 mysql mysql 147 7月 10 17:38 xtrabackup_checkpoints
-rw-rw---- 1 mysql mysql 845 7月 8 13:31 xtrabackup_info
-rw-rw---- 1 mysql mysql 13565952 7月 10 17:38 xtrabackup_logfile
-rw-r--r-- 1 mysql mysql 1 7月 10 17:38 xtrabackup_master_key_id
-rw-rw---- 1 mysql mysql 74 7月 8 13:31 xtrabackup_slave_filename_info
-rw-rw---- 1 mysql mysql 162 7月 8 13:31 xtrabackup_slave_info
[root@test2 ~]# innobackupex --defaults-file=/var/lib/mysql/backup-my.cnf --apply-log /var/lib/mysql
xtrabackup: recognized server arguments: --innodb_checksum_algorithm=crc32 --innodb_data_file_path=ibdata1:200M:autoextend --innodb_log_files_in_group=2 --innodb_log_file_size=1048576000 --innodb_page_size=16384 --innodb_undo_directory=./ --innodb_undo_tablespaces=0 --server-id=2931342899
xtrabackup: recognized client arguments:
200710 17:38:03 innobackupex: Starting the apply-log operation
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints "completed OK!".
innobackupex version 2.4.20 based on MySQL server 5.7.26 Linux (x86_64) (revision id: c8b4056)
xtrabackup: cd to /var/lib/mysql/
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=13565952, start_lsn=(10489267059)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:200M:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 13565952
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:200M:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 13565952
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 10489267059
InnoDB: Doing recovery: scanned up to log sequence number 10494509568 (43%)
InnoDB: Doing recovery: scanned up to log sequence number 10498831278 (79%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 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 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: xtrabackup: Last MySQL binlog file position 593541, file name mysql-bin.001448
InnoDB: Removed temporary tablespace data file: "ibtmp1"
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.7.26 started; log sequence number 10498831278
InnoDB: page_cleaner: 1000ms intended loop took 46390ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
InnoDB: xtrabackup: Last MySQL binlog file position 593541, file name mysql-bin.001448
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 10498832727
InnoDB: Number of pools: 1
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:200M:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 1048576000
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: Setting log file ./ib_logfile101 size to 1000 MB
InnoDB: Progress in MB:
100 200 300 400 500 600 700 800 900 1000
InnoDB: Setting log file ./ib_logfile1 size to 1000 MB
InnoDB: Progress in MB:
100 200 300 400 500 600 700 800 900 1000
InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
InnoDB: New log files created, LSN=10498832727
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 10498832908
InnoDB: Doing recovery: scanned up to log sequence number 10498832917 (0%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: xtrabackup: Last MySQL binlog file position 593541, file name mysql-bin.001448
InnoDB: Removed temporary tablespace data file: "ibtmp1"
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: page_cleaner: 1000ms intended loop took 35376ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
InnoDB: 5.7.26 started; log sequence number 10498832917
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 10498832936
200710 17:39:28 completed OK!
You can see that the execution of innobackupex has succeeded in restoring the data.
注意：
数据恢复成功后，由于我们是恢复的RDS全备文件，所以我们自建的Mysql数据库之前设置的密码会被覆盖成RDS的备份数据库的密码，如果忘记密码，可以临时在Mysql配置文件中加入skip-grant-tables配置，无密码进入数据库，验证数据恢复情况，后面再重置root密码。
[root@test2 ~]# vim /etc/my.cnf
[mysqld]
…
skip-grant-tables
16. Execute the following command to start the MySQL process.
note:
When starting the Mysql process, because I directly restore the backup data to the Mysql default database directory /var/lib/mysql, I can directly start the Mysql process with systemctl start mysqld. If you restore the backup file of the RDS database to another directory at the beginning, you need to use mysqld_safe to specify the database directory to start the process when you start the Mysql database process, otherwise the restored data will not be seen after the database is started in the default mode.
command:
mysqld_safe --defaults-file=<数据库恢复到的目录>/backup-my.cnf --user=mysql --datadir=<数据库恢复到的目录> &
[root@test2 ~]# systemctl start mysqld
[root@test2 ~]# mysql -uroot
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.30 MySQL Community Server (GPL)
Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> use crmdb;
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> show tables;
+------------------------+
| Tables_in_crmdb |
+------------------------+
| 产品表_rsow_product |
| calllist |
| cus_manage_set |
| dictionary |
| importtel |
| imptable |
| imptable2 |
| log |
| rsow_product |
| rxpbls |
| sys_app_user |
| sys_dept |
| sys_dictionaries |
| sys_gl_qx |
| sys_menu |
| sys_role |
| sys_user |
| sys_user_qx |
| tb_pictures |
| test |
| tmp_ybc |
| user |
mysql> select * from user;
+--------+----------+----------+------+------+------------+
| userID | userName | password | name | sex | department |
+--------+----------+----------+------+------+------------+
| 1 | admin | admin | NULL | NULL | NULL |
| 2 | 111111 | 111111 | NULL | NULL | NULL |
| 3 | 222222 | 222222 | NULL | NULL | NULL |
| 4 | 333333 | 333333 | NULL | NULL | NULL |
| 5 | 444444 | 444444 | NULL | NULL | NULL |
| 6 | 555555 | 555555 | NULL | NULL | NULL |
+--------+----------+----------+------+------+------------+
6 rows in set (0.00 sec)
You can see that the data is successfully displayed and the data is restored successfully! ! !
重置连接Mysql数据库的Root密码
Password reset error resolution:
Solution to the problem that the password is overwritten after the Alibaba Cloud RDS database or other host database fully prepared files are restored to the self-built database, and various errors are reported when the password is reset
1. Modify the configuration file, add the skip authorization table configuration to start the MySQL service
[root@test2 ~]# vim /etc/my.cnf
[mysqld]
...
skip-grant-tables
2. After restarting the Mysql service process, log in to the database to change the root password
[root@test2 ~]# systemctl restart mysqld
[root@test2 ~]# mysql -uroot
mysql> use mysql;
mysql> update user set authentication_string=password('123qqq...A') where user='root' and host='%';
mysql> flush privileges;
mysql> exit
Bye
[root@test2 ~]# sed -i s/skip-grant-tables//g /etc/my.cnf
[root@test2 ~]# systemctl restart mysqld
[root@test2 ~]# mysql -uroot -p123qqq...A
mysql> select user();
+--------+
| user() |
+--------+
| root@ |
+--------+
1 row in set (0.00 sec)
Successfully reset the database password!
其他相关报错解决：
1. Error when installing Mysql: Error: Package: mysql-community-server-5.7.30-1.el7.x86_64 (mysql57-community) Need: mysql-community solution
2. Install percona-xtrabackup-24 error: file /etc/my.cnf from install of Percona-Server-shared-56-5.6.48-rel88. Solution
3. Alibaba Cloud database RDS MySQL physical full backup file is restored to the self-built database Mysql error: InnoDB: Log file ./ib_logfile1 is of different size...xtrabacku
https://mp.weixin.qq.com/s/hRU-8SNJKnerJv0s8PbMdA