FastDFS运维友好那些事儿

Posted 2021-08-05 Huazie

FastDFS运维友好那些事儿

本篇文章转载于FastDFS作者 余庆 大佬的 FastDFS分享与交流 公众号。
FastDFS运维友好那些事儿（一）
FastDFS运维友好那些事儿（二）

最近有人在 FastDFS QQ 技术交流群里爆料，说网上有人吐槽FastDFS 是最难配置的一款开源软件。我当时在群里反驳说 FastDFS 自带配置文件示例，绝大多数配置项使用默认值即可，实际需要设置的配置项就十个左右。刚才统计了一下最新的配置文件示例，tracker.conf 中有52个配置项，storage.conf 中有59个配置项。嗯，居然有这么多，把我也吓了一跳。

众多配置项的好处主要体现在功能定制化和系统调优灵活性。如果你对某些系统调优和功能特性有需要，比如更好的运行性能、小文件合并存储、日志轮转和定期清除、binlog 自动压缩和解压等等，可能就不会嫌弃配置项繁多了。

先抛开 FastDFS 配置这个梗，FastDFS 一直在努力提高运维友好性。日志记录如何详尽周全且不冗余绝对营养之类的，属于软件开发的基本功，这里就不多说了。列举FastDFS 几个充分体现运维友好性的功能和特性如下：

1. 更换单盘后自动恢复单盘数据

2. storage server 支持动态增加存储路径（通常是增加磁盘）

3. 日志轮转和定期清除

4. binlog 自动压缩和解压（V6.01支持的功能，已完成开发）

1. 更换单盘后自动恢复单盘数据

先说1这个特性，V2.08 就实现了这个功能。

判断一个单盘（FastDFS 为存储路径 store_path）是否需要恢复数据的逻辑为：检测 $store_path/data/ 目录下的两个子目录 00/00/ 和 FF/FF/（每级子目录采用默认 256 个的情况下）是否存在，如果其中一个不存在，则自动建立所需子目录，并启动单盘数据自动恢复。

单盘数据恢复逻辑：

1. 从 tracker server 获取一台可用的 storage server 作为源服务器；

2. 从源 storage server 拉取该存储路径（按 store_path 顺序对应）的 binlog，并存储到本地；

3. 根据本地 binlog 从源 storage server 复制文件到 $store_path/data/ 下对应目录；

4. 单盘数据恢复完成后，才能对外提供服务。

2. storage server支持动态增加存储路径

我们再看2这个特性，storage server 支持动态增加存储路径，这个特性应该是 V3.05 开始支持的。这个功能本身并不复杂，但有一点需要大家注意一下：一个 group 内的所有 storage server 的存储路径数量必须一致，配置不一致的 storage server 将无法加入集群。

群里偶尔有人反映说 storage server 增加磁盘后日志报错，这是因为同一 group 内的 storage server 的存储数量不同导致的。用 fdfs_monitor 可以查看集群中的服务器列表和状态，查看存储路径数目是否一致的命令行示例：

fdfs_monitor /etc/fdfs/client.conf list group1 | grep store | grep path | grep count

输出的第一个store path count为 group 接受的存储路径数，其余为各个 storage server 的存储路径数。当该 group 下所有 storage server 的存储路径数相同，group 才会接受最新的存储路径数。

如果出现废弃的 storage server 而导致存储路径数量不一致，需要将其从集群中删除，命令行示例：

fdfs_monitor /etc/fdfs/client.conf  delete  <group>  <id or IP>

为了防止误操作，不允许 删除状态为 ACTIVE 的 storage server。

删除后该 storage server 的状态为 DELETED，如果看着不爽，重启 tracker server 后该 storage server 将从集群中消失。

查看一个 group 内 storage server 的 IP 地址及状态列表：

fdfs_monitor /etc/fdfs/client.conf list group1 | grep ip_addr

查看一个 group 内 storage server 的 id 列表（storage 采用 server id 特性的情况下使用）：

fdfs_monitor /etc/fdfs/client.conf list group1 | grep '^\\s*id'

注： 以上命令行示例中的 group1 为需要查看的 group（存储分组）名称，修改为你要查看的 group 名称即可。

3. 日志轮转和定期清除

V4.02 支持日志轮转和定期清除日志文件。

日志轮转支持按天轮转和按文件大小轮转，定期清除是指删除N天前的日志文件，这两个特性默认是关闭的。

日志轮转和定期清除功能已经整合到 libfastcommon 的 logger 实现中，C 开发工程师自取就好，请不要客气。

tracker.conf 和 storage.conf 中的配置示例如下：

# if rotate the error log every day
# default value is false
# since V4.02
rotate_error_log = false

# rotate error log time base, time format: Hour:Minute
# Hour from 0 to 23, Minute from 0 to 59
# default value is 00:00
# since V4.02
error_log_rotate_time=00:00

# rotate error log when the log file exceeds this size
# 0 means never rotates log file by log file size
# default value is 0
# since V4.02
rotate_error_log_size = 0

# keep days of the log files
# 0 means do not delete old log files
# default value is 0
log_file_keep_days = 0

4. binlog自动压缩和解压

V6.01 支持 binlog 自动压缩和解压，这个功能默认是关闭的。

有人反馈经过长期运行，binlog 占用空间较大，希望能对 binlog 文件进行压缩，于是近期实现了 binlog 自动压缩和解压功能。

binglog 自动压缩只会压缩已经完成同步的 binglog 文件，不会影响当前storage server 的文件同步功能。在一些特定情况下（如新增 storage server、单盘数据恢复等）需要访问已经压缩的 binglog，程序将自动将其解压。出于简洁和统一考虑，压缩和解压直接使用 gzip 命令。

binlog 自动压缩和解压没有任何副作用，请大家放心使用。

storage.conf 中的配置示例如下：

# if compress the binlog files by gzip
# default value is false
# since V6.01
compress_binlog = false

# try to compress binlog time, time format: Hour:Minute
# Hour from 0 to 23, Minute from 0 to 59
# default value is 01:30
# since V6.01
compress_binlog_time=01:30