dedecms5.7装饰网站模板,wordpress主题怎么制作,蝙蝠做等级的网站,如何自己建网址日志
如果发生停电、操作系统错误或数据库服务器崩溃等故障#xff0c;RAM中的所有内容都将丢失#xff1b;只有写入磁盘的数据才会被保留。要在故障后启动服务器#xff0c;必须恢复数据一致性。如果磁盘本身已损坏#xff0c;则必须通过备份恢复来解决相同的问题。
理论…日志
如果发生停电、操作系统错误或数据库服务器崩溃等故障RAM中的所有内容都将丢失只有写入磁盘的数据才会被保留。要在故障后启动服务器必须恢复数据一致性。如果磁盘本身已损坏则必须通过备份恢复来解决相同的问题。
理论上您可以始终保持磁盘上的数据一致性。但在实践中这意味着服务器必须不断地将随机页面写入磁盘(尽管顺序写入更便宜)而且这种写入的顺序必须保证在任何特定时刻都不会损害一致性(这很难实现特别是在处理复杂的索引结构时)。
就像大多数数据库系统一样PostgreSQL使用了不同的方法。
当服务器运行时一些当前数据仅在RAM中可用将其写入永久存储器被推迟。因此在服务器操作期间存储在磁盘上的数据总是不一致的因为页面永远不会一次刷新。但是在RAM中发生的每个更改(例如在缓冲区缓存中执行的页面更新)都被记录下来PostgreSQL创建一个日志条目其中包含在需要时重复此操作所需的所有基本信息。
与页面修改相关的日志条目必须在被修改的页面本身之前写入磁盘。因此该日志的名称为预写日志(write-ahead log)或WAL。这个要求保证了在发生故障的情况下PostgreSQL可以从磁盘读取WAL条目并重放它们以重复已经完成的操作这些操作的结果仍然在RAM中并且在崩溃之前没有将其保存到磁盘中。
保持预写日志通常比将随机页面写入磁盘更有效。WAL条目构成连续的数据流甚至可以由HDD处理。此外WAL条目通常小于页面大小。
在发生故障时需要记录所有可能破坏数据一致性的操作。具体来说在WAL中记录了以下动作
在缓冲缓存中执行的页面修改——因为写操作被延迟事务提交和回滚—因为状态更改发生在CLOG缓冲区中而不会立即将其转移到磁盘文件操作(比如在添加或删除表时创建和删除文件和目录)——因为这些操作必须与数据更改同步
以下操作不被记录
UNLOGGED表的操作对临时表的操作——因为它们的生命周期受到生成它们的会话的限制
在PostgreSQL 10之前哈希索引也不被记录。它们的唯一目的是将哈希函数与不同的数据类型相匹配。
除了崩溃恢复之外WAL还可以用于从备份和复制中进行时间点恢复。
WAL结构
逻辑结构
谈到它的逻辑结构我们可以将WAL描述为可变长度的日志条目流。每个条目包含一些关于特定操作的数据前面有一个标准头。除其他事项外头文件提供以下信息
和条目有关于的事务ID解释条目的资源管理器检测数据损坏的校验和条目长度对前一个WAL条目的引用
WAL通常是向前读取的但是一些实用程序(如pg_rewind)可能会向后扫描它。
WAL数据本身可以具有不同的格式和含义。例如它可以是一个页片段它必须在指定的偏移量处替换页的某些部分。相应的资源管理器必须知道如何解释和重放特定的条目。表、各种索引类型、事务状态和其他实体都有单独的管理器。
WAL文件占用服务器共享内存中的特殊缓冲区。WAL使用的缓存大小由wal_buffers参数定义。默认情况下自动选择该大小为总缓冲区缓存大小的1/32。
WAL缓存与缓冲区缓存非常相似但它通常以环形缓冲区模式运行新条目添加到其头部而旧条目从尾部开始保存到磁盘。 如果WAL缓存太小则执行磁盘同步的频率将超出必要的范围。
在低负载情况下插入位置(缓冲区的头部)几乎总是与已经保存到磁盘的条目的位置(缓冲区的尾部)相同 在PostgreSQL之前所有函数名都包含XLOG缩写而不是WAL。
为了引用一个特定的条目PostgreSQL使用一个特殊的数据类型pg_lsn(日志序列号LSN)。它表示从WAL开始到条目的64位字节偏移量。LSN表示为两个32位的十六进制数中间用斜杠分隔。
创建一个表 启动一个事务并记录WAL插入位置的LSN 现在运行一些任意命令例如更新一行 页面修改在RAM中的缓冲缓存中执行。此更改记录在WAL页面中也记录在RAM中。因此插入LSN被提前 为了确保修改后的数据页严格在相应的WAL条目之后被刷新到磁盘页头存储了与该页相关的最新WAL条目的LSN。你可以使用pageinspect查看LSN 整个数据库集群只有一个WAL并且不断向其添加新条目。由于这个原因存储在页面中的LSN可能比前一段时间pg_current_wal_insert_lsn函数返回的LSN要小。但是如果系统中什么都没有发生这些数字将是相同的。
现在提交事务 提交操作也被记录插入LSN再次更改 提交更新CLOG页面中的事务状态这些页面保存在它们自己的缓存中。CLOG缓存通常在共享内存中占用128页。为了确保在相应的WAL条目之前不会将CLOG页面刷新到磁盘还必须跟踪CLOG页面的最新WAL条目的LSN。但是这些信息存储在RAM中而不是页面本身。
在某个时刻WAL条目将被写入磁盘然后就可以从缓存中驱逐CLOG和数据页。如果必须更早地驱逐它们则会发现它并且会先将WAL条目强制写入磁盘。
如果您知道两个LSN位置则可以通过简单地从一个位置减去另一个位置来计算它们之间的WAL条目的大小(以字节为单位)。你只需要将它们强制转换为pg_lsn类型 在本例中与UPDATE和COMMIT操作相关的WAL条目占用了大约100个字节。
您可以使用相同的方法来估计特定工作负载在单位时间内生成的WAL条目的数量。检查点设置将需要这些信息。
物理结构
在磁盘上WAL作为单独的文件或段存储在PGDATA/pg_wal目录中。它们的大小由只读的wal_segment_size参数显示。
对于高负载系统增加段大小是有意义的因为它可以减少开销但是这个设置只能在集群初始化期间修改(initdb --wal-segsize)。
WAL条目进入当前文件直到空间用完然后PostgreSQL启动一个新文件。
我们可以知道一个特定的条目位于哪个文件中以及从文件开始的偏移量 文件名由两部分组成。最高的8个十六进制数字定义了用于从备份中恢复的时间线而其余的数字表示最高的LSN位(最低的LSN位显示在file_offset字段中)。
要查看当前的WAL文件可以调用以下函数 现在让我们使用pg_waldump实用程序查看新创建的WAL条目的头该实用程序可以根据LSN范围(如本例中所示)和特定事务ID过滤WAL条目。
应该使用postgres操作系统用户启动pg_waldump实用程序因为它需要访问磁盘上的WAL文件。 这里我们可以看到两个条目的标题。
第一个是由Heap资源管理器处理的HOT_UPDATE操作。blkref字段显示了更新后的堆页的文件名和页ID 第二个条目是由事务资源管理器监督的COMMIT操作。
检查点
在失败后恢复数据一致性(即执行恢复)PostgreSQL必须往前重放WAL并将代表丢失的更改的条目应用到相应的页面。为了找出丢失的内容将存储在磁盘上的页面的LSN与WAL条目的LSN进行比较。但我们应该从什么时候开始复苏呢?如果我们开始得太晚在此之前写入磁盘的页面将无法接收到所有更改这将导致不可逆转的数据损坏。从头开始是不现实的:不可能存储如此庞大的潜在数据量也不可能接受如此长的恢复时间。我们需要一个逐渐向前移动的检查点这样可以安全地从该点开始恢复并删除所有以前的WAL条目。
创建检查点最直接的方法是定期挂起所有系统操作并将所有脏页强制放到磁盘上。这种方法当然是不可接受的因为系统将挂起一段不确定但相当重要的时间。
由于这个原因检查点随着时间的推移而分散实际上构成了一个间隔。检查点的执行是由一个叫做checkpointer的特殊后台进程执行的。 检查点开始。 checkpointer进程将可以立即写入的所有内容刷新到磁盘CLOG事务状态、子事务的元数据和一些其他结构。 检查点执行。 检查点执行的大部分时间都花在将脏页刷新到磁盘上。首先在检查点开始时已脏的所有缓冲区的标头中设置一个特殊标记。由于不涉及I/O操作因此它发生得非常快。然后checkpointer进程遍历所有缓冲区并将标记的缓冲区写入磁盘。它们的页面不会从缓存中被驱逐它们只是被写下来因此使用量和pin计数可以忽略。页面按照其ID的顺序进行处理以尽可能避免随机写入。为了更好地实现负载平衡PostgreSQL 在不同的表空间之间进行切换 (因为它们可能位于不同的物理设备上)。后端也可以将带标签的缓冲区写入磁盘——如果它们先到达的话。在任何情况下缓冲区标记都在此阶段被删除因此出于检查点的目的每个缓冲区将只被写入一次。当然当检查点正在进行时仍然可以在缓冲缓存中修改页面。但是由于新的脏缓冲区没有标记checkpointer将忽略它们。 检查点完成。 当检查点开始时所有脏的缓冲区都被写入磁盘时就认为检查点完成了。从现在开始(但不是更早!)检查点的起点将被用作恢复的新起点。不再需要在此之前编写的所有WAL条目。 最后checkpointer创建一个与检查点完成相对应的WAL条目指定检查点的起始LSN。 由于检查点在启动时不记录任何日志因此该LSN可以属于任何类型的WAL条目。
PGDATA/global/pg_control文件也得到更新以引用最新完成的检查点。 (在此过程结束之前pg_control将保留前一个检查点。) 为了一劳永逸地弄清楚哪些点在哪里让我们看一个简单的例子。我们将使几个缓存页面变脏 现在让我们手动完成检查点。所有脏页都将刷新到磁盘由于系统中没有发生任何事情因此不会出现新的脏页 让我们看看检查点是如何反映在WAL中的 最新的WAL条目与检查点完成(CHECKPOINT_ONLINE)有关。 这个检查点的起始LSN在redo后面指定这个位置对应于检查点开始时最近插入的WAL条目。
同样的信息也可以在pg_control文件中找到 恢复
在服务器启动时启动的第一个进程是postmaster。反过来postmaster生成startup进程在发生故障时负责数据恢复。
为了确定是否需要恢复启动进程读取pg_control文件并检查集群状态。pg_controldata实用程序使我们能够查看这个文件的内容 正常停止的服务器处于“shut down”状态非运行服务器的“in production”状态表示故障。在这种情况下启动进程将自动从同一个pg_control文件中找到的最近完成的检查点的起始LSN启动恢复。
如果PGDATA目录包含与备份相关的backup_label文件则从该文件获取起始LSN位置。 启动进程从定义的位置开始逐条读取WAL条目如果页面的LSN小于WAL条目的LSN则将其应用于数据页。如果页面包含较大的LSN则不应用WAL事实上它不能被应用因为它的条目被设计成严格按顺序重放。
然而一些WAL条目构成了一个完整的页面映像(FPI)。这种类型的条目可以应用于页面的任何状态因为无论如何都会擦除所有页面内容。这样的修改称为幂等的。幂等操作的另一个例子是注册事务状态更改:每个事务状态在CLOG中由某些位定义这些位的设置与它们以前的值无关因此不需要在CLOG页面中保留最新更改的LSN。
WAL条目应用于缓冲缓存中的页面就像在正常操作期间的常规页面更新一样。
以类似的方式从WAL中恢复文件例如如果WAL条目显示该文件必须退出但由于某种原因丢失则将重新创建该文件。
一旦恢复结束所有未记录的关系将被相应的初始化分支覆盖。
最后执行检查点以保护磁盘上恢复的状态。
启动过程的工作现在已经完成。
在经典形式中恢复过程包括两个阶段。在前滚阶段重放WAL条目重复丢失的操作。在回滚阶段服务器中止在发生故障时尚未提交的事务。 在PostgreSQL中第二阶段是不需要的。在恢复之后CLOG将既不包含未完成事务的提交位也不包含未完成事务的abort位(技术上表示活动事务)但是由于可以确定事务不再运行因此将认为它已终止。
我们可以通过强制服务器在immediate模式下停止来模拟故障 当我们启动服务器时启动进程看到发生了故障并进入恢复模式 如果服务器正常停止postmaster断开所有客户机的连接然后执行最后一个检查点将所有脏页刷新到磁盘。
注意当前的WAL位置 现在让我们正确地停止服务器 下面是新的集群状态 在WAL的末尾我们可以看到CHECKPOINT_SHUTDOWN条目它表示 最后一个检查点 最新的pg_waldump消息表明该实用程序已将WAL读取到最后。
让我们重新启动实例 后台写
如果后端需要从缓冲区中驱逐脏页则必须将该页写入磁盘。这种情况是不希望出现的因为它会导致等待——在后台异步执行写入要好得多。
这个任务部分由checkpointer来完成但是这还不够。
因此PostgreSQL提供了另一个名为bgwriter的进程专门用于后台写操作。它依赖于与驱逐相同的缓冲区搜索算法除了两个主要区别
bgwriter进程使用自己的时钟指针它从不落后于驱逐进程而且通常会超过驱逐进程。在遍历缓冲区时使用计数不会减少。
如果缓冲区没有固定且使用计数为零则将脏页刷新到磁盘。因此bgwriter在驱逐之前运行并主动将那些极有可能很快被驱逐的页面写入磁盘。
它提高了被选中用于驱逐的缓冲区是干净的可能性。
