注意
本文档适用于 Ceph 的开发版本。
异步恢复
Ceph 放置组（PG）维护着一个写入事务日志，以方便快速恢复数据。在恢复过程中，每个 PG 日志都用于确定每个 OSD 中缺少或过时哪些内容。这避免了扫描所有 RADOS 对象的需要。有关此过程的更多详细信息，请参阅 基于日志的 PG。
在 Nautilus 版本之前，此恢复过程是同步的：它会阻塞对 RADOS 对象的写入，直到该对象恢复为止。相比之下，回填（backfill）可以允许写入继续进行（假设有足够多的最新副本可用），方法是临时分配一个不同的活动集，并在活动集之外回填一个 OSD。在某些情况下，这对可用性来说会明显更好，例如，如果 PG 日志包含 3000 次对不相关对象的写入。当 PG 日志包含数千个条目时，通过删除并重新部署包含该 PG 的 OSD 来用回填替换恢复（虽然不如同步恢复安全）可能实际上更快，而不是迭代 PG 日志。恢复几兆字节的 RADOS 对象数据（更糟糕的是，几兆字节的 omap 键，特别是 RGW 存储桶索引）可能会极大地增加小更新的延迟，再加上请求分布在许多降级对象上，这是导致慢请求的原因。
为了避免这种情况，我们可以在与活动活动集带外（out-of-band）的 OSD 上在后台执行恢复，类似于回填，但仍然使用 PG 日志来确定需要做什么。这被称为异步恢复。
执行异步恢复而不是同步恢复的阈值并不是很明确。异步恢复需要满足一些条件：
尽量保持
min_size副本可用使用日志长度差异的大致大小以及历史丢失对象来估计恢复成本
使用参数
osd_async_recovery_min_cost来确定何时适合进行异步恢复
在现有的对等（peering）过程中，当我们选择活动集时，我们还没有从每个对等点获取 PG 日志；我们只从它们的 pg_info_t 中获取了日志的边界和其他元数据。此时获取和检查每个日志会更昂贵，因此我们目前只考虑对日志长度进行近似检查。在 Nautilus 中，我们改进了丢失对象的统计，因此在 Nautilus 之后，此信息也用于确定恢复成本。
在发生异步恢复时，对活动集成员的写入可以继续进行，但我们需要将它们的日志条目发送给异步恢复目标（就像我们对回填 OSD 所做的那样），以便它们能够完全赶上。