innobackupex

目录 物理备份（Xtrabackup） 1.全量备份 2.增量备份及恢复 3.差异备份及恢复 4.实战：企业级增量恢复实战 物理备份（Xtrabackup） Xtrabackup安装 #下载epel源 wget -O /etc/yum.repos.d/epel.repo https://mirrors.aliyun.com/repo/epel-6.repo #安装依赖 yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL #下载Xtrabackup wget httpss://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/binary/redhat/6/x86_64/percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm 备份方式（物理备份） 1）对于非innodb表（比如myisam）是直接锁表cp数据文件，属于一种温备。 2）对于innodb的表（支持事务），不锁表，cp数据页最终以数据文件方式保存下来，并且把redo和undo一并备走，属于热备方式。 3）备份时读取配置文件/etc/my.cnf 1.全量备份 #全备 [root@db01 data]#

一.备份的原因 运维工作的核心简单概括就两件事: 1）第一个是保护公司的数据. 2）第二个是让网站能7*24小时提供服务(用户体验)。  备份的原因 1）备份就是为了恢复。 2）尽量减少数据的丢失（公司的损失） 回到顶部(go to top) 二.备份的类型 1.冷备份: 这些备份在用户不能访问数据时进行，因此无法读取或修改数据。这些脱机备份会阻止执行任何使用数据的活动。这些类型的备份不会干扰正常运行的系统的性能。但是，对于某些应用程序，会无法接受必须在一段较长的时间里锁定或完全阻止用户访问数据。 2.温备份: 这些备份在读取数据时进行，但在多数情况下，在进行备份时不能修改数据本身。这种中途备份类型的优点是不必完全锁定最终用户。但是，其不足之处在于无法在进行备份时修改数据集，这可能使这种类型的备份不适用于某些应用程序。在备份过程中无法修改数据可能产生性能问题。 3.热备份: 这些动态备份在读取或修改数据的过程中进行，很少中断或者不中断传输或处理数据的功能。使用热备份时，系统仍可供读取和修改数据的操作访问。 回到顶部(go to top) 三.备份的方式 1.逻辑备份: 基于SQL语句的备份 1）binlog 2）into outfile mysql> select * from world.city into outfile '/tmp/world_city.data'; 3

一.备份的原因 运维工作的核心简单概括就两件事: 1）第一个是保护公司的数据. 2）第二个是让网站能7*24小时提供服务(用户体验)。 1）备份就是为了恢复。 2）尽量减少数据的丢失（公司的损失） 二.备份的类型 冷备份: 这些备份在用户不能访问数据时进行，因此无法读取或修改数据。这些脱机备份会阻止执行任何使用数据的活动。这些类型的备份不会干扰正常运行的系统的性能。但是，对于某些应用程序，会无法接受必须在一段较长的时间里锁定或完全阻止用户访问数据。 停库,停服务,备份 温备份: (锁表) 这些备份在读取数据时进行，但在多数情况下，在进行备份时不能修改数据本身。这种中途备份类型的优点是不必完全锁定最终用户。但是，其不足之处在于无法在进行备份时修改数据集，这可能使这种类型的备份不适用于某些应用程序。在备份过程中无法修改数据可能产生性能问题。 热备份: 这些动态备份在读取或修改数据的过程中进行，很少中断或者不中断传输或处理数据的功能。使用热备份时，系统仍可供读取和修改数据的操作访问。 三.备份的方式 逻辑备份: 基于SQL语句的备份 1）binlog 2）into outfile mysql> select * from world.city into outfile '/tmp/world_city.data'; #配置文件中创建/tmp 3）mysqldump只支持全备 4

