快速恢复IBD文件中的数据库数据方法 (ibd文件恢复数据库)
当数据库中的某些数据或者表格不小心被删除或者损坏时，管理员需要找到恢复IBD文件中的数据的方法。IBD文件是InnoDB存储引擎文件，用于存储MySql数据库的表格结构和数据。
恢复IBD文件中的数据可以使用数据恢复专业工具，但是这些工具往往比较昂贵，不适合小公司或个人使用。
以下是一些快速、简单的方法来恢复IBD文件中的数据库数据。
1. 从备份中恢复数据
如果你还没有开启数据备份，现在就是时候了。备份可以保护你的数据，同时也为紧急情况提供了一条安全之路。
当你需要从备份中恢复数据时，可以在MySql中运行一条命令导入备份文件。例如：
mysql -u username -p database_name
这个命令会将备份文件中的数据导入到指定的数据库中。
2. 从frm、ibd和MDM文件中恢复数据
创建一个新的数据库和表格，名称与你原本的表格名称一致。然后，在你备份的数据库目录中找到对应的frm、ibd和MDM文件。
复制frm文件到新创建的表格的数据库目录中。
接着，关闭MySql服务器，将备份的ibd文件重命名为你新创建表格的名称，然后将其复制到与frm文件同样的目录中。
重新启动MySql服务器，查看新创建的表格，这个表格里面应该包含了从IBD文件中恢复的数据。
3. 使用Undrop for InnoDB
Undrop for InnoDB是一个免费的开源工具，可以快速地从IBD文件中恢复数据。这个工具专门用于恢复InnoDB数据，支持所有版本的MySQL和MariaDB服务器。
将IBD文件从备份目录中复制到MySql数据目录中的新目录。然后，在新目录中启动MySql服务器，并停止服务器。
接着，运行Undrop for InnoDB，指定数据目录，以及需要从IBD文件中恢复的表格名称。这个工具会自动扫描IBD文件，并尝试从IBD文件中恢复数据。
在完成后，你可以重新启动MySql服务器，并查看恢复后的数据。
通过以上方法快速恢复IBD文件中的数据库数据可以帮助管理员避免因数据丢失而引起的问题，同时保证数据的完整性。这些方法都比较简单，适用于小公司或个人使用。当然，备份是更好的方法，希望管理员们都能够定期地进行备份，及时保护好数据库数据。
相关问题拓展阅读：
网站宕机 服务器宕机 数据库宕机 宕机怎么办
最近遇到个比较有意思的问题，服务器宕掉后无法启动，想了好多办法，虽然解决了问题，数据没有丢失，但是没有按照自已的思路来，未免还是有些不甘。遇到问题不能慌，尤其是线上的环境，更不能紧张，心理素质对DBA来说也是一伍没拆项挑战，可能你的手一抖就会导致多少人无法正常使用业务，如果你没有把握，请先把现场环境备份后再进行操作，避察竖免数据的二次损坏，下面壹基比小喻说一下大概的思路吧。
1.检查是否有备份，如果备份存在，binlog存在，那么万事大吉，一切都有挽回的余地，慢慢来搞，只要你基础扎实，数据还原只是时间的问题。
2.对于没有备份的，那处理这个问题就有些棘手了，还得一步一步的来。
在my.cnf中下加上以下配置，采用强制恢复机制，看是否能够启动
innodb_force_recovery=1
如果设置成1不能启动，可以逐渐的将数据增大到6，下文会详细说下1-6是什么意思，如果在1-6之间启动成功了，那么你运气还不错，这时候不要恢复业务，赶紧把数据用逻辑方式导出来，再启个新的实例把数据还原，有人会问，为什么mysql已经启动了，还要导出数据呢，原因在这：
当innodb_force_recovery被设置为大于0的时候 ，会阻止用户insert,update,delete也就是你启动的mysql不是一个正常的mysql服务，类似于windows系统下的安全模式。以下这段引于其它地方，具体地址不太清楚了，也可以从官方文档中找到。
innodb_force_recovery被允许的非零值如下。一个更大的数字包含所有更小数字的预防措施。如果你能够用一个多数是4的选项值来转储你的表，那么你是比较安全的，只有一些在损坏的单独页面上的数据会丢失。一个为6的值更夸张，因为数据库页被留在一个陈旧的状态，这个状态反过来可以引发对B树和其它数据库结构的更多破坏。
innodb_force_recovery=1 (SRV_FORCE_IGNORE_CORRUPT)
即使服务器检测到一个损坏的页，腔枣也让服务器运行着；试着让SELECT * FROM tbl_name 跳过损坏的索引记录和页，这样有助于转储表。
innodb_force_recovery=2 (SRV_FORCE_NO_BACKGROUND)
阻止主线程运行，如果崩溃可能在净化操作过程中发生，这将阻止它。
innodb_force_recovery=3 (SRV_FORCE_NO_TRX_UNDO)
恢复后不运行事务回滚。
innodb_force_recovery=4 (SRV_FORCE_NO_IBUF_MERGE)
也阻止插入缓冲合并操作。如果你可能会导致一个崩溃。更好不要做这些操作，不要计算表统计表。
innodb_force_recovery=5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库之时不查看未完成日志：InnoDB把未完成的事务视为已提交的。
innodb_force_recovery=6 (SRV_FORCE_NO_LOG_REDO)
不要在恢复连接中做日志前滚。
数据库不能另外地带着这些选项中被允许的选项来使用。作为一个安全措施，当innodb_force_recovery被设置为大于0的值时，InnoDB阻止用户执行INSERT, UPDATE或DELETE操作.
即使强制恢复被使用，你也可以DROP或CREATE表。如果你知道一个给定的表正在导致回滚崩溃，你可以移除它。你也可以用这个来停止由失败的大宗导入或失败的ALTER TABLE导致的失控回滚。你可以杀掉mysqld进程，然后设置innodb_force_recovery为3，使得数据库被挂起而不需要回滚，然后舍弃导致失控回滚的表。
关于上面进行逻辑备份也可能会遇到问题，可能会备份失败，如果出错，建议先按库一个一个的备份，到哪个库出错后，再按照当前库的表一个一个备份，表出错根据表中主键一点一点备份，最终将大部分数据导出。如果你的数据不重要，可以容忍丢失，那么可以当我说的都是废话了。
3.如果还是不可以启动，那么恭喜你，你遇到挑战了。
查看错误日志，看没有提示因为某个表的原因而导致启动不了，可以先把损坏的表的ibd文件先从数据目录mv走，再试着启动，在数据已经恢复后，我把当时错误的文件拿到本地，做了测试，把几个报错的ibd文件mv走后，数据库就可以正常启动了，但是mv走的这几个表数据会丢失。怎么把这个表的数据弄回来呢，曾想过用在线表空间传输，但是.cfg文件却没有，这种方法没有行通。后来用Percona Data Recovery Tool for InnoDB工具进行数据恢复，关于这个工具的介绍与操作，网上一大堆，我就不详细说明了。
服务器
宕机的原因是多方团渣此面的.最常见的几种原因:
一.
服务器
硬件故障,尤其是电源,主板等塌迅故障造成的.
二.服务器系统问题.比如说中病毒木马等.
三.长时间超负荷运行导致.尤其是机器配置低.硬件老化的情况下.
建议你找
服务商协助
你检查原因.或者是提梁枣供更加详细的问题描述.大家方便帮你解决.
a、是否是应用程序导致内存溢出或者泄露，out of memory导致
b、是否是进程过多或者不断创建，耗尽资源斗迹导致
c、是否是数据库程序死锁，连接数过多导致
d、是否是应用程序异常导致
e、侍销亏是老神否是流量负载过大导致
f、 是否是遭受黑客入侵攻击导致
生产环境究竟是使用mysqldump还是xtrabackup来备份与恢复数据库
生产环境究竟是使用mysqldump还是xtrabackup来备份与恢复数据库
root@client2:/var/lib/my；total77860；drwxmysqlmysql409；drwxr-xr-x38rootroot4096；-rw-r–r–1rootroot0Jan5；drwxmysqlmysql409；-rw-rw—-1mysqlmysql692；-rw-rw—-1mysqlmys
root@client2:/var/lib/mysql# ll
total 77860
drwxmysql mysql 4096 Mar 7 21:06 ./
drwxr-xr-x 38 root root 4096 Mar 7 19:52 ../
-rw-r–r– 1 root root 0 Jan 5 14:22 debian-5.5.flag
drwxmysql mysql 4096 Feb 11 17:39 django/
-rw-rwmysql mysqlMar 7 21:02 ibdata1
-rw-rwmysql mysqlMar 7 21:02 ib_logfile0
-rw-rwmysql mysqlMar 7 21:01 ib_logfile1
drwxmysql mysql 4096 Jan 5 22:55 monitor/
drwxmysql root 4096 Jan 5 14:22 mysql/
-rw-rwroot root 6 Jan 5 14:22 mysql_upgrade_info
drwxmysql mysql 4096 Jan 5 14:22 performance_schema/
drwxr-xr-x 2 mysql mysql 4096 Mar 7 21:03 test/
drwxr-xr-x 2 mysql mysql 4096 Mar 7 19:58 xtrbackup/
然后启动mysql，并查看test数据库的表里内容
root@client2:/var/lib/mysql# service mysql start
mysql start/running, process 12730
root@client2:/var/lib/mysql# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 36
Server version: 5.5.28-0ubuntu0.12.04.3-log (Ubuntu)
Copyright (c) 2023, 2023, 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 test;
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> select * from test;
+——+
| id |
+——+
| 1 |
| 2 |
| 3 |
| 5 |
+——+
5 rows in set (0.01 sec)
可以看到数据库已经恢唤毕派复完成
可能大家有个疑问，为什么我这里不像和贺很多网上的文章里是在apply-log后，使用copy-back如果使用/usr/bin/innobackupex –copy-back命令后，会报Original data directory is not empty! at /usr/local/xtrabackup/bin/innobackupex line 538.恢复的目录必须为空。经查官网，这是xtrabackup的一个BUG。
innobackupex–copy-back was run. With this bug fix, innobackupex–copy-back operation if the destination is not empty, avoiding potential data loss or a strang combination of a restored backup and previous data. Bug Fixed: #(Valentine Gostev) will now error out of the did not check that MySQL datadir was empty before
所以在apply-log后直接复制数据目录到数据库的位置上吧。
三、对数据库的增量备份与恢复
为了进行增量备份，先对数据库添加一些数据
mysql> insert into test values(11);
Query OK, 1 row affected (0.10 sec)
mysql> insert into test values(12);
Query OK, 1 row affected (0.05 sec)
mysql> insert into test values(13);
Query OK, 1 row affected (0.00 sec)
mysql> insert into test values(14);
Query OK, 1 row affected (0.00 sec)
mysql> insert into test values(15);
Query OK, 1 row affected (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.01 sec)
mysql> select * from test;
+——+
| id |
+——+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 11 |
| 13 |
| 14 |
| 15 |
+——+
10 rows in set (0.00 sec)
然后进行增量的备份
root@client2:/var/lib/mysql# innobackupex –user=root –password=database=test –incremental –incremental-basedir=/tmp/restore/ /tmp/data
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2023, 2023 Innobase Oy
and Percona Inc. All Rights Reserved.
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
:13:38 innobackupex: Starting mysql with options: –password=xx –user=’root’ –unbuffered —
:13:38 innobackupex: Connected to database with mysql child process (pid=12864):13:44 innobackupex: Connection to database server closed
IMPORTANT: Please check that the backup run completes successfully.
At the end of a successful backup run innobackupex
prints “completed OK!”.
innobackupex: Using mysql Ver 14.14 Distrib 5.5.28, for debian-linux-gnu (x86_64) using readline 6.2
innobackupex: Using mysql server version Copyright (c) 2023, 2023, Oracle and/or its affiliates. All rights reserved.
innobackupex: Created backup directory /tmp/data/_
:13:44 innobackupex: Starting mysql with options: –password=xx –user=’root’ –unbuffered —
:13:44 innobackupex: Connected to database with mysql child process (pid=12891):13:46 innobackupex: Connection to database server closed
:13:46 innobackupex: Starting ibbackup with command: xtrabackup_55 –backup –suspend-at-end –target-dir=/tmp/data/_incremental-basedir=’/tmp/restore/’
innobackupex: Waiting for ibbackup (pid=12898) to suspend
innobackupex: Suspend file ‘/tmp/data/_/xtrabackup_suspended’
xtrabackup_55 version 1.6.7 for Percona Server 5.5.16 Linux (x86_64) (revision id: undefined) incremental backup fromis enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size =
:13:46 InnoDB: Using Linux native AIO
>> log scanned up to ()
Copying ./ibdata1
to /tmp/data/_/ibdata1.delta
…done
:13:50 innobackupex: Continuing after ibbackup has suspended
:13:50 innobackupex: Starting mysql with options: –password=xx –user=’root’ –unbuffered —
:13:50 innobackupex: Connected to database with mysql child process (pid=12913) >> log scanned up to ()
:13:52 innobackupex: Starting to lock all tables…
>> log scanned up to ()
>> log scanned up to ()
:14:03 innobackupex: All tables locked and flushed to disk
:14:03 innobackupex: Starting to backup .frm, .MRG, .MYD, .MYI,
innobackupex: .TRG, .TRN, .ARM, .ARZ, .C, .CSV and .opt files in
innobackupex: subdirectories of ‘/var/lib/mysql’
innobackupex: Backing up file ‘/var/lib/mysql/test/test.frm’
innobackupex: Backing up file ‘/var/lib/mysql/test/db.opt’
:14:03 innobackupex: Finished backing up .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSV, .C and .opt files
innobackupex: Resuming ibbackup
xtrabackup: The latest check point (for incremental): ”
>> log scanned up to ()
xtrabackup: Stopping log copying thread.
xtrabackup: Transaction log of lsn () to () was copied.
:14:05 innobackupex: All tables unlocked
:14:05 innobackupex: Connection to database server closed
innobackupex: Backup created in directory ‘/tmp/data/_’
innobackupex: MySQL binlog position: filename ‘mysql-bin.000023’, position 107
:14:05 innobackupex: completed OK!
其中，–incremental指明是增量备份，–incremental-basedir指定上次完整备份或者增量备份文件的位置。这里的增量备份其实只针对的是InnoDB，对于MyISAM来说，还是完整备份。 在进行增量备份的恢复之前，先关闭数据库，然后删除数据库test
root@client2:/var/lib/mysql# service mysql stop
mysql stop/waiting
root@client2:/var/lib/mysql# rm -rf test
root@client2:/var/lib/mysql# ll
total 77856
drwxmysql mysql 4096 Mar 7 21:17 ./
drwxr-xr-x 38 root root 4096 Mar 7 19:52 ../
-rw-r–r– 1 root root 0 Jan 5 14:22 debian-5.5.flag
drwxmysql mysql 4096 Feb 11 17:39 django/
-rw-rwmysql mysqlMar 7 21:17 ibdata1
-rw-rwmysql mysqlMar 7 21:17 ib_logfile0
-rw-rwmysql mysqlMar 7 21:11 ib_logfile1
drwxmysql mysql 4096 Jan 5 22:55 monitor/
drwxmysql root 4096 Jan 5 14:22 mysql/
-rw-rwroot root 6 Jan 5 14:22 mysql_upgrade_info
drwxmysql mysql 4096 Jan 5 14:22 performance_schema/
drwxr-xr-x 2 mysql mysql 4096 Mar 7 19:58 xtrbackup/
增量备份的恢复
root@client2:/var/lib/mysql# innobackupex -user=root –password=defaults-file=/etc/mysql/my.cnf –apply-log /tmp/restore/ –incremental-dir=/tmp/data/_/
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2023, 2023 Innobase Oy
and Percona Inc. All Rights Reserved.
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints “completed OK!”.
:18:20 innobackupex: Starting ibbackup with command: xtrabackup_55 –defaults-file=”/etc/mysql/my.cnf” –prepare –target-dir=/tmp/restore –incremental-dir=/tmp/data/_/
xtrabackup_55 version 1.6.7 for Percona Server 5.5.16 Linux (x86_64) (revision id: undefined) incremental backup fromis enabled.
xtrabackup: cd to /tmp/restore
Xtrabackup 是由 percona 开源的免费数据库热备份软件，它能对 InnoDB 和 XtraDB 存储引擎的数据库非阻塞地备份。
为了方便建立从库，Xtrabackup 在备份完成后会将 binlog position 与 GTID 的相关信息保存于 xtrabackup_binlog_info 文件中。但是当你使用 Xtrabackup 生成的备份建立一个从库时，会发现恢复后的实例执行 show master status，显示的 Executed_Gtid_Set 与 xtrabackup_binlog_info 文件中记录的信息并不一致，而且使用 Xtrabackup 2.4 与 8.0（对 MySQL 8.0 进行备份）生成的备份在恢复后，信息不一致的表现又不相伏厅让同。本篇文章主要针对该现象进行简单的分析。一、Xtrabackup 2.4.18 for MySQL 5.7.26
现象
1. 使用 Xtrabackup 工具备份后，xtrabackup_binlog_info 文件记录的信息如下：\# cat xtrabackup_binlog_infomysql-bin.d3d9b9-4d49-11ea-932c-02023aba3fa6:. 将该备份恢复至一个新实例并启动该实例，执行 show master status; 查看信息：mysql> show master status\G*************************** 1. row ***************************File: mysql-bin. Position:Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 55d3d9b9-4d49-11ea-932c-02023aba3fa6:row in set (0.00 sec)此时会发现使用备份恢复的实例显示已执行过的 GTID 是，而备份文件显示的是，这是否表示两者相差的 GTID:代表的事务丢失了？通过对原实例（进行备份的实例）的 binlog 进行解析，来查询 GTID:这部分事务所生成的数据在新实例（通过备份恢复的实例）上是否存在。可以发现 GTID:这部分事务的数据都存在于新实例上，也就是说数据与 xtrabackup_binlog_info 文件记录的是一致的，只不过与 show master status 命令获取的信息的不一致。
原因分析
首先我们要清楚 Xtrabackup 2.4 的备份流程，大致如下：
1. start backup
2. copy ibdata1 / copy .ibd file
3. Excuted ftwrl
4. backup non-InnoDB tables and files
5. Writing xtrabackup_binlog_info
6. Executed FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS
7. Executed UNLOCK TABLES
8. Copying ib_buffer_pool
9. completed OK!
结合备份时的 general log 可知，Xtrabackup 在执行 ftwrl 并备份完所有非 InnoDB 表格的文件后通过 show master status 获取了 binlog position 和 GTID 的信缺局息，将其记录到 xtrabackup_binlog_info 文件中。
那么 show master status 获取的是哪些信息？
该命令提供本实例的 binlog 文件的状态信息，显示正在写入的 binlog 文件，以及伏芦当前的binlog position，并且 MySQL 5.7 在 MySQL 库下引入了 gtid_executed 表，该表会记录当前执行过的 GTID。
那么目前看来问题可能就出在 gtid_executed 表格上，通过测试和官方文档提供的信息可知，该表格虽然是 InnoDB 表，但是其中的数据并非是实时更新的，且该表格记录信息的方式存在以下两个情况：1. 如果禁用了 log_bin，实例不会在该表格记录任何信息；若从库的 log_slave_updates 为 OFF，那么从库会在应用 relay-log 中的每个事务时执行一次 insert mysql.gtid_executed 的操作。2. 如果启用了 log_bin，则该表格记录的是在 binlog 发生切换（rotate）的时候直到上一个 binlog 文件执行过的全部 GTID，而此时 show master status 获取的 Gtid 信息不再由 mysql.gtid_executed 表提供，而是由全局系统变量 gtid_exected 提供；如果服务器意外停止，则当前 binlog 文件中的 Gtid 不会保存在 mysql.gtid_executed 表中，在实例恢复期间，这些 Gtid 从 binlog 文件中读取并添加到表中。
小结
所以当备份恢复时，实际 show master status 可能会出现以下情况：1. 当 log_bin 禁用或者 log_slave_updates 为 OFF 时，备份恢复后的实例 show master status 显示为空。2. 当开启了 log_bin，但是该实例并未发生过 binlog 的切换时，备份恢复后的实例 show master status 显示也为空。3. 当开启了 log_bin，其该实例的 binlog 发生过切换时，备份恢复后的实例 show master status 显示的信息会比 xtrabackup_binlog_info 文件中记录的 GTID 缺失一部分，这一部分就是 mysql.gtid_executed 表格未记录的部分。二、Xtrabackup 8.0.8 for MySQL 8.0.18现象1. 使用 Xtrabackup 工具备份后，xtrabackup_binlog_info 文件记录的信息如下：# # cat xtrabackup_binlog_infobinlog. 70ec927f-4c6d-11ea-b88c-02023aba3fb1:. 查看备份实例相对应的 binlog 解析后的内容：
# mysqlbinlog -vv binlog.| less
定位至 70ec927f-4c6d-11ea-b88c-02023aba3fb1:621683
# at 508
#:46:47 server idend_log_posGTID last_committed=sequence_number=rbr_only=yes original_committed_timestamp=07 immediate_commit_timestamp=
transaction_length=317
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=07 (:46:47.CST)
# immediate_commit_timestamp=07 (:46:47.CST)
/*!80001 SET @@session.original_commit_timestamp=07*//*!*/;
/*!80014 SET @@session.original_server_version=80018*//*!*/;
/*!80014 SET @@session.immediate_server_version=80018*//*!*/;
SET @@SESSION.GTID_NEXT= ’70ec927f-4c6d-11ea-b88c-02023aba3fb1:621683’/*!*/;
# at 583
#:46:47 server idend_log_posQuery thread_id=214 exec_time=0 error_code=0
SET TIMESTAMP=/*!*/;
BEGIN
/*!*/;
# at 659
#:46:47 server idend_log_posRows_query
# insert into t1 values(null,2)
# at 708
#:46:47 server idend_log_posTable_map: `mysqlslap`.`t1` mapped to number 314
# at 758
#:46:47 server idend_log_posWrite_rows: table id 314 flags: STMT_END_F
BINLOG ‘
x+JEXh2wIAoAMQAAAMQCAACAAB1pbnNlcnQgaW50byB0MSB2YWx1ZXMobnVCwyKQ==
x+JEXhOwIAoAMgAAAPYCAAAAADoBAAAAAAEACW15c3Fsc2xhcAACdDEAAgMDAAIBAQA=
x+JEXh6wIAoAKAAAAB4DAAAAADoBAAAAAAEAAgAC/wCKAAEAAgAAAA==
‘/*!*/;
### INSERT INTO `mysqlslap`.`t1`
### SET
### @1=65674 /* INT meta=0 nullable=0 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
# at 798
#:46:47 server idend_log_posXid =
COMMIT/*!*/;
可以发现该文件提供的 binlog position 与 GTID 并不对应。而 binlog.000033:1459 对应的 GTID 是 70ec927f-4c6d-11ea-b88c-02023aba3fb1:提交后的下一个位置：
# at 1142
#:46:47 server idend_log_posGTID last_committed=sequence_number=rbr_only=yes original_committed_timestamp=46 immediate_commit_timestamp=
transaction_length=317
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=46 (:46:47.CST)
# immediate_commit_timestamp=46 (:46:47.CST)
/*!80001 SET @@session.original_commit_timestamp=46*//*!*/;
/*!80014 SET @@session.original_server_version=80018*//*!*/;
/*!80014 SET @@session.immediate_server_version=80018*//*!*/;
SET @@SESSION.GTID_NEXT= ’70ec927f-4c6d-11ea-b88c-02023aba3fb1:621685’/*!*/;
# at 1217
#:46:47 server idend_log_posQuery thread_id=215 exec_time=0 error_code=0
SET TIMESTAMP=/*!*/;
BEGIN
/*!*/;
# at 1293
#:46:47 server idend_log_posRows_query
# insert into t1 values(null,2)
# at 1342
#:46:47 server idend_log_posTable_map: `mysqlslap`.`t1` mapped to number 314
# at 1392
#:46:47 server idend_log_posWrite_rows: table id 314 flags: STMT_END_F
BINLOG ‘
x+JEXh2wIAoAMQAAAD4FAACAAB1pbnNlcnQgaW50byB0MSB2YWx1ZXMobnVCwyKQ==
x+JEXhOwIAoAMgAAAHAFAAAAADoBAAAAAAEACW15c3Fsc2xhcAACdDEAAgMDAAIBAQA=
x+JEXh6wIAoAKAAAAJgFAAAAADoBAAAAAAEAAgAC/wCMAAEAAgAAAA==
‘/*!*/;
### INSERT INTO `mysqlslap`.`t1`
### SET
### @1=65676 /* INT meta=0 nullable=0 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
# at 1432
#:46:47 server idend_log_posXid =
COMMIT/*!*/;
# at 1459
3. 再看将备份恢复到一个新实例并启动后，执行 show master status 显示的信息：mysql> show master status\G*************************** 1. row ***************************File: binlog. Position:Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 70ec927f-4c6d-11ea-b88c-02023aba3fb1:row in set (0.00 sec)
可以发现与 Xtrabackup 2.4 不同的是，该备份的 xtrabackup_binlog_info 文件记录的信息并不准确，而备份恢复后显示的信息却是准确的。
原因
首先我们来看一下 Xtrabackup 8.0 针对 MySQL 8.0 备份的大致过程：1. start backup2. copy .ibd file3. backup non-InnoDB tables and files4. Executed FLUSH NO_WRITE_TO_BINLOG BINARY LOGS5. Selecting LSN and binary log position from p_s.log_status6. copy last binlog file7. Writing /mysql/backup/backup/binlog.index8. Writing xtrabackup_binlog_info9. Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS10. copy ib_buffer_pool11. completed OK!由以上步骤可知，Xtrabackup 8.0 对 MySQL 8.0 的备份与 Xtrabackup 2.4 略有不同，根据 percona 官方文档的信息，当 MySQL 8.0 中仅存在 InnoDB 引擎的表格时，不再执行ftwrl（当存在非 InnoDB 的表格或者使用 –slave-info 选项时会执行），而是根据上述步骤的第 5 步，Xtrabackup 8.0 会通过SELECT server_uuid, local, replication, storage_engines FROM performance_schema.log_status
来获取 LSN 、binlog position and Gtid。1. performance_schema.log_status 是 MySQL 8.0 提供给在线备份工具获取复制日志文件信息的表格。查询 log_status 表时，服务器将阻止日志的记录和相关的更改来获取足够的时间以填充该表，然后释放资源。Log_status 表通知在线备份工具应记录主库的 binlog 的哪个位点和 gtid_executed 的值，还有每个复制通道的 relay log。它还为各个存储引擎提供了相关信息，例如 InnoDB 存储引擎使用的最后一个日志序列号（LSN）和最后一个检查点的 LSN。2. 经过测试发现，当无数据写入时， performance_schema.log_status 提供的 binlog position 与 GTID 是一致的，但是当有大量数据持续写入时，该表格提供的 binlog position 与 GTID 信息将不再一致，如下图：
3. 既然 performance_schema.log_status 提供的信息不一致，那么为什么备份恢复后，GTID 没有缺失？这是因为 Xtrabackup 8.0 在备份过程中多了两步操作，FLUSH NO_WRITE_TO_BINLOG BINARY LOGS 和 copy binlog，Xtrabackup 8.0 在备份完非 InnoDB 表格的文件时会先切换 binlog，然后将切换后的 binlog 也进行备份，这样使用该备份恢复的新实例在启动后不仅会读取 gtid_executed 表，也会读取 binlog 文件来更新 GTID，就可以保持与备份时 xtrabackup_binlog_info 文件记录的 binlog position 保持一致（需要注意的是 MySQL 8.0 的 gtid_executed 表格不再是当 binlog 切换时更新，而是会不断的实时更新，但需要注意在有大量数据写入时也不能做到和全局变量 gtid_exeuted 保持严格一致）。4. 当 MySQL 8.0 中存在非 InnoDB 的表格，比如 MyISAM 表时，Xtrabackup 8.0 会在执行完 FLUSH NO_WRITE_TO_BINLOG BINARY LOGS 后执行 ftwrl，此时查询 performance_schema.log_status 得到的 binlog position 与 GTID 是一致的，且备份恢复后 show master status 显示的信息也与 xtrabackup_binlog_info 文件记录的信息一致。
总结1. Xtrabackup 2.4 备份后生成的 xtrabackup_binlog_info 文件记录的 GTID 信息是准确的，但是备份恢复后 show master status 显示的 GTID 是不准确的。2. Xtrabackup 8.0 在备份只有 InnoDB 表的实例时，xtrabackup_binlog_info 文件记录的 GTID 信息不一定是准确的，但是备份恢复后 show master status 显示的 GTID 是准确的。3. Xtrabackup 8.0 在备份有非 InnoDB 表格的实例时，xtrabackup_binlog_info 文件记录的 GTID 信息是准确的，备份恢复后 show master status 显示的 GTID 也是准确的。
注意：此处的“准确”主要指 xtrabackup_binlog_info 文件中记录的 GTID 与备份中实际的 binlog position & 数据是否一致。
ibd文件恢复数据库的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于ibd文件恢复数据库,快速恢复IBD文件中的数据库数据方法,网站宕机 服务器宕机 数据库宕机 宕机怎么办,生产环境究竟是使用mysqldump还是xtrabackup来备份与恢复数据库的信息别忘了在本站进行查找喔。
