预写日志(WAL)介绍

参考：

https://blog.csdn.net/qq_14855971/article/details/105852637

https://blog.csdn.net/dyllove98/article/details/8841973

https://blog.csdn.net/a964921988/article/details/84953078

 

 

 

 

你常听说的WAL到底是什么

什么是 WAL

数据库中一种高效的日志算法，对于非内存数据库而言，磁盘I/O操作是数据库效率的一大瓶颈。在相同的数据量下，采用WAL日志的数据库系统在事务提交时，磁盘写操作只有传统的回滚日志的一半左右，大大提高了数据库磁盘I/O操作的效率，从而提高了数据库的性能。

WAL(Write Ahead Log)预写日志，是数据库系统中常见的一种手段，用于保证数据操作的原子性和持久性。

在计算机科学中，「预写式日志」（Write-ahead logging，缩写 WAL）是关系数据库系统中用于提供原子性和持久性（ACID 属性中的两个）的一系列技术。在使用 WAL 的系统中，所有的修改在提交之前都要先写入 log 文件中。

log 文件中通常包括 redo 和 undo 信息。这样做的目的可以通过一个例子来说明。假设一个程序在执行某些操作的过程中机器掉电了。在重新启动时，程序可能需要知道当时执行的操作是成功了还是部分成功或者是失败了。如果使用了 WAL，程序就可以检查 log 文件，并对突然掉电时计划执行的操作内容跟实际上执行的操作内容进行比较。在这个比较的基础上，程序就可以决定是撤销已做的操作还是继续完成已做的操作，或者是保持原样。

WAL 允许用 in-place 方式更新数据库。另一种用来实现原子更新的方法是 shadow paging，它并不是 in-place 方式。用 in-place 方式做更新的主要优点是减少索引和块列表的修改。ARIES 是 WAL 系列技术常用的算法。在文件系统中，WAL 通常称为 journaling。PostgreSQL 也是用 WAL 来提供 point-in-time 恢复和数据库复制特性。

备份

我们想一想，如果想保证对一个数据的操作可以恢复。可以怎么做？你不用去想数据库是怎么实现的，也不用想太高深。其实这是一个很简单的问题，我们常常在处理这种问题。最简单的方法其实就是备份一份数据：当我需要对一条数据做更新操作前，先将这条数据备份在一个地方，然后去更新，如果更新失败，可以从备份数据中回写回来。这样就可以保证事务的回滚，就可以保证数据操作的原子性了。其实 SQLite 引入 WAL 之前就是通过这种方式来实现原子事务，称之为 rollback journal， rollback journal 机制的原理是：在修改数据库文件中的数据之前，先将修改所在分页中的数据备份在另外一个地方，然后才将修改写入到数据库文件中；如果事务失败，则将备份数据拷贝回来，撤销修改；如果事务成功，则删除备份数据，提交修改。

WAL

再继续上面的问题？如何做到数据的可恢复（原子性）和提交成功的数据被持久化到磁盘（持久性）？另一种机制就是WAL，WAL 机制的原理也很简单：「修改并不直接写入到数据库文件中，而是写入到另外一个称为 WAL 的文件中；如果事务失败，WAL 中的记录会被忽略，撤销修改；如果事务成功，它将在随后的某个时间被写回到数据库文件中，提交修改。」

WAL 的优点

  1. 读和写可以完全地并发执行，不会互相阻塞（但是写之间仍然不能并发）。

  2. WAL 在大多数情况下，拥有更好的性能（因为无需每次写入时都要写两个文件）。

  3. 磁盘 I/O 行为更容易被预测。

  4. 使用更少的 fsync()操作，减少系统脆弱的问题。

提升性能

我们都知道，数据库的最大性能挑战就是磁盘的读写，许多先辈在提供数据存储性能上绞尽脑汁，提出和实验了一套又一套方法。其实所有方案最终总结出来就三种：「随机读写改顺序读写」、「缓冲单条读写改批量读写」、「单线程读写改并发读写」。WAL 其实也是这两种思路的一种实现，一方面 WAL 中记录事务的更新内容，通过 WAL 将随机的脏页写入变成顺序的日志刷盘，另一方面，WAL 通过 buffer 的方式改单条磁盘刷入为缓冲批量刷盘，再者从 WAL 数据到最终数据的同步过程中可以采用并发同步的方式。这样极大提升数据库写入性能，因此，WAL 的写入能力决定了数据库整体性能的上限，尤其是在高并发时。

checkpoint

上面讲到，使用 WAL 的数据库系统不会再每新增一条 WAL 日志就将其刷入数据库文件中，一般积累一定的量然后批量写入，通常使用「页」为单位，这是磁盘的写入单位。同步 WAL 文件和数据库文件的行为被称为 checkpoint（检查点），一般在 WAL 文件积累到一定页数修改的时候；当然，有些系统也可以手动执行 checkpoint。执行 checkpoint 之后，WAL 文件可以被清空，这样可以保证 WAL 文件不会因为太大而性能下降。

有些数据库系统读取请求也可以使用 WAL，通过读取 WAL 最新日志就可以获取到数据的最新状态。

具体实现

常见的数据库一般都会用到 WAL 机制，只是不同的系统说法和实现可能有所差异。mysql、sqlite、postgresql、etcd、hbase、zookeeper、elasticsearch 等等都有自己的实现。

mysql

mysql 的 WAL，大家可能都比较熟悉。mysql 通过 redo、undo 日志实现 WAL。redo log 称为重做日志，每当有操作时，在数据变更之前将操作写入 redo log，这样当发生掉电之类的情况时系统可以在重启后继续操作。undo log 称为撤销日志，当一些变更执行到一半无法完成时，可以根据撤销日志恢复到变更之间的状态。mysql 中用 redo log 来在系统 Crash 重启之类的情况时修复数据（事务的持久性），而 undo log 来保证事务的原子性。

zookeeper

和大多数分布式系统一样，ZooKeeper 也有 WAL(Write-Ahead-Log)，对于每一个更新操作，ZooKeeper 都会先写 WAL, 然后再对内存中的数据做更新，然后向 Client 通知更新结果。另外，ZooKeeper 还会定期将内存中的目录树进行 Snapshot，落地到磁盘上。这么做的主要目的，一当然是数据的持久化，二是加快重启之后的恢复速度，如果全部通过 Replay WAL 的形式恢复的话，会比较慢。

elasticsearch

如果没有用 fsync 把数据从文件系统缓存刷（flush）到硬盘，elasticsearch 不能保证数据在断电甚至是程序正常退出之后依然存在。为了保证可靠性，需要确保数据变化被持久化到磁盘。

在动态更新索引时，elasticsearch 说一次完整的提交会将段刷到磁盘，并写入一个包含所有段列表的提交点。Elasticsearch 在启动或重新打开一个索引的过程中使用这个提交点来判断哪些段隶属于当前分片。

即使通过每秒刷新（refresh）实现了近实时搜索，elasticsearch 仍然需要经常进行完整提交来确保能从失败中恢复。但在两次提交之间发生变化的文档怎么办？

Elasticsearch 增加了一个 translog ，或者叫事务日志，在每一次对 Elasticsearch 进行操作时均进行了日志记录。

etcd

用过 etcd 的同学可能会发现，etcd 的数据目录下有两个子目录wal和snap。它们的作用就是实现 WAL 机制用的。

wal: 存放预写式日志,最大的作用是记录了整个数据变化的全部历程。在 etcd 中，所有数据的修改在提交前，都要先写入到 WAL 中。

snap: 存放快照数据,etcd 防止 WAL 文件过多而设置的快照，存储 etcd 数据状态。

WAL 机制使得 etcd 具备了以下两个功能：

  • 故障快速恢复：当你的数据遭到破坏时，就可以通过执行所有 WAL 中记录的修改操作，快速从最原始的数据恢复到数据损坏前的状态。

  • 数据回滚（undo）/重做（redo）：因为所有的修改操作都被记录在 WAL 中，需要回滚或重做，只需要方向或正向执行日志中的操作即可

hbase

hbase 实现 WAL 的方法将 HLog，hbase 的 RegionServer 会将数据保存在内存中（MemStore），直到满足一定条件，将其 flush 到磁盘上。这样可以避免创建很多小文件。内存存储是不稳定的，HBase 也是使用 WAL 来解决这个问题：每次更新操作都会写日志，并且写日志和更新操作在一个事务中。

 

