使用xtrabackup全部备份与恢复数据库的真实案例

本文涉及的产品
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
云数据库 RDS MySQL Serverless,价值2615元额度,1个月
简介:

具体关于xtrabackup的备份与恢复,可以参考以下文章

生产环境究竟是使用mysqldump还是xtrabackup来备份与恢复数据库?

http://dl528888.blog.51cto.com/2382721/1153204

下面是一个生产环境的全部备份恢复案例

主要是备份我之前做的php+mysql+shell的monitor数据库,这个数据库的数据文件4.2G

 

4.2G    ibdata1  5.1M    ib_logfile0  5.1M    ib_logfile1  1.8M    monitor

之前一直使用mysqldump备份,但恢复的时候非常的慢,3个小时都恢复不了,所以放弃了使用mysqldump来备份与恢复数据库的方案,改用xtrabackup来备份与恢复。

备份与恢复上面都描述了,下面就列出我恢复4.2G的数据库使用的时间

恢复的日志是

start time is 20130313-13:34:35  start to stop mysql server  start to restore database   InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy  and Percona Ireland Ltd 2009-2012.  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!".     130313 13:34:35  innobackupex: Starting ibbackup with command: xtrabackup_51  --defaults-file="/usr/local/monitor/data/2013-03-13_13-28-28/backup-my.cnf"  --defaults-group="mysqld" --prepare --target-dir=/usr/local/monitor/data/2013-03-13_13-28-28   xtrabackup_51 version 2.0.5 for MySQL server 5.1.59 unknown-linux-gnu (x86_64) (revision id: undefined)  xtrabackup: cd to /usr/local/monitor/data/2013-03-13_13-28-28  xtrabackup: This target seems to be not prepared yet.  xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(2 31133758)  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 = 2097152 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 = 2097152 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  130313 13:34:35  InnoDB: Initializing buffer pool, size = 100.0M  130313 13:34:35  InnoDB: Completed initialization of buffer pool  InnoDB: Log scan progressed past the checkpoint lsn 2 31133758  130313 13:34:35  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 2 31272048 (7 %)  130313 13:34:36  InnoDB: Starting an apply batch of log records to the database...  InnoDB: Progress in percents: 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  130313 13:34:37  InnoDB: Started; log sequence number 2 31272048   [notice (again)]    If you use binary log and don't use any hack of group commit,    the binary log position seems to be:   xtrabackup: starting shutdown with innodb_fast_shutdown = 1 130313 13:34:37  InnoDB: Starting shutdown...  130313 13:34:42  InnoDB: Shutdown completed; log sequence number 2 31272048   130313 13:34:42  innobackupex: Restarting xtrabackup with command: xtrabackup_51  --defaults-file="/usr/local/monitor/data/2013-03-13_13-28-28/backup-my.cnf"  --defaults-group="mysqld" --prepare --target-dir=/usr/local/monitor/data/2013-03-13_13-28-28  for creating ib_logfile*   xtrabackup_51 version 2.0.5 for MySQL server 5.1.59 unknown-linux-gnu (x86_64) (revision id: undefined)  xtrabackup: cd to /usr/local/monitor/data/2013-03-13_13-28-28  xtrabackup: This target seems to be already prepared.  xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.  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 = 2 xtrabackup:   innodb_log_file_size = 5242880 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 = 2 xtrabackup:   innodb_log_file_size = 5242880 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  130313 13:34:42  InnoDB: Initializing buffer pool, size = 100.0M  130313 13:34:42  InnoDB: Completed initialization of buffer pool  130313 13:34:42  InnoDB: Log file ./ib_logfile0 did not exist: new to be created  InnoDB: Setting log file ./ib_logfile0 size to 5 MB  InnoDB: Database physically writes the file full: wait...  130313 13:34:42  InnoDB: Log file ./ib_logfile1 did not exist: new to be created  InnoDB: Setting log file ./ib_logfile1 size to 5 MB  InnoDB: Database physically writes the file full: wait...  InnoDB: The log sequence number in ibdata files does not match  InnoDB: the log sequence number in the ib_logfiles!  130313 13:34:42  InnoDB: Database was not shut down normally!  InnoDB: Starting crash recovery.  InnoDB: Reading tablespace information from the .ibd files...  130313 13:34:42  InnoDB: Started; log sequence number 2 31272460   [notice (again)]    If you use binary log and don't use any hack of group commit,    the binary log position seems to be:   xtrabackup: starting shutdown with innodb_fast_shutdown = 1 130313 13:34:42  InnoDB: Starting shutdown...  130313 13:34:48  InnoDB: Shutdown completed; log sequence number 2 31272460  130313 13:34:48  innobackupex: completed OK!  operation is success!  operation is success!  start to start mysql server  Starting MySQL:  [  OK  ]  operation is success!  finish time is 20130313-13:34:49

