Highly available databases are essential to organizations depending on mission-critical, 24/7 access to data. Postgres is widely recognized as an excellent open-source database, with critical maturity and features that allow organizations to scale and achieve high availability.
This webinar will explore:
- Evolution of replication in Postgres
- Streaming replication
- Logical replication
- Replication for high availability
- Important high availability parameters
- Options to monitor high availability
- HA infrastructure to patch the database with minimal downtime
- EDB Postgres Failover Manager (EFM)
- EDB tools to create a highly available Postgres architecture
Webinar video:
Webinar slides:
Webinar Q&A
Q: Is there a strategy to do a pg_upgrade on master/standby’s that doesn't involve promoting a standby and rebuilding the master?
A: Yes, pg_upgrade has instructions on upgrading the standby in place, rather than rebuilding it from scratch. However, it requires downtime on master and standby. In case, you want a near-zero downtime, then using logical replication you could create a new HA cluster and replace it with a new version of the cluster after the switchover.
Q: How can we reduce the downtime to perform a major version upgrade?
A: You can use either logical replication or pg_upgrade. However, depending on the committed 9s, you would like to verify which method is suitable for your environment.
Q: Is streaming replication available in version 11?
A: Yes, for many years before PG 11.
Q: Is there a possibilité to include in roadmap to have master/master in order to use all databases with a cluster? (I manage big select for statistique)
A: Most cases are better handled with primary/replica. You can create multi-master clusters, but not with core Postgres tools. It is unlikely that it would be in core Postgres because of the management/conflict resolution needed in the multi-master replication product. For more information, please see the link below
Q: What are the requirements for VIP creation?
A: For creating a VIP address and assigning the VIP address, please discuss it with Operating System Vendor. For Linux, you could use the following link:
https://linuxconfig.org/how-to-configure-virtual-network-interface-on-redhat-7-linux
Q: Where do we find the blogs listed on the presentation slide?
A: Following are the links of blogs:
- https://www.enterprisedb.com/blog/edb-postgres-automatic-failover-detection-high-availabile-clusters
- https://www.enterprisedb.com/blog/high-availibility-parameters-configuration-streaming-replication-postgresql
- https://www.enterprisedb.com/blog/what-does-database-high-availability-really-mean
- https://www.enterprisedb.com/blog/postgresql-database-patching-ha-cluster-postgres-update-minor-versions
Q: Are there any documents for Windows server Postgres replication?
A: Steps included in the Postgres guide can be used for Windows. Below is a link which shows all commands for
Q: This is related to the with 2 nodes in primary site - 1 master and 1 standby, 1 node in DR(standby) + 1 witness in DR in case of a site failure. Does the database failover automatically?
A: <will share the response later>
Q: Can we promote the DR manually?
A: Yes, you can promote DR manually using either EFM command or using the pg_ctl promote -D <DATA DIRECTORY>
Q: How are most customers handling switching applications to point to the standby on dynamic failover events?
A: You can use a pooler to repoint applications to the new primary or use VIP migration, or libpq allows for it to try multiple hosts.
Q: We can manual failover on 2 node clusters without a witness?
A: Yes you can use manual failover on 2 node clusters or you can also Postgres pg_ctl command for performing the manual failover.
Q: Can EFM be efficient if there are only one master and one standby?
A: If your cluster has one master, one standby, and one witness, then failover time can be faster because EFM doesn’t have to use the election algorithm to find the correct node for failover.
Q: Is it possible to replicate from master to target for only selected tables?
A: Yes, with logical replication.
Q: Do we need to rebuild de slave servers on major version upgrade?
A: Not with pg_upgrade. However, with logical replication, you can create a new HA cluster with a higher version and replace the old version HA cluster with the new one.