为什么要使用WAL呢？：真正的执行操作可能数据量会比较大，操作比较繁琐，并且写数据不一定是顺序写，所以如果每一次操作都要等待结果flush到可靠存储（比如磁盘）中才执行下一步操作的话，效率就太低了。换一种思路，如果我们在做真正的操作之前，先将这件事记录下来，持久化到可靠存储中（因为日志一般很小，并且是顺序写，效率很高），然后再去执行真正的操作。这样执行真正操作的时候也就不需要等待执行结果flush到磁盘再执行下一步，因为无论在哪一步出错，我们都能够根据备忘录重做一遍，得到正确的结果。 

 

 

SQLite的WAL机制

1.什么是WAL？

      WAL的全称是Write Ahead Logging，它是很多数据库中用于实现原子事务的一种机制，SQLite在3.7.0版本引入了该特性。

      2.WAL如何工作？

      在引入WAL机制之前，SQLite使用rollback journal机制实现原子事务。

      rollback journal机制的原理是：在修改数据库文件中的数据之前，先将修改所在分页中的数据备份在另外一个地方，然后才将修改写入到数据库文件中；如果事务失败，则将备份数据拷贝回来，撤销修改；如果事务成功，则删除备份数据，提交修改。

      WAL机制的原理是：修改并不直接写入到数据库文件中，而是写入到另外一个称为WAL的文件中；如果事务失败，WAL中的记录会被忽略，撤销修改；如果事务成功，它将在随后的某个时间被写回到数据库文件中，提交修改。

      同步WAL文件和数据库文件的行为被称为checkpoint（检查点），它由SQLite自动执行，默认是在WAL文件积累到1000页修改的时候；当然，在适当的时候，也可以手动执行checkpoint，SQLite提供了相关的接口。执行checkpoint之后，WAL文件会被清空。

      在读的时候，SQLite将在WAL文件中搜索，找到最后一个写入点，记住它，并忽略在此之后的写入点（这保证了读写和读读可以并行执行）；随后，它确定所要读的数据所在页是否在WAL文件中，如果在，则读WAL文件中的数据，如果不在，则直接读数据库文件中的数据。

      在写的时候，SQLite将之写入到WAL文件中即可，但是必须保证独占写入，因此写写之间不能并行执行。

      WAL在实现的过程中，使用了共享内存技术，因此，所有的读写进程必须在同一个机器上，否则，无法保证数据一致性。

      3.WAL的优点与缺点

      优点：

      1.读和写可以完全地并发执行，不会互相阻塞（但是写之间仍然不能并发）。

      2.WAL在大多数情况下，拥有更好的性能（因为无需每次写入时都要写两个文件）。

      3.磁盘I/O行为更容易被预测。

      缺点：

      1.访问数据库的所有程序必须在同一主机上，且支持共享内存技术。

      2.每个数据库现在对应3个文件：<yourdb>.db，<yourdb>-wal，<yourdb>-shm。

      3.当写入数据达到GB级的时候，数据库性能将下降。

      4.3.7.0之前的SQLite无法识别启用了WAL机制的数据库文件。

      4.WAL引入的兼容性问题

      在启用了WAL之后，数据库文件格式的版本号由1升级到了2，因此，3.7.0之前的SQLite无法识别启用了WAL机制的数据库文件。

      禁用WAL会使数据库文件格式的版本号恢复到1，从而可以被SQLite 3.7.0之前的版本识别。

      5.WAL引入的性能问题

      在一般情况下，WAL会提高SQLite的事务性能；但是在某些极端情况下，却会导致SQLite事务性能的下降。

      1.在事务执行时间较长或者要修改的数据量达到GB级的时候，WAL文件会被占用，它会暂时阻止checkpoint的执行（checkpoint会清空WAL文件），这将导致WAL文件变得很大，增加寻址时间，最终导致读写性能的下降。

      2.当checkpoint执行的时候，会降低当时的读写性能，因此，WAL可能会导致周期性的性能下降。

 

 

 

 

 

 

Postgresql wal日志

wal日志是什么

