Skip to content

Commit cdbd5ad

Browse files
digoal zhoudigoal zhou
authored andcommitted
new doc
1 parent cfec4e0 commit cdbd5ad

File tree

6 files changed

+87
-0
lines changed

6 files changed

+87
-0
lines changed

202112/20211230_04.md

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
## 一起学PolarDB - 第7期 - 为什么数据库越大崩溃恢复越慢?
2+
3+
### 作者
4+
digoal
5+
6+
### 日期
7+
2021-12-30
8+
9+
### 标签
10+
PostgreSQL , PolarDB
11+
12+
----
13+
14+
## 背景
15+
懂PostgreSQL, 学PolarDB不难, 就好像有九阳神功护体, 可以快速融会贯通.
16+
对于DBA只要学会PolarDB精髓即可.
17+
对于开发者来说不需要学习, 使用PolarDB和PostgreSQL一样.
18+
19+
#### 为什么数据库越大崩溃恢复越慢?
20+
社区版本:
21+
22+
![pic](20211230_04_pic_001.png)
23+
24+
崩溃后, 需要从上一次完整检查点开始将所有这个时刻以来所有wal日志读取并进行恢复. 为什么慢?
25+
- 1、startup 为单一进程. 再加上wal apply属于同步IO, 所以容易变慢.
26+
- 2、大实例, 为了充分利用内存以及提高SQL稳定性, 通常来说检查点跨度都较大, 可能跨越数十GB, 需要recovery的WAL日志非常多. 增加恢复耗时.
27+
- 3、恢复过程中, 被恢复多block有可能会被挤出shared buffer, 然后再次恢复到这个block对应的wal时, 又不得不从datafile读取出来+wal record进行恢复, 导致IO增加, 也是增加耗时的原因之一.
28+
29+
PolarDB:
30+
![pic](20211230_04_pic_002.png)
31+
32+
采用log index 支持lazy recovery.
33+
- startup 进程仅仅将wal的meta信息解析出来, 并按key: pageid, value: lsn(wal address) 重新组合后存储在logindex中(在shared buffer中存在的page, 标记为outdata(过期), 不存在的页则直接写logindex文件). 所以startup进程不需要读数据文件, 不需要apply. 非常快.
34+
- wal解析完成后, 数据库就算恢复完成, 可以读写了.
35+
- 那么什么时候去执行真正的apply呢?
36+
- 当session读取到某个datablock(page)时, 从logindex 找到对应的wal meta信息, 再从wal文件中获取对应的wal record进行apply.
37+
- 由于session是并行的, 所以recovery更快.
38+
39+
PolarDB的思路是: 异步化(offload 给 session, 按需恢复)、并行化(session 可并行)
40+
41+
效果很显著
42+
![pic](20211230_04_pic_003.png)
43+
44+
45+
本期问题1:
46+
为什么数据库越大崩溃恢复越慢?
47+
- a. wal日志量大
48+
- b. starup采用单一进程并且wal apply是同步IO
49+
- c. 恢复过程中有些block会被挤出shared buffer, 再次恢复同样的数据块增加了IO, 导致变慢
50+
- d. 需要恢复完所有的wal
51+
52+
答案:
53+
- abcd
54+
55+
解释:
56+
- 参考本文内容
57+
58+
本期问题2:
59+
为什么PolarDB崩溃恢复比社区版本快很多?
60+
- a. PolarDB支持logindex特性, 存储了wal日志的meta信息和page的映射关系
61+
- b. PolarDB把崩溃恢复offload到session了, 即实现了异步, 又实现了后台并行.
62+
- c. PolarDB在崩溃恢复时不需要恢复data page的内容
63+
- d. PolarDB不需要崩溃恢复
64+
65+
答案:
66+
- abc
67+
68+
解释:
69+
- 参考本文内容
70+
71+
72+
#### [期望 PostgreSQL 增加什么功能?](https://github.com/digoal/blog/issues/76 "269ac3d1c492e938c0191101c7238216")
73+
74+
75+
#### [PolarDB for PostgreSQL云原生分布式开源数据库](https://github.com/ApsaraDB/PolarDB-for-PostgreSQL "57258f76c37864c6e6d23383d05714ea")
76+
77+
78+
#### [PostgreSQL 解决方案集合](https://yq.aliyun.com/topic/118 "40cff096e9ed7122c512b35d8561d9c8")
79+
80+
81+
#### [德哥 / digoal's github - 公益是一辈子的事.](https://github.com/digoal/blog/blob/master/README.md "22709685feb7cab07d30f30387f0a9ae")
82+
83+
84+
![digoal's wechat](../pic/digoal_weixin.jpg "f7ad92eeba24523fd47a6e1a0e691b59")
85+

202112/20211230_04_pic_001.png

94 KB
Loading

202112/20211230_04_pic_002.png

122 KB
Loading

202112/20211230_04_pic_003.png

109 KB
Loading

202112/readme.md

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

33
### 文章列表
44
----
5+
##### 20211230_04.md [《一起学PolarDB - 第7期 - 为什么数据库越大崩溃恢复越慢?》](20211230_04.md)
56
##### 20211230_03.md [《一起学PolarDB - 第6期 - 为什么failover后逻辑复制会丢数据?》](20211230_03.md)
67
##### 20211230_02.md [《一起学PolarDB - 第5期 - 为什么PG有Double Cache?》](20211230_02.md)
78
##### 20211230_01.md [《一起学PolarDB - 第4期 - 为什么增加RO节点动则数小时?》](20211230_01.md)

README.md

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

8888
### 所有文档如下
8989
----
90+
##### 202112/20211230_04.md [《一起学PolarDB - 第7期 - 为什么数据库越大崩溃恢复越慢?》](202112/20211230_04.md)
9091
##### 202112/20211230_03.md [《一起学PolarDB - 第6期 - 为什么failover后逻辑复制会丢数据?》](202112/20211230_03.md)
9192
##### 202112/20211230_02.md [《一起学PolarDB - 第5期 - 为什么PG有Double Cache?》](202112/20211230_02.md)
9293
##### 202112/20211230_01.md [《一起学PolarDB - 第4期 - 为什么增加RO节点动则数小时?》](202112/20211230_01.md)

0 commit comments

Comments
 (0)