备案控制台
探索云世界
开发者社区 数据库 文章 正文

【Mysql】xtrabackup 备份和恢复测试

2011-12-11 694
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 RDS MySQL Serverless，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
简介： 1 创建测试环境mysql> create table t1 as select * from sbtest;Query OK, 1000000 rows affected (33.
1 创建测试环境
mysql> create table t1 as select * from sbtest;
Query OK, 1000000 rows affected (33.37 sec)
Records: 1000000  Duplicates: 0  Warnings: 0
mysql> insert into t1 select * from t1;                          
Query OK, 1000000 rows affected (1 min 4.02 sec)
Records: 1000000  Duplicates: 0  Warnings: 0
mysql> 
mysql> exit
2 执行备份
-bash-3.2$ xtrabackup --defaults-file=/etc/my.cnf --backup --target-dir=/opt/mysql/backup/test
xtrabackup version 1.6.3 for Percona Server 5.1.55 unknown-linux-gnu (x86_64) (revision id: 292)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /opt/mysql/data
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 = 268435456
>> log scanned up to (4972495139)
[01] Copying ./ibdata1 
     to /opt/mysql/backup/test/ibdata1
>> log scanned up to (4972495139)
>> log scanned up to (4972495139)
>> log scanned up to (4972495139)
>> log scanned up to (4972495139)
>> log scanned up to (4972495139)
>> log scanned up to (4976241217)
>> log scanned up to (5050531464)
>> log scanned up to (5116904909)
>> log scanned up to (5144668918)
>> log scanned up to (5167804122)
>> log scanned up to (5228139500)
>> log scanned up to (5230910238)
>> log scanned up to (5230910238)
>> log scanned up to (5230910238)
>> log scanned up to (5230910238)
>> log scanned up to (5230910238)
[01]        ...done
xtrabackup: The latest check point (for incremental): '5178591272'
>> log scanned up to (5230910238)
xtrabackup: Stopping log copying thread.
xtrabackup: Transaction log of lsn (4972495139) to (5230910238) was copied.
3 关闭mysql 服务：
[root@rac3 tmp]# service mysql stop 
Shutting down MySQL..                                      [确定]
4 删除数据文件和innodb log
-bash-3.2$ pwd
/opt/mysql/data
-bash-3.2$ ls ib*
ibdata1  ib_logfile0  ib_logfile1  ib_logfile2
-bash-3.2$ rm ib*
-bash-3.2$ 
5 使用xtrabackup 恢复数据
-bash-3.2$ xtrabackup --defaults-file=/etc/my.cnf --prepare --target-dir=/opt/mysql/backup/test
xtrabackup version 1.6.3 for Percona Server 5.1.55 unknown-linux-gnu (x86_64) (revision id: 292)
xtrabackup: cd to /opt/mysql/backup/test
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=290717696, start_lsn=(4972495139)
xtrabackup: Temporary instance for recovery is set 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 = 1
xtrabackup:   innodb_log_file_size = 290717696
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
111211 16:25:36  InnoDB: Initializing buffer pool, size = 100.0M
111211 16:25:36  InnoDB: Completed initialization of buffer pool
111211 16:25:36  InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 4972495139
111211 16:25:36  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Doing recovery: scanned up to log sequence number 4977737728 (2 %)
InnoDB: Doing recovery: scanned up to log sequence number 4982980608 (4 %)
InnoDB: Doing recovery: scanned up to log sequence number 4988223488 (6 %)
InnoDB: Doing recovery: scanned up to log sequence number 4993466368 (8 %)
InnoDB: Doing recovery: scanned up to log sequence number 4998709248 (10 %)
InnoDB: Doing recovery: scanned up to log sequence number 5003952128 (12 %)
InnoDB: Doing recovery: scanned up to log sequence number 5009195008 (14 %)
InnoDB: Doing recovery: scanned up to log sequence number 5014437888 (16 %)
InnoDB: Doing recovery: scanned up to log sequence number 5019680768 (18 %)
InnoDB: Doing recovery: scanned up to log sequence number 5024923648 (20 %)
InnoDB: Doing recovery: scanned up to log sequence number 5030166528 (22 %)
111211 16:25:38  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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: Doing recovery: scanned up to log sequence number 5035409408 (24 %)
InnoDB: Doing recovery: scanned up to log sequence number 5040652288 (26 %)
InnoDB: Doing recovery: scanned up to log sequence number 5045895168 (28 %)
InnoDB: Doing recovery: scanned up to log sequence number 5051138048 (30 %)
InnoDB: Doing recovery: scanned up to log sequence number 5056380928 (32 %)
InnoDB: Doing recovery: scanned up to log sequence number 5061623808 (34 %)
InnoDB: Doing recovery: scanned up to log sequence number 5066866688 (36 %)
InnoDB: Doing recovery: scanned up to log sequence number 5072109568 (38 %)
InnoDB: Doing recovery: scanned up to log sequence number 5077352448 (40 %)
InnoDB: Doing recovery: scanned up to log sequence number 5082595328 (42 %)
InnoDB: Doing recovery: scanned up to log sequence number 5087838208 (44 %)
111211 16:25:42  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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: Doing recovery: scanned up to log sequence number 5093081088 (46 %)
InnoDB: Doing recovery: scanned up to log sequence number 5098323968 (48 %)
InnoDB: Doing recovery: scanned up to log sequence number 5103566848 (50 %)
InnoDB: Doing recovery: scanned up to log sequence number 5108809728 (52 %)
InnoDB: Doing recovery: scanned up to log sequence number 5114052608 (54 %)
InnoDB: Doing recovery: scanned up to log sequence number 5119295488 (56 %)
InnoDB: Doing recovery: scanned up to log sequence number 5124538368 (58 %)
InnoDB: Doing recovery: scanned up to log sequence number 5129781248 (60 %)
InnoDB: Doing recovery: scanned up to log sequence number 5135024128 (62 %)
InnoDB: Doing recovery: scanned up to log sequence number 5140267008 (64 %)
InnoDB: Doing recovery: scanned up to log sequence number 5145509888 (66 %)
111211 16:25:45  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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: Doing recovery: scanned up to log sequence number 5150752768 (68 %)
InnoDB: Doing recovery: scanned up to log sequence number 5155995648 (71 %)
InnoDB: Doing recovery: scanned up to log sequence number 5161238528 (73 %)
InnoDB: Doing recovery: scanned up to log sequence number 5166481408 (75 %)
InnoDB: Doing recovery: scanned up to log sequence number 5171724288 (77 %)
InnoDB: Doing recovery: scanned up to log sequence number 5176967168 (79 %)
InnoDB: Doing recovery: scanned up to log sequence number 5182210048 (81 %)
InnoDB: Doing recovery: scanned up to log sequence number 5187452928 (83 %)
InnoDB: Doing recovery: scanned up to log sequence number 5192695808 (85 %)
InnoDB: Doing recovery: scanned up to log sequence number 5197938688 (87 %)
InnoDB: Doing recovery: scanned up to log sequence number 5203181568 (89 %)
111211 16:25:48  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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: Doing recovery: scanned up to log sequence number 5208424448 (91 %)
InnoDB: Doing recovery: scanned up to log sequence number 5213667328 (93 %)
InnoDB: Doing recovery: scanned up to log sequence number 5218910208 (95 %)
InnoDB: Doing recovery: scanned up to log sequence number 5224153088 (97 %)
InnoDB: Doing recovery: scanned up to log sequence number 5229395968 (99 %)
InnoDB: Doing recovery: scanned up to log sequence number 5230910238 (100 %)
111211 16:25:51  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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: Last MySQL binlog file position 0 1249, file name ./mysql-bin.000018
111211 16:25:52 Percona XtraDB (http://www.percona.com) 1.0.15-12.5 started; log sequence number 5230910238
[notice (again)]
  If you use binary log and don't use any hack of group commit,
  the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 1249, file name ./mysql-bin.000018
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
111211 16:25:52  InnoDB: Starting shutdown...
111211 16:25:53  InnoDB: Shutdown completed; log sequence number 5230910238
6 将生成的文件拷贝备份到/opt/mysql/data
-bash-3.2$ cp ibdata1  /opt/mysql/data/
7 启动mysql服务
[root@rac3 tmp]# service mysql start
Starting MySQL..                                           [确定]
8 测试
-bash-3.2$ mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.5.18-log MySQL Community Server (GPL)
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> use test;
Database changed
mysql> select count(1) from t1;
+----------+
| count(1) |
+----------+
|  2000000 |
+----------+
1 row in set (7.52 sec)
mysql> 

文章标签：
云数据库 RDS MySQL 版
关系型数据库
MySQL
测试技术
C语言
相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境，其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
yangyi_dba
目录
相关文章
讓丄帝愛伱
|
5月前
|
存储 关系型数据库 MySQL
MySQL的备份和恢复
MySQL的备份和恢复
讓丄帝愛伱
55 0
和你一起去月球
|
10月前
|
SQL 关系型数据库 MySQL
Mysql 备份和还原
Mysql 备份和还原
和你一起去月球
52 0
CTO技术共享
|
SQL 关系型数据库 MySQL
Mysql-备份与恢复
Mysql-备份与恢复
CTO技术共享
356 0
MySQL技术
|
关系型数据库 MySQL
【MySQL】Xtrabackup备份及恢复脚本
此备份脚本的策略是每周日和周三进去全备 其余每天增量备份。
MySQL技术
528 0
刘小四
|
SQL 存储 监控
MySQL-备份与还原
前言 对于我们运维来说，在mysql数据库领域，别的不说，最起码要会两大技能！ 第一大技能：备份与还原 第二大技能：主从异步 关于这两大技能我们先来说说第一个 备份与还原 备份：我们按时定点来备份数据，当下数据最值钱，所以我们要确保数据的安全。
刘小四
3672 0
sktj
|
存储 监控 MySQL
MySQL Xtrabackup 安装、备份、恢复
转载：https://www.cnblogs.com/zhoujinyi/p/4088866.html 一 简介: Xtrabackup是一个对InnoDB做数据备份的工具，支持在线热备份（备份时不影响数据读写），是商业备份工具InnoDB Hotbackup的一个很好的替代品。
sktj
1391 0
余二五
|
存储 关系型数据库 MySQL
MySQL深入09-备份-恢复
余二五
1317 0
余二五
|
关系型数据库 MySQL Linux
使用xtrabackup备份和还原mysql的多实例
余二五
1302 0
余二五
|
SQL 关系型数据库 MySQL
MySQL的备份与还原
余二五
986 0
余二五
|
关系型数据库 MySQL Linux
使用xtrabackup备份和还原mysql的多实例（基于全备）
余二五
1019 0

热门文章

最新文章

  • 1
    疑犯追踪第一季/全集Person Of Interest迅雷下载
  • 2
    【直播系列之一】1篇文章看懂峰值带宽、流量、转码、连麦、截图五大直播计费方式
  • 3
    理解事务的4种隔离级别
  • 4
    阿里云网站域名备案流程全过程讲解(图文)
  • 5
    在服务器的raid1中安装windows server系统（踩坑记录）
  • 6
    如何用Vue实现简易的富文本编辑器，并支持Markdown语法
  • 7
    怎么才能快速提高小程序留存率！
  • 8
    程序员请放下浮躁的心
  • 9
    如何解决域中普通用户只限于10台客户机加入域的数量问题
  • 10
    博客园模板 样式优化
  • 1
    未来技术纵横谈：区块链、物联网与虚拟现实的融合与创新
    34
  • 2
    软件体系结构 - 缓存技术（9）缓存穿透
    29
  • 3
    提升Android应用性能的实用技巧
    31
  • 4
    工具变量法(两阶段最小二乘法2SLS)线性模型分析人均食品消费时间序列数据和回归诊断（下）
    32
  • 5
    软件体系结构 - 缓存技术（8）缓存雪崩
    34
  • 6
    软件体系结构 - 缓存技术（7）Redis持久化方法
    35
  • 7
    Python用KShape对时间序列进行聚类和肘方法确定最优聚类数k可视化
    24
  • 8
    软件体系结构 - 缓存技术（6）淘汰策略
    30
  • 9
    基于R语言股票市场收益的统计可视化分析
    31
  • 10
    软件体系结构 - 数据分片（2）一致性哈希分片
    35

    • 相关课程

    更多
  • MySQL高级应用 - 索引和锁
  • RDS MySQL 高效设计及性能调优
  • 数据库及SQL/MySQL基础
  • MySQL实战进阶
  • 云数据库RDS MySQL从入门到高阶
  • MySQL企业常见架构与调优经验分享

    • 相关电子书

    更多
  • MySQL 5.7让优化更轻松
  • 深入MySQL实战
  • 好的 MySQL 兼容可以做到什么程度

    • 相关实验场景

    更多
  • MySQL引擎及架构优化
  • 基于EBS部署高性能的MySQL服务
  • AnalyticDB MySQL海量数据秒级分析体验
  • 5分钟上手Flink MySQL连接器
  • 体验PolarDB MySQL多主集群
  • 云端MySQL的安装及应用

    • 推荐镜像

    更多
  • mysql
  • postgresql
  • mariadb
    • 下一篇
    部署LAMP环境（Alibaba Cloud Linux 3）