WAL即Write-Ahead Logging,预写式日志（WAL）是保证数据完整性的一种标准方法。WAL的中心概念是数据文件（存储着表和索引）的修改必须在这些动作被日志记录之后才被写入，即在描述这些改变的日志记录被刷到持久存储以后。如果我们遵循这种过程，我们不需要在每个事务提交时刷写数据页面到磁盘，因为我们知道在发生崩溃时可以使用日志来恢复数据库：任何还没有被应用到数据页面的改变可以根据其日志记录重做（这是前滚恢复，也被称为REDO）。WAL 的中心思想是先写日志，再写数据，数据文件的修改必须发生在这些修改已经记录在日志文件中之后。

WAL机制实现

实现WAL机制，需要保证脏页在刷新到磁盘前，该数据页相对应的日志记录已经刷新到磁盘中。为了实现WAL机制，当PostgreSQL进行事务提交（脏数据页需要刷新到磁盘）时，需要进行如下操作：

  1. 生成该事务提交的日志记录（唯一标示为LSN–Log sequence number）
  2. 将该LSN之前的xlog日志刷入到磁盘中
LSN标记

为了标记每个数据页最后修改它的日志记录号，在每个数据页的PageHeaderData结构中引入了一个LSN标记，如下：

typedef struct PageHeaderData
{
	PageXLogRecPtr 	pd_lsn; //指向最后修改页面的日志记录
	uint16			pd_checksum;	
	uint16		    pd_flags;			
	LocationIndex  	pd_lower;			
	LocationIndex  	pd_upper;			
	LocationIndex  	pd_special;	
	uint16   		pd_pagesize_version;
	TransactionId     pd_prune_xid; 	
	ItemIdData       pd_linp[1];		
} PageHeaderData;

其中PageXLogRecPtr结构是一个无符号的64位整数，它的含义如下：
32位8位13位11位
逻辑日志文件号 段号 块号 块内偏移

PageXLogRecPtr结构和每个日志记录一一对应，同时LSN是全局统一管理，顺序增加的。

当缓冲区管理器(Bufmgr)写出脏数据页时，必须确保小于页面PageHeaderData中pd_lsn指向的Xlog日志已经刷写到磁盘上了。这里的LSN检查只用于共享缓冲区，用于临时表的local缓冲区不需要，因此临时表是没有WAL日志的，不受WAL机制的保护。

pg的wal配置
  • wal_level
wal_level决定多少信息写入到 WAL 中。默认值是replica， 它写入足够的数据以支持WAL归档和复制，包括在备用服务器上运行只读查询。
但最少的 WAL 不会包括足够的信息来从基础备份和 WAL 日志中重建数据，因此，要启用 WAL 归档（archive_mode）和流复制，必须使用replica或更高级别。
在9.6之前的版本中，此参数还允许值archive和 hot_standby。这些仍然被接受，但映射到replica。
minimal则删除除了从崩溃或立即关闭中恢复所需的信息之外的所有日志记录。logical会增加支持逻辑解码所需的信息。
  • synchronous_commit：
控制事务提交后返回客户端是否成功的策略，代表一个事务是否需要等待 WAL 记录被写入磁盘
on：默认值，为on且没有开启同步备库的时候,会当wal日志真正刷新到磁盘永久存储后才会返回客户端事务已提交成功,
	当为on且开启了同步备库的时候(设置了synchronous_standby_names),必须要等事务日志刷新到本地磁盘,并且还要等远程备库也提交到磁盘才能返回客户端已经提交.
remote_apply：提交将等待， 直到来自当前同步备用数据库的回复表明它们已收到事务的提交记录并应用它， 以便它对备用数据库上的查询可见。
remote_write：提交将等待，直到来自当前同步的后备服务器的一个回复指示该服务器已经收到了该事务的提交记录并且已经把该记录写出到后备服务器的操作系统。
local：当事务提交时,仅写入本地磁盘即可返回客户端事务提交成功,而不管是否有同步备库。
off：写到缓存中就会向客户端返回提交成功，但也不是一直不刷到磁盘，延迟写入磁盘,延迟的时间为最大3倍的wal_writer_delay参数的(默认200ms)的时间,所有如果即使关闭synchronous_commit,也只会造成最多600ms的事务丢失。
	可能会造成一些最近已提交的事务丢失，但数据库状态是一致的，就像这些事务已经被干净地中止。但对高并发的小事务系统来说,性能来说提升较大。
  • wal_writer_delay
