PostgreSQL 10.1 手册_部分 III. 服务器管理_第 30 章 可靠性和预写式日志_30.1. 可靠性

本文涉及的产品
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
日志服务 SLS,月写入数据量 50GB 1个月
简介: 30.1. 可靠性 可靠性是任何严肃的数据库系统的重要属性,PostgreSQL尽一切可能来保证可靠的操作。可靠的操作的一个方面是,被一个提交事务记录的所有数据应该被存储在一个非易失的区域, 这样就不会因为失去电力、操作系统失败以及硬件失败(当然,除了非易失区域自身失效之外)等原因导致的数据丢失。

30.1. 可靠性

可靠性是任何严肃的数据库系统的重要属性,PostgreSQL尽一切可能来保证可靠的操作。可靠的操作的一个方面是,被一个提交事务记录的所有数据应该被存储在一个非易失的区域, 这样就不会因为失去电力、操作系统失败以及硬件失败(当然,除了非易失区域自身失效之外)等原因导致的数据丢失。 向计算机的永久存储(磁盘驱动器或者等效的设备)成功写入数据通常可以满足这个要求。 实际上,即使计算机受到致命损坏,只要磁盘驱动器幸存下来,那么它们就可以被移动到另外一台具有类似硬件的计算机上, 而所有已经提交的事务将保持原状。

周期地强制数据进入磁盘盘片看上去像一件简单的操作,但实际上并不是。 因为磁盘驱动器比内存和CPU要慢很多,在计算机的主存和磁盘盘片之间存在多层的高速缓存。 首先,有操作系统的高速缓存,它缓冲常用的磁盘块并且组合对磁盘的写入。 幸运的是,所有操作系统都给予应用一种强制从高速缓存写入磁盘的方法,PostgreSQL则使用了那个特性(参阅wal_sync_method参数调节如何完成之)。

然后,在磁盘驱动器的控制器上可能还有一个高速缓存;这在RAID控制卡上是特别常见的。有些高速缓存是直写式的,即写入动作在到达的时候就立刻写入到磁盘上。其它是回写式的, 即发送给驱动器的数据在稍后的某个时间写入驱动器。这样的高速缓存可能会称为可靠性灾难,因为磁盘控制器高速缓存的内存是易失性的,在发生电力失败的情况下会丢失其内容。 好一些的控制器卡有后备电池单元(BBU), 即这种卡上面有电池可以在系统电力失败的情况下提供电力。 在电力恢复之后,这些数据将会被写入磁盘驱动器。

最后,大多数磁盘驱动器都有高速缓存。有些是直写的,有些是回写的, 和磁盘控制器一样,回写的磁盘高速缓存也存在数据丢失的问题。 消费级别的IDE和SATA驱动器尤其可能包含回写式高速缓存,在掉电的情况下很容易丢失数据。很多固态驱动器(SSD)也具有易失性回写式高速缓存。

这些高速缓存通常可以被禁用,但是不同的操作系统和驱动器类型有不同的做法:

  • Linux上,可以使用hdparm -I查询IDE和SATA驱动器,如果在Write cache之后有一个*则表示写高速缓存被启用。可以用hdparm -W 0来关闭写高速缓存。可以使用sdparm查询SCSI驱动器。使用sdparm --get=WCE来检查写高速缓存是否被启用,而sdparm --clear=WCE可以用来禁用它。

  • FreeBSD上,IDE驱动器可以使用atacontrol查询,而写高速缓存可以用/boot/loader.conf中的hw.ata.wc=0关闭。SCSI驱动器可以使用camcontrol identify查询,而写高速缓存的查询和更改都可以使用sdparm

  • Solaris上,磁盘的写高速缓存被format -e控制(Solaris的ZFS文件系统对于开启的磁盘写高速缓存是安全的,因为它会发出它自己的磁盘高速缓存刷写命令)。

  • Windows上,如果wal_sync_methodopen_datasync(默认值),写高速缓存可以通过取消选中My Computer\Open\disk drive\Properties\Hardware\Properties\Policies\Enable write caching on the disk禁用。另一种方法可以通过设置wal_sync_methodfsyncfsync_writethrough来阻止写高速缓存。

  • macOS上,通过设置wal_sync_methodfsync_writethrough可以阻止写高速缓存。

