gs_replace修复节点时容易遇到的坑

举报
你怎么不讲道理 发表于 2020/12/30 20:46:40 2020/12/30
【摘要】 本帖使用的环境均为测试环境,不涉及客户信息该节点需要修复的实例,对端所在的机器上,所有主dn实例的postgresql.conf文件不能有损坏以下图为例,如果dn6002的磁盘出现问题,需要gs_replace对linux180125节点进行修复时,对端为6001,此时就要求linux180123节点上面6001,6003的postgresql.conf文件都是正常的,而不是只要6001正常...

本帖使用的环境均为测试环境,不涉及客户信息

  1. 该节点需要修复的实例,对端所在的机器上,所有主dn实例的postgresql.conf文件不能有损坏

    以下图为例,如果dn6002的磁盘出现问题,需要gs_replace对linux180125节点进行修复时,对端为6001,此时就要求linux180123节点上面6001,6003的postgresql.conf文件都是正常的,而不是只要6001正常就可以

    image.png


  2. gs_replace时,要考虑磁盘空间

    image.png

    如果linux180123的data1磁盘发生故障,此时6001和6008不可用,6002会升主开始主从复制,6007也会开始主从复制

    在磁盘修复之前,6002和6007都会有大量的xlog积压

    由于6002和6007分别在两个不同的盘,所以磁盘可能压力不是很大,但是gs_replace修复时,6001和6008是在同一块盘的,这时将6002和6007的数据拷贝过来就有可能导致磁盘空间不足;所以要提前计算空间

    如果计算后发现空间确实不足,可以在dn6002和6007查找已经失效的主备复制槽,并删除,然后做checkpoint,这样再做gs_replace时就不会拷贝大量的积压xlog了

    这里手动将6001停掉,作为例子

    image.png

    切到linux180125节点,登录到dn6002上(dn6002端口是25490,查端口号的方法不在这里赘述)

    执行select * from pg_get_replication_slots();

    image.png

    可以看到主备复制槽已经失效(active为f)

    删掉这个主备复制槽

    select pg_drop_replication_slot('dn_6001_6002');

    连接到cn,执行多次checkpoint

    这时再对dn6001做全量build就可以恢复,并且不会拷贝大量的积压xlog

    (所有dn的复制槽都处理完之后做gs_replace也一样,gs_replace实质还是调全量build)

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。