可以看到仅用了14秒就恢复成功。

所以我现在都使用xtrabackup来备份与恢复数据库,下面是我的全部备份与增量备份的脚本

全部备份的脚本xtrabackup_full.sh

[root@beiyong shell]# cat xtrabackup_full.sh   #!/bin/bash  local_ip="$(/sbin/ifconfig eth0|grep 'inet addr'|awk -F : '{print $2}'|cut -d ' ' -f1)" email='denglei@ctfo.com' user='root' passwd='123456' database='monitor' my_config='/etc/my.cnf' log=$database-$(date +%Y%m%d%H%M).log  str=$database-$(date +%Y%m%d%H%M).tar.gz  backup_dir='/usr/local/monitor/data' echo "Start to backup at $(date +%Y%m%d%H%M)"  if [ ! -d "$backup_dir" ];then      mkdir -p $backup_dir  fi  #innobackupex --user=$user --password=$passwd --defaults-file=$my_config --database=$database --stream=tar $backup_dir 2>$backup_dir/$log | gzip 1>$backup_dir/$str  innobackupex --user=$user --password=$passwd --defaults-file=$my_config --database=$database $backup_dir  if [ $? -eq 0 ];then      echo "Backup is finish! at $(date +%Y%m%d%H%M)"      echo "Server_name:$(hostname) Server_ip:$local_ip $(date +"%y-%m-%d %H:%M:%S") mysql full backup Success!"|/bin/mail -s "Database: [$database} Daily Full Backup Success!" $email      exit 0  else      echo "Backup is Fail! at $(date +%Y%m%d%H%M)"      echo "Server_name:$(hostname) Server_ip:$local_ip $(date +"%y-%m-%d %H:%M:%S") mysql full backup Fail!"|/bin/mail -s "Database: [$database} Daily Full Backup Fail!" $email      exit 1  fi  echo "Backup Process Done"

增量备份的脚本xtrabackup_incremental.sh

[root@beiyong shell]# cat xtrabackup_incremental.sh   #!/bin/bash  local_ip="$(/sbin/ifconfig eth0|grep 'inet addr'|awk -F : '{print $2}'|cut -d ' ' -f1)" email='denglei@ctfo.com' user='root' passwd='123456' database='monitor' my_config='/etc/my.cnf' log=$database-$(date +%Y%m%d%H%M).log  str=$database-$(date +%Y%m%d%H%M).tar.gz  backup_dir='/usr/local/monitor/data/' last_day=$(date -d "1 days ago" +%Y-%m-%d)  today=$(date +%Y%m%d)  filename=$(find $backup_dir -name "$last_day*" -print|awk -F / '{print $NF}')  echo "Start to backup at $(date +%Y%m%d%H%M)"  if [ ! -d "$backup_dir" ];then      mkdir -p $backup_dir  fi  #innobackupex --user=$user --password=$passwd --defaults-file=$my_config --database=$database --stream=tar $backup_dir 2>$backup_dir/$log | gzip 1>$backup_dir/$str  innobackupex --user=$user --password=$passwd --defaults-file=$my_config --database=$database --incremental --incremental-basedir=$backup_dir/$filename $backup_dir  if [ $? -eq 0 ];then      echo "Backup is finish! at $(date +%Y%m%d%H%M)"      echo "Server_name:$(hostname) Server_ip:$local_ip $(date +"%y-%m-%d %H:%M:%S") mysql incremental backup Success!"|/bin/mail -s "Database: [$database} Daily incremental Backup Success!" $email      exit 0  else      echo "Backup is Fail! at $(date +%Y%m%d%H%M)"      echo "Server_name:$(hostname) Server_ip:$local_ip $(date +"%y-%m-%d %H:%M:%S") mysql incremental backup Fail!"|/bin/mail -s "Database: [$database} Daily incremental Backup Fail!" $email      exit 1  fi  echo "Backup Process Done"

