Update 20210915_07.md

Author: digoal

202109/20210915_07.md

@@ -22,33 +22,39 @@ PostgreSQL , 崩溃恢复
 - 恢复需要用到从上一个完成的检查点的逻辑开始位点处的WAL日志 - 到最新的WAL日志文件之间的所有WAL文件.  
     - 需要多少个wal文件取决于检查点的长短, 通常内存很大的机器, 会设置较大的shared buffer, 同时设置较长的checkpoint周期来优化数据库写性能.   
 - 恢复过程中被恢复的数据块包含full page时, 只需要从wal拿对应full page+wal增量record进行恢复, 但是恢复过程中数据块可能从shared buffer挤出, 那么就需要从datafile读取对应块然后+wal record恢复.   
-    - 这可能是非常耗费IO的操作  
+    - 这可能是非常耗费IO的操作. shared buffer较小时block被反复挤出和读入, IO消耗更加明显.   
 
 3、这个问题将影响哪些行业以及业务场景  
 - 所有行业, 特别是规格大的实例  
 
 4、会导致什么问题?  
 - IO如果较差的话, 崩溃恢复速度慢.  
-- 特别是在业务高峰期, 如果出现OOM的话, 崩溃恢复时间长对业务造成的影响巨大  
+- 特别是在业务高峰期 + 检查点长 + IO延迟高, 如果系统出现OOM的话, 崩溃恢复时间长对业务造成的影响巨大  
 
 5、业务上应该如何避免这个坑  
 - 使用standby, 如主库崩溃, 激活从库.  
-- 不管是数据文件还是wal文件都使用性能好(IOPS 以及 吞吐、RT)的SSD  
+- 不管是数据文件还是wal文件都使用性能好(IOPS高、带宽吞吐大、单次IO RT低)的SSD  
 - 缩短checkpoint周期, 让一个周期内的wal文件尽量的少  
 
 6、业务上避免这个坑牺牲了什么, 会引入什么新的问题  
 - 使用HA架构会增加风险和复杂度, 例如双节点的异步HA, 可能丢数据风险. 三节点的同步HA, 成本高, 复杂度高.   
-- 使用很好的SSD, 增加了成本  
-- 提高checkpoint频率, 会损耗写性能. 并且会导致full page增加, 使得产生更多的wal文件  
+- 使用性能很好的SSD(IOPS高、带宽吞吐大、单次IO RT低), 增加了成本  
+- 提高checkpoint频率, 会损耗写性能. 并且会导致full page write增加, 使得产生更多的wal文件, 甚至导致standby的延迟增加   
     - [《PolarDB 为什么要解决FPW的性能问题?》](../202108/20210809_01.md)    
     - [《DB吐槽大会,第11期 - FPW | Double Write》](../202108/20210830_02.md)    
 
 7、数据库未来产品迭代如何修复这个坑  
 - 希望内核层面支持更友好的恢复功能  
     - 并行的恢复, 提高恢复速度. 目前PolarDB支持并行wal回放  
-    - 例如可以支持立即开放只读功能, 恢复过程允许只读操作，自动过滤不一致数据块，或自动使用旧快照  
-        - polardb pg共享存储版本支持lazy恢复模式, 几乎可以毫秒级恢复.   
-        - https://github.com/alibaba/PolarDB-for-PostgreSQL    
+    - 例如可以支持立即开放只读功能, 恢复过程允许只读操作，自动过滤不一致数据块，或自动使用旧的快照, 又或者读到该数据块时再进行恢复(这个必须使用PolarDB)    
+        - polardb pg共享存储版本支持lazy恢复模式, 几乎可以毫秒级恢复. 原理参考: [《一起学PolarDB - 第7期 - 为什么数据库越大崩溃恢复越慢?》](../202112/20211230_04.md)     
+        - https://github.com/alibaba/PolarDB-for-PostgreSQL  
+  
+如果你对PolarDB感兴趣, 可以阅读:   
+- [《2024-开源PolarDB|PostgreSQL 应用开发者&DBA 公开课》](../202310/20231030_02.md)   
+- [《《一起学PolarDB》系列》](../202203/20220314_01.md)  
+  
+  
 
 
 #### [PostgreSQL 许愿链接](https://github.com/digoal/blog/issues/76 "269ac3d1c492e938c0191101c7238216")