PostgreSQL 10.1 手册_部分 III. 服务器管理_第 19 章 服务器配置_19.5. 预写式日志

本文涉及的产品
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
日志服务 SLS,月写入数据量 50GB 1个月
简介: 19.5. 预写式日志 19.5.1. 设置 19.5.2. 检查点 19.5.3. 归档 参阅第 30.4 节获取调节这些设置的额外信息。 19.5.1. 设置 wal_level (enum) wal_level决定多少信息写入到 WAL 中。

19.5. 预写式日志

参阅第 30.4 节获取调节这些设置的额外信息。

19.5.1. 设置

wal_level (enum)

wal_level决定多少信息写入到 WAL 中。默认值是replica, 它写入足够的数据以支持WAL归档和复制,包括在备用服务器上运行只读查询。 minimal删除除了从崩溃或立即关闭中恢复所需的信息之外的所有日志记录。 最后,logical会增加支持逻辑解码所需的信息。每个层次包括所有更低层次 记录的信息。这个参数只能在服务器启动时设置。

minimal级别中,某些批量操作的 WAL 日志可以被安全地跳过,这可以使那些操作更快(见第 14.4.7 节)。这种优化可以应用的操作包括:

CREATE TABLE AS
CREATE INDEX
CLUSTER
COPY到在同一个事务中被创建或截断的表中

但最少的 WAL 不会包括足够的信息来从基础备份和 WAL 日志中重建数据,因此,要启用 WAL 归档(archive_mode)和流复制,必须使用replica或更高级别。

logical层,与replica相同的信息会被记录,外加上 允许从 WAL 抽取逻辑修改集所需的信息。使用级别 logical将增加 WAL 容量,特别是如果为了REPLICA IDENTITY FULL配置了很多表并且执行了很多UPDATEDELETE 语句时。

在9.6之前的版本中,此参数还允许值archive和 hot_standby。这些仍然被接受, 但映射到replica

fsync (boolean)

如果打开这个参数,PostgreSQL服务器将尝试确保更新被物理地写入到磁盘,做法是发出fsync()系统调用或者使用多种等价的方法(见wal_sync_method)。这保证了数据库集簇在一次操作系统或者硬件崩溃后能恢复到一个一致的状态。

虽然关闭fsync常常可以得到性能上的收益,但当发生断电或系统崩溃时可能造成不可恢复的数据损坏。因此,只有在能很容易地从外部数据中重建整个数据库时才建议关闭fsync

能安全关闭fsync的环境的例子包括从一个备份文件中初始加载一个新数据库集簇、使用一个数据库集簇来在数据库被删掉并重建之后处理一批数据,或者一个被经常重建并却不用于失效备援的只读数据库克隆。单独的高质量硬件不足以成为关闭fsync的理由。

当把fsync从关闭改成打开时,为了可靠的恢复,需要强制在内核中的所有被修改的缓冲区进入持久化存储。这可以在多个时机来完成:在集簇被关闭时或在fsync因为运行initdb --sync-only而打开时、运行sync时、卸载文件系统时或者重启服务器时。

在很多情况下,为不重要的事务关闭synchronous_commit可以提供很多关闭fsync的潜在性能收益,并不会有的同时, 关闭fsync可以提供很多潜在的性能优势,而不会有伴随着的数据损坏风险。

fsync只能在postgresql.conf文件中或在服务器命令行上设置。如果你关闭这个参数,请也考虑关闭full_page_writes

synchronous_commit (enum)

指定在命令返回success指示给客户端之前,一个事务是否需要等待 WAL 记录被写入磁盘。合法的值是onremote_applyremote_writelocaloff。默认的并且安全的设置是on。当设置为off时,在向客户端报告成功和真正保证事务不会被服务器崩溃威胁之间会有延迟(最大的延迟是wal_writer_delay的三倍)。不同于fsync,将这个参数设置为off不会产生数据库不一致性的风险:一个操作系统或数据库崩溃可能会造成一些最近据说已提交的事务丢失,但数据库状态是一致的,就像这些事务已经被干净地中止。因此,当性能比完全确保事务的持久性更重要时,关闭synchronous_commit可以作为一个有效的代替手段。更多讨论见第 30.3 节

