2020年1月11日，星期一，这天我在湖北省武汉市给一辆品牌为理想one的新车上牌照，步骤如下。

首先，到位于湖北省武汉市洪山区旭东小路汪家墩小区的车辆购置税办税服务厅办理购置税纳税事宜。由于是属于新能源牌照汽车，免缴购置税。下午两点一刻左右，到该办税大厅后，到离门口约3m的机器上，在工作人员的帮助下，扫描车辆合格证，验证车辆车架号、发动机号和营业执照（我是以企业名义购车，若是个人的话，则是身份证信息）等信息。确认无误后，打印出电子版纳税证明（后续办理车牌时不需要出具该凭证，因为系统联网识别了）即完毕。整个过程办完约2分钟，花费0元。

第二步，到位于湖北省武汉市武昌区友谊大道与楚汉路交叉口附近的武汉市交管局车管所办理验车事宜。开车进入车管所后，沿指示到验车场地，此时约下午三点左右（从办税大厅到车管所虽然很近，但绕了不少路，欲找地方洗车花费了不少时间）。在进入场地前的通道处窗口出示购车发票、车辆合格证和营业执照领取验车单。然后排队等候约15分钟后（排队车辆不算多，前面约4辆车），到我的车进行验车手续。将理想one公司给的车架后拓印号贴到验车单上并交给验车员。验车员查验发动机舱的编号信息和前挡风玻璃上的编号信息；个人将三脚架装好放到车辆尾部正下方；验车员对车辆拍照。最后验车员检测合格后，在验车单上盖章并交给我。然后开车到车管所停车场。验车过程约3分钟。此外，由于没有洗车，车辆很脏也不影响正常验车，就是最后行驶证上的车辆照片明显看到很脏，有强迫症的还请注意提前洗车。

第三步，从正门进入车管所大厅并办理牌照。直接到靠门口的前台出示购车发票、车辆合格证、营业执照，前台会给排队号码纸条。按照号码找到对应的窗口进行上牌（这次是下午三点半左右人少没有排队），提交车辆合格证、购车发票、营业执照、电子保单打印件和办理人身份证。由于是公司购车，需要填写一份办理人委托书并盖公章。然后缴纳60元上牌费（支付宝、微信或银行卡都可以缴纳）。办理结束后，得到一张有条形码的A4打印纸，用于到机器上扫码选号。有3~5台选号机，也没有排队，直接开始选好。点击开始选号后，给随机50个号码，必须在180秒内选号完毕。注意没有第二次选号机会。

第四步，选号完毕去二楼领取车辆行驶证并办理邮寄车牌服务。需要在车管所二楼大屏幕前等待，当看到提示领取车辆行驶证时，到对应窗口领取行驶证和临时牌照。然后到旁边的台柱上扫码办理车牌邮寄。缴纳20元邮寄费即可邮寄到本市。至此，到下午四点一刻左右，办理车辆牌照结束。

其它办牌经验：大部分人觉得办牌照比较麻烦，会考虑额外花一些前找4S店人员搞定，这样会节约时间。若是当天买车，当天能这样办好是最好的。我当时交车时已经到下午三点半了，再介绍个车辆并在理想one交付中心直接缴纳保险后都过四点了。然后理想one公司送了临时牌照，到办理临牌地点都已经四点半了。该办牌地点虽然能400元全套办牌搞定，但是验车员提前下班走了，当天就没法办正式牌照。后来有一天过去，排队人太多，也没办成。但不管怎么样，去办牌，都得开车到某地点，花时间验车上牌。预计自行到车管所上牌和到专门地点一套全部快速搞定，花费的时间其实差不多的。因为该专门地点就是多了个车辆购置税交税功能而已，而该步骤其实是很快的，才花费3分钟而已。自行上牌好处是只花费80元，省了至少320元，但需要花精力自行找办税地点和车管所地点。

SGE集群可能出现独列错误状态。此时，使用命令 qstat -f 检测集群队列队列状态。最后一列stats若为空，则表示队列状态正常，可以用于任务提交。其它状态解释如下：

a： 负载超限了，开启警报alarm。
A： 超限暂替，开启警报Alarm。
E： 队列有错误，不能提供任务提交服务了。
au：主机和SGE系统连接中断，此时负载状态为-NA-。需要重启相应服务器的sgeexecd命令。

