标签: wal

我已经阅读了很多关于ios7 SQLite/Core Data堆栈中新的WAL默认设置的主题.

首先它看起来是个好主意......虽然我需要根据我的业务需求不时地向远程Web服务执行数据库副本.目前我只备份SQLITE文件,我无法将其他2个文件添加到我正在使用的webservice操作中.这意味着我的备份显然不是最新的,因此毫无意义.

其他人建议我应该使用journal_mode = DELETE(NSSQLitePragmasOption)禁用WAL,这对我来说是一个可接受的解决方法.不过,我对此并不满意.感觉就像我错过了相当不错的表现.

理想情况下,我希望能够告诉Core Data/SQLite将SHM/WAL同步到主数据文件,然后执行备份.有没有办法在不挖掘疯狂的私有或未记录的API的情况下这样做？

我正在尝试创建一个将日志模式设置为 WAL 的数据库，并通过将锁定模式设置为 EXCLUSIVE 来禁用共享内存，但我似乎无法使其工作。

我的连接字符串如下所示：

_connectionString = string.Format("Data Source={0};Synchronous=Off;Journal Mode=WAL; PRAGMA locking_mode=EXCLUSIVE", _databasePath);

当我启动应用程序并创建数据库时，我仍然得到一个 shm 文件，我的印象是使用 EXCLUSIVE 作为锁定模式时不会发生这种情况。我还可以在多个应用程序中打开数据库，因此似乎没有设置独占锁。

如果有人能解释一下这种情况，我将不胜感激。

编辑说我正在使用 System.Data.SQLite v-1.0.74.0，它正在使用 SQLite v-3.7.7.1，因此应该在 WAL 模式下禁用共享内存。

我正在尝试配置 PostgreSQL 9.6 数据库以限制 pg_xlog 文件夹的大小。我已经阅读了很多关于这个问题或类似问题的主题，但我尝试过的任何内容都没有帮助。

我为我的 Postgresql 9.6 服务实例编写了一个安装脚本。它执行 initdb，注册 Windows 服务，启动它，创建一个空数据库并将转储恢复到数据库中。脚本完成后，数据库结构很好，数据在那里，但 xlog 文件夹已经包含 55 个文件 (880 mb)。

为了减小文件夹的大小，我尝试将 wal_keep_segments 设置为 0 或 1，将 max_wal_size 设置为 200mb，减少 checkpoint_timeout，将 archive_mode 设置为 off 和 archive_command 为空字符串。当我查询 pg_settings 时，我可以看到属性设置正确。

然后我通过 SQL 强制检查点，清空数据库，重新启动 Windows 服务并尝试 pg_archivecleanup，没有任何效果。我的 xlog 文件夹缩小到 50 个文件（800 mb），远不及我在配置中设置的 200 mb 限制。

我不知道还有什么可以尝试的。如果有人能告诉我我做错了什么，我将不胜感激。如果需要更多信息，我很乐意提供。

非常感谢

我们的 postgresql 数据库（版本 11）实例中有两个逻辑复制槽，我们使用 pgJDBC 从这两个槽传输数据。我们确保定期发送反馈并将两个插槽的confirmed_flush_lsn（每10分钟）更新到同一位置。然而，从我们的数据中我们可以看出，两者的 restart_lsn 动作并不同步，并且大多数时候其中一个落后太多，无法不必要地保存 WAL 文件。以下是一些数据点来表明问题

Thu Dec 10 05:37:13 CET 2020
                      slot_name       |  restart_lsn  | confirmed_flush_lsn 
--------------------------------------+---------------+---------------------
 db_dsn_metadata_src_private          | 48FB/F3000208 | 48FB/F3000208
 db_dsn_metadata_src_shared           | 48FB/F3000208 | 48FB/F3000208
(2 rows)



Thu Dec 10 13:53:46 CET 2020
                      slot_name      |  restart_lsn  | confirmed_flush_lsn 
-------------------------------------+---------------+---------------------
 db_dsn_metadata_src_private         | 48FC/2309B150 | 48FC/233AA1D0
 db_dsn_metadata_src_shared          | 48FC/233AA1D0 | 48FC/233AA1D0
(2 rows)


Thu Dec 10 17:13:51 CET 2020
                      slot_name      |  restart_lsn  | confirmed_flush_lsn 
-------------------------------------+---------------+---------------------
 db_dsn_metadata_src_private         | 4900/B4C3AE8  | 4900/94FDF908
 db_dsn_metadata_src_shared          | 48FD/D2F66F10 | 4900/94FDF908 …

概括

