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

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

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

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

   
   

   
   

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

   

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

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

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

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

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

   

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

   执行select * from pg_get_replication_slots();

   

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

   删掉这个主备复制槽

   select pg_drop_replication_slot('dn_6001_6002');

   连接到cn，执行多次checkpoint

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

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