当出现状态 E 时，则需要使用root用户在对应的主机中重启sge计算服务：

/opt/sysoft/sge/default/common/sgeexecd restart

然后，清除队列中的错误信息：

qmod -c all.q

在服务器使用过程中，我遇到这样一种情况：服务器将网络上的文件系统挂载到了 /home 目录；当系统出现问题导致 /home 没有响应时，导致了 /home 目录下的普通用户无法登陆。

解决方法我于是使用了备用的不在 /home 目录下的其它普通用户登陆。此时则可以登陆到服务器中了。此时，可能遇到一种情况，能登陆到服务器，但是不会返还命令提示符。这可能依然是 /home 目录没有响应，而很多依赖该分区下数据运行的程序异常运行导致的。此时，按如下方式可以登陆到服务器中：

ssh -t chenlianfu@xx.xx.xx.xx "cd /; bash"

由于挂载的 /home 分区没有响应。此时，使用正常的重启命令，极可能关机失败，从而无法再次连接服务器。因为依赖 /home 分区数据运行的程序无法强行杀死导致系统无法关机。则需要直接通过硬件关机再开机。若无法直接接触服务器，则使用IPMI方法实现硬件上的强制关机或重启：

# 加载 ipmi 驱动，确认服务器支持IPMI
sudo modprobe ipmi_msghandler ipmi_devintf ipmi_si
sudo ls -l /dev/ipmi*

# 数显按照 ipmitool 软件
sudo yum reinstall ipmitool
# 需要值得注意的是：在CentOS系统上，重启系统后ipmitool命令失效了。每次重启系统后，需要重新安装ipmitool才能正常使用。

# 再使用 ipmitool 命令实现应硬件上强制重启
sudo ipmitool power reset

1. EndNote软件安装

我当前先安装Microsoft office软件，然后安装了EndNote X9.3.1汉化破解版。在联网状态下，打开EndNote软件会闪退。原因是程序开始运行时会联通download.endnote.com网址，可能识别出盗版软件而退出。只需要不联网、禁止EndNote程序联网或将域名指向不能识别的ip地址即可。较好的方法是禁止EndNote程序联网，方法如下：

首先，键盘输入Windows+q打开搜索，输入“高级安全”，点击“高级安全 Windows Defender 防火墙”，弹出窗口设置界面。
然后，左侧栏目点击“出站规则”，右侧“操作”栏中点击“新建规则”，在弹出的窗口依次选择“程序”→“下一步”→“此程序路径”→“浏览”→选择EndNote安装目录下的“EndNote.exe”→“打开”→“下一步”→“阻止连接”→“下一步”→域、专用、公用全部勾选→“下一步”→名称随意填写（例如“EndNote禁止联网”），描述可不填→“完成”。

2. 导出文献

有时候，我们需要将目标文献信息导出成文本文件。先用鼠标选中一篇文献，然后点击“文件”——“导出”——导出样式中选中一个目标样式——“保存”，即可导出成需要的格式结果。一般情况下RIS是通用的文献格式，在导出样式中选择其它样式，搜索ris即可找到RefMan (RIS) Export格式。RIS格式的文件内容依然是文本文件，可以手动将输出的文件后缀修改为ris即可。

当我运行得到结果文件后，需要删除当前目录下许多的中间文件夹：

find ./ -maxdepth 1 -type d -regex "./\w.*" -exec rm -rf {} +

各参数意义如下：
./ 是被搜索的文件夹
-maxdepth 1 表示仅搜索第一层目录
-type d 表示仅搜索文件夹类型数据，注意该参数要放-maxdepth参数后面，否则程序会有警告信息。
-regex "./\w.*" 使用正则表达式方式搜索数据，该正则表达式不会搜索当前目录下名称为 . 的目录，以防把当前目录直接删除
-exec rm -rf {} + 用于对搜索到的文件执行相应的操作，其中{}表示搜索到的文件路径。{}后面可以接空格加号或空格反斜线分号。

将当前目录下所有权限为600的普通文件变为644，

find ./ -type f -perm 600 -exec chmod 644 {} +

将当前目录下所有权限为700的文件夹变成755：

find ./ -type d -perm 700 -exec chmod 755 {} +

