Skip to content

Commit a61ae69

Browse files
committed
improve
1 parent aad246b commit a61ae69

File tree

5 files changed

+64
-0
lines changed

5 files changed

+64
-0
lines changed

201807/20180711_02.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -503,3 +503,6 @@ postgres=# select st_ymax(box2d(ST_GeomFromEWKT('CIRCULARSTRING(220268 150415 1,
503503

504504
[《PostgreSQL 自定义函数表达式选择性评估算法 - Statistics, Cardinality, Selectivity, Estimate》](../201806/20180625_02.md)
505505

506+
507+
<a rel="nofollow" href="http://info.flagcounter.com/h9V1" ><img src="http://s03.flagcounter.com/count/h9V1/bg_FFFFFF/txt_000000/border_CCCCCC/columns_2/maxflags_12/viewers_0/labels_0/pageviews_0/flags_0/" alt="Flag Counter" border="0" ></a>
508+

201807/20180711_03.md

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
## PostgreSQL WAL replay 加速(datapage preload) - 恢复加速, 备库延迟优化
2+
3+
### 作者
4+
digoal
5+
6+
### 日期
7+
2018-07-11
8+
9+
### 标签
10+
PostgreSQL , replace , standby , recovery , preload , 预加载
11+
12+
----
13+
14+
## 背景
15+
PostgreSQL 数据库恢复时,读取wal,如果当前wal page不是full page,则从这笔wal record对应的data file中拿到datapage,与wal record合并,覆盖对应data page。持续读取wal 实现恢复的目的。
16+
17+
需要注意wal是顺序读写,而data file可能是离散读写(大部分oltp业务都是如此),WAL的目的就是要将离散的DATA FILE写变成顺序的IO。
18+
19+
那么问题来了,恢复时,data file就变成了离散的读操作。
20+
21+
在主库WAL产生量非常巨大时,standby recovery(replay)将会导致与主库的延迟,通常wal write不会有大的延迟(因为WAL是顺序写),replay的延迟主要是recovery时data file的离散读导致。
22+
23+
如何降低离散读呢?
24+
25+
26+
DBAs struggling with replication lag is nothing new. A large volume of data or write IO comes into the system and the followers struggle to keep up. pg_prefaulter was written to eliminate replication lag on followers and also improves database startup times.
27+
28+
If your database is under 24/7 write workload, has periodic replication lag that is unacceptable, or want to reduce the startup time of PostgreSQL, pg_prefaulter will help all three of these scenarios.
29+
30+
At Joyent we use PostgreSQL as the metadata tier for our object storage system, Manta. This talk chronicles how we identified our source of replication lag and why we found it necessary to write pgprefaulter. pgprefaulter is a sidecar process for PostgreSQL written in Go that pre-fetches pages from disk and loads them into the operating system's filesystem cache before PostgreSQL requests them during the startup and application of WAL records.
31+
32+
Additionally, this talk also discusses:
33+
34+
the design considerations that went into writing pg_prefaulter
35+
the various forms of "replication lag" in PostgreSQL (WAL receive lag, WAL apply lag, and checkpoint lag)
36+
pathologies that came from deploying pg_prefaulter
37+
why we now consider pg_prefaulter mission critical software for our production databases
38+
tips for deploying pg_prefaulter
39+
40+
## 优化方法
41+
在备库接收到WAL后,解析WAL,并提前将需要用到的DATA FILE PAGE加载到OS PAGE CACHE中,在postgresql startup process replay wal时,读取需要的data page时,从os cache读取,从而降低replay时因为读取data page带来的IO等待。
42+
43+
patch:
44+
45+
http://www.postgresql-archive.org/WAL-prefetch-td6024900.html
46+
47+
## 参考
48+
[pg_prefaulter: Scaling WAL Performance (application/pdf - 2.6 MB)](20180711_03_pdf_001.pdf)
49+
50+
http://www.postgresql-archive.org/WAL-prefetch-td6024900.html
51+
52+
http://www.pgcon.org/2018/schedule/events/1204.en.html
53+
54+
https://github.com/joyent/pg_prefaulter
55+
56+
57+
58+
<a rel="nofollow" href="http://info.flagcounter.com/h9V1" ><img src="http://s03.flagcounter.com/count/h9V1/bg_FFFFFF/txt_000000/border_CCCCCC/columns_2/maxflags_12/viewers_0/labels_0/pageviews_0/flags_0/" alt="Flag Counter" border="0" ></a>
59+

201807/20180711_03_pdf_001.pdf

2.64 MB
Binary file not shown.

201807/readme.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,7 @@
22

33
### 文章列表
44
----
5+
##### 20180711_03.md [《PostgreSQL WAL replay 加速(datapage preload) - 恢复加速, 备库延迟优化》](20180711_03.md)
56
##### 20180711_02.md [《PostgreSQL 空间类型统计信息不准确导致SQL执行计划不准(包含、相交查询)的优化实践》](20180711_02.md)
67
##### 20180711_01.md [《PostgreSQL jdbc 错误代码映射(SQLSTATE)》](20180711_01.md)
78
##### 20180704_04.md [《PostgreSQL quorum based同步复制模式在极端情况下的0丢失破坏问题》](20180704_04.md)

README.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -31,6 +31,7 @@ digoal's|PostgreSQL|文章|归类
3131

3232
### 未归类文档如下
3333
----
34+
##### 201807/20180711_03.md [《PostgreSQL WAL replay 加速(datapage preload) - 恢复加速, 备库延迟优化》](201807/20180711_03.md)
3435
##### 201807/20180711_02.md [《PostgreSQL 空间类型统计信息不准确导致SQL执行计划不准(包含、相交查询)的优化实践》](201807/20180711_02.md)
3536
##### 201807/20180711_01.md [《PostgreSQL jdbc 错误代码映射(SQLSTATE)》](201807/20180711_01.md)
3637
##### 201807/20180704_04.md [《PostgreSQL quorum based同步复制模式在极端情况下的0丢失破坏问题》](201807/20180704_04.md)

0 commit comments

Comments
 (0)