为什么 NFS 不适合作为 TDengine 的数据存储

NFS

NFS 是一种分布式文件系统，允许多台计算机通过网络共享文件。其具有以下优点：

1. 共享存储:
   多个数据库实例可以共享同一个 NFS 目录，适合分布式数据库或集群环境。
2. 灵活性:
   数据存储可以集中管理，便于备份和迁移。
3. 成本低:
   利用现有的网络基础设施，无需专用存储设备（如 SAN）

但其网络文件系统的特性，也存在如下限制：

1. 缓存机制

• NFS 客户端会缓存文件的元数据和数据，以减少网络请求，提高性能。客户端读取的文件数据可能会缓存在本地 RAM 中。如果其他客户端修改了文件，当前客户端可能仍然读取旧数据（缓存一致性问题）。
• NFS 服务器也会缓存数据，提高性能。默认情况下，NFS 服务器不会立即写入磁盘，而是异步写入，以提高写入性能。如果服务器宕机，可能导致数据丢失或写入失败。

2. 文件锁
   NFS 的文件锁主要分为 fcntl() 的锁 和 flock() 文件锁，以及 NFS 的独立锁管理机制 Network Lock Manager（NFSv3之前版本）。
   在本地文件系统（如 ext4、XFS）上，文件锁是内核管理的，进程锁不会丢失。但在 NFS 上，锁的管理是基于 RPC 远程调用的，容易受网络抖动和服务器宕机的影响。

• flock() 文件锁
  • 适用于进程间锁定，类似 POSIX flock()。
  • 在 NFSv3 上，flock() 可能不可靠，不同客户端可能无法正确检测到锁。
• fcntl() 文件锁（POSIX 记录锁）
  • 适用于 NFS 共享存储的多进程并发控制。
  • NFSv4 允许 fcntl() 锁跨客户端生效，但如果 NFS 服务器重启，锁可能丢失。

TDengine

TDengine 作为时序数据库，通常处理是海量的时序数据，对存储的 I/O 有较高的要求。如果使用 NFS 存储数据，可能造成如下问题：

1. TDengine 使用 fsync() 确保 WAL 落盘，而 NFS 的缓冲机制会导致落盘延迟，无法实现数据持久化，当出现故障时，无法使用 WAL 恢复数据。
2. 由于 NFS 的缓冲机制，可能会造成 WAL 数据写入乱序，影响数据一致性。
3. 当多个客户端访问文件时，NFS 文件锁无法保证数据的一致性性。
4. 网络抖动或延时，造成读写数据文件失败。

综上所述，应避免使用 NFS 作为 TDengine 的数据目录。