6.7. RADOS
执行带有两个站点扩展集群的 DR 测试不再会导致 Ceph 变得无响应
在以前的版本中，当使用两个站点进行 DR 测试时，删除并在集群中添加新监控器会导致 ConnectionTracker 类中的等级不正确。因此，监控器无法在 peer_tracker 复制中识别自己，永远不会更新其正确的字段，从而导致在选择过程中死锁导致 Ceph 变得没有响应。
在这个版本中，进行了以下修正：
-
在函数
notify_rank_removed （）中添加了 assert，将Monmap提供的预期等级与手动调整的等级进行比较。 -
从每个
Monmap更新中清除removed_ranks变量。 -
添加了在执行命令时手动重置
peer_tracker.rank的操作 - 每个 monitor 的ceph connection score reset。peer_tracker.rank与 monitor 的当前排名匹配。 -
添加了
Elector和ConnectionTracker类中的函数，以便在升级监控器时检查干净的peer_tracker，包括启动。如果找到 unclean，则peer_tracker被清除。 -
在 Red Hat Ceph Storage 中，用户可以在关闭 monitor 前手动删除 monitor 等级，从而导致
Monmap不一致。因此，在Monitor::notify_new_monmap （）中，我们阻止该函数删除在Monmap中不存在的等级或等级。
集群现在可以按预期工作，且没有未完成的停机时间。当使用两个站点扩展集群执行 DR 测试时，集群不再变得无响应。
等级从 live_pinging 和 dead_pinging 集中删除，以减少连接分数不一致的问题
在以前的版本中，当按顺序删除两个监视器时，如果排名大小等于 Paxos 的大小，则 monitor 将面临一个条件，且不会从 dead_pinging 设置中删除排名。因此，等级保留在 dead_pinging 集合中，这会导致问题，比如启用扩展模式时连接分数不一致。
在这个版本中，添加了一个删除最高等级监控的情况，即当等级等于 Paxos 的大小时，从 live_pinging 和 dead_pinging 设置中删除排名。monitor 通过干净的 live_pinging 和 dead_pinging 集保持健康。
Prometheus 指标现在根据请求反映所有 Ceph Monitor 的正确 Ceph 版本
在以前的版本中，当监控器升级时，Prometheus 指标报告 Ceph Monitor 不匹配的 Ceph 版本。因此，需要重启活跃的 Ceph Manager 守护进程来解决这个问题。
在这个版本中，当 MON 选举结束时，Ceph Monitor 会在 mgr 中使用 mon 元数据明确发送带有元数据的更新请求。
ceph daemon heap status 命令显示堆状态
在以前的版本中，由于通过 ceph daemon 命令无法获取堆信息，ceph daemon heap stats 命令会返回空输出，而不是返回 Ceph 守护进程的当前堆使用量。这是因为 ceph::osd_cmds::heap （） 混淆 stderr 和 stdout 概念，这会导致输出差异。
在这个版本中，ceph daemon heap stats 命令返回 Ceph 守护进程的堆使用量信息，类似于使用 ceph tell 命令的信息。
当使用 ceph orch apply mon <num> 命令时，Ceph Monitor 不再崩溃
在以前的版本中，当使用 ceph orch apply mon <num > 命令来减少集群中的监控器时，会在 ceph-adm 中关闭 monitor 前删除 monitor，从而导致 monitor 崩溃。
在这个版本中，在检查对等排名是否大于或等于 monitor 映射中的等级大小的所有代码路径中添加了一个完整性检查。如果条件满足，则跳过导致监控器崩溃的某些操作。对等等级最终会在 monitor 映射的下一版本中解决自己。从 monitor 映射中删除时，监视器不再崩溃，然后再关机。
最终用户现在可以从 Ceph 集群日志中看到 scrub 或 deep-scrub 启动的消息
在以前的版本中，由于 Ceph 集群日志中缺少 scrub 或 deep-scrub 启动的消息，最终用户无法通过日志知道已为 PG 启动了清理。
在这个版本中，清理或深度清理 启动信息被重新加入。现在，在清理或深度清理进程启动时，Ceph 集群日志会为 PG 显示相关的消息。
Ceph Manager 故障切换过程中没有断言
在以前的版本中，当激活 Ceph Manager 时，它会接收之前活跃管理器发送的多个 service_map 版本。当新激活的管理器收到带有更高版本的映射时，代码中的检查会导致断言失败。
在这个版本中，管理器中处理初始服务映射的检查已被放宽，在 Ceph 管理器故障切换过程中没有断言。
在升级集群后，用户可以删除克隆的对象
在以前的版本中，在将集群从 Red Hat Ceph Storage 4 升级到 Red Hat Ceph Storage 5 后，删除之前版本中创建的对象快照会离开克隆，且无法删除。这是因为 SnapMapper 键被错误地转换。
在这个版本中，更新了 SnapMapper 的传统规格，以匹配新的密钥格式。早期版本的 Ceph 中的克隆对象现在可以在升级后轻松删除。
对于小型的写，不再会发生 RocksDB 错误
BlueStore 对于 HDD 采用了一种延迟小型写的策略，在 RocksDB 中存储数据。从 RocksDB 清理延迟数据是一个后台进程，它不与 BlueFS 同步。
在这个版本中，延迟重播不再覆盖 BlueFS 数据，且不会发生一些 RocksDB 错误，例如：
-
osd_superblock崩溃。 - CURRENT 不会以换行符结尾。
-
.sst文件校验和错误。
不要写延迟数据，因为写入位置可能包含正确的对象或为空。不可能以这种方式破坏对象数据。BlueFS 是唯一可以分配此空间的实体。
可以通过脱机和在线修剪删除 PG 日志条目损坏
在以前的版本中，在低级 PG 分割操作期间，PG 日志 dups 条目的修剪会无法被 PG 自动扩展器使用，超过人为 operator 的频率。使 dups 修剪导致 PG 日志的内存增长造成大量内存增长，因为 OSD 内存不足时会导致 OSD 崩溃。重启 OSD 不会解决此问题，因为 PG 日志存储在磁盘上，并在启动时重新加载到 RAM。
在这个版本中，离线（使用 ceph-objectstore-tool 命令）和在线（带有 OSD）进行修剪可能会移除 PG Log 的损坏的 dups 条目，该条目会阻塞修建机制并导致内存增长。实施了调试功能，它将 dups 条目的数量输出到 OSD 的日志，以帮助调查未来。
