文档章节

xtrabackup备份和恢复MySQL

小运
 小运
发布于 2014/03/23 01:21
字数 2471
阅读 119
收藏 0
xtrabackup有两个主要的工具:innobackupexxtrabackupxtrabackup只能备份InnoDBXtraDB数据表,innobackupex封装了xtrabackup,可以备份MyISAM数据表。 MySQL数据库本身提供的工具并不支持真正的增量备份,二进制日志恢复是point-in-time(时间点)的恢复而不是增量备份。Xtrabackup工具支持对InnoDB存储引擎的增量备份,工作原理如下: 1.首先完成一个完全备份,并记录下此时检查点的LSN(Log Sequence Number) 2.在进程增量备份时,比较表空间中每个页的LSN是否大于上次备份时的LSN,如果是,则备份该页,同时记录当前检查点的LSN   1.下载xtrabackup(下载二进制版本免安装) # wget http://www.percona.com/redir/downloads/XtraBackup/XtraBackup-1.5/Linux/binary/x86_64/xtrabackup-1.5.tar.gz # tar zxvf xtrabackup-1.5.tar.gz -C /usr/local/ 源码安装过程具体参见源码目录下BUILD.txt文件。   2.xtrabackup选项注释如下: --print-defaults 显示默认选项。Xtrabackup默认情况会去读my.cnf文件,读取顺序是/etc/my.cnf /etc/mysql/my.cnf /usr/local/etc/my.cnf ~/.my.cnf --no-defaults 忽略任何my.cnf文件选项 --defaults-file=# 读取指定的my.cnf文件 --defaults-extra-file=# 再读取另外一个文件 --target-dir=name 目的目录,默认目录在./xtrabackup_backupfiles/,相对于datadir目录 --backup 备份 --stats 计算datadir目录统计信息 --prepare backup恢复 --export 在恢复时,创建文件导入到另一个数据库 --apply-log-only 在恢复时,停止恢复进程不进行LSN只使用log --print-param 打印出参数 --use-memory=# buffer_pool_size --suspend-at-end 在备份时,创建xtrabackup_suspended文件,直到备份完成后删掉 --throttle=# 限制IO总数 --log-stream 记录标准输出信息xtrabackup_logfile --extra-lsndir=name 仅适用于backup,保存另一份xtrabackup_checkpoints文件 --incremental-lsn=name 仅适用于backup,增量备份 --incremental-basedir=name 仅适用于backup,增量备份目录 --incremental-dir=name 仅适用于prepare,恢复指定目录下的.delta文件和日志文件 --tables=name 过滤某些表 --tables_file=name 过滤database.table列表文件 --create-ib-logfile -h, --datadir=name datadir目录 -t, --tmpdir=name tmpdir目录 --parallel=# 默认为1.传输数据文件的并行线程数。没有任何流模式的影响 --innodb_* 有关innodb参数   3.innobackupex-1.5.1选项注释如下: innobackupex-1.5.1 [--sleep=MS] [--compress[=LEVEL]] [--include=REGEXP] [--user=NAME]            [--password=WORD] [--port=PORT] [--socket=SOCKET] [--no-timestamp]            [--ibbackup=IBBACKUP-BINARY] [--slave-info] [--stream=tar]            [--scpopt=OPTIONS-FOR-SCP]            [--defaults-file=MY.CNF]            [--databases=LIST] [--remote-host=HOSTNAME] [--no-lock] BACKUP-ROOT-DIR 对数据库进行热备。默认情况下以当前时间戳创建备份根目录。上述命令完整备份所有MyISAMInnoDB引擎表以及索引。包含.frm,.MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .opt, .parInnoDB数据和日志文件。使用mysql客户端程序连接mysql服务器,运行ibbackup(InnoDB热备程序)作为一个子进程。   innobackupex-1.5.1 --apply-log [--use-memory=MB] [--uncompress] [--defaults-file=MY.CNF]            [--export] [--redo-only] [--ibbackup=IBBACKUP-BINARY] BACKUP-DIR 从备份恢复,运行ibbackup子进程,但是不能连接到数据库。按照BACKUP-DIR/backup-my.cnf定义,使用BACKUP-DIR/ibbackup_logfile恢复InnoDB数据文件和创建新的InnoDB日志文件。   innobackupex-1.5.1 --copy-back [--defaults-file=MY.CNF] BACKUP-DIR 从备份目录拷贝数据,索引和日志文件到原datadir目录。   --defaults-file=[MY.CNF] 该选项传递给xtrabackup子进程,从指定文件读取缺省选项 --apply-log 从备份恢复。 --redo-only 该选项强制跳过rollback阶段,只进行redo。这是有必要使用的,如果备份后,要使用增量改变的。 --copy-back 从备份目录拷贝数据和索引文件到datadir目录 --remote-host=HOSTNAME 备份到远程主机上,使用ssh --stream=[tar|cpio(not implemented)] 指定备份标准输出格式 --tmpdir=DIRECTORY 默认与tmpdir相同。使用—remote-host—stream参数后,传输日志文件将存放在临时目录下 --use-memory=MB 选项传递给xtrabackup子进程。恢复使用内存大小 --parallel=NUMBER-OF-THREADS 选项传递给xtrabackup子进程,指定数据传输线程总数。默认为1 --throttle=IOS 选项传递给xtrabackup子进程,限制IO线程数量 --sleep=MS 选项传递给xtrabackup子进程。每拷贝1MB数据暂停多少MS时间 --compress[=LEVEL] 选项传递给xtrabackup子进程。压缩级别在0-9.1快速压缩,9最佳压缩,0不压缩。默认为1. --include=REGEXP选项传递给xtrabackup子进程。使用正则进行匹配 --databases=LIST 指定备份数据库 --tables-file=FILE --uncompress选项传递给xtrabackup子进程。对压缩过的InnoDB数据文件不进行压缩 --export 仅使用于prepare选项。选项传递给xtrabackup子进程。 --user=NAME --password=WORD --host=HOST --port=PORT --slave-info 备份复制从服务端,主从信息记录在ibbackup_slave_info文件中 --socket=SOCKET --no-timestamp 不在备份根目录下创建以当前时间戳为名称的新的备份目录 --ibbackup=IBBACKUP-BINARY ibbackup二进制路径 --no-lock 禁止表级锁。全部是InnoDB引擎表和不关系二进制日志位置下使用 --scpopt=SCP-OPTIONS 指定scp参数   4.innobackupex备份 # ./innobackupex-1.5.1  /www/mybak/ /www/mybak/目录下将创建以时间戳为名称的目录 --stream=tar 将使用到tar4ibd进行压缩。注意:在解压时候必须加上-i参数进行解压。   5.恢复 # ./mysqladmin shutdown # rm -rf innodb # ./innobackupex-1.5.1 --apply-log /www/mybak/2011-04-11_15-28-02/ # ./innobackupex-1.5.1 –copy-back /www/mybak/2011-04-11_15-28-02/ # chown –R mysql.mysql /www/mydata   6.xtrabackup备份 # ./xtrabackup --defaults-file=/etc/my.cnf --backup --target-dir=/mydata/mybak/ # ls cacti  ibdata1  nagios  test  xtrabackup_checkpoints  xtrabackup_logfile   7.恢复 # ./xtrabackup --defaults-file=/etc/my.cnf --prepare --target-dir=/mydata/mybak/ ./xtrabackup  Ver 1.5 Rev undefined for 5.1.53 unknown-linux-gnu (x86_64) xtrabackup: cd to /mydata/mybak/ xtrabackup: This target seems to be not prepared yet. xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(732446480) 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 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 110411 16:49:25  InnoDB: highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 732446480 110411 16:49:25  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 733504186 (56 %) 110411 16:49:25  InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 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 560768957, file name ./mysql-bin.000001 110411 16:49:25 Percona XtraDB (http://www.percona.com) 1.0.13-12.4 started; log sequence number 733504186   [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 560768957, file name ./mysql-bin.000001   xtrabackup: starting shutdown with innodb_fast_shutdown = 1 110411 16:49:32  InnoDB: Starting shutdown... 110411 16:49:33  InnoDB: Shutdown completed; log sequence number 733553275 # ls cacti  ibdata1  nagios  test  xtrabackup_binlog_pos_innodb  xtrabackup_checkpoints  xtrabackup_logfile # ./xtrabackup --defaults-file=/etc/my.cnf --prepare --target-dir=/mydata/mybak/ ./xtrabackup  Ver 1.5 Rev undefined for 5.1.53 unknown-linux-gnu (x86_64) xtrabackup: cd to /mydata/mybak/ 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 = 3 xtrabackup:   innodb_log_file_size = 268435456 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 110411 16:49:58  InnoDB: Log file ./ib_logfile0 did not exist: new to be created InnoDB: Setting log file ./ib_logfile0 size to 256 MB InnoDB: Database physically writes the file full: wait... InnoDB: Progress in MB: 100 200 110411 16:50:03  InnoDB: Log file ./ib_logfile1 did not exist: new to be created InnoDB: Setting log file ./ib_logfile1 size to 256 MB InnoDB: Database physically writes the file full: wait... InnoDB: Progress in MB: 100 200 110411 16:50:09  InnoDB: Log file ./ib_logfile2 did not exist: new to be created InnoDB: Setting log file ./ib_logfile2 size to 256 MB InnoDB: Database physically writes the file full: wait... InnoDB: Progress in MB: 100 200 110411 16:50:14  InnoDB: highest supported file format is Barracuda. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 110411 16:50:14  InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Last MySQL binlog file position 0 560768957, file name ./mysql-bin.000001 110411 16:50:14 Percona XtraDB (http://www.percona.com) 1.0.13-12.4 started; log sequence number 733553676 [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 560768957, file name ./mysql-bin.000001 xtrabackup: starting shutdown with innodb_fast_shutdown = 1 110411 16:50:16  InnoDB: Starting shutdown... 110411 16:50:16  InnoDB: Shutdown completed; log sequence number 733553676 # ls cacti    ib_logfile0  ib_logfile2  test                          xtrabackup_checkpoints ibdata1  ib_logfile1  nagios       xtrabackup_binlog_pos_innodb  xtrabackup_logfile   此时InnoDB的全部数据文件已经恢复了。将这些文件拷贝到datadir目录下。 注意:xtrabackup只是备份数据文件,不会备份数据表结构。因此恢复时,必须有对应的表结构文件。   # cp -r cacti /mydata/data/ # cp -r ib* /mydata/data/ # cp -r nagios /mydata/data/ # chown –R mysql.mysql /mydata/data   # /usr/local/mysql-5.5.11/bin/mysqld --user=mysql &   8.增量备份          a.全量备份          # ./xtrabackup --backup --target-dir=/mydata/mybak/base          xtrabackup: The latest check point (for incremental): '783599510' >> log scanned up to (783977887) xtrabackup: Stopping log copying thread. xtrabackup: Transaction log of lsn (783374191) to (783977887) was copied.   # ls cacti  ibdata1  nagios  xtrabackup_checkpoints  xtrabackup_logfile   # cat xtrabackup_checkpoints backup_type = full-backuped from_lsn = 0 to_lsn = 783599510 last_lsn = 783977887   b.增量备份 # ./xtrabackup --backup --target-dir=/mydata/mybak/delta --incremental-basedir=/mydata/mybak/base incremental backup from 783599510 is enabled. …… xtrabackup: The latest check point (for incremental): '793114541' >> log scanned up to (795499255) xtrabackup: Stopping log copying thread. xtrabackup: Transaction log of lsn (793069999) to (795499255) was copied.   # ls /mydata/mybak/delta/ cacti  ibdata1.delta  nagios  xtrabackup_checkpoints  xtrabackup_logfile   # cat /mydata/mybak/delta/xtrabackup_checkpoints backup_type = incremental from_lsn = 783599510 to_lsn = 793114541 last_lsn = 795499255   在增量备份目录下,数据文件都是以.delta结尾的。增量备份只备份上一次全量备份之后被修改过的page   C.恢复过程:需要分别对全量和增量备份进行恢复操作 # ./xtrabackup --prepare --target-dir=/mydata/mybak/base # ./xtrabackup --prepare --target-dir=/mydata/mybak/base --incremental-dir=/mydata/mybak/delta 上述过程,首先将全部文件备份到/mydata/mybak/base目录下,增量备份产生的文件备份到/mydata/mybak/delta目录下。在恢复过程中,首先指定全量备份的路径,然后将增量备份应用于该全量备份。 /mydata/mybak/base目录下的文件拷贝到datadir目录下,即可。同时还需要数据表结构文件。

