最简单的Postgresql 高可用方式 与 kong 网关

事情的起因是，一家比较大的公司，要使用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 。