什么是低级存储要求？

Question

通常，数据库引擎会满足一些请求，并且任何修改都必须保持持久性（您称之为持久性）。如何确保/假设持久性？对 HW/OS 有哪些要求？

特别，

服务器什么时候进行刷新？是否会发生 OS 刷新命令传播到某个中间缓冲区而不传播到 HDD 盘的情况？今天，许多存储制造商和接口都支持乱序写入缓冲区。有什么影响？：您是否应该采取任何措施来抵消它？磁盘上的 ram 缓冲区重要吗？是否需要任何 UPS（以及哪些）来支持 RAM 缓冲区？

如果我有自己的“数据库”——将我的数据存储在纯文件中，我应该保证什么？我认为 DB 做得最好。什么是最好的，以便我可以做同样的事情来保证数据不会丢失？有简单的程序吗？是否有教授安全存储的课程？

Answer 1

你没有提到数据库平台，我可以提供有关 SQL Server 的见解。

SQL Server 使用称为 WAL 的概念确保持久性。提前写日志。这意味着在应用到数据文件之前，首先将所有更改写入日志。

当需要更改一行时。相应的数据（可能还有索引）页面从磁盘中提取到缓冲池（在内存中）。

在内存中，页面被更新，然后页面被标记为脏。完毕。但是当你停电时会发生什么？记忆被清除了吧？

为什么页面不立即写入磁盘？因为这可能会导致严重的磁盘争用。想象一下，你有一个有几百行的页面。如果每行更新都将页面写入磁盘，则会产生大量磁盘 IO。

因此使用了不同的机制。一种机制，每次在该页面上发生单个更新时不再需要将数据页面写入磁盘。

每当更新一行时，更改以及撤消更改的信息首先写入日志文件。完成后，发出更改的客户端会收到确认更改实际上已写入磁盘（已硬化）并且客户端可以继续执行下一条语句。

这样，当您断电时，数据库服务器再次启动后，可以从日志文件中读取所有已完成（已提交）的更改并仍然应用，并且可以撤消所有未完成或回滚的更改。

最终，如果所有那些脏的和挂在内存中的数据页都应用于数据文件，那会很好吗？对于初学者，您不希望在服务器重新启动后需要重新应用的日志文件中的几天更改。因此，脏数据页偶尔会刷新到数据文件中。这称为检查点。检查点发生的时间间隔取决于重新启动后恢复数据库所需的时间。（读取日志文件中的所有更改并将它们应用于数据文件所需的时间。但要理解的关键是数据页以及它们是否写入磁盘对于持久性并不重要。

回到日志文件。为了确保一旦 SQL Server 向操作系统发出日志文件写入 IO 请求，并且操作系统回复确认 IO 已被处理，它实际上确实已固化到磁盘而不是在操作系统缓存中徘徊，日志文件创建为以下标志：FILE_FLAG_WRITE_THROUGH。这告诉操作系统不要缓存将要发送到此文件的任何写入 IO。

- 更新

原子性是通过您的更改都包含在事务中这一事实来实现的。（隐式或显式）。因此，当您更新记录时，您至少有 3 条日志记录：

1. 开始传输

2. 更新记录 X

3. 提交传输

为简单起见，我们假设这 3 条记录在 3 个独立的 IO 中发送到磁盘。持久性规则规定，只有在 1、2 和 3 被硬化到磁盘时，客户端才能获得确认。

原子性规则规定要么应用完整的事务，要么不应用事务的任何步骤。所以在上面的例子中，如果你在 IO #2 被硬化到磁盘后出现故障。重新启动后，数据库服务器将查看事务日志。事务日志中所有尚未应用于数据文件且具有最终 COMMIT TRAN 记录的事务记录都将应用于数据文件。但是，对于上述事务，数据库服务器不会在日志文件中找到 COMMIT TRAN 记录。你可能不得不现在的情景。

1. SQL Server 在数据文件中查找是否已将 UPDATE RECORD X 应用于数据文件。（一种可能性可能是您在生成日志记录 2 之后和崩溃之前刚好有一个检查点。）在这种情况下，由于数据库服务器找不到提交记录，因此它假定整个事务最多被回滚. 它将撤消更改。由于您的客户端应用程序从未收到事务已提交的确认。您现在回到了一致的状态。应用程序必须重试事务。

2. SQL Server 查看数据文件并发现该事务的任何内容都没有应用于数据文件。它只会忽略这些日志记录。

--END 更新

大多数处理 IO 的现代硬件都有处理停电的机制。例如控制器卡缓存由电池备份，SAN 具有相同的原理。唯一要记住的是，即使它们确实具有这些机制，如果您的任何硬件允许您继续操作，即使电池不存在或出现故障，您也可以实施适当的错误事件监控并采取相应措施。

事务日志管理器以有保证的顺序将 IO 发送到操作系统。一旦硬件设备告诉操作系统 IO 已处理，这实际上意味着从那一刻起 IO 要么在电池备份缓存中，要么实际上在磁盘上。换句话说：IO 在断电后是可重现的。IO 硬件设备可能会以不同的顺序将 IO 写入物理磁盘以进行优化。但这对我们来说已经不重要了。

当您实现 SAN 级别镜像时，IO 排序是一个值得关注的问题。但那是另一个话题。

你自己的数据库是什么意思？您要开发自己的 RDBMS 吗？您至少需要以下 3 个核心概念：

1. 仅当将日志记录写入可以完全重现更改的磁盘或将更改本身写入磁盘时，才向客户端应用程序确认事务实际上已提交。（如果你不想实现像 WAL 这样的东西）

2. 为了强化写入文件，在文件初始化时实现 FILE_FLAG_WRITE_THROUGH 标志。确保 Windows 操作系统不缓存。

3. 使用具有电池备份缓存的硬件。并监控电池问题

可以在SQL Server I/O 白皮书 中找到详细的 SQL Server 信息。

有关 ACID 的更多信息。原子性、一致性、隔离性和持久性在这里