GPDB · 特性分析· GreenPlum Primary/Mirror 同步机制

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS SQL Server,基础系列 2核4GB
简介: PostgreSQL 主备同步机制是通过流复制实现,其原理见之前的月报PG主备流复制机制。 Greenplum 是基于PostgreSQL开发的,它的主备也是通过流复制实现,但是Segment节点中的Primary和Mirror之间的数据同步是基于文件级别的同步实现的。为什么Primary和Mir

PostgreSQL 主备同步机制是通过流复制实现,其原理见之前的月报PG主备流复制机制

Greenplum 是基于PostgreSQL开发的,它的主备也是通过流复制实现,但是Segment节点中的Primary和Mirror之间的数据同步是基于文件级别的同步实现的。为什么Primary和Mirror不能再使用流复制实现呢?主要有两个原因:

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

GP总体结构

Greenplum 的架构采用了MPP 无共享体系。在 MPP 系统中,每个数据节点有自己的CPU、磁盘和内存(Share nothing),每个节点内的 CPU 不能访问另一个节点的内存。节点之间的信息交互是通过节点互联网络实现的,这个过程一般称为数据重分配(Data Redistribution)。GP master负责协调整个集群 ,一个数据节点可以配置多个节点实例(Segment Instances),节点实例并行处理查询(SQL)。

GP

Primary和Mirror同步机制

Primary和Mirror同步的内容主要有两部分,即文件和数据。之所以Primary和Mirror要同步文件,是Primary和Mirror之间可以自动failover,只有两者保持同步才能相互替代,如果只把数据同步过去,pg_control、pg_clog、pg_subtrans 没有同步,那么从Primary切换到Mirror会出现问题。GP master和GP slave却不用担心这些问题,Append Only 表的数据只会存在 Segment,所以WAL日志足够保持GP master和GP slave同步(只要是流复制,pg_control、pg_clog、pg_subtrans 这些文件Slave会自动更新,无需从Master同步)。

数据同步

当GP master向Primary下发执行计划后,Primary开始执行,如果是DML操作,那么Primary会产生XLOG及更新page。会在SlruPhysicalWritePage函数中(写数据页)产生FileRepOperationOpen、FileRepOperationWrite、FileRepOperationFlush、FileRepOperationClose等指令消息(消息中包含具体要更新的文件page及内容),通过primary sender进程向Mirror发送Message,然后Mirror的mirror consumer等进程解析消息,执行变更。XLOG通过XLogWrite函数(写XLOG)执行同样的操作,把XLOG更新同步过去。

文件同步

Primary会有个recovery进程,这个进程会循环把Primary的 pg_control、pg_clog、pg_subtrans 等文件覆盖到Mirror。同时检查XLOG是否一致,如果不一致以Primary为主,对Mirror进行覆盖。除了把Primary部分文件同步到Mirror之外recovery进程还会将Mirror上面的临时文件删掉。

master_2_

总结

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

目录
相关文章
|
SQL AliSQL 关系型数据库
AliSQL · 开源 · Sequence Engine
Introduction 单调递增的唯一值,是在持久化数据库系统中常见的需求,无论是单节点中的业务主键,还是分布式系统中的全局唯一值,亦或是多系统中的幂等控制。不同的数据库系统有不同的实现方法,比如MySQL提供的AUTO_INCREMENT,Oracle,SQL Server提供SEQUENCE等。 在MySQL数据库中,如果业务系统希望封装唯一值,比如增加日期,用户等信息,AUTO_INCR
1396 0
|
存储 运维 关系型数据库
|
MySQL 关系型数据库 数据库
MySQL · 引擎特性 · Group Replication内核解析
背景 为了创建高可用数据库系统,传统的实现方式是创建一个或多个备用的数据库实例,原有的数据库实例通常称为主库master,其它备用的数据库实例称为备库或从库slave。当master故障无法正常工作后,slave就会接替其工作,保证整个数据库系统不会对外中断服务。master与slaver的切换不管是主动的还是被动的都需要外部干预才能进行,这与数据库内核本身是按照单机来设计的理念悉悉相关,并且数
4970 0
|
存储 关系型数据库 数据库
|
存储 监控 NoSQL
MongoDB · 引擎特性 · journal 与 oplog,究竟谁先写入?
MongoDB journal 与 oplog,谁先写入?最近经常被人问到,本文主要科普一下 MongoDB 里 oplog 以及 journal 这两个概念。 journal journal 是 MongoDB 存储引擎层的概念,目前 MongoDB主要支持 mmapv1、wiredtiger、mongorocks 等存储引擎,都支持配置journal。
1949 0
|
SQL MySQL 关系型数据库
MySQL · 引擎特性 · Group Replication内核解析之二
背景 前文已经介绍了MySQL的Group Replication的实现机制和原理,本文就Group Replication的具体实现进行详细的阐述,以更深入的理解Group Replication的机制,在实践中更好的应用Group Replication,提升应用系统的可用性,优化其性能。
1680 0
|
关系型数据库
GPDB · 特性分析· Greenplum 备份架构
Greenplum是分布式数据库,这为备份带来了一些困难。其本身提供了一个工具是gpcrondump,对其二进制备份工具gp_dump做了一些封装,而gp_dump则是对pg_dump做了封装,在每个节点上执行pg_dump完成数据的备份。在其每个节点的行为上,与PG类似,但其分布式的架构,则有值得了解的地方。 备份方法 GP备份的工具gpcrondump是一个Python脚本,是对gp_du
2737 0
|
监控 算法 关系型数据库
MySQL · 引擎特性 · InnoDB 同步机制
前言 现代操作系统以及硬件基本都支持并发程序,而在并发程序设计中,各个进程或者线程需要对公共变量的访问加以制约,此外,不同的进程或者线程需要协同工作以完成特征的任务,这就需要一套完善的同步机制,在Linux内核中有相应的技术实现,包括原子操作,信号量,互斥锁,自旋锁,读写锁等。InnoDB考虑到效率和监控两方面的原因,实现了一套独有的同步机制,提供给其他模块调用。本文的分析默认基于MySQL 5.
1931 0