2个人干3个人的活？这思想用在数据库绝了！
digoal约 3 分钟文中参考文档在github需点击阅读原文打开, 同时推荐2个学习环境:
1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》
从3副本到2.5副本?
https://www.bilibili.com/video/BV1Lm4y1d7ed/
为了提高数据库集群的可靠性, 我们通常会采用数据库多副本的功能, 例如一份数据3个副本(1主2从), 或者一份数据2个副本(1主1从).
为了保障极端场景的0事务丢失, 同时保证高可用(某一个节点故障, 可以切换到另1个节点), 至少需要1个与主节点完全同步的副本.
对于跨地域的部署架构, 为了同时保证可用性和可靠性, 通常会选择3节点的部署架构(A地域部署同步的主从节点+B地域的异步从节点). 这么做的原因是降低跨地域同步带来的RT增加.
社区版本:
PostgreSQL 社区版本支持quorum based sync replication功能, 可以配置同步副本数. 但是每个节点都必须是完整的才能参与failover的选举, 或者将wal日志转发给其他节点.
社区版本采用典型的3节点架构.
虽然 pg_receivewal 可以实时接收WAL, 但是它不支持将接收到的内容再通过流复制协议发送给其他的节点. 不友好, 无法实现实时wal文件中继.
弊端:
数据和日志都有3份, 性价比较低.
WAL日志都需要从主库传输, 需要2条流复制链路, 主库的压力较大
PolarDB:
datamax组件: 简单的理解是整合了pg_receivewal + wal sender的功能.
优势:
数据只需要2份, 3份日志
主节点只需要一份同步链路, 减轻了主库的wal sender负担
中继节点无需要回放日志, 效率、稳定性都比完整的从库节点更高
PolarDB PG 的部署架构相当于2.5节点. 而不是3节点.
本期问题1:
为什么pg_receivewal不能作为wal的实时中继节点?
a. pg_receivewal 只接收日志文件, 不接收数据文件
b. pg_receivewal 只能接收日志, 不能发送日志
c. pg_receivewal 不是采用流复制协议的
d. pg_receivewal 采用的是流复制协议
答案:
b
解释:
参考本文内容
本期问题2:
PolarDB datamax通常被用于跨地域的高可靠和高可用部署架构中, datamax组件有哪些功能?
a. 实时接收wal日志
b. 实时接收数据文件
c. 实时发送wal日志
d. 实时发送数据文件
答案:
ac
解释:
参考本文内容
欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.
近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号:
文章中的参考文档请点击阅读原文获得.