我有多台服务器，每台服务器都将其存储挂载到了/disks/目录下并通过万兆网共享给所有局域网其它服务器。此时，我需要当切换到其它服务器时，一步到位自动切换到其存储目录下。此时，我按如下操作执行ssh命令即可。

ssh -t node2 "cd /disks/node2_16TB/chenlianfu; bash"

# ssh登陆node2服务器时，执行cd命令并使用bash命令登陆当前用户。若不加-t参数，ssh则时登陆到目标服务器后，执行相应命令后返回到当前主机。添加-t参数则表示强制分配虚拟终端，有利于远程服务器上一些依赖屏幕软件（例如less和bash命令）的运行。

# 想了解-t参数的意义，可以比较以下两个命令的差异。
ssh -t node2 "less /proc/cpuinfo"
ssh node2 "less /proc/cpuinfo"
# 只有添加了-t参数，才能真正让less命令使用屏幕，否则，不会为less命令分配虚拟终端而不能正常运行。

1. 从广州火车站到华南植物园科研区

在广州火车站地铁站，搭乘地铁5号线（文冲方向）到区庄站；换乘地铁6号线（香雪方向）到地铁长湴站A出口；换乘775路公交车到华南植物园西门下车即到。

安装CentOS8系统后，由于缺少DELL H700/H800的阵列卡驱动。可以自己手动安装其驱动：

wget https://elrepo.org/linux/dud/el8/x86_64/dd-megaraid_sas-07.710.50.00-1.el8_2.elrepo.iso
mount -o ro dd-megaraid_sas-07.710.50.00-1.el8_2.elrepo.iso /mnt/
dnf -y install /mnt/rpms/x86_64/kmod-megaraid_sas-07.710.50.00-1.el8_2.elrepo.x86_64.rpm

但是要注意的是，安装驱动完毕后，重启系统后导致网卡驱动不能正常识别。

可以考虑安装系统时，同时安装Megaraid驱动。将其ISO镜像文件使用UltraISO烧录到一个U盘中。然后将该U盘和CentOS8启动U盘同时插入到服务器上安装系统。从启动U盘启动CentOS8系统安装，在启动安装界面按字母e对启动参数进行编辑，后面添加参数信息inst.dd=/dev/sdb4，表示通过第二个U盘第四个分区中的驱动数据安装驱动，然后按ctrl + x启动，若顺利的话，则可以识别H700整列卡从而可以安装CentOS8系统。

当在Windows系统上使用UltraISO软件来制作CentOS8系统的U盘启动盘时：若使用默认的USB-HDD+写入方式制作出来的CentOS8启动盘是无法启动安装系统的，这种方式适合绝大部分系统镜像；这时需要使用RAW写入方式来烧录ISO镜像文件，从而可以正常启动CentOS8系统安装界面，但是这种模式下U盘不能再正常写入数据。

推荐在Windows系统下使用Rufus软件制作CentOS8的U盘启动盘。这种方法既能制作正常的启动盘，也能让U盘正常读写数据。

1. 先下载Rufus软件
2. 启动软件，选择CentOS8镜像文件
3. 设置卷标为CentOS8_1
4. 点击开始，同意联网下载两个文件
5. 选择默认的ISO镜像模式写入
6. 点击OK开始将数据烧录到U盘中。

1. Slow OSD heartbeats

# ceph -s
health: HEALTH_WARN
       Slow OSD heartbeats on back (longest 6181.010ms)
       Slow OSD heartbeats on front (longest 5953.232ms)

OSDs之间会相互测试（ping）访问速度，若两个OSDs之间的连接延迟高于1s，则表示OSDs之间的延迟太高，不利于CEPH集群的数据存储和访问。两个OSDs之间可以通过内网（存储服务器之间 / back）检测其延迟，也可以通过外网（存储服务器到使用服务器 / front）检测其延迟。若延迟过高，会将相应的OSDs down掉，进而可能导致CEPH数据丢失。

一般情况下OSDs之间延迟高的原因是因为网络原因导致的。可能是某台存储服务器重启网络导致，或网线出问题导致。前者的时间会逐渐变小，最后恢复正常，后者则问题一直存在。通过查看详细的OSDs延迟信息查找延迟较高的主机，再进行解决。

# ceph health detail

