Stolon
The stolon is a cloud-native PostgreSQL manager for PostgreSQL high availability. It’s cloud-native because it’ll let…
- Databases
- 5.9K
The stolon is a cloud-native PostgreSQL manager for PostgreSQL high availability. It’s cloud-native because it’ll let…
The stolon is a cloud-native PostgreSQL manager for PostgreSQL high availability. It’s cloud-native because it’ll let you keep a high available PostgreSQL inside your containers (kubernetes integration) but also on every other kind of infrastructure (cloud IaaS, old style infrastructures etc…)
Stolon is composed of 3 main components
Stolon is under active development and used in different environments. Probably it’s on-disk format (store hierarchy and key contents) will change in the future to support new features. If a breaking change is needed it’ll be documented in the release notes and an upgrade path will be provided.
Anyway, it’s quite easy to reset a cluster from scratch keeping the current master instance working and without losing any data.
Since stolon by default leverages consistency over availability, there’s the need for the clients to be connected to the current cluster elected master and be disconnected to unelected ones. For example, if you are connected to the current elected master and subsequently the cluster (for any valid reason, like network partitioning) elects a new master, to achieve consistency, the client needs to be disconnected from the old master (or it’ll write data to it that will be lost when it resyncs). This is the purpose of the stolon proxy.
For our need to forcibly close connections to unelected masters and handle keepers/sentinel that can come and go and change their addresses we implemented a dedicated proxy that’s directly reading it’s stated from the store. Thanks to going goroutines it’s very fast.
We are open to alternative solutions (PRs are welcome) like using haproxy if they can meet the above requirements. For example, an hypothetical haproxy based proxy needs a way to work with changing ip addresses, get the current cluster information and being able to forcibly close a connection when an haproxy backend is marked as failed (as a note, to achieve the latter, a possible solution that needs testing will be to use the on-marked-down shutdown-sessions haproxy server option).
Currently, the proxy redirects all requests to the master. There is a feature request for using the proxy also for standbys but it’s low in the priority list.
If your application wants to query the hot standbys, currently you can read the standby dbs and their status form the cluster data directly from the store (but be warned that this isn’t meant to be stable).
stolon eliminates the requirement of a shared storage since it uses Postgres streaming replication and can avoid the need of fencing (killing the node, removing access to the shared storage etc…) due to its architecture:
It uses etcd/consul as the first step to determine which components are healthy.
The stolon-proxy is a sort of fencer since it’ll close connections to old masters and direct new connections to the current master.
A pure kubernetes approach to achieve Postgres high availability is using persistent volumes and statefulsets (petsets). By using persistent volumes means you won’t lose any transaction. k8s currently requires fencing to avoid data corruption when using statefulsets with persistent volumes (see https://github.com/kubernetes/kubernetes/pull/34160).
stolon instead uses postgres streaming replication to achieve high availability. To avoid losing any transaction you can enable synchronous replication.
With stolon you also have other pros:
Tell us about a new Kubernetes application
Never miss a thing! Sign up for our newsletter to stay updated.
Discover and learn about everything Kubernetes