最近的SATA驱动器(遵循ATAPI-6及更新标准)提供了一个驱动器高速缓存刷写命令(FLUSH CACHE EXT),而SCSI驱动器有一个存在很长时间的类似命令SYNCHRONIZE CACHE。这些命令对于PostgreSQL并不能直接访问,但某些文件系统(例如ZFS、ext4)可以使用它们将数据刷写到回写式驱动器的盘片上。不幸的是,这些文件系统在和后备电池单元(BBU)一起工作时的表现要略差。在这种设置下,同步命令强制所有来自控制器高速缓存的数据到磁盘,消除了BBU的很多好处。你可以运行pg_test_fsync程序来看你是否被影响。如果你被影响了,BBU带来的性能好处可以通过关闭文件系统的写障碍或者重新配置磁盘控制器来重新获得。如果写障碍被关闭,请确认电池是否保持有效,一个有问题的电池可能会导致数据丢失。但愿文件系统和磁盘控制器设计师们将最终解决这种次优行为。

在操作系统向存储硬件发出一个写请求的时候,它没有什么好办法来保证数据真正到达非易失的存储区域。 实际上,确保所有存储部件都保证数据和文件系统元数据的完整性是管理员的责任。 避免使用那些没有电池作为后备的写高速缓存的磁盘控制器。在驱动器级别,如果驱动器不能保证在关闭(掉电)之前写入数据, 那么关闭回写高速缓冲。如果你在使用SSD,注意很多SSD默认都没有兑现高速缓存刷写命令。你可以使用diskchecker.pl来测试可靠的I/O子系统行为。

另外一个数据丢失的风险来自磁盘盘片写操作自身。磁盘盘片会被分割为扇区,通常每个扇区512字节。每次物理读写都对整个扇区进行操作。当一个写操作到达磁盘的时候,它可能是512 字节(PostgreSQL通常一次写8192字节或者16个扇区)的某个倍数,而写入处理可能因为电力失效在任何时候失败,这 意味着某些512字节的扇区写入了,而有些没有。为了避免这样的失效,PostgreSQL在修改磁盘上的实际页面之前, 周期地把整个页面的映像写入永久WAL存储。这么做之后,在崩溃恢复的时候,PostgreSQL可以从WAL恢复部分写入的页面。如果你的文件系统阻止部分页面写入(如ZFS),你可以通过关闭full_page_writes参数来关闭这种页映像。后备电池单元(BBU)磁盘控制器不阻止部分页面写入,除非它们保证数据都是以整页(8kB)写入到BBU。

PostgreSQL也能防止由于硬件错误或者介质失败超时在存储设备上造成的各种数据损坏,例如读/写垃圾数据。

  • WAL文件中的每一个记录都被一个CRC-32(32位)校验码所保护,这让我们可以判断记录内容是否正确。CRC值在我们写入每一个WAL记录时设置,并且在崩溃恢复、归档恢复和复制时检查。

  • 目前数据页并没有默认地被校验,但是WAL记录中记录的整页映像将被保护。关于启用数据页校验的内容详见initdb

  • 诸如pg_xactpg_subtranspg_multixact、 pg_serialpg_notifypg_statpg_snapshots等内部数据结构既没有被直接校验,其页面也没有被整页写保护。但是,这些数据结构是持久的话,WAL记录被写入,它允许最近的修改能在崩溃恢复时被准确重建且这些WAL记录被按照以上讨论的方式保护着。

  • pg_twophase中的单个状态文件被CRC-32保护。

  • 用在大型SQL查询中排序的临时数据库文件、物化和中间结果目前没有被校验,对于这些文件的改变也不会导致写入WAL记录。

