如何build模Docker / Kubernetes的PostgreSQL故障转移群集？
我还在包围着Kubernetes，而且应该如何工作。 目前，我正在努力了解如何使用stream式复制，扩展和自动故障转移/故障回复（ pgpool-II ， repmgr ，select毒药）来模拟PostgreSQL群集。
这个方法的主要问题是PostgreSQL实例的双重属性，configuration方面 – 它是一个主或冷/暖/热备用。 如果我增加副本的数量，我希望他们都作为备用，所以我想像创buildpostgresql-standby复制控制器与postgresql-master复制控制台分开。 不过，我也希望其中一个备用数据库在当前主数据库closures的情况下成为主数据库，所以它毕竟是一个常见的postgresql复制控制器。
我到目前为止唯一的想法是将复制configuration放在外部卷上，并pipe理容器外部的状态和状态更改。
（在PostgreSQL的情况下，configuration可能已经在其data目录中的一个卷上，这本身显然是我希望在卷上的东西，但这不是重点）
这是正确的方式，还是有其他更清洁的方式吗？
在OpenShift中有一个例子： https : //github.com/openshift/postgresql/tree/master/examples/replica纯Kube的原理是一样的（它并没有真正使用OpenShift，你可以使用plain泊坞窗）
Kubernetes的有状态是build立有状态服务的良好基础。 您仍然需要一些工作来在PostgreSQL副本中configuration正确的成员资格。
Kubernetes有一个例子。 http://blog.kubernetes.io/2017/02/postgresql-clusters-kubernetes-statefulsets.html
你可以试试PostDock ，或者用docker-compose或者Kubernetes。 目前我已经在我们的docker-compose项目中试过了，模式如下：
pgmaster (primary node1) --| |- pgslave1 (node2) --| | |- pgslave2 (node3) --|----pgpool (master_slave_mode stream)----client |- pgslave3 (node4) --| |- pgslave4 (node5) --|
我已经testing了以下场景，并且它们都工作得很好：
- 复制：在主节点（即主节点）进行的更改将被复制到所有备用节点（即从节点）
- 故障切换：停止主节点，并且备用节点（例如，节点4）将自动接pipe主要angular色。
- 预防两个主节点：复活先前的主节点（节点1），节点4将继续作为主节点，而节点1将同步而作为备用节点。
至于客户端应用程序，这些更改都是透明的。 客户端只是指向pgpool节点，并在上述所有场景中保持正常工作状态。
注意 ：如果遇到问题让PostDock运行，您可以尝试我的分叉版本的PostDock 。
带看门狗的Pgpool-II
上述架构的一个问题是，pgpool是单点故障。 所以我也试着用一个委托的虚拟IP 为pgpool-II启用看门狗，以避免单点故障。
master (primary node1) --\ |- slave1 (node2) ---\ / pgpool1 (active) \ | |- slave2 (node3) ----|---| |----client |- slave3 (node4) ---/ \ pgpool2 (standby) / |- slave4 (node5) --/
我已经testing了以下场景，并且它们都工作得很好：
- 正常情况：两个pgpools都启动，虚拟IP会自动应用到其中的一个，在我的情况下，pgpool1
- 故障切换：closurespgpool1。 虚拟IP将被自动应用到pgpool2，从而变得活跃。
- 启动失败的pgpool：再次启动pgpool1。 虚拟IP将与pgpool2保持一致，而pgpool1现在作为备用。
至于客户端应用程序，这些更改都是透明的。 客户端只是指向虚拟IP，在上述所有情况下都能正常工作。
您可以在我的GitHub存储库的watchdog分支上find这个项目。