问题标签 [journaling]

我想每天备份单个 mongodb 数据库，可能使用 mongodump。为了不丢失任何数据，我希望这是增量的，所以如果在一天中间出现问题，我需要能够在执行 mongorestore 后重播当天的更改，直到故障点。

我是否正确理解我需要为此使用oplog？还是记录答案？我尝试执行以下操作：

1. 将我的 mongo 数据库变成只有一个的副本集，以便它创建一个 oplog。（这感觉很hacky）
2. 使用 --oplog 选项重新启动 mongod
3. 执行应记录在 oplog 中的更改

然而，没有任何东西存储在 oplog 中。进行此类增量备份的最佳方法是什么？我基本上是在寻找一种类似的方法来重放 mysql binlog。

谢谢

在Writeback 模式下，只有 inode 数据写入日志，并且无法控制何时写入文件数据。

这一行让我想到了在正常情况下何时将数据写入设备以及何时丢失数据。

在写回模式下，是否有任何选项可以在日志记录后立即将数据强制写入设备，从而保证与有序模式提供的相同安全性？

另外，Writeback 模式和Ordered 模式是否仅基于此进行区分？

从本地设备测试中，我看到将文件写入 iOS 文件系统（无论您使用的调用级别如何）通常会在文件完全提交到闪存之前返回成功。这意味着，如果您硬重置设备然后重新启动，您的文件可能会回滚（如果写入完成或是原子的）或损坏。这种延迟的原因是什么（感谢文档，我找不到任何东西），有没有办法在实际文件系统写入完成时获得反馈。例如，我想确认从远程服务器接收并存储了一条数据，但我发现在写入“报告”成功后确认它可能会在发生硬崩溃或电源故障时导致数据丢失。

开发 ac# 应用程序，该应用程序将根据用户上传的文件运行一系列任务；这可能需要几秒钟到几天的时间。如果进程中断，我计划实施某种日志系统以恢复工作。什么是中断/恢复日志，我在哪里可以了解有关现有实现的更多信息？

编辑：

到目前为止我发现的有用的东西：

日志文件系统将使用相同的基本过程，但需要一些额外的步骤。就像是：

• 日记条目：将文件从 A 移动到 B
  • 将旧文件物理复制到新位置
  • 更新新驱动器上的目录条目
  • 从旧驱动器中删除目录条目
  • 旧驱动器上的可用空间
• 日记条目：完成将文件从 A 移动到 B

来自https://serverfault.com/questions/173176/what-is-a-journaling-file-system

检查点：将日志元数据和数据写入其固定位置的过程称为检查点。当超过各种阈值时触发检查点，例如，当文件系统缓冲区空间不足时，当日志中剩余的可用空间很少时，或者当计时器到期时。

崩溃恢复：在 ext3 中，崩溃恢复很简单（就像在许多日志文件系统中一样）；使用重做日志的基本形式。因为新的更新（无论是数据还是元数据）被写入日志，恢复就地文件系统结构的过程很容易。在恢复期间，文件系统扫描日志以查找已提交的完整事务；不完整的交易被丢弃。已完成事务中的每次更新都会简单地重播到固定位置的 ext2 结构中。

来自http://research.cs.wisc.edu/adsl/Publications/sba-usenix05.pdf（第 5 页）

编辑2：

与我第一次发布这个问题时相比，我觉得我对容错的了解并不多，但这里是我实现的概要。

Main 首先尝试让作业管理器从文件加载任何现有的已保存状态，或者创建一个新的空管理器。

JobManager 类看起来像这样

注意事项：

• 这是不完整的代码，以防有人试图复制它（缺少基类和东西）
• 常规（二进制）和 XML 序列化从未完全正常工作，因此我实现了将对象保存为 XML 的自定义序列化。这是ToXElement()方法，也是接受XElement参数的构造函数。
• 序列化的顶层 (JobManager) 包含一个校验和 (SHA-256)。当从 实例化新对象时XElement，将保存的序列化对象的校验和与文件中的校验和进行比较。
• 有一个静态方法.Load(file)通过读取文件并尝试反序列化内容来返回一个新的 JobManager 对象。
• 此处未显示自定义 ConcurrentQueue 类。这是 MSDN ConcurrentQueue类的包装器，但添加了一个事件以在队列更改时进行通知。
• 这个 JobManager 类实现了一个带有上述 ConcurrentQueue 的基类；那些队列更改事件挂在构造函数助手中
• 当事件触发时，JobManager 设置一个标志_isDirty
• JobManager 在实例化时启动一个线程，它监视_isDirty标志。大部分时间都花在睡眠上，但如果至少_minTimeToSave已经过去，JobManager 的内容将被序列化到磁盘。这应该可以防止 JobManager 过于频繁地写入磁盘。