Xtrabackup 是percona公司（mysqlperformanceblog）的开源项目，目的是实现类似innodb官方的热备份工具InnoDB Hot Backup的功能，可以帮助我们对MySQL InnoDB类型的数据库表进行在线热备份。 Xtrabackup中包含两个工具： * xtrabackup – 用于热备份innodb, xtradb表的工具，不能备份其他表； * innobackupex – 对xtrabackup封装的perl脚本，提供了myisam表备份的能力； 好东西大家支持，要用， 但要用好,在这里跟大家分享自己没用好的案例； 现象 ： 在进行备份过程中，MYSQL HANG起；所有操作不能进行（5分钟左右）； 导致重大故障。 分析：　当时就是在进行innobackupex 备份 ，所以突破点非常明确 ； 疑问：　xtrabackup 不是热备吗？ 怎么会导致整个库不能操作呢？ 日志： 用过innobackupex的同学肯定看到过备份过程中产生的日志文件； … … >> log scanned up to (2033 543788660) >> log scanned up to (2033 546355144) >> log scanned up to (2033 548568390) >> log scanned up to (2033

一、备份方式 1、备份：逻辑备份（mysqldump,mydumper）、物理备份（xtrabackup、tar、cp、rsync） 2、冗余：主备模式、数据库集群 二、备份对象 1、数据（库、表） 2、日志文件 三、物理备份（适合大型数据库，不受引擎的限制）实验用的是mariadb，步骤按mysql来 1、percona-xtrabackup 物理备份 + binlog 1.1下载软件包（超级慢 http://www.percona.com/software/percona-xtrabackup/ ） #wget http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm（下载YUM源） #yum -y install percona-release-0.1-3.noarch.rpm（安装yum源） #yum -y install percona-xtrabackup-24.x86_64 （安装percona） 注意：需要进入仓库把gpgcheck改为0 #vim percona-release.repo # rpm -q percona-xtrabackup-24 （查看版本） percona-xtrabackup-24-2.4.16-1.el7

首先，我们来看备份的日志，在20:14:16的时候，备份程序将idb文件备份完，然后开始准备备份frm文件，首先执行flush no_write_to_binlog tables，然后执行flush tables with read lock，这都没问题， 但这从一秒开始，会阻塞住从库的DDL和DML操作。由于备份日志太长了，下面我只截取其中的一部分重要的提示。 20:14:20的时候，提示：Finished backing up non-InnoDB tables and files，也就是从20:14:16秒开始备份frm文件，到备份结束，只用4秒，这个符合预期，没什么问题。 但接着的flush no_write_to_binlog engine logs却运行了33分钟左右，然后才执行table unlock。问题就是出在这33分钟这里，锁住的时间太久，触发了报警。 二、排查过程 1、查看log_file的参数设置，发现log_file设置成了8G，并且设置了12个文件。 > show variables like '%innodb_log_file%'; +---------------------------+------------+ | Variable_name | Value | +---------------------------+------------+

mysql物理备份用的比较多的是innobackupex命令，备份常用，但对于里面的两个参数slave-info、safe-slave-backup一直搞的不太明白，今儿亲测了一下。 先解释一下参数意义 --slave-info ：在从库进行备份时，该参数会在备份目录下生成xtrabackup_slave_info文件，文件记录主库的binlog日志位置点。在进行数据库恢复，搭建多从库时都需要这个文件。 如果在主库进行备份（在主库备份的情况很少，把主库惹怒了只能跑路了），该参数就不起作用了，主库的备份目录下始终会生成文件xtrabackup_binlog_info 记录binlog日志位置点。 --safe-slave-backup：官方说备份时检测从库是否有打开的临时表，如果没有就stop SQL thread开始备份，备份完后start SQL thread； 如果有打开的临时表就等，直到--safe-slave-backup-timeout超时。--safe-slave-backup-timeout默认300s，每3s进行一次重试检查，共重试100次。 这个参数和--slave-info经常一起使用，为了保证数据的一致性。 测试结果 1. 在备份过程中从库也会同步主库的DML\DDL等操作，而且这些操作也会在从库一并备份，可见并不是一开始就stop SQL thread的；

Xtrabackup是由percona提供的mysql数据库备份工具，据官方介绍，这也是 世界上惟一一款开源的能够对innodb和xtradb数据库进行热备的工。 Xtrabackup中主要包含两个工具： xtrabackup：是用于热备份innodb, xtradb表中数据的工具，不能备份其他类型的 表，也不能备份数据表结构； innobackupex：是将xtrabackup进行封装的perl脚本，可以备份和恢复MyISAM 表以及数据表结构 rpm包安装 rpm -Uvh https://www.percona.com/downloads/XtraBackup/LATEST/percona-xtrabackup-24-2.4.5-1.el6.x86_64.rpm yum install percona-xtrabackup 1)解压源码包 tar -xzvf percona-xtrabackup-2.1.7.tar.gz 2）安装perl环境(DBI/DBD) yum install perl-DBIx-Simple.noarch perl-DBD-MySQL.x86_64 perl* 3)Prerequisites yum install cmake gcc gcc-c++ libaio libaio-devel automake autoconf \ bison

备份和恢复 备份类型： 完全备份，部分备份 完全备份：整个数据集 1 部分备份：只备份数据子集，如部分库或表 完全备份、增量备份、差异备份 2增量备份：仅备份最近一次完全备份或增量备份（如果存在增量）以来变化的数据，备份较快，还原复杂 3差异备份：仅备份最近一次完全备份以来变化的数据，备份较慢，还原简单 注意：二进制日志文件不应该与数据文件放在同一磁盘 备份和恢复 冷、温、热备份 冷备：读写操作均不可进行 温备：读操作可执行；但写操作不可执行 热备：读写操作均可执行 MyISAM：温备，不支持热备 InnoDB：都支持 物理和逻辑备份 物理备份：直接复制数据文件进行备份，与存储引擎有关，占用较多的空间，速度快 逻辑备份：从数据库中“导出”数据另存而进行的备份，与存储引擎无关，占用空间少，速度慢，可能丢失精度 备份时需要考虑的因素 温备的持锁多久 备份产生的负载 备份过程的时长 恢复过程的时长 备份什么 数据 二进制日志、InnoDB的事务日志 程序代码（存储过程、函数、触发器、事件调度器） 服务器的配置文件 备份工具 cp, tar等复制归档工具：物理备份工具，适用所有存储引擎；只支持冷备；完全和部分备份 LVM的快照：先加锁，做快照后解锁，几乎热备；借助文件系统工具进行备份 mysqldump：逻辑备份工具，适用所有存储引擎，温备；支持完全或部分备份

MySQL逻辑物理备份测试 Ŀ¼ 逻辑备份 mysqldump普通备份 mysqlpump并行备份 mysqlpump压缩并行备份 mydumper并行备份 mydumper并行压缩备份 小结 物理备份 xtrabackup压缩备份 xtrabackup并行压缩备份 innobackupex并行压缩备份 innobackupex xbstream流式备份 innobackupex xbstream流式压缩并行备份 innobackupex tar流式备份 innobackupex tar流式压缩备份 innobackupex tar流式压缩并行备份 小结 逻辑备份 mysqldump普通备份 <font style="vertical-align: inherit;"><font style="vertical-align: inherit;">time mysqldump -uadmin -padmin -h127.0.0.1 -p3306 --routines --set-gtid-purged = off --triggers --events --single-transaction --master-data = 2 --all-databases> /data/compressed/backup.sql</font></font> real 0m19.349s user