[progress Communities] [progress Openedge Abl] Ceate Cluster Management Tool And...

[jankeir]

Currently you can have replication and replication sets on databases but failover is stil something you'd probably prefer to do manually and automatic failover in case of a network split can cause split brain where multiple nodes can become master because they can't talk to each other, even if clients can talk to the servers (ie due to network issues on a deticated network between the servers.) In Postgres there is a tool, patroni ( https://github.com/zalando/patroni ) that configures the cluster of databases, sets up replication and elects the leader using RAFT, this way you can failover automatically without thinking. It also takes care of the complexities of setting up the cluster, doing the failover, adding and removing nodes,... so that the chance of misconfigurations that only show up in edge case situations that you didn't think to test is very small. Once you have something like this you can also create clusters on docker/kubernetes with something like Spilo ( https://spilo.readthedocs.io/en/latest/DESIGN/ ) The important requirement for this to work is a good management daemon, a leadership election tool and the ability for the database to add new and remove old nodes to the cluster set as you go. It is also desireable to add a connection proxy like haproxy in such a setup so that database client connections could either survive or else reconnect without reconfiguration (even if the cluser nodes themselves didn't even exist when the client started.) Such proxy could even allow read only queries to be forwarded to slaves instead of the master. The advantage of such proxy is that since it does not do much heavy lifting the chance for it to ever go down is smaller than the DB, and if it does go down, it can be handled with halinux easily. It is very important that there is a very good frontend to manage such cluster (something like patroni, which might even be porteable to postgres?) because the chances of errors are simply too big when managing such cluster manually or with custom scripting by every single customer.

Continue reading...