关于greenplum:特性分析-GreenPlum-PrimaryMirror-同步机制

本文首发于 2016-01-21 20:02:26

引言

PostgreSQL 主备同步机制是通过流复制实现，其原理见 PG 主备流复制机制。

Greenplum 是基于 PostgreSQL 开发的，它的主备也是通过流复制实现，然而 Segment 节点中的 Primary 和 Mirror 之间的数据同步是基于文件级别的同步实现的。

为什么 Primary 和 Mirror 不能再应用流复制实现呢？

次要有两个起因:

1. Append Only 表不写 WAL 日志，所以 Append Only 表的数据就不能通过 XLOG 发送到 Mirror 再 Apply。
2. pg_control等文件也是不写 WAL 日志，也只能通过文件形式同步到 Mirror。

GreenPlum 总体构造

Greenplum 的架构采纳了 MPP 无共享体系。在 MPP 零碎中，每个数据节点有本人的 CPU、磁盘和内存 (Share nothing)，每个节点内的 CPU 不能拜访另一个节点的内存。节点之间的信息交互是通过节点互联网络实现的，这个过程个别称为 数据重调配(Data Redistribution)。

Master 负责协调整个集群，一个数据节点能够配置多个节点实例(Segment Instances)，节点实例并行处理查问(SQL)。

Primary 和 Mirror 同步机制

Primary 和 Mirror 同步的内容次要有两局部，即 文件 和数据。之所以 Primary 和 Mirror 要同步文件，是 Primary 和 Mirror 之间能够主动 failover，只有两者放弃同步能力互相代替。如果只把数据同步过来，pg_control、pg_clog、pg_subtrans 没有同步，那么从 Primary 切换到 Mirror 会呈现问题。

Master 和 slave 却不必放心这些问题，Append Only 表的数据只会存在 Segment，所以 WAL 日志足够放弃 Master 和 slave 同步(只有是流复制，pg_control、pg_clog、pg_subtrans 这些文件 Slave 会自动更新，无需从 Master 同步)。

1. 数据同步

当 Master 向 Primary 下发执行打算后，Primary 开始执行，如果是 DML 操作，那么 Primary 会产生 XLOG 及更新 page。会在 SlruPhysicalWritePage 函数中 (写数据页) 产生 FileRepOperationOpen、FileRepOperationWrite、FileRepOperationFlush、FileRepOperationClose 等指令音讯 (音讯中蕴含具体要更新的文件 page 及内容)，通过 primary sender 过程向 Mirror 发送 Message，而后 Mirror 的 mirror consumer 等过程解析音讯，执行变更。XLOG 通过XLogWrite 函数 (写 XLOG) 执行同样的操作，把 XLOG 更新同步过来。

2. 文件同步

Primary 会有个 recovery 过程，这个过程会循环把 Primary 的 pg_control、pg_clog、pg_subtrans 等文件笼罩到 Mirror。同时查看 XLOG 是否统一，如果不统一以 Primary 为主，对 Mirror 进行笼罩。除了把 Primary 局部文件同步到 Mirror 之外，recovery 过程还会将 Mirror 下面的临时文件删掉。

总结

Primary 和 Mirror 同步数据的时候，Primary 对于每一次写 page 都会通过音讯发送到 Mirror，如果 Primary 大量的更新 page，那么 Primary 和 Mirror 同步将有可能成为瓶颈。

本文转自：http://mysql.taobao.org/month…

欢送关注我的微信公众号【数据库内核】：分享支流开源数据库和存储引擎相干技术。