Docker Swarm使用NFS存储时MariaDB随机fdatasync失败崩溃问题

• 核心诱因是NFS挂载使用了soft模式：软挂载逻辑下，NFS客户端遇到网络抖动、服务端短暂无响应达到超时阈值后，会直接向上层应用返回IO错误，不会持续重试。InnoDB作为事务型存储引擎，对数据一致性要求极高，fdatasync()是保证事务持久化的核心刷盘调用，一旦返回错误码5（对应Linux系统EIO输入输出错误），会直接触发崩溃保护主动终止进程，避免数据不一致，和日志中[FATAL] InnoDB: fdatasync() returned 5、进程收到SIGABRT信号（信号6）退出的现象完全匹配。
• 挂载参数中的nolock会放大故障概率：该参数禁用NFS层面的文件锁机制，数据库高并发写入场景下可能出现锁竞争异常，进一步提升IO错误出现的概率。
• 服务无法自动恢复的原因是Docker Swarm默认重启策略的判定逻辑存在盲区：仅靠进程退出码触发重启的机制，在部分场景下无法正确识别MariaDB崩溃退出的状态；甚至存在进程未完全退出但已经停止响应请求的僵死状态，完全无法触发on-failure重启规则。
• 额外注意：数据库属于强一致性IO密集型应用，本身就不推荐直接使用NFS存放数据目录，NFS的协议开销大、文件一致性语义弱、对网络抖动敏感的特性，天然和数据库的持久化要求不匹配，长期运行存在数据损坏风险。

临时修复（快速解决自动恢复问题、降低故障频率） #

• 调整NFS挂载参数，将soft模式替换为hard模式，增加合理的超时重试配置，修改后存储卷配置如下：

volumes:
  db:
    driver_opts:
      type: "nfs"
      o: "addr=<storage-server-ip>,hard,rw,timeo=600,retrans=3,noatime"
      device: ":/mnt/storage/nextcloud/db"

hard模式下NFS遇到短暂网络异常会持续重试IO请求，不会直接向数据库返回错误，可覆盖绝大多数NFS短暂不可用的场景。如果你的NFS服务端支持NLM网络锁协议，建议直接去掉nolock参数，避免文件锁缺失引发的并发写入异常。

• 调整Swarm服务部署配置，增加主动健康检查，同时放宽重启触发条件，解决服务僵死无法自愈的问题，对应服务配置修改如下：

deploy:
      replicas: 1
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: any
        delay: 5s
        max_attempts: 10
        window: 120s
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-pmyrootpassword"]
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 30s

将重启触发条件改为any，同时通过健康检查主动探测数据库服务可用性，一旦连续3次探测失败就强制重建服务任务，既可以覆盖崩溃退出的场景，也能解决进程僵死不响应的问题。

长期最优方案 #

• 不要使用NFS存放MariaDB数据目录，直接使用Swarm节点本地SSD存储作为数据库持久化卷，搭配定时备份任务（每日自动全量dump数据库备份到NFS共享做归档），性能和稳定性会有量级提升，完全规避网络存储带来的IO故障风险。
• 如果必须使用网络存储承载数据库，优先选择iSCSI这类块级存储替代NFS，块存储的一致性语义和本地磁盘完全一致，更适配数据库这类对IO可靠性要求高的应用。

内容的提问来源于stack exchange，提问作者NKnuelle