WAL writer进程的间歇时间。默认值是200ms。准确的配置应该根据自身系统的运行状况。
如果时间过长可能造成WAL buffer的内存不足；反之过小将会引起WAL的不断的写入，对磁盘的IO也是很大考验。
  • min_wal_size
个已经提交的数据在WAL buffer中存放的时间，单位ms，默认值是0，不用延迟。非0值表示可能存在多个事务的WAL同时写入磁盘。
如果设置为非0，表明了某个事务执行commit后不会立即写入WAL中，而仍存放在WAL buffer中，这样对于后面的事务申请WAL buffer时非常不利，尤其是提交事务较多的高峰期，可能引起WAL buffer内存不足。
如果内存足够大，可以尽量延长该参数值，能够使数据集中写入这样降低了系统的IO，提高了性能。
同样如果此时崩溃数据面临着丢失的危险。个人建议采用默认值，同时将WAL文件存放在IO性能好的磁盘上。

 

检查点
检查点是在事务序列中的点，这种点保证被更新的堆和索引数据文件的所有信息在该检查点之前已被写入。
在检查点时刻，所有脏数据页被刷写到磁盘，并且一个特殊的检查点记录将被写入到日志文件（修改记录之前已经被刷写到WAL文件）。
在崩溃时，崩溃恢复过程检查最新的检查点记录用来决定从日志中的哪一点（称为重做记录）开始REDO操作。在这一点之前对数据文件所做的任何修改都已经被保证位于磁盘之上。
因此，完成一个检查点后位于包含重做记录的日志段之前的日志段就不再需要了，可以将其回收或删除（当WAL归档工作时，日志段在被回收或删除之前必须被归档）。
服务器的检查点进程常常自动地执行一个检查点。检查点在每checkpoint_timeout秒开始，或者在快要超过 max_wal_size时开始。 默认的设置分别是 5 分钟和 1 GB。如果从前一个检查点以来没有WAL被写入， 则即使过了checkpoint_timeout新的检查点也会被跳过。
  • checkpoint_timeout
自动 WAL 检查点之间的最长时间，以秒计。 有效值在30秒和1天之间。 默认是 5 分钟（5min）。 增加这个参数的值会增加崩溃恢复所需的时间。
  • max_wal_size
在自动WAL检查点使得WAL增长到最大尺寸。缺省是1GB。

 

 

 

 

附录：

PostgreSQL

https://www.runoob.com/postgresql/postgresql-tutorial.html

PostgreSQL 是一个免费的对象-关系数据库服务器(ORDBMS)，在灵活的BSD许可证下发行。

PostgreSQL 开发者把它念作 post-gress-Q-L。

PostgreSQL 的 Slogan 是 "世界上最先进的开源关系型数据库"。

https://baijiahao.baidu.com/s?id=1669655888792593702&wfr=spider&for=pc

PostgreSQL不是Oracle公司的，这是相对于MySQL最大的优势，没有之一！

图片来源于网络

MySQL是目前最受欢迎的开源数据库，PostgreSQL则是我认为最先进的开源数据库。MySQL是C/C++混合开发，PostgreSQL则是完全的C语言开发，这是在技术方面的差异，接下来我详细列一下PostgreSQL相对于MySQL优势，当然其实这些也都能招到，我就列举几个比较关键的优势。

图片来源于网络

对比

1.稳定性

PostgreSQL稳定性非常强，InnoDB即使是在断电这种场景下，PostgreSQL也是相当稳定的，这个MySQL用户应该是深有体会的，很多估计都经历过服务器级别的数据丢失。

图片来源于网络

2.储引擎

MySQL是单存储引擎，PostgreSQL是多存储引擎，包括InnoDB、MyISAM等。

3.操作

删除临时表的时候，PostgreSQL语句没有TEMP、TEMPORARY关键字，DROP TABLE通过数据库连接的排列被删除。MySQL支持TEMP、TEMPORARY关键字，DROP TABLE语句只允许删除临时表，要手动删除。PostgreSQL支持CASCADE选择删除表的依赖对象，PostgreSQL的TRUNCATE TABLE支持功能更多。MySQL TRUNCATE TABLE不支持CASCADE食物安全，数据删除之后就没办法回滚了。

4.数据类型

