作为 OceanBase 数据库备份恢复介质的 NFS 挂载选项推荐

NFS 作为一种常用的文件共享方式，经常被用于集群化部署环境中。在 OceanBase 数据库的多节点集群部署中，NFS 也经常被用来作为 OceanBase 数据库物理备份/恢复的介质和 OBLOADER/OBDUMPER 工具逻辑备份恢复的存储介质。

本文主要介绍了 NFS 客户端挂载时推荐使用的 mount 选项，以及各个选项的具体含义。

适用版本

OceanBase 数据库 V2.2.52 及后续版本

OceanBase LOADER and DUMPER 所有版本

NFS 挂载选项介绍

假设 Mount 到 /data/nfs 目录，如果没有合适的目录可以新建一个目录。

sudo mount -tnfs4 -o rw,nfsvers=4.1,sync,lookupcache=positive,hard,timeo=600,wsize=1048576,rsize=1048576,namlen=255 100.xx.xx.xx:/data/nfs_server /data/nfs

语句中：

• nfsvers=4.1：由于备份依赖 NFS 4 原生的文件锁，推荐使用 NFS 4.1 及以上版本。如果 NFS 服务端安装的 NFS 版本为 4.2，这边可以改成 nfsvers=4.2。

• sync：使用同步写保证数据能及时刷到服务端，从而保证数据的一致性。

  对于异步挂载，客户端下发的写数据会先缓存在内存中，达到一定大小或者其他条件（与客户端设置，状态有关），再一起发往服务端。而同步挂载，每次下发的写数据马上发到服务端。同步挂载要求每个请求立即发到服务端，增加了请求连接、发送次数，对于小 IO 场景性能差异很明显（IO 越小，差异越大，一般都能达到几倍甚至更大的差异）。因此，OBDUMPER 逻辑备份场景如果追求性能的话，可以考虑将 sync 选项去掉，使用缺省的 async 模式。

• lookupcache=positive：用于避免并发访问目录或者文件时误报目录或文件不存在的问题，保证数据的一致性。

• hard：在 NFS 不可用的情况下，系统会卡住应用的读写请求，以保证数据的一致性。不能使用 soft 选项，会有数据错误的风险。

• timeo：用于指定 NFS 客户端在重试向文件系统发送请求之前等待响应的时间，单位为 0.1s。在设置时，建议不要设置得过大，推荐值为 600。如果您必须更改超时参数（timeo），建议您使用 150 或更大的值。该 timeo 参数的单位为 0.1 秒，因此 150 表示的时间为 15 秒。

  timeo、retrans 这两个参数选择主要取决于网络性能。对于网络吞吐量小，延时高，抖动高，丢包率大的情况，建议将timeo、retrans 两个参数值设置大一些。对于网络吞吐量大，延时低，抖动低，丢包率小的情况，建议将 timeo、retrans 两个参数值设置小一些。具体设置值因网络状况而定。

• wsize：表示写的数据块大小，建议设置为 1048576。

• rsize：表示读的数据块大小，建议设置为 1048576。

• namlen：建议设置为 255。

• 100.xx.xx.xx：表示 NFS 服务器的 IP 地址。

注意事项

• 如果需要将挂载路径写入到 /etc/fstab，需要提前确保 NFS 服务端稳定可访问，否则如果 NFS 服务端无法访问的话，可能会导致 NFS 客户端机器重启流程夯住。

  observer1:~# tail /etc/fstab
  ...
  100.xx.xx.xx:/data/nfs /obbackup nfs4 rw,nfsvers=4.1,sync,lookupcache=positive,hard,timeo=600,wsize=1048576,rsize=1048576,namlen=255 0 0
  observer1:~# 
  

• 在挂载 NFS 时，必须保证备份挂载环境的参数中包含 nfsvers=4.1、sync、lookupcache=positive 及 hard。

• Docker 环境需要在宿主机上挂载 NFS，然后映射到 Docker 里面。如果 Docker 内部直接挂载 NFS，可能会出现客户端 Hung 住的场景。