事件缘由:
客户要求开发greenplum master高可用脚本,要实现master宕机的情况下,standby master被激活,接管业务。
但是在测试的过程中master切来切去,切乱了。
两个节点都是master,都能读写数据库。。。
即便杀掉第一个节点的master的进程,然后在第二个节点使用gpinitstandby -n 以启动的standby master的方式启动第一个节点的master,期望第一个节点的master启动后自动识别为standby master,从而不能连接以及读写数据库。但是发现第一个节点每次都是以正常模式启动,并且可以读写数据库。。。
原因是standby master节点$MASTER_DATA_DIRECTORY目录下的recovery.conf文件丢失,从而该节点不知道自己是standby master,不会从另外一个节点复制master信息。。。
由此可见greenplum的master节点很容易脑裂!!!
为了解决这一问题,需要修改greenplum的系统表,将其中一个master节点删除,然后重新创建standby master。
原理:
只启动greenplum的master节点,以utility模式连接到数据库,修改系统表,删除系统表中与standby master相关的信息(包括文件空间)。
具体操作如下:
#将数据库关闭(需要检查另一个master是否也关闭&