上一篇文章中提到了Segment节点的故障转移，其中主要涉及Mirror添加、故障自动切换、故障修复后balanced到原集群状态，以及一些建议。具体请移步传送门-->《 Deepgreen & Greenplum 高可用（一） - Segment节点故障转移 》。



书接上文，今天来谈一谈Master节点的故障转移。





一、首先从理论上来讲，要达到Master节点的单点保障，Master Standby要与Master部署在不同的服务器上。当Master节点故障时，同步程序停止，此时手动在Master主机激活Standby。激活Standby时，同步日志被用来恢复Master最后一次事务成功提交时的状态。另外，在激活Standby主机同时，可以指定一个新的Standby。




greendao detachall导致卡顿 greenplanting_初始化



下面我们开始实验：


1.首先给原有集群添加Standby 


gpinitstandby -s reverse <<--Standby所在主机名，与/etc/hosts中相对应


2.通过SQL查看现有Master及Standby Master状态 


postgres=# select string_agg(role||'-'||hostname,'|') from gp_segment_configuration where content='-1';
  string_agg 
--------------
 p-flash|m-reverse


3.模拟Master故障并切换到Standby 


# 查询Master进程
ps -ef | grep postgres
kill -9 3897 <<-- 上面查询到的Master进程pid


# 测试是否可以连接到集群（失败）
psql -d postgres


#切换到Standby
gpactivatestandby -d ${MASTER_DATA_DIRECTORY}


# 测试是否可以连接到集群（成功）
psql -d postgres



#如果想在切换的同时创建一个新的Standby，可以执行如下命令
gpactivatestandby -d ${MASTER_DATA_DIRECTORY} -c new_standby_hostname


4.切换完成后，在新Master主机上连接数据库并运行ANALYZE 


psql dbname -c 'ANALYZE;'


至此，切换完成。



二、与Mirror一样，因为Standby一般不会单独占用一台机器，通常部署在某个Segment节点之上，所以长期使用Standby接管服务，会导致Standby主机争抢Segment实例资源。通常在原Master修复后，应尽快切换为原集群状态，下面我们来做这个实验。



1.首先在原Standby主机（现已经承担Master服务）上，执行如下命令，将Standby初始化到原Master主机（刚修复的问题机器） 


gpinitstandby -s flash


2.在当前承担Master服务的Standby主机上停止Master服务 


gpstop -m


3.在原Master主机上重新激活Master服务 


gpactivatestandby -d $MASTER_DATA_DIRECTORY


4.激活之后，通过下面命令查看状态 


gpstate -f


5.一旦状态正常，便可将原Standby主机重新初始化 


gpinitstandby -s reverse


至此，集群已经恢复到原始状态，这里面关于原Master、现Master、原Standby和现Standby的概念，有点绕，需要认真品味。



三、最后分享另外两个与Standby相关的操作



1. 同步Standby并更新到最新的同步 


gpinitstandby -s standby_master_hostname -n


2.删除Standby 


gpinitstandby -s standby_master_hostname -r


备注：


  • Standby可以轻松添加和删除，然而Mirror却只允许添加，不允许删除。
  • 需要注意，Master的热备Standby需要手工激活，并且使用不同的访问IP；而Segment的镜像却可以自动切换。


End~~