问题标签 [durability]

对不起，标题不是很明显，但我不能更好地用词。

我们现在使用传统的数据库（oracle）作为我们的作业队列，这些“作业”被一些节点（机器）消耗。所以数据库服务器受到这些节点的打击，我们不得不为这个数据库服务器的软硬件付出很多。

现在，前几天我突然想到，

1）系统中已经有多个节点
2）“作业”可能不会因为节点故障而丢失，但没有理由它们必须坐在辅助存储中（没有理由它们不能驻留在内存中，只要他们没有丢失）

鉴于此，难道不能将这些作业保留在内存中，确保整个集群中至少存在 n 个该作业的副本，从而摆脱数据库服务器吗？

有这样的技术吗？

更具体地说，是否有任何数据库不需要辅助存储（例如 HDD）来提供持久性？

注意：这是我之前的问题的跟进。

Amazon S3 提供两种计划：

存储（设计用于 99.999999999% 的耐用性）

和

减少冗余存储（设计用于 99.99% 的耐用性）

旨在在给定年份内提供 99.999999999% 的持久性和 99.99% 的对象可用性。

这是链接

因此，如果我有 10 000 个文件，我可以期望在第二个计划中平均每年丢失一个文件？我的解释正确吗？

编辑：也许我必须更清楚地说：

您如何解释特别是“设计为”部分。例如，如果提供 99,9% 的可用性，我保证并为每小时或类似的事情支付罚金。但是，如果我将系统设计为 99.9% 的可用性，我会在知道系统停机时间平均为 0.1% 的情况下选择部件。

这并不一定意味着我保证什么。它正是该系统的设计目的......

我在使用 ActiveMQ-CPP 和 stomp 协议创建持久的消费者和生产者时遇到问题。我正在尝试使用 stomp 连接到 HornetQ，并且能够在非持久状态下发送和接收消息。我尝试通过将其传递模式以及消息的 CMSDeliveryMode 设置为持久，并创建一个 DurableConsumer 而不是普通消费者，将生产者更改为持久。但是当我查看 JBoss JMX-Console 时，它​​们都被认为是非持久的（消息被归类为非持久的，消费者也被订阅为非持久的）。

我什至尝试了集成测试 StompDurableTest 并且只收到了 20 条消息中的 10 条（当消费者处于活动状态时发送的消息）。所以测试失败了。

由于集成测试不起作用，我猜它与 ActiveMQ-cpp 或 Stomp 配置有关，而不是代码。我是否缺少任何东西来启用耐用性？

提前致谢，

萨米人

我检查了 Redis，我很好奇数据库（将所有数据存储在易失性内存中）如何在系统崩溃情况下提供数据持久性。

我已经研究了很多如何在数据库中实现持久性，如果我理解得很好，它的工作原理是这样的（简化的）：

克伦特观点：

1. 开始交易。
2. 插入表值...
3. 提交事务

DB引擎观点：

1. 将事务开始指示器写入日志文件
2. 将客户端所做的更改写入日志文件
3. 将事务提交指示符写入日志文件
4. 将日志文件刷新到 HDD（这确保了数据的持久性）
5. 向客户端返回“OK”

我观察到的：

客户端应用程序是单线程应用程序（一个数据库连接）。我能够执行 400 个事务/秒，而将某些内容写入文件然后将此文件 fsync 到 HDD 的简单测试仅执行 150 个同步/秒。如果客户端是多线程/多连接，我会想象数据库引擎对事务进行分组并每几笔事务执行一次 fsync，但事实并非如此。

我的问题是，例如，MsSQL 是否真的在每次事务提交时同步日志文件（fsync、FlushFileBuffers 等），还是背后有其他某种魔法？

我读过 mongoDB 不会立即将数据写入磁盘，它会定期执行此操作。

关于如何处理这个问题的任何想法？

ACID 中的“D”表示“持久性”，维基百科将其定义为：“每个提交的事务都受到保护，免受断电/崩溃/错误的影响，并且不会被系统丢失，因此可以保证完成”。

但是，这意味着在报告成功之前，每个事务都必须同步到磁盘，而不仅仅是刷新。（'flush'=发送到操作系统级别，'sync'=发送到物理磁盘盘片）。这将使得不可能实现高事务率的 RDBMS。

流行的 RDBMS 真的会同步每笔交易吗？

MongoDB 具有可配置的持久性：在执行更新操作时，您可以指定“写入关注点”来告诉系统您希望仅在数据（例如）已刷新到磁盘并复制到 X 从属服务器时才认为更新完成.

是否有任何关于不是当前更新的保证，而是之前的写入？如果我想更新三个文档，我是否必须在所有文档上标记昂贵的写入关注点，或者仅使用最后一个操作发布它就足够了？

此外，使用连接池（即通过三个不同的连接完成三个更新）和分片（即影响多个分片的三个更新）是否会影响这种推理？

这是我的看法，不知道是对是错：

日记日志是“重做”日志。它记录数据文件的修改。

比如我想把一条记录的字段值从'a'改成'b'，那么mongodb会找到怎么修改dbfile（包括所有的命名空间、数据、索引等），然后mongodb写对期刊的修改。

之后，mongodb 对 dbfile 进行所有真正的修改。如果这里出现问题，当 mongoDB 重新启动时，它将读取日志（如果存在）。然后它将更改 dbfile 以使数据集保持一致。

所以，在日志中，没有记录要更改的数据，而是记录了如何更改dbfile。

我对吗？我在哪里可以获得有关期刊格式的更多信息？