如何定位 NFS 服务异常

当备份、归档出现异常时，我们应该首先排除备份介质、网络是否正常，本文讲述如何通过系统表和日志来定位 NFS 服务异常。

适用版本

OceanBase 数据库 V2.x，V3.x 版本。

关于 V4.x 版本，可参考文档 日志归档延迟或日志归档慢的原因和解决方法

如何查看备份归档异常？

1. 查看备份归档状态表，MAX_NEXT_TIME 应与当前时间接近，如果该时间停止则说明归档可能存在异常。

   select tenant_id, MIN_FIRST_TIME,MAX_NEXT_TIME
   from CDB_OB_BACKUP_ARCHIVELOG;
   

2. 或者查看归档进度表，通过类似方法进行判断。

   select * from CDB_OB_BACKUP_ARCHIVELOG_PROGRESS
   where TENANT_ID = xx
   order by MAX_NEXT_TIME limit 10;
   

3. 查看 OBServer 日志中关于归档的统计日志，搜索关键词 archive_sender statistic。

   grep 'archive_sender statistic' observer*
   observer.log.20230612161618:[2023-06-12 16:15:50.311863] INFO [ARCHIVE] ob_archive_sender.cpp:1589 [25879][0][Y0-0000000000000000-0-0] [lt=5] [dc=0] archive_sender statistic in 10s(total_send_buf_size=29384, total_send_log_count=157, avg_log_size=187, total_send_task_count=2, total_send_cost_ts=2809, avg_send_task_cost_ts=1404)
   

   该日志为 archive_sender 在 10 秒内的统计信息：

   • total_send_buf_size: log 发送缓冲区发生的日志大小。
   • total_send_log_count: 总发送日志数量。
   • total_send_task_count: 总的网络 IO 个数。
   • total_send_cost_ts: 所有网络 IO 的总耗时，单位为微秒（us）。
     • 如果接近或者超过 10s，说明 IO 已经跑满了。
   • avg_send_task_cost_ts: 平均一个网络 IO 的耗时，单位为微秒（us）。
     • 一般几十 ms 量级算正常，超过 100ms 就要看看 NFS 盘是不是性能不够，网络带宽是否瓶颈等。

4. 查看 OBServer 日志中关于归档文件访问的日志，搜索关键词 print_access_storage_log，查看归档日志文件的写入速度，如果写入速度不符合预期，则可能存在问题。

   cat observer.log|grep 'print_access_storage_log'
   [2023-06-12 16:15:50.311863] WARN [STORAGE] print_access_storage_log(ob_i_storage.cpp:47) [16182][4130][YB420A12992F-0005EFDDF8A827B0] [lt=6] [dc=0] access storage op=storage appender_url=file:///obbackup/xxxxxxx size=0 Byte cost_ts=1008485 us speed=0.00 MB/s
   

5. 如果第 4 步 print_access_storage_log 的日志显示 NFS 归档有问题，继续使用该日志的 trace_id 来查看更多的报警、报错信息，比如 -4009 failed to lock file、OB_IO_ERROR 等。

   

6. 如果 NFS 服务存在异常，也可以使用操作系统日志来查看是否存在相关的报错信息。

   dmesg -T|grep NFS