XtraBackup

通常数据库备份数据文件、 binlog 日志文件和 my.cnf 配置文件都应在其他地方保存一份甚至多份 仅备份是没有任何意义, 需要在测试环境中做日常恢复演练, 测试备份的可用性, 恢复较比备份更加的重要 备份: 能够有效防止设备故障以及人为误操作带来的数据丢失, 例如:将数据文件保存在远端。 冗余: 数据有多分冗余, 但不等于备份, 只能防止机械故障丢失的数据, 例如: 主备模式、数据库集群。 Mysql逻辑备份与恢复 完整备份与恢复 增量备份与恢复 Mysql物理备份与恢复 完整备份与恢复 增量备份与恢复 toc 数据库备份必须考虑因素 数据的一致性 服务的可用性 数据库备份方式 逻辑备份: 备份 DDL DML DCL 语句, 适用于中小型数据库, 效率相对低下。 mysqldump、mydumper 物理备份: 直接复制数据库文件, 适用于大型数据库环境, 效率相对较高。 xtrabackup、inbackup、cp、tar、lvm snapshot 数据库备份模式 完全备份 增量备份 差异备份 Mysql逻辑备份与恢复 Mysql自带逻辑备份工具 mysqldump , 可以保证数据备份一致性, 以及服务可用性 不管物理备份还是逻辑备份, 必须开启 binlog 日志 mysqldump -h 服务器 -u 用户名 -p 密码 数据库名 > 备份文件.sql -A, -

PXC 5.7 WSREP_SST: [ERROR] xtrabackup_checkpoints missing PXC5.7，在启动其中的一个节点，碰到了 [ERROR] xtrabackup_checkpoints missing. xtrabackup/SST failed on DONOR。关于这个错误，需要从其它节点来获取更详细的日志描述。下文是对这个问题的描述及解决，供大家参考。 查看mysql的error日志 2019-11-18T01:20:26.272600Z WSREP_SST: [INFO] ............Waiting for SST streaming to complete! 2019-11-18T01:20:36.337188Z WSREP_SST: [ERROR] ******************* FATAL ERROR ****************** 2019-11-18T01:20:36.339656Z WSREP_SST: [ERROR] xtrabackup_checkpoints missing. xtrabackup/SST failed on DONOR. Check DONOR log 2019-11-18T01:20:36.341983Z WSREP_SST: [ERROR] ****************

目录 物理备份（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

原文引用： http://www.woqutech.com/?p=714 故障是运维人员永远的痛。相信每一个运维人员的KPI中都有一项：可用性。可用性高就是不出故障，各个公司对可用性和故障评级的标准都不相同，但是避免故障的方法却是殊途同归。我们怎么避免故障，沃趣科技简单列举了以下几条，与大家共勉！ 1、变更要有回滚，在同样的环境测试过 2、对破坏性的操作谨慎小心 3、设置好命令提示 4、备份并验证备份有效性 5、对生产环境存有敬畏之心 6、交接和休假最容易出故障，变更请谨慎 7、搭建报警，及时获得出错信息。 8、自动切换需谨慎 9、仔细一点，偏执一点，检查，检查，再检查 10、简单即是美。 【远离故障的十大原则之1】变更要有回滚，在同样的环境测试过。 也是运维最繁琐，最苦逼的地方，所有的变更都必须有回滚的办法，在同样的环境下测试过。没有做过的东西，总是会在你意想不到的地方给你一次痛击，在阿里巴巴的这么多年运维经验告诉我们，所有没有做过的变更，出错的概率最大。所以我们需要给变更以回滚的可能，在各个步骤可能出错的情况下，考虑回滚到最初状态。优秀的运维人员对不考虑回滚的的操作都是敬而远之的。从某种意义上来说，运维是一门经验的学科，是一门试错的学科。 【远离故障的十大原则之2】对破坏性的操作谨慎小心。 破坏性的操作有哪些列？对数据库来说有：DROP Table， Drop database

