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

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
简介: 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数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
16天前
|
存储 安全 关系型数据库
Mysql 的binlog日志的优缺点
MySQL的binlog(二进制日志)是一个记录数据库更改的日志文件,它包含了所有对数据库执行的更改操作,如INSERT、UPDATE和DELETE等。binlog的主要目的是复制和恢复。以下是binlog日志的优缺点: ### 优点: 1. **数据恢复**:当数据库出现意外故障或数据丢失时,可以利用binlog进行点恢复(point-in-time recovery),将数据恢复到某一特定时间点。 2. **主从复制**:binlog是实现MySQL主从复制功能的核心组件。主服务器将binlog中的事件发送到从服务器,从服务器再重放这些事件,从而实现数据的同步。 3. **审计**:b
|
27天前
|
SQL 关系型数据库 MySQL
MySQL数据库,可以使用二进制日志(binary log)进行时间点恢复
对于MySQL数据库,可以使用二进制日志(binary log)进行时间点恢复。二进制日志是MySQL中记录所有数据库更改操作的日志文件。要进行时间点恢复,您需要执行以下步骤: 1. 确保MySQL配置文件中启用了二进制日志功能。在配置文件(通常是my.cnf或my.ini)中找到以下行,并确保没有被注释掉: Copy code log_bin = /path/to/binary/log/file 2. 在需要进行恢复的时间点之前创建一个数据库备份。这将作为恢复的基准。 3. 找到您要恢复到的时间点的二进制日志文件和位置。可以通过执行以下命令来查看当前的二进制日志文件和位
|
3月前
|
存储 运维 应用服务中间件
[运维日志] Web 服务器日志依日期归档(Powershell 实现,附源代码)
[运维日志] Web 服务器日志依日期归档(Powershell 实现,附源代码)
74 0
|
3月前
|
运维 监控 关系型数据库
百度搜索:蓝易云【MYSQL四种管理日志详细介绍】
这四种管理日志对于MySQL服务器的性能监控、故障排查以及主从复制等方面都非常重要。在使用这些日志时,应根据具体需求来选择开启和配置,并定期清理和维护日志文件,以免占用过多磁盘空间。
56 0
|
3月前
|
关系型数据库 MySQL
mysql的日志为什么需要两阶段提交
mysql的日志为什么需要两阶段提交
|
1月前
|
SQL 缓存 关系型数据库
MySQL的万字总结(缓存,索引,Explain,事务,redo日志等)
MySQL的万字总结(缓存,索引,Explain,事务,redo日志等)
66 0
|
2月前
|
存储 监控 关系型数据库
ELK架构监控MySQL慢日志
ELK架构监控MySQL慢日志
|
2月前
|
SQL 运维 关系型数据库
MySQL中常见的几种日志类型
MySQL中常见的几种日志类型
|
2月前
|
关系型数据库 MySQL 数据库
MySQL员工打卡日志表——数据库练习
MySQL员工打卡日志表——数据库练习
136 0
|
2月前
|
SQL 关系型数据库 MySQL
MySQL技能完整学习列表11、日志和备份——1、查看日志——2、数据备份和恢复(mysqldump, mysqlbinlog)
MySQL技能完整学习列表11、日志和备份——1、查看日志——2、数据备份和恢复(mysqldump, mysqlbinlog)
45 0