PgSQL · 特性分析 · 神奇的pg

  • 时间:
  • 浏览:0
  • 来源:uu快3下载网址_uu快3IOS下载_电脑版

朋友会在pg_rewind 的用法当中删剪说明两者的区别。注意:这里拷贝的就是表数据文件,下文会具体将满足那先 条件的才是表数据文件。

在常见的PostgreSQL双节点高可用构架中,机会主库挂了且主备无延迟,高可用系统会提升老备库为新主库对外服务。而对于老主库,则都后能 不都后能 有某些某些处置策略,类似:

很显然,相比来说第三种都不 个很好的方案。当数据量比较大时,重搭备库的时间成本太高,系统的可用性降低。或者机会老的主库挂掉的是因为 多种多样,甚至有机会是高可用系统的误判,而老主库都不 机会是在挂掉完后 又重新作为主库启动起来,这个完后 降级并重搭流基因重组关系的操作都不 机会失败(新的备库比新主库数据更超前)。

通过第2步骤中找到的 一定是另一4个 集群数据一致的位点,即前文中另一4个 集群的分叉点。或者这某些的数据都后能 够保证数据的删剪性和一致性,某些某些实际上pg_rewind 会以这个位点完后 的最近的checkpoint 点作为另一4个 集群的分叉点。

其中,值得注意的是,第3步机会源集群没办法 对应的page 咋整 办?经过分析代码,朋友发现机会源集群没办法 对应的page,该page 我过多 被标记为居于变化的page,而该文件的action 会被置为FILE_ACTION_TRUNCATE,在第4步中将对应的文件进行相应的删减。

pagemap 存储了另一4个 bitmap,每一位存储了对应的目的集群文件中的每个page 从另一4个 集群的分叉点完后 否是 居于了变化,1代表居于变化,0代表未变化。

励志的话 概括,pg_rewind 都后能 不都后能 快速找到另一4个 集群数据随后随后刚开始 英语 分叉的点,或者找到目的集群从该点完后 的数据变化,通过拷贝源集群的对应数据页,再通过应用源集群的WAL 日志达到数据一致。

不过这里有十多少 间题值得朋友探究:

file_action_t action指示该文件(目录)对应的处置action,包括以下几种:

接下来,朋友将深入代码(代码分析基于10.0版本)分析这十多少 间题。

另外,使用文件的大小来进行数据变化的比较真的可行吗?会我过多 出現另一4个 集群修改的数据是相同的,是因为 实际上文件大小是相同的,或者这时机会数据页头的pd_lsn 等信息机会是不同的,影响数据同步后的数据可见性。或者随便说说 即使这个具体情况居于了,也对数据的同步没办法 影响,机会pg_rewind 随后随后刚开始 英语 完后 ,朋友都后能 不都后能 通过应用源集群的WAL 日志重新恢复该page。

励志的话 概括,pg_rewind 通过文件的大小比较和目的集群的WAL 日志来选取那先 文件(目录)居于了变化,并使目的集群在pg_rewind 随后随后刚开始 英语 完后 通过应用源集群的WAL 日志来完成所有的数据同步。这都后能 否不都后能 注意的是,一定要保证目的集群从上文中另一4个 集群的分叉点到现在的WAL 日志是连续的,没办法 被移除,或者在找另一4个 集群的分叉点时就会报错。

PostgreSQL 提供了pg_controldata 工具,朋友都后能 不都后能 执行pg_controldata $PGDATA 命令解析PGDATA 下的pg_control 文件,返回结果如下:

在PostgreSQL,备库提升为主库完后 会产生history 文件(关于备库提升为主库的过程这里不再删剪介绍,里边的月报朋友会具体分析)。而history 文件居于WAL 日志所在的目录$PGDATA/pg_wal(10.0完后 的版本是pg_xlog),主要内容分为以下三列,每列之间用tab分割,比如00000006.history的具体内容如下所示:

经过以上的分析,朋友了解了pg_rewind 的某些具体实现,下面简单介绍下它的使用法子。

pg_rewind 工具主要实现了从源集群到目的集群的文件级别数据同步。或者和rsync的区别是,pg_rewind 都后能 都后能 去读那先 未变化的文件块,当数据量比较大而变化较小的完后 ,pg_rewind会变慢。

从上文可见,都后能 不都后能 那我不都后能 保证WAL 日志记录了新老主库的所有数据差异,建议结合归档WAL 日志文件来使用pg_rewind。另外,在对pg_rewind 的分析中,history 文件用于寻找另一4个 集群的分叉点,朋友这里就是简单分析了其内容,其具体的生成法子与生成时机将在里边的月报中继续分析,敬请期待。

很糙注意:pg_rewind 都后能 使用root 用户运行,都后能 不都后能 使用PostgreSQL superuser 用户运行。

isrefile 表示该文件否是 另一4个 表数据文件,表数据文件的路径要满足以下十多少 条件:

-V

--version

显示pg_rewind 的版本号。

--debug

增加该选项会显示pg_rewind 的debug 信息。

在PostgreSQL 的双节点高可用构架中,pg_rewind 提供了三种让比新主库数据超前的老主库降级为另一4个 新备库的法子。这对于较大的实例来说,大大缩短了重建备库的时间,减少了单点的风险,提高了集群的可用性。