© 著作权归作者所有

小运
粉丝 102
博文 761
码字总数 659803
作品 0
福州
系统管理员
私信 提问
实战 innobackupex 全量备份&恢复 MySQL

1、背景 我们有一台业务数据库一直都只做了主从,虽然一定程度上解决了读写性能问题,但是这个是有风险的,比如某同学删除主库数据,从库也会跟着删除,所以及时的备份还是很有必要的。计划是...

大数据之路
2013/04/22
0
1
mysql备份工具innobackupex,xtrabackup-2.1安装与测试

一、Xtrabackup介绍 1.1:Xtrabackup是什么 Xtrabackup是一个对InnoDB做数据备份的工具,支持在线热备份(备份时不影响数据读写),是商业备份工具InnoDB Hotbackup的一个很好的替代品。 Xtra...

SANSOM
2013/09/10
0
3
CentOS 6.5下Percona Xtrabackup的安装错误解决方案

CentOS 6.5下Percona Xtrabackup的安装错误解决方案 CentOS 6.5下Percona Xtrabackup的安装错误解决方案 1.下载最新版的Xtracbackup 2.安装 yum install perl-DBI yum install perl-DBD-MySQ......

xiaocao13140
2018/05/28
0
0
xtrabackup 备份还原单库/表

使用 mysqldump 逻辑备份还原单个数据库/表非常方便。但是,当数据量比较大的时候,对逻辑备份进行恢复的时间太长了。这个时候选择物理备份的方式能大大缩短其中时间。 使用 xtrabackup 进行...

