问题标签 [wal]

在 WAL 的原始文档中，明确说明了FULL和同步之间的区别¹：NORMAL

写入事务非常快，因为它们只涉及写入一次内容（相对于回滚日志事务两次）并且因为写入都是顺序的。此外，不需要将内容同步到磁盘，只要应用程序愿意在断电或硬重启后牺牲耐用性。（如果 PRAGMA 同步设置为 FULL，则写入器在每次事务提交时同步 WAL，但如果 PRAGMA 同步设置为 NORMAL，则忽略此同步。）

但是我在任何地方都找不到PRAGMA synchronous = OFFWAL 模式的效果。我怀疑它与NORMAL. 有人有知情的答案吗？

我正在使用 WAL E 并尝试恢复 postgresql 数据库我收到错误 WAL file is from different database system: WAL file database system identifier is 6422218584094261886, pg_control database system identifier is 6338745400937582833

如何强制 postgresql 数据库使用 WAL 存档的数据库标识符或强制 WAL 存档使用数据库的数据库系统标识符

由于 Bulkload 方法完全绕过了写入路径，WAL 不会作为进程的一部分被写入，因此在区域服务器故障/崩溃的情况下如何恢复批量加载的数据？

我在使用这些标志编译的 WAL 模式下使用 SQLite 3：

我有一个带有一堆插件的 Mac 应用程序（每个插件都在自己的进程中）随机访问数据库并进行修改。所有进程都链接到使用自定义 SQLite 代码构建的同一个共享库。文档说多个进程可以随时读取，但实际上只有一个进程可以进行修改。这是否意味着我需要以某种方式编排和协调进程之间的写入？

我问是因为自从我采用 WAL 以来，我经常看到有关格式错误的数据库的报告。这似乎主要发生在一个进程在打开一个连接后崩溃（不管它是否用SQLITE_OPEN_READONLY标志打开）并且另一个进程已经打开了一个连接或稍后打开了一个连接。我不能总是可靠地重现这一点，但它似乎与一个进程创建的 -shm 和 -wal 索引文件有关，而另一个进程要么在内存中有自己的副本，要么产生了一些不匹配不知何故。不应该是这种情况，但可能是新进程使用的 -shm 文件以某种方式修改它（或 .db 文件）而没有第一个进程发现，从而导致数据库损坏（如前所述在如何损坏 SQLite 的 2.4 下）？

我唯一的猜测是让两个进程写入同一个数据库是这些损坏实例的根本原因。如果这是真的，我们如何在没有复杂的进程间通信的情况下在两个独立的进程之间进行协调？有任何想法吗？我不想诉诸使用，journal_mode=DELETE因为我有一个高度多线程的应用程序，否则它会从并发读取器和单个写入器中受益。

顺便说一句，这就是我打开阅读器的方式（多个阅读器同时由多个线程打开）：

这就是我打开作家的方式（单个进程存在一个作家）：

在关闭作家之前，我总是运行以下检查点：

编辑：我发现了另一种奇怪的行为，不确定这是否相关。SQLITE_OPEN_READWRITE如果我用而不是打开我的阅读器，则在调用连接后会正确删除SQLITE_OPEN_READONLY-shm 和 -wal 文件。如果我切换回，我会看到 -shm 和 -wal 文件永远不会被删除，即使进程完全关闭也是如此。我在我的一个插件中使用只读模式（这似乎主要导致损坏，特别是在它退出或使用插件的主机应用程序崩溃等情况下），我看到了这种行为变化。我想知道这是否表明 SQLite 中存在错误，或者只是我不知道的一些行为。我很乐意切换到读写模式并使用sqlite3_close_v2(...)SQLITE_OPEN_READONLYPRAGMA query_only如果这不会在锁定方面破坏 SQLite 中的任何其他内容，那么实际上我所有的读者实际上都是作家，但从不进行任何修改。

关于 postgresql WAL 文件名，以下限制是什么？

• 时间线
• 日志文件
• 部分

我的理解是该段限制为 00..FF（包括边界）。

例如，下面的 WAL 可以由 postgresql 生成吗？

更新：

从那以后，我在 postgresql 源代码中发现了以下内容：

它允许从数据存储值 0x00000000..0xFFFFFFFF

我正在尝试了解我在 PostgreSQL 环境中的 wals 行为。我的沃尔设置是：