如果synchronous_standby_names被设置,这个参数也控制事务提交是否将等待事务的 WAL 记录被复制到后备服务器上。当这个参数被设置为on时,直到来自于当前同步的后备服务器的一个回复指示该后备服务器已经收到了事务的提交记录并将其刷入了磁盘,主服务器上的事务才会提交。这保证事务将不会被丢失,除非主服务器和后备服务器都遭受到了数据库存储损坏的问题。 当设置为remote_apply>时,提交将等待, 直到来自当前同步备用数据库的回复表明它们已收到事务的提交记录并应用它, 以便它对备用数据库上的查询可见。 当这个参数被设置为remote_write时,提交将等待,直到来自当前同步的后备服务器的一个回复指示该服务器已经收到了该事务的提交记录并且已经把该记录写出到后备服务器的操作系统,但是该数据并不一定到达了后备服务器上的稳定存储。这种设置足以保证数据在后备服务器的PostgreSQL实例崩溃时得以保存,但是不能保证后备服务器遭受操作系统级别崩溃时数据能被保持。 最后,设置local会导致提交等待本地刷新到磁盘, 但不会进行复制。当使用同步复制时通常不需要这样做, 但是为了完整性而提供。

当使用同步复制时,它将对等待本地刷写磁盘和 WAL 记录复制很敏感,或者对允许事务异步提交很敏感。不过,设置local可以用于希望等待本地刷写磁盘但不等待同步复制的事务。如果没有设置synchronous_standby_names,设置onremote_writelocal都提供了同样的同步级别:事务提交只等待本地刷写磁盘。

这个参数可以随时被修改;任何一个事务的行为由其提交时生效的设置决定。因此,可以同步提交一些事务,同时异步提交其他事务。例如,当默认是相反时,实现一个单一多语句事务的异步提交,在事务中发出SET LOCAL synchronous_commit TO OFF

wal_sync_method (enum)