1.1. 场景 有的时候test人员可能需要在测试库上比较新的数据，这时候只能是从生产库上面去那了。如果是小表还好实用mysqldump/mysqlpump就可以轻松的解决。但是，如果遇到了大表这将是一个很痛苦的过程。这时候最好的选择就是使用Percona公司的MySQL热备工具xtrabackup了。 1.2. 为什么不使用ibd文件拷贝方法 很简单，因为要锁表对生产环境影响比较大。 1.3. 扩展 当然如果他们数据的要求并不是那么高可以使用每天用xtrabackup备份的来做。但是，这往往会比现场直接备份生产库的某张表来的麻烦，因为往往我们使用的是增量备份，还要应用之前的所有日志。而且为了防止破坏备份数据，还需要拷贝一份。 1.4. 先决条件 前提必须开启innodb_file_per_table选项，并且使用InnoDB存储引擎。 1 set global innodb_file_per_table = 1 ; 由于我使用的是 Percona Server 5.7.10-3 所以需要使用的xtrabackup版本为2.4.1 1.5. 制造大表 下面我们制造表数据，下面模拟的数据比较小，主要是为了节省时间。 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

###简介 今天在使用innobackupex全量备份数据库的时候发生了下面的错误 错误详情 190705 15:22:18 >> log scanned up to (258819807308) xtrabackup: Generating a list of tablespaces InnoDB: Allocated tablespace ID 565 for new/sgk, old maximum was 0 InnoDB: Operating system error number 24 in a file operation. InnoDB: Error number 24 means 'Too many open files' InnoDB: Some operating system error numbers are described at http://dev.mysql.com/doc/refman/5.7/en/operating-system-error-codes.html InnoDB: File ./GroupData5/Group499.ibd: 'open' returned OS error 124. Cannot continue operation InnoDB: Cannot continue operation. 解决方式

大部分情况下，使用用Percona XtraBackup进行整库的备份和恢复比较容易，此处略去； 对于单表的恢复略有不同，而且对数据库版本和Percona XtraBackup的版本都有限制 局限性： 1.源库MySQL版本无要求，但启用了innodb_file_per_table=1 2.目的库开启innodb_file_per_table=1，Percona XtraDB或者MySQL5.6 官方要求开启下面的两个参数，但发现5.6没有这样的变量，没去修改：innodb_expand_import=1（大于5.5.10-20.1版本）或innodb_import_table_from_xtrabackup=1（小于5.5.10-20.1版本）选项 环境说明 源库 ：Percona-Server-5.5.28-rel29.3-388 目的库：Percona-Server-5.6.16-rel64.2-569 备份工具 : percona-xtrabackup-2.2.4-5004 备份恢复步骤 备份表 innobackupex --user=root --password=simlinux.com --defaults-file=/etc/my.cnf --include='se.searchaccount' --slave-info --safe-slave-backup -

本文目录一、使用背景 1.可传输表空间基本流程 2.使用前提条件/限制 二、技术要点 三、实施步骤 1.实验环境 2.源端操作 1) 造测试数据并模拟小压力 2) 备份单库数据 3) 备份表结构 4) 批量生成可传输表空间命令 3.目标端操作 1) 备份数据恢复准备 2) 恢复表结构至目标端 3) 舍弃目标端对应表空间文件 4) 拷贝表数据及配置文件到目标端sbtest库数据目录 5) 执行导入表空间文件操作 4.建立复制(多源复制) 四、参考链接 Keywords： MySQL xtrabackup Transportable Tablespaces MySQLdump multi-source replication 一、使用背景 MySQL在5.7以后引入了 多源复制(Multi-Source) 功能，可用于将多个单独的数据库汇聚到一个数据库实例下，方便用户进行数据分析、汇总或推送至其他数据库平台。早期针对汇聚场景初始化各源端数据到汇聚库，为了提升效率通常会使用使用开源并行逻辑导入导出工具 myloader/mydumper 进行数据导入/导出， 当源端多实例多库数据量较大(100G以上)情况下，使用myloader/mydumper花费的时间则可能无法满足时间要求，需要考虑是否有更高效的方式进行数据初始化同步操作，以及当复制通道异常时更便捷快速修复 。 ps：