PostgreSQL支持多种高级数据类型，比如array，用户也可以定义类型，MySQL只支持标准类型。PostgreSQL支持布尔型，支持IP地址数据类型，支持常量和函数调用。PostgreSQL支持JSON和其他NoSQL功能，本机支持XML，允许索引JSON数据，MySQL支持JSON，不过不支持其他的NoSQL功能。PostgreSQL的对象统计功能也很强，这一点MySQL也有差距。

5.线程

PostgreSQL是多进程、MySQL是多线程。PostgreSQL支持大多数命令类型上触发的触发器。MySQL是异步复制，PostgreSQL支持同步、异步、半同步复制。PostgreSQL要求所有数据必须完全满足需求，只要出一个错误整个数据入库过程都要失败，不过MySQL没这样的问题。

 
 
 
 

SQLite

百度百科

SQLite，是一款轻型的数据库，是遵守ACID的关系型数据库管理系统，它包含在一个相对小的C库中。它是D.RichardHipp建立的公有领域项目。它的设计目标是嵌入式的，而且已经在很多嵌入式产品中使用了它，它占用资源非常的低，在嵌入式设备中，可能只需要几百K的内存就够了。它能够支持Windows/Linux/Unix等等主流的操作系统，同时能够跟很多程序语言相结合，比如 Tcl、C#、PHP、Java等，还有ODBC接口，同样比起Mysql、PostgreSQL这两款开源的世界著名数据库管理系统来讲，它的处理速度比他们都快。SQLite第一个Alpha版本诞生于2000年5月。 至2019年已经有19个年头，SQLite也迎来了一个版本 SQLite 3已经发布。

 

 

 

 

磁盘读写数据的方式是顺序的吗？

就访问磁盘的位置来说，是随机访问的。但就文件的数据读写，是顺序访问的

随机写是不是比顺序写慢？

作者：Qilan Yuan
链接：https://www.zhihu.com/question/26028619/answer/32932317
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

这个问题要分情况讨论：在机械硬盘上写还是在固态硬盘上写。尽管结论都是顺序写比随机写快，但是原因却是不一样的。

首先说机械硬盘，我先介绍一下它的存储原理。机械硬盘的结构你可以想象成一个唱片机，它有一个旋转的盘片和一个能沿半径方向移动的磁头。处理读取和写入请求时，首先可以根据请求的开始地址算出要处理的数据在磁盘上的位置，之后要进行以下几步工作：
1、磁头沿半径方向移动，直至移动到数据所在的柱面（相同半径的磁道组成的环面）
2、盘片高速旋转，使磁头到达数据的起始位置
3、磁头沿磁道从磁盘读取或写入数据
当一次读取的数据量很少的时候，1、2步骤带来的开销是无法忽略的，这使得随机写相对于顺序写会有巨大的性能劣势。因为在顺序写的时候，1、2步骤只需要执行一次，剩下的全是数据传输所需要的固有开销；而每次随机写的时候，前两个步骤都需要执行，带来了极大的额外开销。

其次说固态硬盘。理论上来说，它不应该存在明显的随机写与顺序写的速度差异，因为它就是一块支持随机寻址的存储芯片，没有寻道和旋转盘片的开销，但是随机写实际上还是比顺序写要慢。这是由于其存储介质闪存的一些特性导致的，简单来说：
1、闪存不支持in-place update：你更新一个数据，不可以直接在原有数据上改，而要写到新的空白的地方，并把原有数据标记为失效。
2、标记失效的数据不是浪费空间么？可以将其清除。但是闪存上清除操作的最小单位是一个大块，大约128K-256K的大小。一次清除会影响到还未标记失效的有用的数据，要先把它们移走。
这种感觉就如同你在网格纸上写一篇文章，一格一格往下写，只能写在空白的格子里；但是你若要清除之前写的内容，只能整行擦除。非常难受而且浪费空间对吧？所以固态硬盘里实现了垃圾回收算法，用来更好地利用存储空间，同时减少数据迁移，保护闪存寿命。
那么随机写显然比顺序写带来更大的碎片化，从而带来更多的垃圾回收开销、数据迁移开销，自然就比顺序写要慢了。
 
 
 

 

posted on 2020-11-25 18:37  秦羽的思考  阅读(11758)  评论(0)  编辑  收藏  举报

Powered by: 博客园 Copyright © 2024 秦羽的思考
Powered by .NET 9.0 on Kubernetes