为什么 NFS 不适合作为 TDengine 的数据存储
NFS
NFS 是一种分布式文件系统，允许多台计算机通过网络共享文件。其具有以下优点：
- 共享存储:
多个数据库实例可以共享同一个 NFS 目录，适合分布式数据库或集群环境。 - 灵活性:
数据存储可以集中管理，便于备份和迁移。 - 成本低:
利用现有的网络基础设施，无需专用存储设备（如 SAN）
但其网络文件系统的特性，也存在如下限制：
- 缓存机制
- NFS 客户端会缓存文件的元数据和数据，以减少网络请求，提高性能。客户端读取的文件数据可能会缓存在本地 RAM 中。如果其他客户端修改了文件，当前客户端可能仍然读取旧数据（缓存一致性问题）。
- NFS 服务器也会缓存数据，提高性能。默认情况下，NFS 服务器不会立即写入磁盘，而是异步写入，以提高写入性能。如果服务器宕机，可能导致数据丢失或写入失败。
- 文件锁
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 存储数据，可能造成如下问题：
- TDengine 使用 fsync() 确保 WAL 落盘，而 NFS 的缓冲机制会导致落盘延迟，无法实现数据持久化，当出现故障时，无法使用 WAL 恢复数据。
- 由于 NFS 的缓冲机制，可能会造成 WAL 数据写入乱序，影响数据一致性。
- 当多个客户端访问文件时，NFS 文件锁无法保证数据的一致性性。
- 网络抖动或延时，造成读写数据文件失败。
综上所述，应避免使用 NFS 作为 TDengine 的数据目录。