事情的起因是，一家比较大的公司，要使用kong网关，就职的朋友问我postgresql 最简单的高可用方式有什么， 所以才有了此文PostgreSQL 的复制默认是异步的方式，如果primary server crash了一些已经commited的事务在primary server 但还没有传送到 standby server 则主从就会不一致，数据就丢失了，所以这是异步复制的模式。
但Postgresql 提供了一种同步的模式，保证primary 和 standby 库的数据是一致的，这样的方式将所有的事务改变必须传送到standby server wal_log 后在确认commit。这也就使得数据丢失的唯一可能性是主库和从库同时无法正常工作。
当然这样操作的缺点也是显而易见
1 性能一定是要大打折扣，因为明明在一个服务器上写操作就可以继续的事情，现在要两台服务器之间要确认，自然性能要损失。
2 从库如果因为某些原因无法写入数据，或者网络出现问题，则数据库的对外服务就会出现问题。
所以这样的高可用的搭建，基本上在现实中很少见。但今天为什么要提他。
任何架构的使用都与他所处的使用的环境和应用的逻辑有关，在某些情况这样的高可用是可以被接受的。
举个例子，现在热门的微服务网关 kong, 使用它就要使用数据库，而这样的情况下，有两种选择postgresql or cassandra 。 如果让你选怎么选，传统的人士估计大概率还是选择 postgresql， 不会选择cassandra（其实cassandra很有意思）。其中的原因如果你知道cassandra 的原理就明白。
那摆在现在的问题就是，是要咱们搭建一个高可用的postgresql，在没有专业人士的指导，patroni , repmgr , 想想还是算了。
那这个例子中有什么特点
1 postgresql 承载的数据量不大
2 不会经常写数据库，基础数据大概率一次写入
3 读多，写少
4 数据库没有高可用，尤其是网关，并且还是微服务的，（有多少模块在这上面），丢了数据，或者主库失效，难道你要整个系统跟着统统down掉。
那怎么高效的完成任务，还能简简单单，让非DB的人士赶紧搞定这个事情，所以这个同步的方式，以及这样方式下的高可用，就是最好的选择。所以这期是最简单的高可用，（我没说是最好的，也没说哪里都能用，就上面那个例子用，再好不过）
那怎么搭建这个高可用的方式，下面就来盘盘道。 postgresql.conf
1 安装这里就不说了，请参见之前的文字
2 配置文件， 这里的关键就是配置文件
1 synchronous_commit
2 synchronous_standby_name
这两个是必须的要进行设置必选项
synchronous_commit
下面是他的几个选项
on
事务提交总是等待，直到将数据真正刷新到事务日志(也称为WAL或XLOG)，以确保事务确实是持久的。在同步流复制模式下，副本也需要这样做。
off
事务flush wal_log 前，就可以向用户提交确认，当然付出的代价就是在服务器crash时会损失那些没有提交单没有flush 到wal_log 的数据
local
这个选择仅仅保证你的事务commited 后不再主节点丢失数据，standby不保证数据不丢失。
remote_write
与on选项相比，这并不会不丢失数据，standby 仅仅等等操作系统返回数据写入的磁盘的确认。
remote_apply
这个是我们需要的选项，提供了复制的强一致选项，主库不会在没有从库提交返回数据已经安全写入standby之前commit，这这个选项的意义在于，主和从在任何一个时间数据都是一直的，或者一起去dead。
列出一个从弱到强的对数据的一致性保护
off (async) > on (async) > remote_write (sync) > on|local (sync) > remote_apply (sync)
而
synchronous_standby_name 的与上面的意义不同的在于，他在选择你要哪个从库与你一致，因为可能有很多的从库与你进行数据的同步。
最简单粗暴的就是用 * 来代表，当然你也可以写成mongodb 的方式 'ANY 2 (服务器1 ，服务器2 服务器3) ' 这就是MONGODB 的里面的大多数的概念，POSTGRESQL 这里也是至少2个 standby与我一致我才罢休，否则不可以。
或者也可以写成固定的模式 'FIRST 2 (服务器1 ，服务器2 服务器3) ' 至少前边两个服务器必须与你的primary 数据一致（具体看上面那个参数的设置）
才能让primary commit or no .
下面我们做一个例子
两台机器，使用pg_basebackup 做了最基本的复制，相关复制怎么做请参见之前的文字。
我们下面做一个实验
1 我们在primary 服务器上开启事务
2 我们在commit 前将从库关闭
3 我们看看会怎么样
主库
从库
可以很清晰的看到，从库不在线的情况下，主库根本没有办法commit
我们可以看下面，明显开启从库后，主库自动就将事务commit了
也可以看一下primary 和 standby 的日志
primary
standby
再次基础上，配合keepalive 去验证postgresql 服务，并且其中包含promote命令，就能完成一个最简单的高可用的postgresql。
其实如果MYSQL 的复制能做到强一致性的话，可能也就没有当初MHA什么事情了。MYSQL KEEPALIVE 也可能是一种可靠的选择。
再次重申，怕有同学误会，觉得我推荐这样的高可用，请在回顾一下题目，最简单的，另外还是那句话，看需求，在做，要不仅仅人家就要一个KONG 的简单需求，并且人家公司也没有POSTGRESQL DBA，要人家REPMGR PATRONI，PG 的 数据库DBA It's too expensive and hard to find 。
