New GB build tool based off of golang-custom-raft branch with a new name - hapg about governor HOT 2 CLOSED

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.

from governor.

@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

from governor.