预写式日志WAL

Chapter 25. 预写式日志(Write-Ahead Logging (WAL))

Table of Contents
25.1. WAL 的好处
25.2. WAL 配置
25.3. 内部

预写式日志 (WAL) 是一种实现事务日志的标准方法。有关它的详细描述可以在大多数(如果不是全部的话)有关事务处理的书中找到。 简而言之,WAL 的中心思想是对数据文件的修改(它们是表和索引的载体)必须是只能发生在这些修改已经记录了日志之后, 也就是说,在描述这些变化的日志记录冲刷到永久存储器之后。 如果我们遵循这个过程,那么我们就不需要在每次事务提交的时候都把数据页冲刷到磁盘,因为我们知道在出现崩溃的情况下, 我们可以用日志来恢复数据库:任何尚未附加到数据页的记录都将先从日志记录中重做(这叫向前滚动恢复,也叫做 REDO)。

25.1. WAL 的好处

使用 WAL 的第一个主要的好处就是显著地减少了磁盘写的次数。 因为在日志提交的时候只有日志文件需要冲刷到磁盘;而不是事务修改的所有数据文件。 在多用户环境里,许多事务的提交可以用日志文件的一次 fsync() 来完成。而且,日志文件是顺序写的, 因此同步日志的开销要远比同步数据页的开销要小。 这一点对于许多小事务修改数据存储的许多不同的位置更是如此。

另外一个好处就是数据页的完整性。实际情况是,在 WAL 之前,PostgreSQL 从来不能保证在崩溃的情况下数据页的完整性。 在 WAL 之前,在写的过程中的任何崩溃都可能导致:

  1. 索引记录指向一个不存在的表的行
  2. 索引记录在分裂操作中丢失
  3. 完全崩溃了的表和索引页的内容,因为数据页只写了一部分

索引的问题(问题 1 和 2)可能已经通过额外的 fsync 调用修补好了,但是如果没有 WAL,那么没有很明显的处理第三种情况的方法; WAL 在日志里保存整个数据页的内容 -- 如果那些内容在崩溃后的恢复中需要确保数据页的完整性的话。

最后,WAL 还提供了数据库在线备份和恢复(backup and restore (BAR))的可能, 就像 Section 22.3 里描述的那样。 通过归档的 WAL 文件,我们可以支持恢复到手头的 WAL 文件包含的任意时刻: 我们只需要简单地安装以前的数据库的物理备份,然后重放 WAL 到自己希望的时间。 另外,物理备份还不必是数据库状态的一个即时快照 — 如果它是花了一段时间制作的话, 因为 WAL 日志的重放将修复任何内部的不一致。

http://www.highgo.com.cn/docs/docs90cn/runtime-config-wal.html

时间: 2024-12-14 17:38:05

预写式日志WAL的相关文章