我们max_slot_wal_keep_size从 Postgresql 13 开始使用来防止 master 被滞后的复制杀死。看来，在我们的例子中，WAL 存储在超过此参数后没有被释放，从而导致复制失败。正如我所认为的，WAL 应该被释放，但似乎没有任何其他事务一次需要它。我想知道这应该如何工作以及为什么 WAL 段没有被删除？

请在下面找到详细信息。

配置

• 主服务器和一个副本 - 使用插槽进行流式复制
• ~700GB 可用于 pg_wal
• max_slot_wal_keep_size = 600GB
• min_wal_size = 20GB
• max_wal_size = 40GB
• 默认checkpoint_timeout= 5 分钟（检查点没有问题）
• 存档已开启并且进展顺利

发生了什么

在重负载（大型 COPY/INSERT 事务，加载数百 GB 数据）下，复制开始落后。pg_wal 上的可用空间以与 safe_slot 相同的速度减少pg_replication_slot.safe_wal_size- 正如预期的那样。在某些时候safe_wal_size出现负值并且流媒体停止工作。这不是问题，因为副本开始从 WAL 存档恢复。我预计一旦槽丢失，WAL 将被删除最多max_wal_size. 但这并没有发生。看来 Postgres 试图维持接近max_slot_wal_keep_size(600GB) 的可用容量，以防副本再次开始追赶。随着时间的推移，没有任何一笔交易需要保留这么多的 WAL。归档也不落后。

• Q1： PG 是否会尝试维护max_slot_keep_sizeWAL 可用？
• Q2：如果不是，为什么当归档程序和系统上运行的任何事务都不需要过多的 WAL 时，PG 不删除它们？

大部分时间 pg_wal 上的可用空间量大约为 70GB，但是在某些时候，在大量自动清理期间，它下降到 0 :( 这是 …

如果使用预写日志记录的 SQLite 数据库被未检查点的事务中断（由于电源故障或其他原因），然后在缺少临时 -wal 文件的情况下重新打开，数据库是否会干净地打开到最后一个检查点时的状态，或者它会以某种方式被损坏吗？

我们正在尝试让 SQLite 与 iCloud 配合使用（是的，我们知道你不应该这样做，但我们也制作了 Windows 和 Android 应用程序，并且需要一个跨平台数据库解决方案），并且我们认为 WAL 提供了避免维护数据库的两个副本的潜在方法 - 我们将 -wal 文件保留在 iCloud 之外，但将主数据库存储在其中，从而避免 iCloud 备份回滚日志（或中途备份数据库）的问题没有这些日记帐的交易）。

假设我pg_dump在进行大规模的破坏性迁移之前对Postgres 9.3数据库进行了快速备份转储,我发现我想撤消它.在此期间没有对DB执行任何写入操作.

假设我运行pg_restore -c -d mydb < foo.dump将转储加载回数据库.假设我已经设置WAL-E来存档每个16mb的WAL,我是否需要archive_mode在执行恢复之前关闭？当我将转储写回数据库时,归档xlog对我来说是非常有用的,因为我已经在转储之前已经存档了完全有效的基本备份和WAL段.当我恢复转储时,执行xlog传输也会产生严重后果,因为转储的大小会变得更糟.

在恢复之前,您最终会禁用存档吗？你还做其他什么来加快速度吗？在这篇文章中讨论了恢复性能,但它根本不涉及归档,除非我遗漏了一些东西.

我一直在通读Postgres 手册的WAL 章节，但对这一章的一部分感到困惑：

使用 WAL 会显着减少磁盘写入次数，因为只需将日志文件刷新到磁盘以确保提交事务，而不是事务更改的每个数据文件。

与简单地写入表/索引数据本身相比，连续写入 WAL 的性能如何？

在我看来（暂时忘记了 WAL 的弹性优势）postgres 需要完成两个磁盘操作；首先 pg 需要在磁盘上提交 WAL，然后您仍然需要更改表数据以与 WAL 一致。我确信我误解了这其中的一个基本方面，但似乎在客户端事务和表数据的最终状态之间添加一个额外的步骤实际上并不能提高整体性能。提前致谢！

我似乎找不到任何与我想做的事情相关的东西。是否可以按模式分离 Postgres WAL 文件？

在阅读 postgreSQL 文档时：

当写入每个新记录时，WAL 记录会附加到 WAL 日志中。插入位置由日志序列号 (LSN) 描述，它是日志中的字节偏移量，随着每个新记录单调增加。LSN 值以数据类型 pg_lsn 返回。可以比较值来计算分隔它们的 WAL 数据量，因此它们用于衡量复制和恢复的进度。

我们可以相信这个序列号是严格单调的吗？是否存在某个时间点，该偏移量会重置到先前的位置（由于 WAL 存档或其他类型的操作）？