其中,file_type_t type 代表文件类型有三种:

--source-server=connstr

定义连接到源集群的 libpq 连接串。这个连接都后能 不都后能 是另一4个 超级用户创建的普通连接,都不 另一4个 流基因重组的连接,关于PostgreSQL 的libpq的各种类型和分析,朋友会在里边的月报进行代码层面的分析。当然这个参数要求源集群比较是健康的,可连接的。

机会history 文件中记录了每次时间线的切换信息,PostgreSQL 通过遍历另一4个 集群的history 文件中每一行,都后能 不都后能 找到两者数据走向不同分支的timeline 和switchpoint。具体逻辑如下:

值的注意的是,pg_rewind为了我过多 都后能 支持文件级别的数据同步,另一4个 集群都打开如下参数:

都后能 不都后能 看出,实际上假若保证目的集群的每个对应的表数据文件比源集群的表数据文件小,在pg_rewind 随后随后刚开始 英语 完后 ,这个表数据文件都后能 不都后能 通过应用源集群的WAL 日志恢复出相同的数据。

至此,朋友得到了所有目的集群都后能 不都后能 变化的文件(目录)和对应action 以及目的集群数据文件变化的page。接下来,pg_rewind 会进行如下具体操作,完成了对目的集群所有文件的修改:

为了在PostgreSQL 中实现文件级别同步数据的功能,pg_rewind 主要进行了如下的处置步骤:

其中:

或者,pg_rewind 实现新老主库的数据同步,是有某些某些前提条件的:

其中,pg_control version number 标示pg_control 文件的文件社会形态版本,Catalog version number标示数据库系统表的社会形态版本。在PostgreSQL的版本迭代中,pg_control文件的社会形态和数据库系统表的社会形态机会有所不同,通过这另一4个 version number 标示不同的社会形态版本。

--source-pgdata=directory

定义源集群的文件系统路径。这个参数生效时源集群都后能 不都后能 机会停止了,或者会报“source data directory must be shut down cleanly”错误。

具体参数含义如下:

-D directory

--target-pgdata=directory

定义目的集群的数据目录。注意:运行pg_rewind完后 目的集群必都后能 不都后能 停止。或者在执行 pg_rewind 都会报“target server must be shut down cleanly”错误。

pg_rewind 的具体用法如下:

title: PgSQL · 社会形态分析 · 神奇的pg_rewind

-n

--dry-run

不去运行initdb -S命令。

根据上文可知,基于同一集群的另一4个 副本是都后能 不都后能 执行pg_rewind的。而在PostgreSQL 中,使用pg_control 文件中的system_identifier 唯一标示一次PostgreSQL数据库的initdb 过程,其生成法子如下:

system_identifier 一旦生成就我过多 变化,而通过拷贝数据文件法子进行数据基因重组(包括pg_basebackup)的法子机会有相同的system_identifier,某些某些基因重组的源集群和目的集群被认为拥有相同的祖先集群,即理论上是都后能 不都后能 使用pg_rewind 进行数据同步的。

完后 说过,pg_rewind 工具执行都后能 不都后能 打开full_page_writes,而打开了full_page_writes 完后 ,checkpoint 后每个数据页的第一次修改对应的数据页的删剪内容都会写在WAL日志记录中,某些某些pg_rewind 都后能 不都后能 根据WAL 日志的组织社会形态(详见完后 的月报)很容易的找到对应机会修改的数据页信息,并把对应的file_entry_t 的bitmap 置为1。

在PostgreSQL 官方文档的介绍中,pg_rewind 不光都后能 不都后能 针对里边说的failover 的场景,理论上,它都后能 不都后能 使基于同一集群基因重组的任意另一4个 副本(集群)进行同步。为了更容易理解,本文把这里的源副本称为源集群,目的副本称为目的集群。

-P

--progress

增加该选项会粗略地显示整个过程的进度条。

以上十多少 参数打开,才我过多 都后能 保证通过WAL 日志恢复出来的数据是删剪的,一致的,从而才我过多 都后能 实现文件级别的数据同步。

为了处置这个具体情况,PostgreSQL 引入了pg_rewind工具。

pg_rewind 会去遍历源集群和目的集群的目录,将每个文件(目录)的差异被记录在社会形态体 file_entry_t 中,其定义如下:

通过分析代码,pg_rewind 生成的backup label 的内容如下:

-?

--help

显示help 文档。

而通过完后 的月报分析可知,backup label 中的CHECKPOINT LOCATION 规定了在线恢复的起始位置,而pg_rewind 这个值存的就是上文中的另一4个 集群的分叉点。而在pg_rewind 随后随后刚开始 英语 完后 ,目的集群就都后能 不都后能 不断应用源集群从CHECKPOINT LOCATION 完后 的WAL 日志,来完成另一4个 集群的数据同步。

oldsize 代表目的集群该文件的大小,newsize 代表源集群该文件的大小。pg_rewind 中通过源集群和目的集群的对应文件大小比较机会文件(目录)否是 居于,指定文件的处置action,类似:

当然,在pg_rewind 的执行过程中,除了 判断源集群和目的集群的 system_identifier 一致性之外,都后能 不都后能 判断: