環境紹介：
CentOS 7.5
Mysql 5.7
percona-xtrabackup-24
予防
データ復旧ツールPerconaXtraBackupがオペレーティングシステムにインストールされています。PerconaXtraBackupの公式Webサイトからダウンロードしてインストールできます。
- MySQL5.6以前のバージョンではPerconaXtraBackup 2.3をインストールする必要があります。インストール手順については、公式ドキュメントPercona
XtraBackup2.3を参照してください。 - MySQL 5.7バージョンでは、Percona XtraBackup 2.4をインストールする必要があります。インストール手順については、公式ドキュメントPercona XtraBackup2.4を参照してください
。 - MySQL 8.0バージョンでは、Percona XtraBackup 8.0をインストールする必要があります。インストール手順については、公式ドキュメントPercona XtraBackup8.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=<数据库恢复到这个目录>
注意：
Alibaba Cloud 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_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.バージョンの問題を回避するには、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に復元されます/では、Mysql5.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 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!
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 startmysqldを使用してMysqlプロセスを直接開始できます。RDSデータベースのバックアップファイルを最初に別のディレクトリに復元する場合は、mysqld_safeを使用して、Mysqlデータベースプロセスの開始時にプロセスを開始するデータベースディレクトリを指定する必要があります。そうしないと、データベースが終了した後、復元されたデータが表示されません。デフォルトモードで開始しました。
コマンド：
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)
データが正常に表示され、データが正常に復元されたことがわかります。！！
重置连接Mysql数据库的Root密码
パスワードリセットエラーの解決：
Alibaba Cloud RDSデータベースまたは他のホストデータベースの完全に準備されたファイルが自己構築データベースに復元された後にパスワードが上書きされ、パスワードがリセットされるとさまざまなエラーが報告されるという問題の解決策
1.構成ファイルを変更し、承認テーブルのスキップ構成を追加してMySQLサービスを開始します
[root@test2 ~]# vim /etc/my.cnf
[mysqld]
...
skip-grant-tables
2. Mysqlサービスプロセスを再起動した後、データベースにログインしてルートパスワードを変更します
[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 solution
2. percona-xtrabackup-24エラーをインストールします：Percona-Server-shared-56-5.6.48-rel88のインストールからのファイル/etc/my.cnf。解決策
3. AlibabaCloudデータベースRDSMySQL物理フルバックアップファイルが自己構築データベースに復元されますMysqlエラー：InnoDB：ログファイル./ib_logfile1のサイズが異なります... xtrabacku
https://mp.weixin.qq.com/s/hRU-8SNJKnerJv0s8PbMdA