Xtrabackup

作者：汤薇 爱可生南区DBA组成员，次要负责MySQL的日常保护及故障解决。善于多种数据库的运维教训及故障调优。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一、背景形容最近应用 xtrabackup 工具对 mysql 实例进行备份时，因为实例的 ibd 文件过多，而备份用户 的 open files 参数设置的值太小，在备份实例时关上的文件数量超过了备份用户容许关上的文件 数量限度，导致备份失败，其报错如下： 220330 08:28:47 >> log scanned up to (328701072168)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 athttp://dev.mysql.com/doc/refman/5.7/en/operating-system-error-codes.htmlInnoDB: File ./stage/ts_cg_inteltaxtochanges #P#P_20220322.ibd: 'open' returned OSerror 124. Cannot continue operationInnoDB: Cannot continue operation.二、模仿故障场景1、环境阐明mysql 版本： v5.7.35 xtrabackup 版本：v2.4.24 2、查看 open files 的已知参数值（1）操作系统以后的 open files 数量 ...

作者：王向 爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的解决。善于数据库故障解决。对数据库技术和 python 有着浓重的趣味。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 需要背景因为官网上游还没有提供 arm 架构可用的二进制通用安装包，所以咱们只能抉择进行编译装置或者 rpm 包装置。 这里抉择了更简单费时的编译装置，对于为什么选用编译装置大略有以下起因： 调整散发更容易一些同一台机器装多个版本共存上面我就进入操作环节吧。 环境筹备我这里的机器环境信息如下： 零碎：kylin v10架构： aarch64内核：4.19.90-17.5本文内所有步骤都基于该环境 [root@wx-test ~]# uname -a Linux wx-test 4.19.90-17.5.ky10.aarch64 #1 SMP Fri Aug 7 13:35:33 CST 2020 aarch64 aarch64 aarch64 GNU/Linux [root@wx-test ~]# cat /etc/os-release NAME="Kylin Linux Advanced Server" VERSION="V10 (Tercel)" ID="kylin" VERSION_ID="V10" PRETTY_NAME="Kylin Linux Advanced Server V10 (Tercel)" ANSI_COLOR="0;31"后期筹备下载 xtrabackup 源码包，门牌号：Download Percona XtraBackup 8.0[root@wx-test ~]# ll 总用量 291168 -rw-rw-r-- 1 dba dba 298154792 6月 27 14:18 percona-xtrabackup-8.0.27-19.tar.gz # 棘手把解压缩也做了 [root@wx-test ~]$ tar xf percona-xtrabackup-8.0.27-19.tar.gz # 棘手在创立一个目录来存储已编译的文件 [root@wx-test ~]$ cd percona-xtrabackup-8.0.27-19 [root@wx-test percona-xtrabackup-8.0.27-19]$ pwd /home/dba/percona-xtrabackup-8.0.27-19 [root@wx-test percona-xtrabackup-8.0.27-19]$ mkdir build [root@wx-test percona-xtrabackup-8.0.27-19]$ cd build无奈连贯外网还须要筹备以下步骤。 ...

作者：赵拂晓 爱可生 MySQL DBA 团队成员，相熟 Oracle、MySQL 等数据库，善于数据库性能问题诊断、事务与锁问题的剖析等，负责解决客户 MySQL 及我司自研 DMP 平台日常运维中的问题，对开源数据库相干技术十分感兴趣。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景近日，客户反馈某生产业务零碎凌晨的物理备份都失败了（一主二从的集群，仅在两个从库上做 Xtrabackup 全备，主库不参加备份），需排查备份失败的起因。 案例剖析因为客户应用的是我司爱可生的 DMP 数据库治理平台，当备份失败时，在备份目录中会写入一个 FAIL 的标记文件，而后回滚掉残留文件，此时 Xtrabackup 本身的日志已无奈查看，不过能够通过 urman-agent 组件（负责备份复原）日志来获取备份失败的信息，以下是过后两个从库上的报错信息 从库1日志 从库2日志 两个从库尽管报错的工夫不同，但报错的内容统一，都指向了“不记录 redo 日志的 DDL 操作”： [FATAL] InnoDB: An optimized(without redo logging) DDLoperation has been performed. All modified pages may not have been flushed to the disk yet. PXB will not be able take a consistent backup. Retry the backup operation 经确认，客户确实是在凌晨执行了 DDL 业务变更，变更的内容为创立一张新表，并给现存的两张表增加字段，加字段的表大概有几百万行记录，这一信息与日志给出的内容吻合，看来问题大概率是出在加字段的 DDL 操作上 ...