我的 wals 目录是/PostgreSQL-wal/9.6/pg_xlog/，我的档案目录是PostgreSQL-wal/9.6/pg_xlog/wal_archives. 昨晚我的 wals 目录存储已满（存档目录也因为它们在同一个文件系统上）。

我的 wals 目录中现在有 211 个 wals：

唯一在夜间运行的只是从我们的监控代理中选择的。我猜想 wal 是因为 archive_timeout 非常低而被创建的，而它们被删除是因为 wal_keep_segments 很高。

今天早上，我将 wal_keep_segments 设置为 100，并将 archive_timeout 设置为 6 分钟。现在，在设置这些设置并启动集群 wals 开关后工作正常，我没有看到创建了很多 wals。但是，不应该自动删除旧的wals吗？我可以安全地删除档案吗？

我们有一个 OrientDB 图形数据库和一个每日调度程序，它使用 Java API 在数据库中执行大量插入。出于这个原因，我们希望在执行这些插入时从 Java 代码中禁用 WAL，否则 WAL 文件的大小将在短时间内变得巨大。

我们已经知道可以通过编辑一些 OrientDB 配置来永久禁用 WAL，但我们不想做出这个选择。

我们在 OrientDB 的 github 存储库上看到了一个已关闭的 issue，它提出了以下解决方案：

问题是我们在打开与数据库的连接时没有使用 ODatabaseDocumentTx 的实例。实际上，由于我们使用的是图形数据库，因此我们通过以下方式使用 OrientGraphFactory：

可以通过以下方式获取 ODatabaseDocumentTx 的实例：

但是，在关闭 ODatabaseDocumentTx 的实例之后，就无法重新打开与我们的图形数据库的连接。

有什么建议么？

请耐心等待我 - 我将尝试在这个问题中使用正确的术语。我有一个 iOS 应用程序，它允许用户创建他们支持 Core Data 的 .sqlite 数据库的备份已有好几年了。出于某种原因，早在何时，我将 journal_mode 的 pragma 选项设置为“MEMORY”，这意味着过去几年所做的每个备份都没有 WAL 或 SHM 文件。我正在重写我所有的数据库代码，并且我知道 iOS 的当前默认 journal_mode 是“ WAL或者我可以做些什么让它在 WAL 模式下运行。我希望这是有道理的——这让我有点困惑，但我会很感激关于如何解决这个问题的任何想法。

我们有一个基于 HBase 的系统，我们希望在生产中每天批量加载几百万行。我们认为与 puts 相比，HBase Bulk Load将是一个不错的选择——批量加载功能使用 MapReduce 作业以 HBase 的内部数据格式输出表数据，然后将生成的 StoreFiles 直接加载到正在运行的集群中。与简单地使用 HBase API 相比，使用批量加载将使用更少的 CPU 和网络资源。我们已经对此进行了评估，并且效果很好。参考指南中的以下部分讨论了限制：

72.2。批量加载限制 由于批量加载绕过了写入路径，WAL 不会作为进程的一部分被写入。复制通过读取 WAL 文件来工作，因此它不会看到批量加载的数据——使用 Put.setDurability(SKIP_WAL) 的编辑也是如此。处理该问题的一种方法是将原始文件或 HFile 发送到另一个集群并在那里进行其他处理。

这是一个大问题，因为我们要使用高可用性。我们还发现了另一个 JIRA HBASE-13153，这表明修复后复制工作正常。

问题：

1. Bulk Load 是否用于生产用途？
2. HBase 文档是否已过时并且限制现在已解决？
3. 使用批量加载还有其他限制吗？如果是，首选方法是什么？

我在这里找到了报价

PostgreSQL 是依赖预写日志 (WAL) 的数据库之一——所有更改首先写入日志（更改流），然后才写入数据文件。这提供了持久性，因为在崩溃的情况下，数据库可能会使用 WAL 执行恢复——从 WAL 读取更改并将它们重新应用于数据文件。

从这篇文章https://blog.2ndquadrant.com/basics-of-tuning-checkpoints/

假设有 WAL 文件继续跟踪查询

UPDATE page SET view_count = view_count + 1;

我可以想象这样的情况，postgres 已经将此 WAL 应用于 DB，但它在应用后立即崩溃。

DB 还没有更新最新的 WAL 位置，也没有删除 WAL 日志文件。

当 DB 启动时，它会进行恢复并再次重新应用此 WAL，不是吗？数据库中的最终值会变成view_count + 2吗？

请指教