问题标签 [durability]

我有一个针对 SQL Server 2012 集群中的数据库运行的测试套件。我希望这个测试套件尽可能快地运行。我愿意为性能牺牲每一个持久性和可用性保证。每次测试运行期间都会重新创建数据库，因此它甚至不必在服务器重新启动后继续存在。

更改恢复模型ALTER DATABASE [dbname] SET RECOVERY SIMPLE没有明显的区别。

似乎是一个不错的选择DELAYED_DURABILITY，但这是 2014 年的新选项，因此我无法使用。

我该怎么做才能在这个集群上创建一个疯狂的快速数据库？我尝试寻找内存数据库，但找不到任何选项。集群不允许我在本地磁盘上创建数据库，坚持它必须位于集群磁盘上。

更新： 该应用程序使用高级 SQL Server 功能，所以我很可能被 MS SQL Server 卡住了。数据库本身很小，因为它用于测试（8MB mdf，1MB ldf）。集群节点是网络中最快的服务器，所以如果我可以将其中一个节点误用于内存数据库，那肯定是最快的。但是怎么做？

我正在使用 Couchbase .NET SDK 1.3。

任务是存储一个值，前提是其键下的数据自读取值以来未在数据库中修改，并确保新值持久/复制到一定数量的节点。对于修改检查，我想利用乐观锁定，即 Couchbase 的 CAS 方法。我需要同步等待，直到值的持久性/复制成功。

问题是 Couchbase SDK 提供了指定CAS 值或持久性要求的方法：

我需要将两者结合起来。还有Observe方法：

似乎这是我需要的，但我在任何地方都找不到它的文档。因此，特别是，我无法确定该方法是否等待该值被持久化/复制，或者只是在调用时检查该值。像这样使用这种方法是否有效？

我对如何正确使用 ActiveMQ 有点困惑。

我想要做什么

我有系统 A，它为虚拟主题生成消息。然后是系统 B 和 C，它们都使用来自同一个虚拟主题的消息。系统 B 或 C 可能会脱机。所以当他们重新上线时，我需要他们接收离线期间产生的所有消息。

到目前为止我尝试过的

我已阅读有关持久订阅者的信息（http://activemq.apache.org/how-do-durable-queues-and-topics-work.html和虚拟主题/队列和持久性）。这似乎符合我的问题描述，并且在做了一些实施之后，一切似乎都按照我最初想要的方式工作。

是什么造成了混乱

然后我阅读了订阅恢复政策 ( http://activemq.apache.org/subscription-recovery-policy.html )。这是我应该配置的东西还是我完全误解了一些东西？例如，如果我想存储指定数量的消息，我应该配置 aFixedCountSubscriptionRecoveryPolicy还是应该查看 some pendingMessageLimitStrategy？

我检查了RabbitMQ 教程的“消息持久性”部分。但它有这个注释：

将消息标记为持久性并不能完全保证消息不会丢失。虽然它告诉 RabbitMQ 将消息保存到磁盘，但是当 RabbitMQ 接受消息并且还没有保存它时，仍然有很短的时间窗口。此外，RabbitMQ 不会对每条消息都执行 fsync(2) ——它可能只是保存到缓存中而不是真正写入磁盘

但是如果我需要真正持久的队列怎么办？我可以使用哪些最佳实践？例如，如果消息在 2 分钟内没有被确认，我是否应该在数据库中有“队列”并通过 cron 进行一些“重新发送”？有没有更好的解决方案？

另外，如果我的消费者在处理完消息之后发送 ACK 之前崩溃了怎么办？

UPD：我的问题被标记为聚类问题的“可能重复”。我不知道集群如何帮助解决这些问题。

如果整个谷歌数据中心遭遇灾难性断电，本地 SSD 上的数据会怎样？当计算引擎实例最终重新上线时，它是否还会在本地 SSD 上保留数据？它似乎可以很好地处理计划的停机时间：

无计划停机：即使没有复制或冗余，Google 进行数据中心维护时本地 SSD 数据也不会丢失。在进行任何计划内维护之前，我们将使用我们的实时迁移技术将您的虚拟机及其本地 SSD 移动到新机器上，这样您的应用程序就不会中断，您的数据也不会丢失。

但我担心计划外停机。磁盘故障是一个永远存在的风险，但如果您将本地 SSD 与复制结合起来，您可以防范这种情况。但是，我试图防止相关故障，例如整个区域变暗。那么内存中的复制数据会丢失，但是当实例恢复时，fsync 到本地 SSD 的数据是否可能仍然存在？如果你丢失了它，那么将数据同步到本地 SSD 确实不会比 RAM 更安全 - 例如，用于运行本地数据库实例或其他东西。

以下代码保证任何给定的文档都将以持久的方式保存到 Couchbase 集群中的活动节点，并复制到 1 个附加节点：

鉴于 Couchbase 视图最终是一致的，在编写文档后调用视图时（确保文档出现在视图中），我似乎有 2 个选项来保证一致性：

选项1

将上述代码中的值更改replicateTo为等于集群中附加节点的总数（减去活动节点），确保每个节点都包含文档的副本：

选项 2

使用标准Upsert函数保存文档，但调用 View 并stale-mode设置为after-update

是否有任何替代方法可以以尽可能高效的方式实现这一目标？本质上，我希望文档在保存后立即出现在所有相关视图中。

我想确保某些类型的消息不会丢失，因此我应该使用Confirms (aka Publisher Acknowledgements)。

如果代理在将所述消息写入磁盘之前崩溃，则会丢失持久消息。在某些情况下，这会导致经纪人以令人惊讶的方式行事。

例如，考虑这种情况：

• 客户端将持久消息发布到持久队列
• 客户端使用队列中的消息（注意消息是持久的并且队列是持久的），但尚未确认它，
• 代理死亡并重新启动，并且
• 客户端重新连接并开始使用消息。

此时，客户端可以合理地假设消息将被再次传递。情况并非如此：重新启动导致代理丢失了消息。为了保证持久性，客户端应该使用确认。

但是，如果使用确认，发布者在收到确认之前就宕机了，并且由于某种原因（即网络故障）消息没有传递到队列中。

假设我们有一个简单的 REST 端点，我们可以在其中发布新的评论，并且当创建新的评论时，我们希望在队列中发布一条消息。（注意：如果我发送一条新评论的消息，例如由于回滚而最终没有创建，这并不重要）。

当服务器重新启动时，通道消失了，消息永远无法传递。我想到的一种解决方案是，在重新启动后，在存储库中查询最近的评论（类似于崩溃前最后 3 分钟之间创建的评论？），并为每个评论发送一条消息并等待确认。

我们已经使用 activemq 实现了持久化机制，因为它内置了在 SQL 数据库中存储消息的支持。

但是我们要求使用rabbitmq将消息存储在SQL中，但经过一些研究，我们无法找到任何强有力的支持或帮助。

任何建议都会对我们有很大帮助。

设置 log.flush.interval.messages=1。刷新是异步的还是同步的？这样，当producer client得到ack后，就说明这个消息是durable还是不持久的呢？

我有一个包含数千个文件的应用程序正在更新。应用程序需要定期将更改提交到磁盘，目前我正在调用fdatasync()，这需要大量时间（分钟）。[减少正在写入的文件数量不是我的选择。]

同时，我注意到如果我从命令行运行sync命令，它会明显更快地返回。从文档看来，它似乎可以保证所有挂起的写入都到达磁盘。

问题是：sync()系统调用是否提供与多次调用相同（或更强）的持久性保证fdatasync()？如果没有，有没有办法fsync()一次调用多个文件描述符？