Chapter 11.预写式日志(Write-Ahead Logging (WAL)

11.1. 一般性描述 预写式日志 (WAL) 是一种实现事务日志的标准方法.有关它的详细描述可以在 大多数(如果不是全部的话)有关事务处理的书中找到. 简而言之,WAL 的中心思想是对数据文件 的修改(它们是表和索引的载体)必须是只能发生在这些修改已经 记录了日志之后 -- 也就是说,在日志记录冲刷到永久存储器之后. 如果我们遵循这个过程,那么我们就不需要在每次事务提交的时候 都把数据页冲刷到磁盘,因为我们知道在出现崩溃的情况下, 我们可以用日志来恢复数据库:任何尚未附加到数据页的记录 都将先

SQLite 预写式日志

SQLite在3.7.0版本引入了WAL (Write-Ahead-Logging),WAL的全称是Write Ahead Logging,它是很多数据库中用于实现原子事务的一种机制,引入WAL机制之前,SQLite使用rollback journal机制实现原子事务.       rollback journal机制的原理是:在修改数据库文件中的数据之前,先将修改所在分页中的数据备份在另外一个地方,然后才将修改写入到数据库文件中:如果事务失败,则将备份数据拷贝回来,撤销修改:如果事务成功,则删

预写式日志(Write-Ahead Logging (WAL))

SQL Server中使用了WAL(Write-Ahead Logging)技术来保证事务日志的ACID特性.而且大大减少了IO操作. WAL的核心思想是:在数据写入到数据库之前,先写入到日志.再将日志记录变更到存储器中. SQL Server修改数据的步骤 1.在SQL Server的缓冲区的日志中写入”Begin Tran”记录 2.在SQL Server的缓冲区的日志页写入要修改的信息 3.在SQL Server的缓冲区将要修改的数据写入数据页 4.在SQL Server的缓冲区的日志中写

pg_resetxlog - 重置一个 PostgreSQL 数据库集群的预写日志以及其它控制内容

SYNOPSIS pg_resetxlog [ -f ] [ -n ] [ -o oid] [ -x xid] [ -l fileid,seg] datadir DESCRIPTION 描述 pg_resetxlog 清理预写日志(WAL)并且可以选择地重置其它一些控制信息(存储在 pg_control 文件中). 有时候,如果这些文件崩溃了,我们需要这个功能. 我们一定只把它用作最后的方法,就是说只有因为这样的崩溃导致服务器无法启动的时候才使用. 在运行这个命令之后,我们可能可以启动服务器了,

glog另启动线程写文本日志

glog本身是非常高效的,google的大牛肯定知道大规模的写日志用glog的话肯定会影响业务线程的处理,带负荷的磁盘IO谁都桑不起.比如levelDB就是默认异步写,更不用说google的三驾马车都是分布式的.之前看过其论文,简直是引领时代. 在glog的issue里有人提出了异步写的问题,但是语焉不详,不过0.33版本已经有了接口,但是还不友好,但是完全可以实现磁盘日志的异步写. 今天算是花了点时间踩了点坑,算是基本可以搞了.稳定之后会把这个版本和glog,g2log,mudo loggin

轻量级流式日志计算分析plog+(zabbix+grafana)

plog是一个用python写的流式计算分析框架,适用于轻量级流式数据的分析场景,大数据场景下大家自然想到使用spark等方案. 拿当前的业务场景看,需要对机器上nginx的流日志进行状态码.响应时间.QPS的实时分析,通过zabbix展现在grafana里,QPS在1000以内.传统方法是用shell脚本来计算各种数据,然后通过主动或被动模式传到zabbix里,此种方法有很大局限性,一是grep或awk过滤日志时,很难控制好过滤的数量,过滤的多了严重影响性能,可能上一个数据都没计算出来,这一次

我们是这样写升级日志的,处处可以体现人文情怀

做软件,特别是SaaS软件,一般都会把升级日志公布给用户.让用户知道每次都升级了哪些内容.传统的格式无非是: 1.新增了某某按钮 2.修改了无法保存的错误 3.... 我们稍微给升级内容加入了人文情怀.升级日志本来就是开发者与用户的沟通的一个载体,何不写的轻松点呢?请看我们的做法. 超级表格已经升级多次了.直到本次升级,我们公布了升级内容.内容是这样写的: 2014-05-26:这是我第一次记录升级内容,以后每次升级都会在这里累计记录-------------------------------

python 提交SVN 写更新日志

SCENE = "mjdy_dyhry" DIRS = { "md5/scenes/" + SCENE, "data/tex/scenes/" + SCENE, "data/tex/share", "data/mesh/scenes/" + SCENE, } import os WORKSPACE = "D:/workspace/muData/"#os.getcwd()+ # execu

android 写行为日志到SD卡 并发处理 异步写入数据到文件不影响界面响应时间

公司在做一个项目 要求记录用户行为,写行为日志文件到SD卡.实现思想 不影响界面用户体验,要时时记录日志 不能漏掉. 1.并发处理日志 写一个类负责管理各个线程传过来的日志数据,日志数据放在队列中等待写线程去处理.这里每次添加一条日志数据都会检查写日志线程是否在工作,同时为了并发处理传过来的数据采用synchronized 同步: ConcurrentLinkedQueue 是基于链接节点的.线程安全的队列.并发访问不需要同步.因为它在队列的尾部添加元素并从头部删除它们,所以只要不需要知道队列的