最简单的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 做了最基本的复制,相关复制怎么做请参见之前的文字。


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


我们下面做一个实验


1 我们在primary 服务器上开启事务

2 我们在commit 前将从库关闭

3 我们看看会怎么样


主库

最简单的Postgresql 高可用方式  与 kong 网关_数据_03

从库

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


可以很清晰的看到,从库不在线的情况下,主库根本没有办法commit

我们可以看下面,明显开启从库后,主库自动就将事务commit了

最简单的Postgresql 高可用方式  与 kong 网关_数据_05


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


也可以看一下primary 和  standby 的日志

primary

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

standby 

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


再次基础上,配合keepalive 去验证postgresql 服务,并且其中包含promote命令,就能完成一个最简单的高可用的postgresql。


其实如果MYSQL 的复制能做到强一致性的话,可能也就没有当初MHA什么事情了。MYSQL + KEEPALIVE 也可能是一种可靠的选择。


再次重申,怕有同学误会,觉得我推荐这样的高可用,请在回顾一下题目,最简单的,另外还是那句话,看需求,在做,要不仅仅人家就要一个KONG 的简单需求,并且人家公司也没有POSTGRESQL DBA,要人家REPMGR  PATRONI,PG 的 数据库DBA It's too expensive and hard to find  。

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