From 174a7f85a5b59d232bc4186a6386fdb5967328d8 Mon Sep 17 00:00:00 2001 From: Joshua Boniface Date: Mon, 17 Sep 2018 12:18:47 -0400 Subject: [PATCH] Remove superfluous header --- content/post/patroni-and-haproxy-agent-checks.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/content/post/patroni-and-haproxy-agent-checks.md b/content/post/patroni-and-haproxy-agent-checks.md index 87996fc..3cd11bd 100644 --- a/content/post/patroni-and-haproxy-agent-checks.md +++ b/content/post/patroni-and-haproxy-agent-checks.md @@ -10,8 +10,6 @@ weight = 1 +++ -#### _Patroni and HAProxy Agent Checks_ - [Patroni](https://github.com/zalando/patroni) is a wonderful piece of technology. In short, it [allows an administrator to configure a self-healing and self-managing replicated PostgreSQL cluster](https://patroni.readthedocs.io/en/latest/), and [quite simply at that](https://www.opsdash.com/blog/postgres-getting-started-patroni.html). With Patroni, gone are the days of having to manage your PostgreSQL replication manually, worrying about failover and failback during an outage or maintenance. Having a tool like this was paramount to supporting PostgreSQL in my own cluster, and after a lot of headaches with [repmgr](https://repmgr.org/) finding Patroni was a dream come true. If you haven't heard of it before, definitely check it out! Once you have a working Patroni cluster, managing client access to it becomes the next major step. And probably the easiest (and, in their docs, recommended) method to do so is using HAProxy. With its integrated health checking and simple load balancing, an HAProxy-fronted Patroni cluster provides the maximum flexibility for the administrator while seamlessly handling failovers.