返回顶部
首页 > 资讯 > 数据库 >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://lsjlt.com/news/66434.html(转载时请注明来源链接)

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

猜你喜欢
  • 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
  • sqlserver数据库怎么恢复到指定时间点
    要将SQL Server数据库恢复到指定时间点,您可以按照以下步骤操作: 首先,您需要确保已启用数据库的完整或者简单恢复模式。如...
    99+
    2024-04-09
    sqlserver
  • Xtrabackup恢复时报错'Error: datadir must be specified'怎么办
    小编给大家分享一下Xtrabackup恢复时报错'Error: datadir must be specified'怎么办,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大...
    99+
    2024-04-02
  • mysql怎么恢复表数据
    通过 mysql 命令行工具,可按以下步骤恢复表数据:确定数据库;导入备份文件;刷新表。要恢复特定表数据,可进一步按照以下步骤操作:确定表;从备份中选择行数据;将数据插入表中。 如何恢...
    99+
    2024-04-14
    mysql
  • oracle误删表怎么恢复
    恢复误删的 oracle 表的方法有两种:使用回滚段:恢复最近已删除的表,步骤包括:查询回滚段、创建临时表、复制数据、删除临时表。使用备份:恢复较旧或回滚段不可用的已删除表,步骤包括:使...
    99+
    2024-04-18
    oracle 数据丢失
  • navicat误删表怎么恢复
    navicat 误删表恢复方法:检查回收站中是否有误删表并还原。使用二进制日志恢复:打开二进制日志,查找起始和停止位置,从二进制日志文件中恢复表并导回数据库。使用第三方备份工具定期备份数...
    99+
    2024-04-24
    mysql navicat 数据丢失
  • mysql清空表怎么恢复
    如果不慎清空了 mysql 表,有以下恢复方法:从备份恢复:如有数据备份,可使用 mysqldump 导出备份,删除清空的表并导入备份。使用 binlog 恢复:如果有启用且保存了二进制...
    99+
    2024-08-01
    mysql 数据丢失
  • SQL怎么恢复drop掉的表
    本篇内容主要讲解“SQL怎么恢复drop掉的表”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“SQL怎么恢复drop掉的表”吧! ...
    99+
    2024-04-02
  • oracle怎么恢复删除的表
    要恢复删除的表,你可以使用Oracle的闪回技术,具体步骤如下:1. 首先,确定你的数据库开启了闪回功能。你可以使用以下命令来检查:...
    99+
    2023-08-22
    oracle
  • mysql误删除表怎么恢复
    当MySQL中的表被误删除后,有以下几种方法可以尝试恢复: 使用回收站功能(仅适用于 InnoDB 引擎):如果你使用的是 In...
    99+
    2023-10-27
    mysql
  • mysql怎么恢复删除的表
    可以通过以下步骤恢复已删除的 mysql 表:使用 binlog 恢复(适用于启用二进制日志记录且未覆盖删除事务的情况);使用 mysql 备份恢复(适用于有定期备份的情况);使用文件系...
    99+
    2024-04-14
    mysql 数据丢失
  • mysql表删除了怎么恢复
    mysql 表误删恢复有两种方法:二进制日志恢复:确认开启二进制日志使用 mysqlbinlog 找出删除表的二进制日志将二进制日志导入或重新应用数据文件恢复:找到被删表的 .frm、....
    99+
    2024-05-30
    mysql
  • mysql删除的表怎么恢复
    mysql 中已删除表的恢复方法主要涉及以下步骤:检查 binlog 日志以获取删除事务信息;使用数据恢复工具扫描数据库文件;从备份还原表数据;或联系 mysql 支持寻求帮助。 My...
    99+
    2024-05-16
    mysql 数据丢失
  • oracle表删除了怎么恢复
    要恢复已删除的 oracle 表,需考虑回收站状态、备份情况和表空间配置。若回收站已启用,可使用回收站查询表信息并恢复;若有备份,可从备份中恢复;若表位于永久表空间,可使用表空间恢复。步...
    99+
    2024-05-21
    oracle
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作