[WRN] OSD_SLOW_PING_TIME_BACK: Slow OSD heartbeats on back (longest 11846.602ms)
    Slow OSD heartbeats on back from osd.12 [] to osd.25 [] 11846.602 msec
    Slow OSD heartbeats on back from osd.8 [] to osd.17 [] 3617.281 msec
    Slow OSD heartbeats on back from osd.16 [] to osd.27 [] 2784.517 msec
    Slow OSD heartbeats on back from osd.21 [] to osd.17 [] 1678.064 msec
    Slow OSD heartbeats on back from osd.11 [] to osd.15 [] 1675.884 msec
    Slow OSD heartbeats on back from osd.20 [] to osd.13 [] 1073.790 msec
[WRN] OSD_SLOW_PING_TIME_FRONT: Slow OSD heartbeats on front (longest 11427.677ms)
    Slow OSD heartbeats on front from osd.12 [] to osd.25 [] 11427.677 msec
    Slow OSD heartbeats on front from osd.8 [] to osd.17 [] 3787.868 msec
    Slow OSD heartbeats on front from osd.16 [] to osd.27 [] 3465.298 msec
    Slow OSD heartbeats on front from osd.11 [] to osd.15 [] 1469.591 msec
    Slow OSD heartbeats on front from osd.21 [] to osd.17 [] 1341.135 msec
    Slow OSD heartbeats on front from osd.20 [] to osd.13 [] 1224.235 msec
    Slow OSD heartbeats on front from osd.5 [] to osd.16 [] 1101.175 msec

通过以上信息查看，可以发现有一台主机和其它主机的OSDs延迟都比较高，将该主机的光纤网线拔下擦拭干净并重新插上得以解决。

2. slow ops

# ceph -s
     21 slow ops, oldest one blocked for 29972 sec, mon.ceph1 has slow ops

先保证所有存储服务器上的时间同步一致，再重启相应主机上的moniter服务解决。

3. pgs not deep-scrubbed in time

# ceph -s
    47 pgs not deep-scrubbed in time

CEPH系统每1~1.5天对所有的PGs进行一致性检验（scrub，通过文件的元数据信息检验PG在各OSDs上对应的对份数据是否完整一致，速度很快）。对每个PG进行一致性检验时，有一定概率转换为深度一致性检验（deep-scrub，通过文件内容来 检验PG在各OSDs上对应的对份数据是否完整一致，速度很慢，非常消耗磁盘读取性能 ）。若设置概率为5%，则需要20~30天才能对所有的PGs进行深度一致性检验。而默认的osd_deep_scrub_interval阈值为1周，当有PGs超过2周未能进行deep-scrub时，则其会进行警报。修改该参数阈值为一个月时间(60*60*24*30)，从而消除警告。

ceph config set global osd_deep_scrub_interval 2592000 

4. MDS cache is too large

ceph config set mds mds_cache_memory_limit 10GB

ceph config dump

当MDS使用的缓存过高，比设定的阈值高很多时，则有此警告信息。使用如上命令设置更高的MDS缓存阈值，即可消除次警告信息，但会消耗更多的内存。使用config dump命令可以查看各项参数阈值信息。

此外，可能增大了mds_cache_memory_limit参数后，过了一段时间后仍然提示该警告，检测发现MDS缓存使用又超过新设定值的1.5倍大小了。此时，可以考虑设置多个活动状态的MDS服务。

# 先开启3台服务器的MDS服务，确保这3台服务器的内存是够用的，最好这3台服务器的内存更大。
ceph orch apply mds cephfs ceph106,ceph107,ceph109
ceph fs set cephfs max_mds 3

# 由于激活了3台服务器的MDS，缺少备用的MDS服务。再增加一个备用的MDS服务主机。
ceph orch apply mds cephfs ceph106,ceph107,ceph109,ceph110

5. Client node18 failing to respond to cache pressure

表示node18主机和MDS服务之前的响应较慢，若过一会儿就显示health_ok，则不用管它。若是长期显示该警告，则在对应的node18主机上卸载ceph文件系统后重新挂载即可。

客户端在使用相应数据时，MDS服务端则将其数据缓存到服务器的内存中。当MDS服务端需要减少缓存消耗时，则会给客户端发送相应的请求。此时，客户端响应过慢，则提示此警告信息。若一直如此，会导致MDS服务器缓存无法释放，内存消耗持续增加甚至导致宕机。

