The terminology that follows is important for understanding EDB Postgres Distributed functionality and the requirements that it addresses in the realms of high availability, replication, and clustering.
Copies data to cluster members after the transaction completes on the origin node. Asynchronous replication can provide higher performance and lower latency than synchronous replication. However, it introduces the potential for conflicts because of multiple concurrent changes. You must manage any conflicts that arise.
The probability that a system will operate satisfactorily at a given time when used in a stated environment. For many people, this is the overall amount of uptime versus downtime for an application. (See also Nines)
Wraps Eager Replication with additional transaction management at the application level to guard against a transaction being executed more than once. This is critical for high-value transactions found in payments solutions. It is roughly equivalent to the Oracle feature Transaction Guard.
An approach for high availability in which multiple redundant systems are managed to avoid single points of failure. It appears to the end user as one system.
Enables scaling out a database by breaking up data into chunks called shards and distributing them across separate nodes.
Conflict-free replication with all cluster members; technically, this is synchronous logical replication using two phase-commit (2PC).
A distributed computing consistency model stating changes to the same item in different cluster members will converge to the same value. With BDR this is achieved through asynchronous logical replication with conflict resolution and conflict-free replicated data types.
The automated process that recognizes a failure in a highly available database cluster and takes action to connect the application to another active database. The goal is to minimize downtime and data loss.
A modern distributed computing approach that manages workloads across multiple nodes, such as scaling out a web server to handle increased traffic.
Provides more flexibility than physical replication in terms of selecting the data replicated between databases in a cluster. Also important is that cluster members can be on different versions of the database software.
A measure of availability expressed as a percentage of uptime in a given year. Three nines (99.9%) allows for 43.83 minutes of downtime per month. Four nines (99.99%) allows for 4.38 minutes of downtime per month. Five nines (99.999%) allows for 26.3 seconds of downtime per month.
One database server in a cluster. A term "node" differs from the term "database server" because there is more than one node in a cluster. A node includes the database server, the OS, and the physical hardware, which is always separate from other nodes in a high-availability context.
Copies all changes from a database to one or more standby cluster members by copying an exact copy of database disk blocks. While fast, this method has downsides. For example, only one master node can run write transactions. Also, you can use this method only where all cluster members are on the same major version of the database software, in addition to several other more complex restrictions.
Can be achieved by introducing one or more read replica nodes to a cluster and have the application direct writes to the primary node and reads to the replica nodes. As the read workload grows, you can increase the number of read replica nodes to maintain performance.
The maximum targeted period in which data might be lost due to a disruption in delivery of an application. A very low or minimal RPO is a driver for very high availability.
The targeted length of time for restoring the disrupted application. A very low or minimal RTO is a driver for very high availability.
The identification of a component in a deployed architecture that has no redundancy and therefore prevents you from achieving higher levels of availability.
A planned change in connection between the application and the active database node in a cluster, typically done for maintenance.
When changes are updated at all participating nodes at the same time, typically leveraging two-phase commit. While this approach delivers immediate consistency and avoids conflicts, a performance cost in latency occurs due to the coordination required across nodes.
A multi-step process for achieving consistency across multiple database nodes.
A traditional computing approach of increasing a resource (CPU, memory, storage, network) to support a given workload until the physical limits of that architecture are reached, e.g., Oracle Exadata.
Occurs when replicating the writes from the original node to other cluster members becomes less expensive. In vertical-scaled architectures, write scalability is possible due to shared resources. However, in horizontal scaled (or nothing-shared) architectures, this is possible only in very limited scenarios.
- On this page
- Asynchronous replication
- CAMO or commit-at-most-once
- Data sharding
- Eager Replication for BDR
- Eventual consistency
- Horizontal scaling or scale out
- Logical replication
- Physical replication
- Read scalability
- Recovery point objective (RPO)
- Recovery time objective (RTO)
- Single point of failure (SPOF)
- Synchronous replication
- Two-phase commit (2PC)
- Vertical scaling or scale up
- Write scalability