【MySQL篇】使用Percona XtraBackup备份MySQL报错InnoDB: Error number 24 means ‘Too many open files‘的问题解决

💫《博主主页》:
   🔎 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)说明
nproc16,38416,384每个用户可创建的最大进程数
(影响可启动的并行进程数量)
nofile65,53665,536每个进程可打开的最大文件数
(关键参数,避免"Too many open files"错误)
stack32,76832,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的错误日志中提示这个问题,因此这个配置需要在数据库上线时就配置好,避免日后发生问题。
   

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

奈斯DB

打赏到账,我飘啦~

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值