ceph集群提供元数据服务，则客户端可以提挂载ceph文件系统。客户端访问数据时，则在客户端和元数据服务器中都缓存相应的数据。元数据服务器会和客户端inode占用情况来消减缓存。当客户端响应太慢，则会报错“failing to respond to cache pressure” or MDS_HEALTH_CLIENT_RECALL。若确实是客户端负荷较大，是正常读写操作，可以考虑增大mds_recall_warning_decay_rate参数的值（默认为60s），从而消除警告。

可以查询ceph客户端的ID号及其使用inode数（num_caps的值）。

ceph tell mds.0 session ls

谨慎使用如下命令踢出目标客户端或全部客户端。

ceph tell mds.0 session evict id=11134635
ceph tell mds.0 session evict

踢出客户端是将客户端加入了黑名单，可以使用如下命令查看黑名单信息或移出黑名单。虽然移出黑名单，可能还不能让客户端正常挂载ceph文件系统，因此需要谨慎处理。

ceph osd blacklist ls
ceph osd blacklist rm 192.168.20.1:0/1498586492
ceph osd blacklist clear

6. Reduced data availability: 4 pgs inactive, 4 pgs incomplete

当有pgs出现incomplete时，表明pgs对应的OSDs存活数量少于最小副本数。因此，其对应的数据无法读写，处于reduced状态，会导致MDS服务出问题，提示如下报错信息，示例：

3 MDSs report slow metadata IOs
2 MDSs report slow requests
2 MDSs behind on trimming
Reduced data availability: 4 pgs inactive, 4 pgs incomplete

pg 5.6de is incomplete, acting [254,356,222,352,111,247,100,133,351,206] (reducing pool cephfs_data min_size from 8 may help; search ceph.com/docs for 'incomplete')
pg 5.6e9 is incomplete, acting [276,244,357,358,221,321,311,229,314,351] (reducing pool cephfs_data min_size from 8 may help; search ceph.com/docs for 'incomplete')
pg 5.73b is incomplete, acting [186,279,351,247,293,354,359,220,181,283] (reducing pool cephfs_data min_size from 8 may help; search ceph.com/docs for 'incomplete')
pg 5.eda is incomplete, acting [164,157,120,227,353,351,295,269,95,354] (reducing pool cephfs_data min_size from 8 may help; search ceph.com/docs for 'incomplete')

此时，需要修复pgs。

# 查询pg信息（pg id 为 5.6de）
ceph pg 5.6de query

# 强行重建pg
ceph osd force-create-pg 5.6de --yes-i-really-mean-it

7. failed to probe daemons or devices stderr:Non-zero exit code 125 from /bin/podman

由于Ceph存储集群中个别服务器的podman容器出问题，导致相应服务启动失败。报告警告如下：

[WRN] CEPHADM_REFRESH_FAILED: failed to probe daemons or devices
host ceph105 ceph-volume inventory failed: cephadm exited with an error code: 1, stderr:Non-zero exit code 125 from /bin/podman run --rm --ipc=host --net=host --entrypoint stat -e CONTAINER_IMAGE=docker.io/ceph/ceph:v15 -e NODE_NAME=ceph105 docker.io/ceph/ceph:v15 -c %u %g /var/lib/ceph
stat:stderr Error: readlink /var/lib/containers/storage/overlay/l/HMGABIBEWBRXOSBT4JLOKQIKDA: no such file or directory
Traceback (most recent call last):
File "", line 6112, in
File "", line 1299, in _infer_fsid
File "", line 1382, in _infer_image
File "", line 3581, in command_ceph_volume
File "", line 1477, in make_log_dir
File "", line 2084, in extract_uid_gid
RuntimeError: uid/gid not found

执行以下命令时，会有如上报错。而正常的存储节点则不会报错。

cephadm shell

该类报错表示podman的docker容器出错。查找出错的存储节点：

ceph orch ps | grep error

在各存储节点重新pull相应的docker镜像：

cephadm pull
podman pull ceph/ceph:v15
# 以上两个命令都可以达到目的，后者能看到下载的速度，以免等待较长时间下载几百M的文件而不清楚进度。
# 重新pull镜像后，会提升ceph版本。不会影响使用

检查podman的docker镜像

podman images
podman ps

最后重启服务器或重启CEPH服务。

8. mds.cephfs.ceph109.avzzqn(mds.1): Behind on trimming (594/128) max_segments: 128, num_segments: 594