用来向强制 WAL 更新到磁盘的方法。如果fsync是关闭的,那么这个设置就不相关,因为 WAL 文件更新将根本不会被强制。可能的值是:

  • open_datasync(用open()选项O_DSYNC写 WAL 文件)

  • fdatasync(在每次提交时调用fdatasync()

  • fsync(在每次提交时调用fsync()

  • fsync_writethrough(在每次提交时调用fsync(),强制任何磁盘写高速缓存的直通写)

  • open_sync(用open()选项O_SYNC写 WAL 文件)

open_* 选项也可以使用O_DIRECT(如果可用)。不是在所有平台上都能使用所有这些选择。默认值是列表中第一个被平台支持的那个, 不过fdatasync是 Linux 中的默认值。默认值不一定是最理想的;有可能需要修改这个设置或系统配置的其他方面来创建一个崩溃-安全的配置,或达到最佳性能。这些方面在第 30.1 节中讨论。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。

full_page_writes (boolean)

当这个参数为打开时,PostgreSQL服务器在一个检查点之后的页面的第一次修改期间将每个页面的全部内容写到 WAL 中。这么做是因为在操作系统崩溃期间正在处理的一次页写入可能只有部分完成,从而导致在一个磁盘页面中混合有新旧数据。在崩溃后的恢复期间,通常存储在 WAL 中的行级改变数据不足以完全恢复这样一个页面。存储完整的页面映像可以保证页面被正确存储,但代价是增加了必须被写入 WAL 的数据量(因为 WAL 重放总是从一个检查点开始,所以在检查点后每个页面的第一次改变时这样做就够了。因此,一种减小全页面写开销的方法是增加检查点间隔参数值)。

把这个参数关闭会加快正常操作,但是在系统失败后可能导致不可恢复的数据损坏,或者静默的数据损坏。其风险类似于关闭fsync, 但是风险较小。并且只有在可关闭fsync的情况下才应该关闭它。

关闭这个选项并不影响用于时间点恢复(PITR)的 WAL 归档使用(见第 25.3 节)。

这个参数只能在postgresql.conf文件中或在服务器命令行上设置。默认值是on

wal_log_hints (boolean)

当这个参数为on时,PostgreSQL服务器一个检查点之后页面被第一次修改期间把该磁盘页面的整个内容都写入 WAL,即使对所谓的提示位做非关键修改也会这样做。

如果启用了数据校验和,提示位更新总是会被 WAL 记录并且这个设置会被忽略。你可以使用这个 设置测试如果你的数据库启用了数据校验和,会有多少额外的 WAL 记录发生。

这个参数只能在服务器启动时设置。默认值是off

wal_compression (boolean)

当这个参数为on, full_page_writes为on,或者基础备份中, PostgreSQL服务器压缩完整页面图片到WAL中。 在WAL回放中解压压缩的页面图片。缺省值为off。 只有超级用户可以修改这个设置。

开启这个参数可以减少WAL量而不增加不可恢复数据丢失的风险, 但是增加了WAL日志压缩以及WAL回放解压过程中一些额外CPU成本开销。

wal_buffers (integer)

用于还未写入磁盘的 WAL 数据的共享内存量。默认值 -1 选择等于shared_buffers的 1/32 的尺寸(大约3%),但是不小于64kB也不大于 WAL 段的尺寸(通常为16MB)。如果自动的选择太大或太小可以手工设置该值,但是任何小于32kB的正值都将被当作32kB。这个参数只能在服务器启动时设置。

在每次事务提交时,WAL 缓冲区的内容被写出到磁盘,因此极大的值不可能提供显著的收益。不过,把这个值设置为几个兆字节可以在一个繁忙的服务器(其中很多客户端会在同一时间提交)上提高写性能。由默认设置 -1 选择的自动调节将在大部分情况下得到合理的结果。

wal_writer_delay (integer)

指定WAL编写器刷新WAL的频率。在刷新WAL之后, 它会睡眠wal_writer_delay毫秒,除非被异步提交的事务唤醒。 如果最后一次刷新发生的时间小于wal_writer_delay毫秒前, 并且从上一次刷写发生以来产生了小于WAL的 wal_writer_flush_after 个字节, 则WAL仅写入操作系统,而不刷新到磁盘。 默认值是 200 毫秒(200ms)。需要注意的是,在许多系统上,有效的休眠延迟解析度是 10 毫秒;将wal_writer_delay设置为不是 10 的倍数将得到把它设置为下一个 10 的倍数同样的效果。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。

wal_writer_flush_after (integer)

指定 WAL 写入器刷写 WAL 的频繁程度。 如果上一次刷写发生在少于wal_writer_delay 毫秒以前并且从上一次刷写发生以来产生了少于wal_writer_flush_after 字节的 WAL,WAL 将只被写入到操作系统,而不刷新到磁盘。如果 wal_writer_flush_after被设置为0, 则 WAL 数据立即被刷新。默认是1MB。 这个参数只能在postgresql.conf文件中或者服务器命令行上设置。

commit_delay (integer)

在一次 WAL 刷写被发起之前,commit_delay增加一个时间延迟,以微秒计。如果系统负载足够高,使得在一个给定间隔内有额外的事务准备好提交,那么通过允许更多事务通过一个单次 WAL 刷写来提交能够提高组提交的吞吐量。但是,它也把每次 WAL 刷写的潜伏期增加到了最多commit_delay微秒。因为如果没有其他事务准备好提交,就会浪费一次延迟,只有在当一次刷写将要被发起时有至少commit_siblings个其他活动事务时,才会执行一次延迟。另外,如果fsync被禁用,则将不会执行任何延迟。默认的commit_delay是零(无延迟)。只有超级用户才能修改这个设置。

PostgreSQL的 9.3 发布之前,commit_delay的行为不同并且效果更差:它只影响提交,而不是所有 WAL 刷写,并且即使在 WAL 刷写马上就要完成时也会等待一整个配置的延迟。从PostgreSQL 9.3 中开始,第一个准备好刷写的进程会等待配置的间隔,而后续的进程只等到领先者完成刷写操作。

commit_siblings (integer)

在执行commit_delay延迟时,要求的并发活动事务的最小数目。大一些的值会导致在延迟间隔期间更可能有至少另外一个事务准备好提交。默认值是五个事务。

19.5.2. 检查点

checkpoint_timeout (integer)

自动 WAL 检查点之间的最长时间,以秒计。 有效值在30秒和1天之间。 默认是 5 分钟(5min)。 增加这个参数的值会增加崩溃恢复所需的时间。 这个参数只能在postgresql.conf文件中或在服务器命令行上设置。

checkpoint_completion_target (floating point)

指定检查点完成的目标,作为检查点之间总时间的一部分。默认是 0.5。 这个参数只能在postgresql.conf文件中或在服务器命令行上设置。

checkpoint_flush_after (integer)

在执行检查点时,只要有checkpoint_flush_after字节被写入, 就尝试强制 OS 把这些写发送到底层存储。 这样做将会限制内核页面高速缓存中的脏数据数量, 降低在检查点末尾发出fsync或者 OS 在后台大批量写回数据时被卡住的可能性。 那常常会导致大幅度压缩的事务延迟,但是也有一些情况 (特别是负载超过shared_buffers但小于 OS 页面高速缓存) 的性能会降低。这种设置可能会在某些平台上没有效果。合法的范围在 0(禁用强制写回)和2MB之间。 Linux 上的默认值是256kB,其他平台上是0 (如果BLCKSZ不是8kB,默认值和最大值会等比例缩放)。 这个参数只能在postgresql.conf文件中或者服务器命令行上设置。

checkpoint_warning (integer)

如果由于填充检查点段文件导致的检查点之间的间隔低于这个参数表示的秒数,那么就向服务器日志写一个消息(它建议增加max_wal_size的值)。默认值是 30 秒(30s)。零则关闭警告。如果checkpoint_timeout低于checkpoint_warning,则不会有警告产生。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。

max_wal_size (integer)

在自动WAL检查点使得WAL增长到最大尺寸。这是软限制;特殊情况下WAL大小可以超过 max_wal_size,如重负载下,错误archive_command,或者 较大wal_keep_segments的设置。缺省是1GB。 增加这个参数会延长崩溃恢复所需要的时间。 这个参数只能在postgresql.conf文件或者服务器命令行上设置。

min_wal_size (integer)

只要WAL磁盘使用率低于这个设置,旧的WAL文件总数被回收,以供将来检查点使用。而不是删除。 这可以用来确保预留足够的WAL空间处理WAL使用中的峰值,比如当运行大批量工作时。 缺省是80MB。这个参数只能在postgresql.conf文件或者 服务器命令行上设置。

19.5.3. 归档

archive_mode (enum)

当启用archive_mode时, 可以通过设置archive_command命令将完成的 WAL段发送到归档存储。 除了off,要禁用两种模式on和 always。在正常操作过程中,两种模式没有区别,但是 当设置为always时,归档恢复或者待机模式中激活WAL归档。 在always模式中, 从归档中恢复所有文件或者再次归档使用流复制传输的文件。 参阅第 26.2.9 节获取详情。

archive_modearchive_command 是独立的变量,这样可以在不影响归档模式的前提下修改 archive_command。这个参数只能在服务器启动时设置。 当wal_level被设置为minimal时, archive_mode不能被启用。

archive_command (string)

本地 shell 命令被执行来归档一个完成的 WAL 文件段。字符串中的任何%p被替换成要被归档的文件的路径名, 而%f只被文件名替换(路径名是相对于服务器的工作目录, 即集簇的数据目录)。如果要在命令里嵌入一个真正的%字符,可以使用%%。有一点很重要,该命令只在成功时返回一个零作为退出状态。更多信息请见第 25.3.1 节

这个参数只能在postgresql.conf文件中或在服务器命令行上设置。除非服务器启动时启用了archive_mode,否则它会被忽略。如果archive_mode被启用时,archive_command是一个空字符串(默认),WAL 归档会被临时禁用,但服务器仍会继续累计 WAL 段文件,期待着一个命令被提供。将archive_command设置为一个只返回真但不做任何事的命令(例如/bin/true或 Windows 上的REM)实际上会禁用归档,也会打破归档恢复所需的 WAL 文件链,因此只有在极少数情况下才能用。

archive_timeout (integer)

archive_command仅在已完成的 WAL 段上调用。因此,如果你的服务器只产生很少的 WAL 流量(或产生流量的周期很长),那么在事务完成和它被安全地记录到归档存储之间将有一个很长的延迟。为了限制未归档数据存在的时间,你可以设置archive_timeout来强制服务器来周期性地切换到一个新的 WAL 段文件。当这个参数被设置为大于零时,只要从上次段文件切换后过了参数所设置的那么多秒并且已经有过任何数据库活动,包括一个单一检查点(如果没有数据库活动则跳过检查点),服务器将切换到一个新的段文件。注意,由于强制切换而提早关闭的被归档文件仍然与完整的归档文件长度相同。因此,使用非常短的archive_timeout是不明智的 — 它将占用巨大的归档存储。一分钟左右的archive_timeout设置通常比较合理。如果你希望数据能被更快地从主服务器上复制下来,你应该考虑使用流复制而不是归档。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。

本文转自PostgreSQL中文社区,原文链接:19.5. 预写式日志

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
4月前
|
存储 关系型数据库 数据库
【赵渝强老师】PostgreSQL的服务器日志文件
本文介绍了PostgreSQL数据库的物理存储结构,重点讨论了服务器日志文件。通过`pg_ctl`命令启动PostgreSQL实例时,使用`-l`参数指定日志文件位置,记录数据库启动、运行及关闭过程中的关键信息。附有相关视频讲解和日志文件示例。
186 0
|
1月前
|
数据可视化 关系型数据库 MySQL
ELK实现nginx、mysql、http的日志可视化实验
通过本文的步骤,你可以成功配置ELK(Elasticsearch, Logstash, Kibana)来实现nginx、mysql和http日志的可视化。通过Kibana,你可以直观地查看和分析日志数据,从而更好地监控和管理系统。希望这些步骤能帮助你在实际项目中有效地利用ELK来处理日志数据。
267 90
|
21天前
|
SQL 运维 关系型数据库
MySQL Binlog 日志查看方法及查看内容解析
本文介绍了 MySQL 的 Binlog(二进制日志)功能及其使用方法。Binlog 记录了数据库的所有数据变更操作,如 INSERT、UPDATE 和 DELETE,对数据恢复、主从复制和审计至关重要。文章详细说明了如何开启 Binlog 功能、查看当前日志文件及内容,并解析了常见的事件类型,包括 Format_desc、Query、Table_map、Write_rows、Update_rows 和 Delete_rows 等,帮助用户掌握数据库变化历史,提升维护和排障能力。
|
23天前
|
存储 弹性计算 容灾
阿里云服务器ECS详细购买流程【新手购买手册】
本文详细介绍了阿里云服务器ECS的购买全流程,包括付费类型、地域选择、网络及可用区配置、实例规格、镜像系统、存储设置(系统盘与数据盘)、快照服务、公网IP与带宽配置、安全组规则设定以及登录凭据设置等关键步骤。以自定义购买为例,帮助用户根据实际需求选择合适的配置,如长时间使用建议包年包月模式,地域选择遵循就近原则降低延迟,实例规格依据性能需求挑选,同时提供带宽计费模式对比和安全组基础配置指导。通过清晰的图文说明,让用户轻松完成阿里云服务器的选购与部署。
173 6
|
2月前
|
存储 SQL 关系型数据库
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
197 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
|
2月前
|
关系型数据库 MySQL 数据库
图解MySQL【日志】——两阶段提交
两阶段提交是为了解决Redo Log和Binlog日志在事务提交时可能出现的半成功状态,确保两者的一致性。它分为准备阶段和提交阶段,通过协调者和参与者协作完成。准备阶段中,协调者向所有参与者发送准备请求,参与者执行事务并回复是否同意提交;提交阶段中,若所有参与者同意,则协调者发送提交请求,否则发送回滚请求。MySQL通过这种方式保证了分布式事务的一致性,并引入组提交机制减少磁盘I/O次数,提升性能。
99 4
图解MySQL【日志】——两阶段提交
|
2月前
|
存储 缓存 关系型数据库
图解MySQL【日志】——Redo Log
Redo Log(重做日志)是数据库中用于记录数据页修改的物理日志,确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式,在内存中缓存修改操作,并在适当时候刷入磁盘,减少随机写入带来的性能损耗。WAL(Write-Ahead Logging)技术的核心思想是先将修改操作记录到日志文件中,再择机写入磁盘,从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数(如 `innodb_flush_log_at_trx_commit`),以平衡性能与数据安全性。
88 5
图解MySQL【日志】——Redo Log
|
2月前
|
SQL 缓存 关系型数据库
MySQL原理简介—7.redo日志的底层原理
本文介绍了MySQL中redo日志和undo日志的主要内容: 1. redo日志的意义:确保事务提交后数据不丢失,通过记录修改操作并在系统宕机后重做日志恢复数据。 2. redo日志文件构成:记录表空间号、数据页号、偏移量及修改内容。 3. redo日志写入机制:redo日志先写入Redo Log Buffer,再批量刷入磁盘文件,减少随机写以提高性能。 4. Redo Log Buffer解析:描述Redo Log Buffer的内存结构及刷盘时机,如事务提交、Buffer过半或后台线程定时刷新。 5. undo日志原理:用于事务回滚,记录插入、删除和更新前的数据状态,确保事务可完整回滚。
186 22
|
2月前
|
关系型数据库 MySQL 数据库
MySQL日志
本文介绍了MySQL中三个重要的日志:binlog、redolog和undolog。binlog记录数据库更改操作,支持数据恢复、复制和审计;redolog保证事务的原子性和持久性,实现crash-safe;undolog用于事务回滚及MVCC的实现。每个日志都有其独特的作用和应用场景,确保数据库的稳定性和数据一致性。
|
2月前
|
关系型数据库 MySQL
图解MySQL【日志】——磁盘 I/O 次数过高时优化的办法
当 MySQL 磁盘 I/O 次数过高时,可通过调整参数优化。控制刷盘时机以降低频率:组提交参数 `binlog_group_commit_sync_delay` 和 `binlog_group_commit_sync_no_delay_count` 调整等待时间和事务数量;`sync_binlog=N` 设置 write 和 fsync 频率,`innodb_flush_log_at_trx_commit=2` 使提交时只写入 Redo Log 文件,由 OS 择机持久化,但两者在 OS 崩溃时有丢失数据风险。
86 3

热门文章

最新文章

下一篇
oss创建bucket