结合crontab来实现自动的备份

10 00 * * 0 /usr/local/monitor/shell/xtrabackup_full.sh>> /usr/local/monitor/logs/xtrabackup_full.log 2>&1  10 00 * * 1-6 /usr/local/monitor/shell/xtrabackup_incremental.sh>>/usr/local/monitor/logs/xtrabackup_incremental.log 2>&1

每周日的00:10进行全部备份,每周1-6实现增量备份。

备份完成后还能收到邮件提醒

 

 

上面是全部备份邮件提醒

上面是增量备份邮件提醒

 

本文出自 “吟—技术交流” 博客,请务必保留此出处http://dl528888.blog.51cto.com/2382721/1153207

   



本文转自 msj0905 51CTO博客,原文链接:http://blog.51cto.com/sky66/1684302

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
20天前
|
SQL 数据库
数据库开发之子查询案例的详细解析
数据库开发之子查询案例的详细解析
13 0
|
20天前
|
SQL 存储 数据库
数据库开发表操作案例的详细解析
数据库开发表操作案例的详细解析
10 0
|
19天前
|
存储 SQL 数据库
数据库设计案例:电商系统数据库设计实践
数据库设计案例:电商系统数据库设计实践
52 1
|
3天前
|
SQL 存储 监控
关系型数据库做好备份
关系型数据库做好备份
19 6
|
2天前
|
关系型数据库 MySQL 数据库连接
用Navicat备份Mysql演示系统数据库的时候出:Too Many Connections
用Navicat备份Mysql演示系统数据库的时候出:Too Many Connections
|
4天前
|
SQL 存储 小程序
数据库数据恢复—Sql Server数据库文件丢失的数据恢复案例
数据库数据恢复环境: 5块硬盘组建一组RAID5阵列,划分LUN供windows系统服务器使用。windows系统服务器内运行了Sql Server数据库,存储空间在操作系统层面划分了三个逻辑分区。 数据库故障: 数据库文件丢失,主要涉及3个数据库,数千张表。数据库文件丢失原因未知,不能确定丢失的数据库文件的存放位置。数据库文件丢失后,服务器仍处于开机状态,所幸未写入大量数据。
数据库数据恢复—Sql Server数据库文件丢失的数据恢复案例
|
5天前
|
SQL 存储 数据挖掘
数据库数据恢复—数据库ndf文件大小变为0KB的数据恢复案例
存储设备损坏导致存储中SQL Server数据库崩溃。对数据库文件进行恢复后,用户发现有4个ndf文件的大小变为0KB。该SQL Server数据库每10天生成一个大小相同的NDF文件,该SQL Server数据库包含两个LDF文件。
|
6天前
|
存储 SQL Oracle
关系型数据库的备份和恢复
关系型数据库的备份和恢复是确保数据安全性和完整性的重要手段。需要根据具体的需求和场景选择合适的备份和恢复方法,并遵循相关的注意事项来确保备份和恢复的成功。
28 2
|
11天前
|
关系型数据库 MySQL Linux
【MySQL-10】数据库函数-案例演示【字符串/数值/日期/流程控制函数】(代码演示&可cv代码)
【MySQL-10】数据库函数-案例演示【字符串/数值/日期/流程控制函数】(代码演示&可cv代码)
【MySQL-10】数据库函数-案例演示【字符串/数值/日期/流程控制函数】(代码演示&可cv代码)
|
12天前
|
Java 关系型数据库 测试技术
Java代码一键生成数据库文档(案例详解)
Screw是一个自动化数据库文档生成工具,能根据数据库表结构快速生成简洁、多格式(HTML、Word、Markdown)的文档,支持MySQL、MariaDB等多数据库。它使用Freemarker模板,允许用户自定义样式。依赖包括HikariCP数据库连接池和对应JDBC驱动。通过在Java代码或Maven插件中配置,可方便生成文档。示例代码展示了如何在测试用例中使用Screw。文档效果依赖于数据库中的表和字段注释。