软删除和影子表

Nova 具有两个不相关的特性，分别称为 软 删除

可恢复的软删除实例

在实例删除请求之后，实际删除会被延迟一个可配置的时间段（配置选项 reclaim_instance_interval）。在延迟期间，实例会被标记为 SOFT_DELETED 状态，并且可以被管理员恢复（openstack server restore），以便优雅地处理人为错误。如果在配置的延迟期间未恢复实例，则会定期作业实际删除该实例。

此功能是可选的，默认情况下未启用。

参见

• “删除，恢复”在 API 指南：服务器概念 中

• 配置参考：reclaim_instance_interval

将软删除数据库行移动到影子表

在实际删除实例时，不会删除任何数据库记录。相反，记录会被标记为已删除（例如，Nova cell 数据库中的 instances.deleted）。这保留了用于调试和审计用途的历史信息。但这也导致 Nova cell DB 表中数据的累积，这可能会影响 Nova DB 性能，如 DB prune deleted rows 中所述。

标记为已删除的记录可以分多个阶段清理。首先，您可以将它们移动到所谓的影子表（Nova cell 数据库中带有前缀 shadow_ 的表）。这称为归档已删除的行。Nova 不查询影子表，因此移动到影子表的数据不再影响数据库性能。但是，仍然会占用存储空间。然后，您可以实际从影子表中删除信息。这称为DB purge。

这些操作可以通过 nova-manage 执行

• https://docs.openstack.org/nova/2025.2/cli/nova-manage.html#db-archive-deleted-rows

• https://docs.openstack.org/nova/2025.2/cli/nova-manage.html#db-purge

此功能不是可选的。每个长期运行的部署都应定期归档和清除已删除的行。例如，通过 cron 作业定期调用 nova-manage db archive_deleted_rows 和 nova-manage db purge。应考虑数据保留、数据库性能和存储需求之间的权衡。

在 Mitaka 版本中，Nova 开发人员达成一致，为 Nova 数据库中的每个表提供影子表是不希望的，在规范中记录。

因此，并非有关实例的所有信息都保存在影子表中。从那时起，没有引入新的影子表。