HGDB 流复制一主两备切换注意事项

一主两从切换的话  可以按照以下两种架构中的方式2实现：

HGDB 流复制一主两从流复制切换注意事项

配置NTP时间同步

以下涉及两种架构：

架构1：一主（A）一从（B）再一从（C）
主机A宕机后：切换从机B为主库时：
方式1：使用pg_ctl prompte方式将B机提升为主机，会导致第二个从机C同步中断
方式2：使用pg_ctl stop方式将从机B关闭，然后mv recovery.conf改名，然后pg_ctl start，此时从机B变为主机，从机C同步正常
***************************************************************************************************

架构2：一主（A）两从（B、C）
方式1：当主端A宕机后，如果使用pg_ctl promote方式将其中一个备机提升为主机，则另一备机的同步也会中断。
方式2：当主端A宕机后，两从机（B、C）也要pg_ctl stop
然后将从机（B）的recovery.conf改名为recovery.d
将从机C的recovert.conf中的主机IP改为从机B的IP
启动从机B为主机
启动从机C
此时新主机B与从机C仍能同步正常

配置同步模式的话，注意备机的recovery.conf中要包含application_name=hg，其中hg为备机本身主机名
[highgo@hg data]$ cat recovery.conf 
standby_mode = 'on'
primary_conninfo = 'application_name=hg user=highgo host=192.168.6.10 port=5866 sslmode=prefer sslcompression=1

highgo=# select * from pg_stat_replication;
其中sync_state列值可以看出当前流复制是同步（sync）还是异步（async）

highgo=# select * from pg_stat_replication;
  pid   | usesysid | usename | application_name |   client_addr   | client_hostname | client_port |         backend_start         | backend_xmin |   state   | sent_lo
cation | write_location | flush_location | replay_location | sync_priority | sync_state 
--------+----------+---------+------------------+-----------------+-----------------+-------------+-------------------------------+--------------+-----------+--------
-------+----------------+----------------+-----------------+---------------+------------
 195520 |       10 | highgo  | db2              | 192.168.100.109 |                 |       33998 | 2017-06-16 10:18:22.264831+08 |              | streaming | 0/95000
8B0    | 0/950008B0     | 0/950008B0     | 0/950008B0      |             2 | potential
 195521 |       10 | highgo  | db1              | 192.168.100.108 |                 |       40278 | 2017-06-16 10:18:31.647778+08 |              | streaming | 0/95000
8B0    | 0/950008B0     | 0/950008B0     | 0/95000758      |             1 | sync
(2 rows)

同步模式一主两备的话，状态显示如上，2个备机，先启动的显示sync，后启动的显示potential；
当显示sync的主机pg_ctl stop后，另一台主机同步状态由potential变为sync；
只要两个备机中有一个是活动的，主端就能提交成功，且能正常同步至活动的备机，不需要两个备机数据库服务都处于启动状态  。