有MDS服务器报警：

[WRN] MDS_TRIM: 2 MDSs behind on trimming
mds.cephfs.ceph109.avzzqn(mds.1): Behind on trimming (594/128) max_segments: 128, num_segments: 594
mds.cephfs.ceph106.hggsge(mds.0): Behind on trimming (259/128) max_segments: 128, num_segments: 259

MDS服务器将元数据以segments(object)方式存放，当MDS中的segments数量超出mds_log_max_segments的设置值（默认为128）时，MDS服务开始启动Trimming，即将segments数据进行回写。当MDS中的segments数超过设定值两倍时，开始报警Behind on trimming信息。当MDS服务器内存足够时，推荐增大mds_log_max_segments参数值。

ceph config set mds mds_log_max_segments 1024

9. mds N slow requests are blocked > 30 secs

MDS服务报警：

[WRN] MDS_SLOW_REQUEST: 3 MDSs report slow requests
mds.cephfs.ceph109.avzzqn(mds.1): 29 slow requests are blocked > 30 secs
mds.cephfs.ceph110.sfagxf(mds.2): 1 slow requests are blocked > 30 secs
mds.cephfs.ceph106.hggsge(mds.0): 3 slow requests are blocked > 30 secs

以上报警表示MDS响应慢，原因可能是：mds服务运行太慢、底层pg或OSD出问题导致写入日志未确认、或BUG。通过设置mds_op_complaint_time值为3000，问题依旧。

出现此警告时，OSD未报错。而mds服务运行应该正常，内存也足够用。通过阵列卡检测硬盘，发现有两台服务器分别有一块硬盘没有检测到。推测是相应的硬盘出问题，而OSD还未反应过来，带后续观察。

10. insufficient standby MDS daemons available

当有mds服务crash的时候，候选的mds则补上。此时，已经连接上的计算服务器还是可以正常访问ceph存储。但是，新的计算服务器无法挂载ceph文件系统。

解决方法是，ssh登陆到mds服务有crash的服务器，然后重启其mds服务。再登陆备用的mds服务器，重启其mds服务。

ssh ceph107
systemctl restart ceph-8f1c1f24-59b1-11eb-aeb6-f4b78d05bf17@mds.cephfs.ceph106.hggsge.service
ssh ceph102
systemctl restart ceph-8f1c1f24-59b1-11eb-aeb6-f4b78d05bf17@mds.cephfs.ceph102.imxzno.service

11. OSD_TOO_MANY_REPAIRS: Too many repaired reads on 1 OSDs

当某个OSD对应的磁盘有坏道时，CEPH系统对PGs进行deep srub的一致性检测时，会检测到某个OSD上同时又多个PGs出问题，于是可能出现以该警告。即使对所有的PGs进行修复后，该警报也不会消失。

[root@ceph101 ~]# ceph health detail
HEALTH_WARN Too many repaired reads on 1 OSDs
[WRN] OSD_TOO_MANY_REPAIRS: Too many repaired reads on 1 OSDs
    osd.174 had 21 reads repaired

若想要解决该警报，进入对应的CEPH主机，重启对应的OSD服务即可。

ssh ceph105
systemctl restart ceph-osd@174.service

12. RECENT_CRASH: 2 daemons have recently crashed

当CEPH有daemons奔溃情况时，虽然解决问题后，但相关crashed警告信息不会消失。比如当有磁盘出现坏道导致OSD服务奔溃自动重启，虽然CEPH系统没有问题，但留下了警告信息。

[root@ceph101 ~]# ceph health detail
HEALTH_WARN 2 daemons have recently crashed
[WRN] RECENT_CRASH: 2 daemons have recently crashed
    osd.174 crashed on host ceph105 at 2022-09-02T22:09:29.443817Z
    osd.174 crashed on host ceph105 at 2022-09-02T23:55:25.357799Z

使用如下命令清除并归档警告信息：

ceph crash archive-all

13. 1 clients failing to advance oldest client/flush tid

正常情况下客户端读写任务完成后，则通知MDS服务器释放资源，并更新tid。若客户端和MDS不能正常沟通了，可能导致tid一直不更新，从而会导致MDS中的内存不能释放，继而出现segment不能trim的情况，同时导致 MDSs behind on trimming 报警。此时，将MDS服务器重启即可解决。