阿里云数据库RDS MySQL 物理全备文件数据恢复至自建数据库Mysql 5.7中
2024-05-13 00:56:06
环境介绍：
CentOS 7.5
Mysql 5.7
percona-xtrabackup-24
注意事项
操作系统中已安装数据恢复工具Percona XtraBackup，您可以从Percona XtraBackup官网下载安装。
- MySQL 5.6及之前的版本需要安装 Percona XtraBackup 2.3，安装指导请参见官方文档Percona
XtraBackup 2.3。 - MySQL 5.7版本需要安装 Percona XtraBackup 2.4，安装指导请参见官方文档Percona XtraBackup
2.4。 - MySQL 8.0版本需要安装 Percona XtraBackup 8.0，安装指导请参见官方文档Percona XtraBackup
8.0。
自建MySQL数据库安装在64位的Linux系统中，且与云数据库MySQL版的版本相同。
备份恢复操作步骤
1.登录RDS管理控制台。
2.在页面左上角，选择实例所在地域。
3.找到目标实例，单击实例ID。
4.在左侧导航栏中单击备份恢复。
5.选择数据备份标签页。
6.选择查询的时间范围，然后单击查询。
7.在数据备份列表中，找到要下载的数据备份，并单击其右侧的下载。
8.在实例备份文件下载窗口，单击复制外网地址旁的复制图标，获取数据备份文件外网下载地址。
9.登录服务器。
10.执行如下命令，下载数据备份文件。
wget -c ‘<数据备份文件外网下载地址>’ -O <自定义文件名>
-c：启用断点续传模式。
-O：将下载的结果保存为指定的文件（使用URL中包含的文件名后缀 .tar.gz 、.xb.gz 或 _qp.xb）。
11.innobackupex解压命令需要安装qpress，下载qpress工具，然后使用如下命令安装：
下载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.执行如下命令，解压已下载的数据备份文件。
目前物理备份集文件有3种格式：
- tar 压缩包 （.tar.gz 后缀）
- xbstream 压缩包 （.xb.gz 后缀）
- xbstream 文件包（_qp.xb 后缀）
1.对于tar 压缩包 （.tar.gz 后缀），使用命令：
tar -izxvf <数据备份文件名>.tar.gz -C <数据库恢复到这个目录>
2.对于xbstream 压缩包 （.xb.gz 后缀），使用命令：
gzip -d -c <数据备份文件名>.xb.gz | xbstream -x -v -C <数据库恢复到这个目录>
3.对于xbstream 文件包（_qp.xb 后缀），使用命令：
--解包
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=<数据库恢复到这个目录>
注意：
由于阿里云RDS数据库备份的是物理全备文件，所以最好是恢复数据至新安装的Mysql数据库。
-C：指定文件要解压到的目录。可选参数，若不指定就解压到当前目录。
[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.安装Percona XtraBackup 2.4（Mysql 5.7需要），恢复备份数据
[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_643.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_643.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.为避免版本问题，需修改backup-my.cnf参数
[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.执行如下命令，恢复解压好的备份文件并修改文件属主，并确定文件所属为MySQL用户。
Mysql5.6/5.7/8.0恢复数据时，backup-my.cnf配置文件为上面RDS备份文件解压后的目录中（即，要恢复的文件夹中），本文中数据恢复至/var/lib/mysql/中，Mysql 5.7为刚安装的新库，无任何数据。
–MySQL 5.6/5.7–
innobackupex --defaults-file=<数据库恢复到的目录>/backup-my.cnf --apply-log <数据库恢复到的目录>
–MySQL 8.0–
xtrabackup --prepare --target-dir=<数据库恢复到的目录>
xtrabackup --datadir=/var/lib/mysql --copy-back --target-dir=<数据库恢复到的目录>
[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 operationIMPORTANT: Please check that the apply-log run completes successfully.At the end of a successful apply-log run innobackupexprints "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.001448xtrabackup: 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!
可以看到执行 innobackupex 恢复数据成功了。
注意：数据恢复成功后，由于我们是恢复的RDS全备文件，所以我们自建的Mysql数据库之前设置的密码会被覆盖成RDS的备份数据库的密码，如果忘记密码，可以临时在Mysql配置文件中加入skip-grant-tables配置，无密码进入数据库，验证数据恢复情况，后面再重置root密码。
[root@test2 ~]# vim /etc/my.cnf
[mysqld]
…
skip-grant-tables
16.执行如下命令，启动MySQL进程。
注意：
在启动Mysql进程的时候，由于我是直接将备份数据恢复到Mysql默认的数据库目录/var/lib/mysql中，所以可以直接systemctl start mysqld启动Mysql进程。如果最开始是将RDS数据库的备份文件恢复到了其他目录中，那么在启动Mysql数据库进程的时候就需要使用mysqld_safe指定数据库目录启动进程，否则默认方式启动数据库后是看不到恢复的数据的。
命令：
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 -ADatabase 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)
可以看到数据成功展示，数据恢复成功！！！
重置连接Mysql数据库的Root密码
密码重置报错解决：
关于将阿里云RDS数据库或其他主机数据库全备文件恢复至自建数据库后密码被覆盖，并在重置密码时出现各种报错的问题解决
1.修改配置文件，添加跳过授权表配置启动MySQL服务
[root@test2 ~]# vim /etc/my.cnf[mysqld]
...
skip-grant-tables
2.重启Mysql服务进程后登陆数据库修改root密码
[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)
重置数据库密码成功！
其他相关报错解决：
1.安装Mysql报错：错误：软件包：mysql-community-server-5.7.30-1.el7.x86_64 (mysql57-community) 需要：mysql-community解决
2.安装percona-xtrabackup-24报错：file /etc/my.cnf from install of Percona-Server-shared-56-5.6.48-rel88.解决
3.阿里云数据库RDS MySQL 物理全备文件恢复到自建数据库Mysql报错：InnoDB: Log file ./ib_logfile1 is of different size…xtrabacku
https://mp.weixin.qq.com/s/hRU-8SNJKnerJv0s8PbMdA
阿里云数据库RDS MySQL 物理全备文件数据恢复至自建数据库Mysql 5.7中相关推荐
- RDS MySQL和Mongodb 物理备份文件.xb恢复到自建数据库
介绍: 本章内容为阿里云RDS Mysql和MongoDB 将物理备份文件.xb恢复到自建数据库的过程.环境搭建.错误解析 前提准备: 1: Centos7环境基础环境准备: IP映射.关闭防火墙.S ...
- 阿里云自动java和mysql数据库_阿里云服务器之基于Linux系统部署上线JavaWeb项目和连接MySQL数据库（从购买云服务器到发布JavaWeb项目全套详细流程）...
阿里云服务器之基于Linux系统部署上线JavaWeb项目和连接MySQL数据库(从购买云服务器到发布JavaWeb项目全套详细流程) (仅此纪念人生第一篇学习博客) 前阵子接了一个小小的JavaWe ...
- 创业公司为什么不自建MySQL而使用阿里云的 RDS
创业公司为什么不自建MySQL而使用阿里云的 RDS 在脉脉看到一条职言:"不明白有人居然使用阿里云的 RDS?" RDS 是什么? 关系型数据库RDS(Relational Da ...
- 试用阿里云的RDS数据库
在免费试用了阿里云的云服务器之后,我又申请了阿里云的关系型数据库RDS, 关系型数据库服务(Relational Database Service,简称RDS),通过云服务的方式让关系型数据库设置.操 ...
- 如何设置和配置阿里云国际版数据管理服务以管理您的所有云数据库
什么是阿里云数据管理服务? 阿里云数据管理服务(DMS) 是一种数据库研发服务,用于管理和保护多个数据源.DMS支持数据库,包括关系数据库(如MySQL,SQL Server PostgreSQL,P ...
- 上传阿里云oss对象型存储 本地文件和上传流上传
上传阿里云oss对象型存储 本地文件和上传流上传 import java.io.ByteArrayInputStream; import java.io.File; import java.io.Fi ...
- 阿里云安装LNMP以及更改网站文件和MySQL数据目录
2019独角兽企业重金招聘Python工程师标准>>> 目前阿里云提供了自家的一键安装工具,可安装LAMP或者LNMP均可,对于低配置的服务器,推荐LNMP,占用资源少. 对于新手, ...
- 怎么删除mysql的所有文件内容_mysql删除全部数据库
{"moduleinfo":{"card_count":[{"count_phone":1,"count":1}],&q ...
- mysql 8.0数据备份恢复_RDS for MySQL8.0物理备份恢复到本地自建数据库
此文章是centos7下的恢复流程. yum localinstall mysql80-community-release-el7-1.noarch.rpm yum -y install yum-ut ...
最新文章
- django 学习笔记（一）
- 动态卷积超进化！通道融合替换注意力，减少75%参数量且性能显著提升｜ICLR 2021
- spring-aop相关概念
- exe打包工具哪个最好_为你的 Python 程序写个启动工具箱
- mysql数据库进行更新、插入显示中文乱码问题
- 实用常识 | 一篇文章记录如何轻松清理C盘，C盘又满了，继续盘它
- 手机支付优惠促销活动插画素材，拿来就能用，高效省时。
- 上海盐城生物php招聘_上海祥源生物科技招聘国际商务专员，中英文熟练
- mysql join联接_MySQL_join连接
- metasfresh 大型java开源制造业erp介绍
- Spring Bean的作用域之prototype
- C语言有四种基本常量,第2章-C语言的基础知识.ppt
- eclipse Job
- 什么是系统的可扩展性？
- 毕业面试 | 如何准确一分钟介绍你自己？
- Java的Set转成逗号分隔的字符串
- 从头开始学习C++（C++Primer第五版）
- uniapp-高德地图Android+IOS appkey申请与使用
- 遇到问题：从采购申请 复制 建立分类的采购订单的时候， 报错： 采购申请未批准。
- 2013-2014年总结