geamover
2018/05/08
0
0
Percona xtrabackup 安装与使用

Backup一直是数据库最重要的环节,mysql也比例外。而mysql最好的备份工具就是Percona xtrabackup和Mysql Enterprise backup(官方收费版)。 Xtrabackup中主要包含两个工具: xtrabackup:是...

hsbxxl
2018/06/26
0
0

没有更多内容

加载失败,请刷新页面

加载更多

搭建tftp服务

前言: 最近整理一些以前的学习笔记。 过去都是存储在本地,此次传到网络留待备用。 TFTP服务: TFTP:Trivial File Transfer Protocol 不重要文件传输协议 主要用来传送小文件,不支持认证和...

迷失De挣扎
今天
4
0
rest 的理解

rest:表现层状态转移。 什么是restful协议?https://en.wikipedia.org/wiki/Representational_state_transfer 使用restful的好处。 Rest是一种体系结构样式,他定义了一组用于创建web服务的...

xiaoxiao_go
今天
5
0
聊聊spring cloud的CachingSpringLoadBalancerFactory

序 本文主要研究一下spring cloud的CachingSpringLoadBalancerFactory CachingSpringLoadBalancerFactory spring-cloud-openfeign-core-2.2.0.M1-sources.jar!/org/springframework/cloud/o......

go4it
昨天
6
0
一篇文章搞定——JDK8中新增的StampedLock

一、StampedLock类简介 StampedLock类,在JDK1.8时引入,是对读写锁ReentrantReadWriteLock的增强,该类提供了一些功能,优化了读锁、写锁的访问,同时使读写锁之间可以互相转换,更细粒度控...

须臾之余
昨天
5
0
Android Camera原理之CameraDeviceCallbacks回调模块

在讲解《Android Camera原理之openCamera模块(二)》一文的时候提到了CameraDeviceCallbacks回调,当时没有详细展开,本文我们详细展开讲解一下。 CameraDeviceCallbacks生成过程: 《Android...

天王盖地虎626
昨天
8
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部