PostgreSQL无法避免可更正内存错误,它假定你会操作由工业标准纠错码(ECC)或更好方案保护的RAM。

本文转自PostgreSQL中文社区,原文链接:30.1. 可靠性

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
3月前
|
存储 关系型数据库 数据库
【赵渝强老师】PostgreSQL的服务器日志文件
本文介绍了PostgreSQL数据库的物理存储结构,重点讨论了服务器日志文件。通过`pg_ctl`命令启动PostgreSQL实例时,使用`-l`参数指定日志文件位置,记录数据库启动、运行及关闭过程中的关键信息。附有相关视频讲解和日志文件示例。
139 0
|
13天前
|
存储 缓存 关系型数据库
图解MySQL【日志】——Redo Log
Redo Log(重做日志)是数据库中用于记录数据页修改的物理日志,确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式,在内存中缓存修改操作,并在适当时候刷入磁盘,减少随机写入带来的性能损耗。WAL(Write-Ahead Logging)技术的核心思想是先将修改操作记录到日志文件中,再择机写入磁盘,从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数(如 `innodb_flush_log_at_trx_commit`),以平衡性能与数据安全性。
27 5
图解MySQL【日志】——Redo Log
|
1月前
|
存储 SQL 关系型数据库
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
102 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
|
12天前
|
关系型数据库 MySQL 数据库
图解MySQL【日志】——两阶段提交
两阶段提交是为了解决Redo Log和Binlog日志在事务提交时可能出现的半成功状态,确保两者的一致性。它分为准备阶段和提交阶段,通过协调者和参与者协作完成。准备阶段中,协调者向所有参与者发送准备请求,参与者执行事务并回复是否同意提交;提交阶段中,若所有参与者同意,则协调者发送提交请求,否则发送回滚请求。MySQL通过这种方式保证了分布式事务的一致性,并引入组提交机制减少磁盘I/O次数,提升性能。
29 4
图解MySQL【日志】——两阶段提交
|
27天前
|
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日志原理:用于事务回滚,记录插入、删除和更新前的数据状态,确保事务可完整回滚。
110 22
|
10天前
|
关系型数据库 MySQL 数据库
MySQL日志
本文介绍了MySQL中三个重要的日志:binlog、redolog和undolog。binlog记录数据库更改操作,支持数据恢复、复制和审计;redolog保证事务的原子性和持久性,实现crash-safe;undolog用于事务回滚及MVCC的实现。每个日志都有其独特的作用和应用场景,确保数据库的稳定性和数据一致性。
|
12天前
|
关系型数据库 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 崩溃时有丢失数据风险。
26 3
|
15天前
|
缓存 关系型数据库 MySQL
图解MySQL【日志】——Buffer Pool
Buffer Pool 是数据库管理系统(DBMS)中用于缓存磁盘数据页的内存区域,主要包含数据页、索引页、undo 页等。它通过减少磁盘 I/O 提升性能,特别是在处理大型数据库时效果显著。查询时,整个数据页而非单条记录会被加载到 Buffer Pool 中,以提高访问效率。
17 0
图解MySQL【日志】——Buffer Pool
|
2月前
|
监控 Oracle 关系型数据库
Mysql、Oracle审计日志的开启
通过上述步骤,可以在 MySQL 和 Oracle 数据库中启用和配置审计日志。这些日志对于监控数据库操作、提高安全性和满足合规性要求非常重要。确保正确配置审计参数和策略,定期查看和分析审计日志,有助于及时发现并处理潜在的安全问题。
82 11
|
2月前
|
SQL 关系型数据库 MySQL
MySQL事务日志-Undo Log工作原理分析
事务的持久性是交由Redo Log来保证,原子性则是交由Undo Log来保证。如果事务中的SQL执行到一半出现错误,需要把前面已经执行过的SQL撤销以达到原子性的目的,这个过程也叫做"回滚",所以Undo Log也叫回滚日志。
107 7
MySQL事务日志-Undo Log工作原理分析