iis服务器助手广告广告
返回顶部
首页 > 资讯 > 数据库 >Percona Xtrabackup 2.4 怎么恢复指定表
  • 706
分享到

Percona Xtrabackup 2.4 怎么恢复指定表

2024-04-02 19:04:59 706人浏览 八月长安
摘要

这期内容当中小编将会给大家带来有关Percona Xtrabackup 2.4 怎么恢复指定表,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。

这期内容当中小编将会给大家带来有关Percona Xtrabackup 2.4 怎么恢复指定表,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。

在5.6之前的服务版本,在不同的Mysql服务中通过复制表的文件来拷贝表是不可能的,即使启用了innodb_file_per_table。然而,通过Percona XtraBackup,可以从任意的InnoDB数据库中导出指定的表,并将它们导入到使用XtraDB的Percona服务中或mysql 5.6。这只对.ibd文件有效。
 
创建测试
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> show tables;
+----------------+
| Tables_in_test |
+----------------+
| test           |
+----------------+
1 row in set (0.00 sec)
mysql> CREATE TABLE export_test (
-> a int(11) DEFAULT NULL
-> ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Query OK, 0 rows affected (0.31 sec)
mysql> insert into export_test values(100),(200);
Query OK, 2 rows affected (0.09 sec)
Records: 2  Duplicates: 0  Warnings: 0
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from export_test;
+------+
| a    |
+------+
|  100 |
|  200 |
+------+
2 rows in set (0.03 sec)

 
导出表
mysql> show variables like 'innodb_file_per_table';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_file_per_table | ON    |
+-----------------------+-------+
1 row in set (0.00 sec)
--执行备份
[root@localhost mysql]# /install/percona-xtrabackup-2.4.4-linux-x86_64/bin/xtrabackup --defaults-file=/etc/my.cnf --backup --datadir=/var/lib/mysql/ --target-dir=/backup/20160810 --user root --passWord 'root'
导出的表必须是以 innodb_file_per_table 格式创建,在备份目录中以.bd文件格式存在。
[root@localhost /]# find /backup/20160810 -name export_test.*
/backup/20160810/test/export_test.frm
/backup/20160810/test/export_test.ibd

 
当准备备份的时候,增加xtrabackup --export参数到命令中。
[root@localhost mysql]# /install/percona-xtrabackup-2.4.4-Linux-x86_64/bin/xtrabackup --prepare --export --target-dir=/backup/20160810/
/install/percona-xtrabackup-2.4.4-Linux-x86_64/bin/xtrabackup version 2.4.4 based on MySQL Server 5.7.13 Linux (x86_64) (revision id: df58cf2)
xtrabackup: auto-enabling --innodb-file-per-table due to the --export option
xtrabackup: cd to /backup/20160810
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(1639441)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:   innodb_log_group_home_dir = .
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 8388608
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:   innodb_log_group_home_dir = .
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 8388608
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: PUNCH HOLE support not available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.3
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: The log sequence number 1633851 in the system tablespace does not match the log sequence number 1639441 in the ib_logfiles!
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Doing recovery: scanned up to log sequence number 1639441 (0%)
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.13 started; log sequence number 1639441
xtrabackup: export option is specified.
xtrabackup: export metadata of table 'mysql/innodb_index_stats' to file `./mysql/innodb_index_stats.exp` (1 indexes)
xtrabackup:     name=PRIMARY, id.low=18, page=3
xtrabackup: export metadata of table 'mysql/innodb_table_stats' to file `./mysql/innodb_table_stats.exp` (1 indexes)
xtrabackup:     name=PRIMARY, id.low=17, page=3
xtrabackup: export metadata of table 'mysql/slave_worker_info' to file `./mysql/slave_worker_info.exp` (1 indexes)
xtrabackup:     name=PRIMARY, id.low=21, page=3
xtrabackup: export metadata of table 'mysql/slave_relay_log_info' to file `./mysql/slave_relay_log_info.exp` (1 indexes)
xtrabackup:     name=PRIMARY, id.low=19, page=3
xtrabackup: export metadata of table 'mysql/slave_master_info' to file `./mysql/slave_master_info.exp` (1 indexes)
xtrabackup:     name=PRIMARY, id.low=20, page=3
xtrabackup: export metadata of table 'test/export_test' to file `./test/export_test.exp` (1 indexes)
xtrabackup:     name=GEN_CLUST_INDEX, id.low=23, page=3
xtrabackup: export metadata of table 'test/test' to file `./test/test.exp` (1 indexes)
xtrabackup:     name=GEN_CLUST_INDEX, id.low=22, page=3

 
xtrabackup: starting shutdown with innodb_fast_shutdown = 0
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 1639460
InnoDB: Number of pools: 1
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:   innodb_log_group_home_dir = .
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 50331648
InnoDB: PUNCH HOLE support not available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.3
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 48 MB
InnoDB: Setting log file ./ib_logfile1 size to 48 MB
InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
InnoDB: New log files created, LSN=1639460
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 1639948
InnoDB: Doing recovery: scanned up to log sequence number 1639957 (0%)
InnoDB: Doing recovery: scanned up to log sequence number 1639957 (0%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
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.13 started; log sequence number 1639957
xtrabackup: starting shutdown with innodb_fast_shutdown = 0
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 1639976
160810 15:14:42 completed OK!
在目标目录下,可以看到.exp文件
[root@localhost ~]# cd /backup/20160810/test/
[root@localhost test]# ls -trl
total 256
-rw-r-----. 1 root root 98304 Aug 10 15:06 export_test.ibd
-rw-r-----. 1 root root 98304 Aug 10 15:06 test.ibd
-rw-r-----. 1 root root  8554 Aug 10 15:06 export_test.frm
-rw-r-----. 1 root root  8556 Aug 10 15:06 test.frm
-rw-r-----. 1 root root 16384 Aug 10 15:14 export_test.exp
-rw-r--r--. 1 root root   374 Aug 10 15:14 export_test.cfg
-rw-r-----. 1 root root 16384 Aug 10 15:14 test.exp
-rw-r--r--. 1 root root   369 Aug 10 15:14 test.cfg
.exp、.ibd、.cfg这三个文件用于数据库导入中

 
导入表
删除表
mysql> drop table export_test;
Query OK, 0 rows affected (1.45 sec)
在目标MySQL服务器上,创建一张具有相同结构的空表。
mysql> CREATE TABLE export_test (
->      a int(11) DEFAULT NULL
->      ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Query OK, 0 rows affected (0.06 sec)
mysql> ALTER TABLE test.export_test DISCARD TABLESPACE;
Query OK, 0 rows affected (0.10 sec)
拷贝导出文件到数据目录中
[root@localhost test]# cp export_test.ibd export_test.exp export_test.cfg /var/lib/mysql/test
mysql> ALTER TABLE test.export_test IMPORT TABLESPACE;
ERROR 1815 (HY000): Internal error: Cannot reset LSNs in table '"test"."export_test"' : Tablespace not found
更改文件权限为mysql
[root@localhost ~]# cd /var/lib/mysql/test/
[root@localhost test]# ls
export_test.frm  test.frm  test.ibd
[root@localhost test]# ls
export_test.cfg  export_test.exp  export_test.frm  export_test.ibd  test.frm  test.ibd
[root@localhost test]# ls -trl
total 236
-rw-r-----. 1 mysql mysql  8556 Aug  8 17:17 test.frm
-rw-r-----. 1 mysql mysql 98304 Aug  8 17:17 test.ibd
-rw-rw----. 1 mysql mysql  8554 Aug 10 15:30 export_test.frm
-rw-r-----. 1 root  root  98304 Aug 10 15:34 export_test.ibd
-rw-r-----. 1 root  root  16384 Aug 10 15:34 export_test.exp
-rw-r--r--. 1 root  root    374 Aug 10 15:34 export_test.cfg
[root@localhost test]# chown -R mysql:mysql .
[root@localhost test]# ls -trl
total 236
-rw-r-----. 1 mysql mysql  8556 Aug  8 17:17 test.frm
-rw-r-----. 1 mysql mysql 98304 Aug  8 17:17 test.ibd
-rw-rw----. 1 mysql mysql  8554 Aug 10 15:30 export_test.frm
-rw-r-----. 1 mysql mysql 98304 Aug 10 15:34 export_test.ibd
-rw-r-----. 1 mysql mysql 16384 Aug 10 15:34 export_test.exp
-rw-r--r--. 1 mysql mysql   374 Aug 10 15:34 export_test.cfg
mysql> ALTER TABLE test.export_test IMPORT TABLESPACE;
Query OK, 0 rows affected (0.11 sec)
验证表中的数据
mysql> select * from export_test;
+------+
| a    |
+------+
|  100 |
|  200 |
+------+
2 rows in set (0.00 sec)
需要注意的是,导入表后,表的永久统计信息是空的,需要重新进行收集
mysql> select * from innodb_index_stats where table_name='export_test';
+---------------+-------------+-----------------+---------------------+--------------+------------+-------------+-----------------------------------+
| database_name | table_name  | index_name      | last_update         | stat_name    | stat_value | sample_size | stat_description                  |
+---------------+-------------+-----------------+---------------------+--------------+------------+-------------+-----------------------------------+
| test          | export_test | GEN_CLUST_INDEX | 2016-08-10 15:36:50 | n_diff_pfx01 |          2 |           1 | DB_ROW_ID                         |
| test          | export_test | GEN_CLUST_INDEX | 2016-08-10 15:36:50 | n_leaf_pages |          1 |        NULL | Number of leaf pages in the index |
| test          | export_test | GEN_CLUST_INDEX | 2016-08-10 15:36:50 | size         |          1 |        NULL | Number of pages in the index      |
+---------------+-------------+-----------------+---------------------+--------------+------------+-------------+-----------------------------------+
3 rows in set (0.00 sec)
mysql> select * from innodb_table_stats where table_name='export_test';
+---------------+-------------+---------------------+--------+----------------------+--------------------------+
| database_name | table_name  | last_update         | n_rows | clustered_index_size | sum_of_other_index_sizes |
+---------------+-------------+---------------------+--------+----------------------+--------------------------+
| test          | export_test | 2016-08-10 15:36:50 |      2 |                    1 |                        0 |
+---------------+-------------+---------------------+--------+----------------------+--------------------------+
1 row in set (0.00 sec)
mysql> analyze table test.export_test;
+------------------+---------+----------+----------+
| Table            | Op      | Msg_type | Msg_text |
+------------------+---------+----------+----------+
| test.export_test | analyze | status   | OK       |
+------------------+---------+----------+----------+
1 row in set (0.01 sec)
mysql> select * from innodb_index_stats where table_name='export_test';
+---------------+-------------+-----------------+---------------------+--------------+------------+-------------+-----------------------------------+
| database_name | table_name  | index_name      | last_update         | stat_name    | stat_value | sample_size | stat_description                  |
+---------------+-------------+-----------------+---------------------+--------------+------------+-------------+-----------------------------------+
| test          | export_test | GEN_CLUST_INDEX | 2016-08-10 15:48:32 | n_diff_pfx01 |          2 |           1 | DB_ROW_ID                         |
| test          | export_test | GEN_CLUST_INDEX | 2016-08-10 15:48:32 | n_leaf_pages |          1 |        NULL | Number of leaf pages in the index |
| test          | export_test | GEN_CLUST_INDEX | 2016-08-10 15:48:32 | size         |          1 |        NULL | Number of pages in the index      |
+---------------+-------------+-----------------+---------------------+--------------+------------+-------------+-----------------------------------+
3 rows in set (0.00 sec)
mysql> select * from innodb_table_stats where table_name='export_test';
+---------------+-------------+---------------------+--------+----------------------+--------------------------+
| database_name | table_name  | last_update         | n_rows | clustered_index_size | sum_of_other_index_sizes |
+---------------+-------------+---------------------+--------+----------------------+--------------------------+
| test          | export_test | 2016-08-10 15:48:32 |      2 |                    1 |                        0 |
+---------------+-------------+---------------------+--------+----------------------+--------------------------+
1 row in set (0.00 sec)

上述就是小编为大家分享的Percona Xtrabackup 2.4 怎么恢复指定表了,如果刚好有类似的疑惑,不妨参照上述分析进行理解。如果想知道更多相关知识,欢迎关注编程网数据库频道。

您可能感兴趣的文档:

--结束END--

本文标题: Percona Xtrabackup 2.4 怎么恢复指定表

本文链接: https://www.lsjlt.com/news/66434.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

本篇文章演示代码以及资料文档资料下载

下载Word文档到电脑,方便收藏和打印~

下载Word文档
猜你喜欢
  • Percona Xtrabackup 2.4 怎么恢复指定表
    这期内容当中小编将会给大家带来有关Percona Xtrabackup 2.4 怎么恢复指定表,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。 ...
    99+
    2024-04-02
  • Percona XtraBackup 2.4 xtrabackup全量、增量备份恢复流程
    xtrabackup常用参数 --backup 创建备份并将备份存放到--target-dir目录 --defaults-file=[MY.CNF] 配置文件的路径 --target-dir=DIRE...
    99+
    2024-04-02
  • 如何用Percona XtraBackup进行MySQL从库的单表备份和恢复
    环境说明: 主库:192.168.0.1 从库1:192.168.0.2 从库2:192.168.0.3 备份工具 : Percona xtrabackup version 2.4.8 based on M...
    99+
    2024-04-02
  • Percona XtraBackup怎样实现全备及增量备份与恢复
    Percona XtraBackup怎样实现全备及增量备份与恢复,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。 p...
    99+
    2024-04-02
  • oracle怎么从dmp中恢复指定表
    要从dmp文件中恢复指定表,可以使用Oracle的impdp工具。以下是使用impdp工具恢复指定表的步骤:1. 打开命令行窗口,使...
    99+
    2023-09-29
    oracle
  • 基于percona xtrabackup 2.4.14的增量备份恢复还原mysql 5.6是怎么样的
    这期内容当中小编将会给大家带来有关基于percona xtrabackup 2.4.14的增量备份恢复还原mysql 5.6是怎么样的,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以...
    99+
    2024-04-02
  • oracle怎么恢复指定时间的数据
    要恢复Oracle数据库中指定时间的数据,可以按照以下步骤进行操作:1. 首先,确定你想要恢复的时间点。可以通过查询数据库的日志文件...
    99+
    2023-08-21
    oracle
  • Xtrabackup恢复时报错'Error: datadir must be specified'怎么办
    小编给大家分享一下Xtrabackup恢复时报错'Error: datadir must be specified'怎么办,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大...
    99+
    2024-04-02
  • sqlserver数据库怎么恢复到指定时间点
    要将SQL Server数据库恢复到指定时间点,您可以按照以下步骤操作: 首先,您需要确保已启用数据库的完整或者简单恢复模式。如...
    99+
    2024-04-09
    sqlserver
  • oracle误删表怎么恢复
    恢复误删的 oracle 表的方法有两种:使用回滚段:恢复最近已删除的表,步骤包括:查询回滚段、创建临时表、复制数据、删除临时表。使用备份:恢复较旧或回滚段不可用的已删除表,步骤包括:使...
    99+
    2024-04-18
    oracle 数据丢失
  • mysql怎么恢复表数据
    通过 mysql 命令行工具,可按以下步骤恢复表数据:确定数据库;导入备份文件;刷新表。要恢复特定表数据,可进一步按照以下步骤操作:确定表;从备份中选择行数据;将数据插入表中。 如何恢...
    99+
    2024-04-14
    mysql
  • navicat误删表怎么恢复
    navicat 误删表恢复方法:检查回收站中是否有误删表并还原。使用二进制日志恢复:打开二进制日志,查找起始和停止位置,从二进制日志文件中恢复表并导回数据库。使用第三方备份工具定期备份数...
    99+
    2024-04-24
    mysql navicat 数据丢失
  • mysql表删除了怎么恢复
    非常抱歉,由于您没有提供文章标题,我无法为您生成一篇高质量的文章。请您提供文章标题,我将尽快为您生成一篇优质的文章。...
    99+
    2024-05-30
  • oracle怎么恢复删除的表
    要恢复删除的表,你可以使用Oracle的闪回技术,具体步骤如下:1. 首先,确定你的数据库开启了闪回功能。你可以使用以下命令来检查:...
    99+
    2023-08-22
    oracle
  • mysql删除的表怎么恢复
    非常抱歉,由于您没有提供文章标题,我无法为您生成一篇高质量的文章。请您提供文章标题,我将尽快为您生成一篇优质的文章。...
    99+
    2024-05-16
  • SQL怎么恢复drop掉的表
    本篇内容主要讲解“SQL怎么恢复drop掉的表”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“SQL怎么恢复drop掉的表”吧! ...
    99+
    2024-04-02
  • mysql误删除表怎么恢复
    当MySQL中的表被误删除后,有以下几种方法可以尝试恢复: 使用回收站功能(仅适用于 InnoDB 引擎):如果你使用的是 In...
    99+
    2023-10-27
    mysql
  • mysql怎么恢复删除的表
    可以通过以下步骤恢复已删除的 mysql 表:使用 binlog 恢复(适用于启用二进制日志记录且未覆盖删除事务的情况);使用 mysql 备份恢复(适用于有定期备份的情况);使用文件系...
    99+
    2024-04-14
    mysql 数据丢失
  • oracle表删除了怎么恢复
    非常抱歉,由于您没有提供文章标题,我无法为您生成一篇高质量的文章。请您提供文章标题,我将尽快为您生成一篇优质的文章。...
    99+
    2024-05-21
  • oracle删除表数据怎么恢复
    oracle 中恢复已删除的表数据涉及以下步骤:检查回收站,如果找到已删除的表,执行步骤 2;运行查询还原表,可指定时间戳恢复到特定时间点;还原后可从回收站中删除表(可选);检查数据是否...
    99+
    2024-05-11
    oracle
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作