New GB build tool based off of golang-custom-raft branch with a new name - hapg

[oneness]

Hi Guys,
Great work. I like the direction you guys are going and just created a new repo with hapg as the project name. I cloned the golang-custom-raft branch and made it gb build tool compatible, which in my opinion benefit this project in the long run (visit here for more info: https://getgb.io/). Currently, you can build it after git clone https://github.com/oneness/hapg once you have gb installed.

At PGConf, you guys talked about a new project off of the governor is under consideration and was wondering if this is ok with you guys.

[CyberDem0n]

There are two major drawbacks of using raft protocol on your own:

• You have to run at least 3 nodes for auto-failover.
• Raft protocol does not recommend to have more than 9 nodes (no big clusters for read-only queries).

Also such approach brings a lot of other inconveniences, like:

• Previously it was possible to have a central place, where you can find all your clusters (and nodes)
• You have to configure every single cluster (and actually every node) uniquely.

I was thinking about implementing more or less the same thing in Patroni with using one of the python raft implementations, but above thoughts stopped me. Now I'm thinking about implementing support of Kubernetes API in addition to Etcd, ZooKeeper and Consul.

[doodles526]

@oneness totally fine! We're planning on creating a new repo from the golang-custom-raft branch ourselves. But we're happy to have folks forking this project. If someone can create something better than we have then that's awesome and welcome that!

@CyberDem0n yes those are some drawbacks. This solution worked quite well for our particular use case at compose.
A couple things on those compromise though. First, while you need 3 nodes participating in a raft cluster for fail over, not every node must be running governor(see lifeboat in github.com/compose/canoe). How we run the new governor internally, we have 2 nodes running a governor process, and 1 node running lifeboat. Lifeboat is essentially a process which runs as a member of a raft cluster, but doesn't retain state itself beyond the raft log. It acts as a quorum pad. This way we have a 3 node cluster, but not have the overhead of running 3 pg processes.

Also, while you don't have a central store for cluster information, you can query any governor node in a cluster for information on the state of the cluster using the Governor API

Finally, yes. The new governor isn't designed for huge clusters. A thought I have in that though... And shooting from the hip on this totally untested. But what you might be able to do with that is have a 3 node governor cluster. That way you have 3 nodes for a failover scenario. But then you might could query the Governor API to find the leader connection string, then configure a read only pg node as a hot_standby. It would never be able to become the leader, and it wouldn't have a replication slot on the leader to ensure it can keep up. But could be something to test out