修改GP系统表修复standby master

事件缘由:

客户要求开发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是否也关闭&
  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
修复STANDBY_MANAGEMENT设置成MANUAL,创建datafile导致的错误的步骤如下: 1. 首先,检查错误日志以获取更多信息。你可以使用以下命令访问错误日志: ```sql SELECT name, value FROM v$parameter WHERE name LIKE '%background_dump_dest%'; ``` 在返回的结果中,找到包含 "alert" 字样的目录,并打开其中的 alert.log 文件。在文件中搜索包含 "ORA-" 或 "error" 字样的行,以查看有关错误的详细信息。 2. 确认数据库是否处于归档模式。如果是,则可以尝试执行以下步骤: - 在主数据库上运行以下命令: ```sql ALTER SYSTEM SWITCH LOGFILE; ``` - 在备用数据库上运行以下命令: ```sql ALTER DATABASE RECOVER MANAGED STANDBY DATABASE; ``` 3. 如果数据库未处于归档模式,则需要在主数据库上手动备份控制文件和日志文件,然后将它们复制到备用数据库。执行以下步骤: - 在主数据库上运行以下命令: ```sql ALTER SYSTEM SWITCH LOGFILE; ALTER SYSTEM CHECKPOINT; ALTER SYSTEM ARCHIVE LOG CURRENT; ``` 这将创建一个新的归档日志文件,并将它们备份到控制文件和日志文件中。 - 将备份的控制文件和日志文件复制到备用数据库,并将其替换为现有的控制文件和日志文件。 - 在备用数据库上运行以下命令: ```sql ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; ``` 这将使备用数据库启动自动恢复过程并将其带到与主数据库同步的状态。 请注意,如果你不熟悉执行此类操作,最好联系专业人员进行支持和帮助,以避免可能的数据丢失或其他问题。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值