未解决的注意事项：

• 线程真的是观看_isDirty标志的正确解决方案吗？
• JobManager（单线程）管理包含任务的作业（一次一个，但不同的线程）；序列化时没有类到基类同步来锁定状态
• 旧的已完成作业被序列化到磁盘，然后重新加载

背景： 我在带有 Ext4 文件系统的 CentOS 6.3(Final) 64bits 上安装了 2 个 rpm 包 -

• mongo-10gen-2.2.1-mongodb_1.x86_64.rpm
• mongo-10gen-server-2.2.1-mongodb_1.x86_64.rpm

现象： mongod第一次启动时，指定文件夹中没有创建预分配的日志文件。顺便说一句，日志选项默认启用。

问题： 是不是正常情况？我查看了MongoDB手册。它声称

如果不存在日志文件，当 mongod 启动时，它必须预先分配新的日志文件

我在下面发布了与 mongod 相关的 mongo.conf -

配置：

提前致谢。

各位程序员好。

我正在尝试使用WinIoCtl函数转储NTFS分区的 USN 日志的内容。我有 *USN_JOURNAL_DATA* 结构，它告诉我它的最大大小为 512 MB。我已经将它与fsutil所说的进行了比较，它的价值是相同的。

现在我必须将每个条目读入 *USN_RECORD* 结构。我在一个从 0 开始的 for 循环中执行此操作，并以 4096（簇大小）为增量达到日志的最大大小。我在相同大小的缓冲区中读取每个 4096 字节，并从中读取所有 USN_RECORD 结构。

一切都很好，文件名正确，时间戳，原因，一切，除了我似乎错过了一些最近的记录。我在分区上创建了一个新文件，在其中写入了一些内容，然后删除了该文件。我再次运行该应用程序并没有出现记录。我发现只有当我继续阅读超过期刊的最大尺寸时才会出现记录。怎么可能？

目前我正在从期刊数据的开头读取到最大大小+分配增量（两者都是存储在 *USN_JOURNAL_DATA* 结构中的值），我不认为它是正确的，我很难找到彻底与此相关的信息。

有人可以解释一下吗？USN 日志周围是否有类似于MFT工作方式的缓冲区（这意味着当其他文件需要磁盘空间时，它的大小减半）？

我究竟做错了什么？

我的情况：我与许多 RPG 程序员一起工作，他们在 IBM-i 上以不创建日志的方式创建文件。我创建了一个 Grails 应用程序，它使用 db2 jdbc 驱动程序连接到文件并更新、插入等。我收到一个错误：

我知道我可以开始用 STRJRNPF 记录文件，但我不想跟上它（请不要责骂）。是否有我可以设置的 db2 jdbc 连接 url 的参数让它知道不要尝试提交？

这是我当前的连接信息：

编辑：这是我尝试过的：

我正在使用 Access 数据库，并找到了跟踪通过表单所做的更改的工具。我知道无法直接通过表跟踪所做的更改，但我很难确定是否可以跟踪通过 SQL 更新语句所做的更改？我猜这是不可能的，但如果有人对如何做到这一点有想法，将不胜感激。也许通过宏？

谢谢！

我一直在阅读一些关于 MongoDB 容错的文章，有些人抱怨它永远无法用 MongoDB 真正实现（比如这篇文章：http ://hackingdistributed.com/2013/01/29/mongo-ft/ ），这让我感到困惑。

有人可以确认（如果可能的话，向我展示适当的文档）使用 Write Concern“Journal + Majority”足以确保 100% 的驱动程序报告为成功的写入是持久写入的并且不会即使任何副本在写入后失败，也会丢失？

我说的是 3 副本设置。我对系统在发生故障时不再接受写入感到满意，但是当驱动程序报告写入成功时，我需要将其持久提交（无论之后失败的副本数量如何）。

If I set journal_size_limit = 67110000 (64 MiB) will I be able to:

1. work with / commit transactions over that value (somewhat unlikely)
2. be able to successfully perform a VACUUM (even if the database has like 3 GiB or more)

The VACUUM command works by copying the contents of the database into a temporary database file and then overwriting the original with the contents of the temporary file. When overwriting the original, a rollback journal or write-ahead log WAL file is used just as it would be for any other database transaction. This means that when VACUUMing a database, as much as twice the size of the original database file is required in free disk space.

It's not entirely clear in the documentation, and I would appreciate if someone could tell me for sure.