Making your PostgreSQL Database Highly Available
0 likes289 views
The document presents a guide on achieving high availability (HA) for PostgreSQL databases, covering concepts, methodologies, and EDB's tools for implementation and monitoring. It emphasizes the importance of eliminating single points of failure, provides an overview of replication techniques, and details the components necessary for maintaining operational performance. EDB, a leader in PostgreSQL solutions, offers various services and best practices to ensure high availability in database environments.
Making your PostgreSQL Database Highly Available
- 1. Making your PostgreSQL Highly Available Presented by: Alok Kumar Mishra Senior Sales Engineer, A/NZ 24th Nov 2020
- 2. © Copyright EnterpriseDBCorporation, 2020. All rightsreserved. Agenda 1. Who is EDB 2. HighAvailability Basics & Terminology 3. How does HighAvailabilitywork? 4. HighAvailabilityfor Postgres using built-in • Streaming Replication • Logical Replication 5. Postgres Multi-Node Architecture for High Availability 6. EDB tools for HighAvailabilitymanagement and monitoring 2
- 3. EDB superchargesPostgreSQL Largest dedicated PostgreSQLcompany Major PostgreSQL communityleader Over 5,000 customers- 1 in 4 of Fortune 500 Founded in 2004 Over 10 years of consecutivequarterly subscriptiongrowth 500+ employees Recognised leader in Relational Database Management Systems (RDBMS) by both Gartner and Forrester 2019 Challengers Leaders Visionaries Abilitytoexecute NichePlayers Completenessof vision 3 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.
- 4. Thelargest dedicated PostgreSQLcompany • More customers: Than any dedicatedPostgreSQL company • More experts: Leading PostgreSQL contributors • More innovation: Positioned to lead in enterprisePostgreSQL and hybridcloud EDB acquires 2ndQuadrant in Sept 2020 + 4 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.
- 6. High Availability 6 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved. High availability (HA) is a characteristicof a system, which aims to ensure an agreed level of operational performance,usually uptime, for a higher than normal period. Key principles: • Eliminatesingle point of failure • Reliablecrossover • Detection offailures Ref:https://en.wikipedia.org/wiki/High_availability
- 7. SLAs.. 7 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved. • Availability mentioned in SLAs are only goals of service provider • Usually when it’s not met than company pays off the fees
- 8. Magic number: 9’s 8 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved. Calculated/expressed as a percentage of uptime in a given year based on the service level agreements.Some companies exclude the planned outage/scheduled downtimebased on their agreementswith customers on the availabilityof their services. Availability% Downtime peryear Downtime permonth Downtime per week Downtime perday 99.99% ("fournines") 52.60minutes 4.38minutes 1.01minutes 8.64seconds 99.995% ("four and a half nines") 26.30minutes 2.19minutes 30.24seconds 4.32seconds 99.999% ("fivenines") 5.26minutes 26.30seconds 6.05seconds 864.00 milliseconds
- 10. RPO/RTO: Key Components of High Availability RecoveryPoint Objective(RPO)/RecoveryTimeObjective(RTO) Recovery Point Objective Recovery TimeObjective http://www.allnetkc.com/definitions.html 10 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.
- 11. GRO: Key Component of High Availability 11 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved. GeographicRedundancy Objective(GRO) "...sometimesconsideredthe disaster recovery requirement.This objectiveencompasses what data needs to be replicated offsite, how often and how far." https://storageswiss.com/2014/01/22/backup-basics-what-do-slo-rpo-rto-vro-and-gro- mean/#:~:text=Geographic%20Redundancy%20Objective&text=Simply%20put%2C%20users%20are%20more,multiple%2 0geographic%20requirements%20per%20application.
- 12. High Availability For Postgres: Key Principles
- 14. Eliminate Single Point of failure 14 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved. • WAL shipping based replication • Replicationbased on the archivedWAL • Streaming replication(SR) • Streaming WAL files to one or more standbys • Logical replication • Streaming logical data modifications from the WAL.
- 15. Eliminate Single Point of failure 15 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved. Hot Standby • Identical to primarysystem • Data is still mirrored in real time • Allows READ • On failure,can replaceprimary • Approaches • WAL shippingbased • Streaming WAL (widelyused after9.0)
- 16. Eliminate Single Point of failure Hot Standby: WALshipping 16 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.
- 17. Eliminate Single Point of failure Hot Standby: StreamingReplication 17 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.
- 18. Eliminate Single Point of failure 18 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved. Streaming Replication • Asynchronous StreamingReplication • Synchronous StreamingReplication • synchronous_standby_names Read more about the parameter in the doc: https://www.postgresql.org/docs/10/runtime-config-replication.html
- 19. Eliminate Single Point of failure 19 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved. • Primary server with one or more "hot" standby servers • Suitable for production environments with high availability and read scaling • Write performant, but un-replicated transactions may be lost during failover Property Description Recovery Time Objective < 60 seconds Recovery Point Objective Typically a few seconds or less during failover (un-replicated transactions maybe lost). Dependent on backup strategy for fullrecovery. Geographic Redundancy Objective Dependent on node placement. Typically multi-availability zone. Target Availability 99.99% (99.999% may be possible with failover tuning) Multi node with asynchronous replication
- 20. 20 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.
- 21. Eliminate Single Point of failure 21 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved. • Primary server with one or more"hot" standby servers • Suitable for production environments with high availability and read scaling • Less write performant,but no loss of committed transactions during failover Property Description Recovery Time Objective < 60 seconds Recovery Point Objective Typically a few seconds or less during failover, with no loss ofcommitted transactions. Dependent on backup strategy for full recovery. Geographic Redundancy Objective Dependent on node placement. Typically multi-availability zone. Target Availability 99.99% (99.999% may be possible with failover tuning) Multi node with synchronous replication
- 22. 22 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.
- 24. Reliable Crossover &Detection of Failure 24 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved. • In a redundant system, the crossover point itself becomes a single point of failure. • Fault-tolerant systems must provide a reliable crossover or automaticswitchover mechanism to avoidfailure. • Detection offailures: • If the above two principles are proactively monitored,then a user may never see a system failure.
- 25. Reliable Crossover &Detection EDBPostgres Failover Manager: • Continuously monitors your PostgreSQL service to automatically detectfailures. • After an outage is confirmed,Failover Manager automatically promotes the most up-to-date standby databaseas the new master. 25 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.
- 26. Reliable Crossover &Detection EDB Postgres Failover Manager: 26 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.
- 28. RPO/RTO/MTTR/GPO BackupAnd RecoveryTool 28 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.
- 29. RPO/RTO/MTTR/GPO BackupAnd RecoveryTool 29 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.
- 31. High AvailabilityMonitoring Postgres EnterpriseManager 31 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.
- 32. High AvailabilityMonitoring Postgres EnterpriseManager 32 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.
- 33. Conclusion 33 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved. • High Availabilitycomponents • Hot Standby (StreamingReplication) • EDBPostgres Failover Manager • Postgres EnterpriseManager • BackupAnd RecoveryTool • Design consideration • Near zero downtime softwaremaintenance • RPO/RTO/GRO
- 34. Resources 34 © Copyright EnterpriseDBCorporation, 2020. All rightsreserved. • Blog series • What Does HighAvailability Really Mean • Patching Minor Version in Postgres HighAvailability(HA) Database Cluster • Plans &Strategiesfor DBAs • Key Parameters and Configuration for Streaming Replicationin Postgres 12 • Quick and Reliable Failure Detection with EDB Postgres Failover Manager
- 35. © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.37
- 36. © Copyright EnterpriseDBCorporation, 2020. All rightsreserved.37