How to Design for Database High Availability
Download as PPTX, PDF2 likes1,715 views
This document outlines a webinar on designing for database high availability, focusing on critical concepts such as replication evolution in Postgres, recovery objectives, and high availability strategies. It introduces key tools like the EDB Postgres Failover Manager and discusses the importance of eliminating single points of failure and monitoring systems. The agenda includes topics ranging from streaming replication to software update strategies for maintaining high availability in Postgres environments.
How to Design for Database High Availability
- 1. © Copyright EnterpriseDB Corporation, 2020. All rights reserved. How to Design for Database High Availability Vibhor Kumar, Chief Performance Architect Marc Linster, Senior Vice President of Product Development Bruce Momjian, Postgres Evangelist 1
- 2. Welcome – Housekeeping Items • Slides and recording will be available in next 48 hours • Submit questions via GotoWebinar – will be answering at end • We will be sharing info about EDB and Postgres later 2
- 3. Webinar Series 3 April 29 2020 My Favorite Postgres books May 13 2020 Database Administration for Postgres June 3 2020 New Approaches to Integrating Oracle and Postgres Database Strategies June 17 2020 How to Design for Database High Availability July 15 2020 Using the Postgres Tuning Wizard in PEM Every other Monday at 8:00 AM PDT/ 11:00 AM EDT 16:00 BST/ 17:00 CET https://www.enterprisedb.com/postgres-pulse
- 4. Agenda ● Evolution of replication in Postgres ○ Streaming replication ○ Logical replication ● Replication for high availability ● Important high availability parameters ● Monitor high availability ● Patch the database with minimal downtime ● EDB Postgres Failover Manager (EFM) ● EDB tools to create a highly available Postgres architecture 4
- 6. High Availability High availability (HA) is a characteristic of a system, which aims to ensure an agreed level of operational performance, usually uptime, for a higher than normal period. ● Key Principles ○ Eliminate single point of failure ○ Reliable crossover ○ Detection of failures 6
- 7. ● RPO – Recovery Point Objective ○ How much data can I lose? ○ Ex: RPO = 2 hours 🡺 In case of a crash I may forget everything that I did in the last 2 hours! ● RTO - Recovery Time Objective ○ How much time do I have to recover the database after a crash? ○ Includes: ■ Load the initial backup ■ Play back the WAL files Key Metrics for HA/DR 7 ● MTTR - Mean Time to Recovery ○ On average – how long will RTO be ○ More WAL files to re-play if the last full backup was a long time ago ● GRO – Geographic Recovery Objective ○ If my datacenter becomes unavailable, how long will it take for the service to become available again? ● Maintenance Windows ○ How many hours of planned maintenance per year?
- 8. Evolution of Replication in Postgres 8 PostgreSQL 7.x (~2000) ● Replication should not be part of core Postgres ● Londiste – Slony (trigger based logical replication) PostgreSQL 8.0 (~2005) ● Point-In-Time Recovery (WAL) PostgreSQL 9.4 (~2014) ● Logical Decoding (changeset extraction) PostgreSQL 9.0 (~2010) ● Streaming Replication (physical) PostgreSQL 8.2 (~2006) ● Warm Standby ● EFM for
- 9. High Availability 9 Eliminate Single Point of Failure
- 10. Eliminate Single Point of Failure ● WAL shipping based replication ○ Replication based on the archived WAL ● Streaming replication (SR) ○ Streaming WAL files to one or more standbys ● Logical replication ○ Streaming logical data modifications from the WAL. 10
- 11. Hot Standby ● Identical to primary system ○ Data is still mirrored in real time ○ Allows READ ○ On failure, can replace primary ● Approaches ○ WAL shipping based ○ Streaming WAL (widely used after 9.0) 11
- 12. Hot Standby: WAL Shipping 12
- 13. Monitor: WAL Shipping ● Functions on standby ○ pg_is_in_recovery() ○ pg_last_xlog/wal_replay_location/lsn() ○ pg_last_xact_replay_timestamp() 13
- 14. Hot standby: Streaming WAL 14
- 15. Streaming Replication ● Asynchronous Streaming Replication ● Synchronous Streaming Replication ○ synchronous_standby_names ■ e.g. ■ FIRST 1 (standby_east, standby_west) ■ ANY 3 (standby_east, standby_west, eu_standby_east, eu_standby_west) ■ 'standby_east, standby_west' ○ synchronous_commit - off/local/remote_write/on/remote_apply 15
- 16. Monitor: Streaming Replication ● Views ○ Master: pg_stat_replication ○ Standby: pg_wal_receiver 16
- 17. High Availability 17 Reliable Crossover & Detection
- 18. 18 EDB POSTGRES FAILOVER MANAGER (EFM) Protect Your Mission Critical Applications from Costly Outages High Availability Infrastructure for EDB Postgres Clusters Ensure Data Remains Available in the Event of a Failure ELIMINATE SINGLE POINTS OF FAILURE DETECTS AND AUTOMATES FAILOVER PEACE OF MIND FAILOVER WILL BE INITIATED
- 21. Software Updates: Postgres H.A. cluster ● Three reasons for software updates ○ Remedy known software issues ○ General stability and reliability of the software ○ Security problem 21
- 22. Software Updates: Strategies ● Three strategies ○ All Nodes Patching ○ Rolling Patching ○ Minimum Downtime Patching 22
- 23. High Availability 23 Postgres H.A Architecture
- 24. USE CASE - Architecture 24 Highly Available Postgres Cluster with Automatic Failover, Backups and Monitoring enabled High Availability & Resiliency • Master & Replica spread across • Failover to most recent standby • Reconfigure remaining standby to the new master • Allow switching the roles of Master-standby Monitoring, Alerting & Tuning • Monitor multiple database servers with intuitive dashboards, email, SNMP alerts, and rich APIs • Alerts on load, bloat, memory utilization, server/agent down • Track slow queries, analyze and tune it Backup & Recovery • Fast Backups and trouble free Disaster Recovery Architecture
- 25. Conclusion ● High Availability components ○ Hot Standby (Streaming Replication) ○ EDB Postgres Failover Manager ○ Postgres Enterprise Manager ● Design consideration ○ Near zero downtime software maintenance ○ RPO/RTO/GRO 25
- 26. Resources Blog series ● What Does High Availability Really Mean ● Patching Minor Version in Postgres High Availability (HA) Database Cluster ● Plans & Strategies for DBAs ● Key Parameters and Configuration for Streaming Replication in Postgres 12 ● Quick and Reliable Failure Detection with EDB Postgres Failover Manager 26
- 27. ONLY OPEN SOURCE BASED RDBMS IN GARTNER MQ EDB Recognized 7 Years In A Row on Gartner’s Magic Quadrant 27 CONFIDENTIAL © Copyright EnterpriseDB Corporation, 2020. All rights reserved.
- 28. 28 Customers working SMARTER, reducing RISK and being more PRODUCTIVE with EDB. OVER 4,000 CUSTOMERS U.S Customers EMEA Customers APAC Customers 102 of the Fortune 500 337 of the Forbes Global 2000
- 29. EDB OPEN SOURCE LEADERSHIP NAMED EDB OPEN SOURCE COMMITTERS AND CONTRIBUTORS 29 ● CORE TEAM ● ● ● ● MAJOR CONTRIBUTORS ● CONTRIBUTORS Akshay Joshi Amul Sul Ashesh Vashi Dilip Kumar Jeevan Ladhe Mithun Cy Devrim Gündüz Amit Kapila Bruce Momjian Dave Page Robert Haas Ashutosh Sharma Rushabh Lathia - designates committers
- 30. 30 EDB Postgres Database 24/7 Global Support Professional Services Postgres Contributions Tools & Innovation Security/performance
- 32. © Copyright EnterpriseDB Corporation, 2020. All rights reserved.32 THANK YOU [email protected] www.enterprisedb.com