Patroni to oprogramowanie z otwartym źródłem dostępne na licencji MIT. To, jak nazywają go jego twórcy, "szablon" na Postgresa o wysokiej dostępności, pozwala zautomatyzować wiele aspektów zarządzania klastrem, jest łatwy w instalacji i obsłudze. Wykorzystuje rozproszony magazyn klucz-wartość, np. ZooKeeper, etcd, Consul lub Kubernetes do przechowywania informacji o stanie instancji i parametrach konfiguracyjnych klastra postgresa oraz działa jako mechanizm elekcji, wspomagający Patroni w momencie awaryjnego przełączenia instancji, wskazując, który z serwerów jest w najlepszym stanie technicznym (najmniejsze opóźnienia healthchecka) oraz ma najmniejszy lag ze wszystkich replik.

Wszystkie serwery zarządzane przez Patroni są sobie równorzędne. Jeden z nich zawsze pełni rolę "Lidera" klastra, jest to instancja primary (wykonujące operacje zapisu/odczytu), pozostałe pełnią rolę "Replik", czyli są serwerami standby replikującymi zmiany z instancji "Lidera", są otwarte dla połączeń i umożliwiają wykonywanie operacji tylko do odczytu. Lider wybierany jest metodą elekcji, w której biorą udział wszystkie serwery ETCD. Na podstawie informacji o stanie serwera, jego obciążenia, oraz opóźnienia na replice, Patroni wybiera najlepszego kandydata.

Patroni jest wysoce konfigurowalny, pozwala dostosować go dokładnie do swoich potrzeb. Potrafi wykorzystywać różne zewnętrzne narzędzia jak np. pgbackrest. Pozwala również na użycie własnych skryptów lub skorzystanie z jego domyślnych funkcjonalności dla wielu zadań, które wykonuje.

Można go skonfigurować dla istniejącego klastra lub możemy stworzyć za jego pomocą nowy, według definicji w sekcji "bootstrap" pliku konfiguracyjnego patroni.

Jeżeli ustawiamy Patroni dla istniejącej instancji, musimy ją wcześniej zatrzymać, wyłączyć autostart usługi, a następnie uruchomić usługę Patroni, która od tej pory będzie odpowiedzialna za działanie postgresa.

Bootstrap, czyli zestaw instrukcji do inicjalizacji nowego klastra postgresa, domyślnie wykona polecenie "initdb" oraz przygotuje całkiem nowy klaster, w którym stworzy użytkowników zdefiniowanych w pliku konfiguracyjnym patroni (/etc/patroni/config.yml), ale możemy mu zadać wykonanie dowolnego skryptu, np. odtworzyć bazę z kopii zapasowej i wykonać data scrambling, usuwając wrażliwe dane, co możemy wykorzystać przykładowo jako łatwy sposób na stworzenie testowego klastra z produkcji, wykorzystując kopie zapasowe.

Podobnie jak bootstrap, inne funkcjonalności Patroni możemy skonfigurować w dowolny sposób, wykorzystując skrypty. Jedną z popularnych możliwości jest konfiguracja ponownego podłączenia byłej instancji primary, która domyślnie wykorzystuje pg_rewind (narzędzie służące do synchronizacji dwóch katalogów PGDATA, dostarczane razem z postgresem), a w sytuacji kiedy w archiwum nie będziemy mieli wszystkich plików WAL, aby ponownie podłączyć starą instancję primary jako replikę. Wtedy patroni wykonuje reinicjalizację, czyszcząc katalog PGDATA i wykonując nową kopię z primary za pomocą pg_basebackup. Możemy jednak zastąpić te akcje własnymi skryptami, które przykładowo wykonają "delta restore" za pomocą pgbackresta, co w przypadku dużych baz danych może oszczędzić kilka/naście godzin na ponowne podłączenie instancji do klastra, ponieważ delta restore pgbackresta, odtwarza z kopii zapasowych tylko te pliki, które były zmienione, co w wieloterabajtowym klastrze często oznacza, że odzyskujemy tylko kilka % całego klastra, zamiast wykonywania pełnej kopii za pomocą pg_basebackupa.

Schemat implementacji przedstawionej na przykładach