1模拟主节点服务故障

在主机上执行，停止postgreql的命令，模拟PostgreSQL进程出现故障。而pgpool的服务未受影响。

systemctl stop postgresql

再次查询，结果如图所示。节点0 的role被切换为standby节点1的role被切换为primary。再看状态，节点0状态down掉了。

2.手动将节点2加入集群中

在实际应用过程中，节点0挂掉之后主节点自动切换到节点1，此时只有节点1正常工作，用户对此并无感知，通过配置的VIP连接数据库，此时仍在继续读写数据。

节点2在虽然在pgpool中的显示是连接状态，但是，它却并不在集群当中。

在节点1中写数据，自然无法同步。

此时人工操作，将节点2加入集群中。

第一步、将数据同步过来。并做好配置。

-bash-4.2$ rm -rf /var/lib/pgsql/data/*

-bash-4.2$ pg_basebackup -h 192.168.149.237 -U repl -D /var/lib/pgsql/data -X stream -P

-bash-4.2$vi /var/lib/pgsql/data/recovery.conf

standby_mode = on

primary_conninfo = 'host=192.168.149.237 port=5432 user=repl password=fanxiaoguang@0'

recovery_target_timeline = 'latest'

trigger_file = '/tmp/trigger_file0'

第二步、重启，之后发现，从节点已经生效了。

数据库的内容已经同步进来。

如果节点2状态出现down的情况。那么可以手动改变一下状态。

在node238节点执行命令

pcp_attach_node 10 localhost 9898 postgres postgres 2

其中参数10表示一个时间，不重要。localhost就是要手动加入的节点，postgres postgres分别代表用户名和密码，2代表节点ID。

重新登陆后，节点状态发生改变。

假设节点0的故障已经修好了。此时，应只是将节点0当作一个普通standby库来看待。配置方法与节点2配置方法相同。

在节点0上将自身加入集群中，重连后，整个集群恢复如初。执行命令

pcp_attach_node 10 localhost 9898 postgres postgres 0

而此时，节点0不再是主节点了，是一个只读的数据库了。