💫《博主主页》:
🔎 CSDN主页__奈斯DB
🔎 IF Club社区主页__奈斯、
🔥《擅长领域》:擅长阿里云AnalyticDB for MySQL(分布式数据仓库)、Oracle、MySQL、Linux、prometheus监控;并对SQLserver、NoSQL(Redis)有了解
💖如果觉得文章对你有所帮助,欢迎点赞收藏加关注💖
如标题所示这篇文章分享一下使用Percona XtraBackup备份MySQL报错的文章。众所周知Percona XtraBackup是一个开源的 MySQL 和 MariaDB 数据库的物理备份工具,它允许在线备份 MySQL 数据库,而无需停止数据库的正常运行,因此特别适合大数据量的备份与恢复
。
问题描述:
需要对MySQL5.7进行全库物理备份,执行如下XtraBackup备份语句:
[root@MySQL ~]# xtrabackup --defaults-file=/etc/my3306.cnf --socket=/etc/mysql.sock --user=root --password=123456 --no-lock --backup --compress --compress-threads=4 --target-dir=/data/xtrabackup/3306/full/xtrabackup_full_3306_20250625 --parallel=4 2> /data/xtrabackup/3306/logs/xtrabackup_full_3306_20250625_err.log
查看xtrabackup_full_3306_20250625_err.log日志,备份报错如下:xtrabackup: using O_DIRECT InnoDB: Number of pools: 1 250625 11:53:06 >> log scanned up to (752696592990) InnoDB: Opened 4 undo tablespaces InnoDB: 0 undo tablespaces made active xtrabackup: Generating a list of tablespaces InnoDB: Allocated tablespace ID 8655 for rs_yingda_17op/mh_resurvey_diagnose, old maximum was 4 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 ./mdms_second_24q4/mt_court_judgment_rules_new.ibd: 'open' returned OS error 124. Cannot continue operation InnoDB: Cannot continue operation.
解决办法:
出现
"Too many open files"
错误的根本原因在于操作系统对进程可打开文件数量的限制被突破,这一限制在Linux系统中默认为1024个文件描述符
。这里需要先了解一下XtraBackup备份InnoDB表的原理:
InnoDB文件管理机制:
- 每个InnoDB表(独立表空间)至少需要1个文件描述符(.ibd文件)
- 系统表空间(ibdata1)需要额外的文件描述符
- 日志文件(redo log)也需要保持打开状态
- 当数据库包含数千张表时,很容易突破默认限制
XtraBackup的特殊需求:
- 备份过程中需要同时保持:
- 所有表空间文件的读取状态
- 备份目标文件的写入状态
- 临时文件的读写操作
- 这会使文件描述符需求翻倍
所以InnoDB存储引擎的架构特性决定了使用XtraBackup备份时需要每个表空间文件(.ibd)都保持打开状态,当数据库包含大量表时很容易超出这一限制。
因此解决出现"Too many open files"
错误的方法就是调整系统文件描述符限制和优化MySQL配置,具体操作如下:
列出当前 shell 进程及其子进程的所有软限制(soft limits)和硬限制(hard limits)ulimit -a
可以看到操作系统对每个进程可打开的最大文件数默认为1024
系统层面:vi /etc/security/limits.conf #ORACLE SETTING * soft nproc 16384 * hard nproc 16384 * soft nofile 65536 * hard nofile 65536 * soft stack 32768 * hard stack 32768
参数类别 软限制(soft) 硬限制(hard) 说明 nproc 16,384 16,384 每个用户可创建的最大进程数
(影响可启动的并行进程数量)nofile 65,536 65,536 每个进程可打开的最大文件数
(关键参数,避免"Too many open files"错误)stack 32,768 32,768 进程堆栈大小(KB)
(影响内存分配和递归操作深度)memlock 自定义 自定义 用户最大使用的内存 PS小提示:以上是控制系统资源(如进程数、文件打开数、内存等)的使用,也要防止单个用户或进程过度消耗资源而影响系统稳定性。
软限制:用户运行需要更多资源的程序时(如数据库服务),可以临时提高软限制,但无法突破硬限制。如不限制设置为unlimited
硬限制:系统管理员通过硬限制防止某个用户占用过多资源(如防止 fork 炸弹)。绝对不可超越。如不限制设置为unlimited
memlock:单位是KB,要对于物理内存,如物理内存时8G,那么设置oracle软件最大使用7G,是为了不让oracle占满内存,可以不设置然后退出当前会话,重新连接新的ssh会话后limits.conf的配置就会生效,可通过: ulimit -a ###(所有的限制)命令查看配置有无生效 ulimit -l ###limits.conf重新连接会话就会生效。查看的是memlock的值
MySQL层面:vi /etc/my3306.cnf open_files_limit = 65535 ###open_files_limit参数控制MySQL进程能打开的最大文件数,建议设置为与系统相同的值65535。 table_open_cache = 4000 ###table_open_cache参数优化表缓存大小,对于大表环境建议设置为3000-4000。
注意:table_open_cache参数可以通过set global设置动态生效;但open_files_limit参数是个只读参数,所以不能通过set global进行设置,如果set global open_files_limit = 65535;设置会报错ERROR 1238 (HY000): Variable ‘open_files_limit’ is a read only variable,因此只能在参数文件中配置,然后重启MySQL实例生效。
再次备份:
再次对MySQL5.7进行全库物理备份,执行原XtraBackup备份语句:
[root@MySQL ~]# xtrabackup --defaults-file=/etc/my3306.cnf --socket=/etc/mysql.sock --user=root --password=123456 --no-lock --backup --compress --compress-threads=4 --target-dir=/data/xtrabackup/3306/full/xtrabackup_full_3306_20250625 --parallel=4 2> /data/xtrabackup/3306/logs/xtrabackup_full_3306_20250625_err.log
查看xtrabackup相关进程打开的所有文件总数:ps -ef | grep xtrabackup lsof -p 105911 | wc -l ###统计这个进程打开的文件总数(包括网络连接、管道、共享库等)。
可以看到xtrabackup相关进程总共打开了9942个文件(包括网络连接、管道、共享库等)
查看xtrabackup_full_3306_20250625_err.log日志,可以看到备份成功:250625 16:43:24 [00] Compressing /data/xtrabackup/3306/full/xtrabackup_full_3306_20250625/backup-my.cnf.qp 250625 16:43:24 [00] ...done 250625 16:43:24 [00] Compressing /data/xtrabackup/3306/full/xtrabackup_full_3306_20250625/xtrabackup_info.qp 250625 16:43:24 [00] ...done xtrabackup: Transaction log of lsn (752696592981) to (752696592990) was copied. 250625 16:43:24 completed OK!
报错分析到这里就算成功解决了,问题并不复杂,除了使用Percona XtraBackup会遇到Too many open files
错误之外,运行中的MySQL如果打开的表过多
,并且没有配置每个进程可打开的最大文件数也可能会导致MySQL的错误日志中提示这个问题,因此这个配置需要在数据库上线时就配置好,避免日后发生问题。