目录
1.GP高可用的总体架构
2.Master节点的冗余
3.Master节点冗余的应用实践
4.Segment节点的冗余
5.Segment节点冗余的应用实践
6.Segment节点信息维护
01
GP高可用的总体架构
02
Master节点的冗余
Master节点是应用程序客户端到数据库系统的唯一入口，存储了数据库global的catalog，以及数据库有关的一系列的元数据。如果master节点出现故障，整个数据库系统失去对客户端的服务支持，因此对master节点的容灾极其重要。在GP的高可用架构中，为master节点配置一个standby节点，作为容灾备份。但是standby master只是一个温备份（warm standby），正常情况下，standby只提供备份服务，不提供查询服务。当primary master节点因为故障而不能继续提供服务时，需要数据库系统管理员执行主备切换命令，手工把standby拉成primary 角色，客户端需要重新连接新的primary master节点，这个过程会丢失一部分在原primary节点故障时没有commit的操作。
Master节点的primary和standby结构设计中需要两个进程，sender和receiver。进程sender运行在primarymaster上，receiver运行在standbymaster上。当primary master节点发生对系统的catalog的修改时，primary节点会使用流复制把WAL log发送到standby节点，保证主备节点的数据一致性。
03
Master节点冗余的应用实践
（1）虽然standby节点并不是必要的，但是建议为每个系统的master设置一个standby节点，防止primary master发生故障。
（2）理论上Standby节点，可以放在任何主机上，但是建议把primary和standby master放到不同主机上，防止主机的物理故障导致primary和standby同时宕机
（3）建议随时监控master的状态，一旦发生故障，及时发送警告给系统管理。以便管理员及时的进行主备切换，防止丢失过多的数据。
（4）当发生主备切换时，做好客户端重新接入新primary master的方案。
04
Segment节点的冗余
每个segment都有一个热备份（hot standby）称为segment mirror。Master节点能够检测到primary segment的状态，当primary segment不能继续提供服务时，会主动激活mirror segment成为新的primary。正常情况下primary segment处于active状态，primary segment和mirror segment之间的数据同步是通过两种方式：
（1）数据同步复制primary segment上，在事务commit之前，把事务的commit log同步到mirror segment上，同步结束以后，primary segment才做真正的commit。这样当mirror segment被提升成primary后，能够保证事务的一致性。
（2）物理文件复制堆表使用物理文件复制。GP中表数据是由元组组成的一个固定大小的块文件存储在磁盘上，为了优化磁盘I/O，块文件会被存储到缓冲区，当缓冲区满了之后会被新更新的块文件替换，被替换出来的块文件被写到primary segment的磁盘上，同时通过网络复制到mirror segment上，Mirror segment只更新其文件副本中的相应块。当块保存在缓存中时，primarysegment和mirror segment具有不同的块镜像，但是数据库仍然是一致的，因为事务日志已经被复制了。
在segment host上能看到启动的两个PG进程，其中primary和mirror侦听的端口号在初始化模板中是可以配置的。
05
Segment节点冗余的应用实践
（2）建议primarysegment 和相应的mirror segment放到不同的主机上。
（3）Mirrorsegment可以跟其他的primary segment共存在同一台主机，或配置到单独主机上。
（4）建议配置监控和报警工具，防止primary segment发生故障。
（5）建议尽快恢复发生故障的primary segment，并切换原来的状态，保证系统性能平衡。
06
Segment节点信息维护和状态检测
字段名 | 描述 |
dbid | 每个节点的唯一id |
content | 每个主备组的id，master-standby为-1，primary-mirror从0开始递增。content相同的两个节点为一对 |
role | 节点角色，p代表 primary，m代表 mirror |
preferred_role | 每个节点初始化时的角色，当发生主备切换时，变成primary的mirror节点，role为p，preferred_role为m |
mode | 主备同步状态，s同步，n不同步 |
status | 运行状态，u在线，d不在线 |
port | 该节点的运行端口 |
hostname | 节点的hostname |
address | 通常和hostname相同 |
datadir | 该节点的数据目录 |
在master节点上，使用ftsprobe进程来定时检测segment节点的状态以便在segment节点发生故障时能够及时的进行自动的切换，但是GP在故障修复之后无法自动将segment节点切换回到起始的角色，需要数据库管理员手工将primary和mirror切回到原状态。
在日常维护中，可以使用gpstate-s 同样可以看到整个数据库中每个节点的状态：
-------------------------------------------------------Master Configuration & Status------------------------------------------------------ Master host = localhost_16- Master postgres process ID = 41472- Master data directory = opt/greenplum/data/master/gpseg-1- Master port = 5432- Master current role = dispatch- Greenplum initsystem version = 6.2.1 buildcommit:d90ac1a1b983b913b3950430d4d9e47ee8827fd4- Greenplum current version = PostgreSQL 9.4.24 (Greenplum Database 6.2.1 buildcommit:d90ac1a1b983b913b3950430d4d9e47ee8827fd4) on x86_64-unknown-linux-gnu,compiled by gcc (GCC) 6.4.0, 64-bit compiled on Dec 12 2019 18:35:48- Postgres version = 9.4.24- Master standby = No master standby configured------------------------------------------------------Segment Instance Status Report------------------------------------------------------ Segment Info- Hostname = localhost_17- Address = gp-sdw1- Datadir = /opt/greenplum/data/primary/gpseg0- Port = 6000- Mirroring Info- Current role = Primary- Preferred role = Primary- Mirror status = Synchronized- Status- PID = 14967- Configuration reports status as = Up- Database status = Up------------------------------------------------------ Segment Info- Hostname = gp-sdw2- Address = gp-sdw2- Datadir = /opt/greenplum/data/mirror/gpseg0- Port = 7000- Mirroring Info- Current role = Mirror- Preferred role = Mirror- Mirror status = Streaming- Replication Info- WAL Sent Location = 0/C04D090- WAL Flush Location = 0/C04D090- WAL Replay Location = 0/C04D090- Status- PID = 14783- Configuration reports status as = Up- Segment status = Up------------------------------------------------------ Segment Info- Hostname = localhost_18- Address = gp-sdw2- Datadir = /opt/greenplum/data/primary/gpseg1- Port = 6000- Mirroring Info- Current role = Primary- Preferred role = Primary- Mirror status = Synchronized- Status- PID = 14782- Configuration reports status as = Up- Database status = Up------------------------------------------------------ Segment Info- Hostname = gp-sdw1- Address = gp-sdw1- Datadir = /opt/greenplum/data/mirror/gpseg1- Port = 7000- Mirroring Info- Current role = Mirror- Preferred role = Mirror- Mirror status = Streaming- Replication Info- WAL Sent Location = 0/C04D198- WAL Flush Location = 0/C04D198- WAL Replay Location = 0/C04D198- Status- PID = 14966- Configuration reports status as = Up- Segment status = Up
I Love PG
关于我们
中国开源软件推进联盟PostgreSQL分会（简称：PG分会）于2017年成立，由国内多家PG生态企业所共同发起，业务上接受工信部产业发展研究院指导。PG分会致力于构建PG产业生态，推动PG产学研用发展，是国内一家PG行业协会组织。
技术文章精彩回顾 PostgreSQL学习的九层宝塔 PostgreSQL职业发展与学习攻略 搞懂PostgreSQL数据库透明数据加密之加密算法介绍 一文读懂PostgreSQL-12分区表 PostgreSQL源码学习之：RegularLock Postgresql源码学习之词法和语法分析 PostgreSQL buffer管理 最佳实践—PG数据库系统表空间重建 PostgreSQL V12中的流复制配置 2019，年度数据库舍 PostgreSQL 其谁? PostgreSQL使用分片（sharding）实现水平可扩展性 一文搞懂PostgreSQL物化视图 PostgreSQL原理解析之：PostgreSQL备机是否做checkpoint PostgreSQL复制技术概述 PG活动精彩回顾 见证精彩|PostgresConf.CN2019大会盛大开幕 PostgresConf.CN2019大会DAY2|三大分论坛，精彩不断 PostgresConf.CN2019培训日|爆满！Training Day现场速递！ 「PCC-Training Day」培训日Day2圆满结束，PCC2019完美收官 创建PG全球生态！PostgresConf.CN2019大会盛大召开 首站起航！2019“让PG‘象’前行”上海站成功举行 走进蓉城丨2019“让PG‘象’前行”成都站成功举行 中国PG象牙塔计划发布，首批合作高校授牌仪式在天津举行 PostgreSQL实训基地落户沈阳航空航天大学和渤海大学，高校数据库课改正当时 群英论道聚北京，共话PostgreSQL 相聚巴厘岛| PG Conf.Asia 2019 DAY0、DAY1简报 相知巴厘岛| PG Conf.Asia 2019 DAY2简报 相惜巴厘岛| PG Conf.Asia 2019 DAY3简报 独家|硅谷Postgres大会简报 全球规模最大的PostgreSQL会议等你来！ PG培训认证精彩回顾 关于中国PostgreSQL培训认证，你想知道的都在这里！ 首批中国PGCA培训圆满结束，首批认证考试将于10月18日和20日举行！ 中国首批PGCA认证考试圆满结束，203位考生成功获得认证！ 中国第二批PGCA认证考试圆满结束，115位考生喜获认证！ 请查收：中国首批PGCA证书！ 重要通知：三方共建，中国PostgreSQL认证权威升级！ 一场考试迎新年 | 12月28日，首次PGCE中级认证考试开考！ 近500人参与！首次PGCE中级、第三批次PGCA初级认证考试落幕！
