PostgreSQL Clustering Solutions Adam Brust Andrew Henle

Quick List of Related Tasks These tasks are related to PostgreSQL clustering but not addressed in these slides PostgreSQL snapshot/archive/restore capability Offsite/disaster recovery Use of Compellant snapshots PostgreSQL monitoring Nagios plugins

PostgreSQL Clustering Goals Highly-available, scalable PostgreSQL data layer Eliminate single points of failure Support workflow processing and potentially product metadata Stable and maintainable Use only well-supported products/technologies K.I.S.S. Minimize introduction of new products/technology Lower risk through directed path: get it working without too many bells and whistles

PostgreSQL Clustering Choices What solutions are available? Many available options Free open source Proprietary Varying features Master/master vs master/standby Some have connection pooling and load balancing

Table of PostgreSQL Failover Options Source:

Selection criteria The three most important criteria used to select a solution Stable, current product Not on “bleeding edge” No abandoned products Simple and maintainable Eliminate single point of failure Master DB in master-slave configuration is a single point of failure Feature list Connection pooling and load balancing for scalability

Recommended Solution: pgpool-II Recommend using pgpool-II Up-to-date product with best balance of features Up-to-date with PostgreSQL Not “bleeding edge” nor abandoned Most complete feature set Implements connection pooling and load balancing But pgpool-II is a single point of failure Single point of failure can be addressed using pgpool-HA to cluster pgpool-II

Multi-Phase Roadmap Why multiple phases Minimize impact on current development and O&M Become more familiar with highly-available clustered PostgreSQL before deploying operationally Allow lessons learned to be applied to later phases Roadmap has three phases Phase 0 – development and test Phase I – initial deployment Phase II – final deployment

Three Phase Deployment of Clustered PostgreSQL Data Layer Phase 0 – Development and test Develop and test pgpool-II/pgpool-HA/PostgreSQL data layer Test throughput and latency Develop failback procedures to recover from primary database failure Primary database failure requires manual repair Phase I – Initial deployment Implement pgpool-II as front end for multiple parallel PostgreSQL servers Phase II – Final deployment Implement pgpool-HA to remove pgpool-II single point of failure

Phase 0 Details – Development and Test Build 2+ VMs for PostgreSQL/pgpool-II/pgpool-HA installation Determine best location of pgpool-II instance(s) Same or different VM(s) from PostgreSQL data base instances? Build/configure PostgreSQL/pgpool-II/pgpool-HA Test, test, test Determine pgpool impacts on Latency Throughput Develop failback procedures to recover from primary database failure

Phase I Details – Initial Deployment Implement single-instance pgpool-II and primary/standby PostgreSQL data servers Something to think about… pgpool-II may be good enough Single point of failure does limit availability of system If multiple single points of failure already exist, the added complexity of pgpool-HA might actually reduce reliability and availability by increasing the chances of human error Answer is very subjective – difficult if not impossible to calculate the odds of added complexity creating more opportunities for human error Customer expectations and desires are also paramount

Phase I Diagram – Initial Deployment Source:

Phase II Details – Possible Final Deployment Install pgpool-HA in production Configuration details are currently TBD Might not be necessary to actually improve reliability/availability

Phase II Diagram – Possible Final Deployment Source: