From bd8ddf0ad236222e6125da4fc0d3e27842720068 Mon Sep 17 00:00:00 2001 From: Josh Earlenbaugh Date: Tue, 14 Jan 2025 12:59:21 -0500 Subject: [PATCH] fixed links. --- .../docs/pgd/5.6/overview/basic-architecture.mdx | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/product_docs/docs/pgd/5.6/overview/basic-architecture.mdx b/product_docs/docs/pgd/5.6/overview/basic-architecture.mdx index 5576b88a4d5..b446c399426 100644 --- a/product_docs/docs/pgd/5.6/overview/basic-architecture.mdx +++ b/product_docs/docs/pgd/5.6/overview/basic-architecture.mdx @@ -40,7 +40,7 @@ BDR is a Postgres extension that enables a multi-master replication mesh between Changes are replicated directly, row-by-row between all nodes. [Logical replication](../terminology/#logical-replication) in PGD is asynchronous by default, so only eventual consistency is guaranteed (within seconds usually). -However, [commit scope](../durability/commit-scopes) options offer stronger consistency and durability guarantees via [CAMO](/pgd/latest/durability/camo/), [group](../durability/group-commit) and [synchronous](../durability/synchronous_commit) commits. +However, [commit scope](../commit-scopes/commit-scopes) options offer stronger consistency and durability guarantees via [CAMO](/pgd/latest/commit-scopes/camo/), [group](../commit-scopes/group-commit) and [synchronous](../commit-scopes/synchronous_commit) commits. The Raft algorithm provides a mechanism for [electing](../routing/raft/04_raft_elections_in_depth/) leaders (both Raft leader and write leader), deciding which nodes should be added or subtracted from the cluster, and generally ensuring that the distributed system remains consistent and fault-tolerant, even in the face of node failures. @@ -49,10 +49,10 @@ The Raft algorithm provides a mechanism for [electing](../routing/raft/04_raft_e PGD comprises several key architectural elements that work together to provide its distributed database solution: - **PGD nodes**: These are individual Postgres instances that store and manage data. They are the basic building blocks of a PGD cluster. - + - **Groups**: PGD nodes are organized into [groups](../node_management/groups_and_subgroups), which enhance manageability and high availability. Each group can contain multiple nodes, allowing for redundancy and failover within the group. Groups facilitate organized replication and data consistency among nodes within the same group and across different groups. Each group has its own write leader. - - **Replication mechanisms**: PGD's replication mechanisms include Bi-Directional Replication (BDR) for efficient replication across nodes, enabling multi-master replication. BDR supports asynchronous replication by default, but can be configured for varying levels of synchronicity, such as [Group Commit](../durability/group-commit) or [Synchronous Commit](../durability/synchronous_commit), to enhance data durabiltiy and consistency. + - **Replication mechanisms**: PGD's replication mechanisms include Bi-Directional Replication (BDR) for efficient replication across nodes, enabling multi-master replication. BDR supports asynchronous replication by default, but can be configured for varying levels of synchronicity, such as [Group Commit](../commit-scopes/group-commit) or [Synchronous Commit](../commit-scopes/synchronous_commit), to enhance data durability. - **Monitoring tools**: To monitor performance, health, and usage with PGD, you can utilize its [built-in command-line interface](../cli) (CLI), which offers several useful commands. For instance, the `pgd show-nodes` command provides a summary of all nodes in the cluster, including their state and status. The `pgd check-health` command checks the health of the cluster, reporting on node accessibility, replication slot health, and other critical metrics. The `pgd show-events` command lists significant events like background worker errors and node membership changes, which helps in tracking the operational status and issues within the cluster. Furthermore, the BDR extension allows for monitoring your cluster using SQL using the [`bdr.monitor`](../security/pgd-predefined-roles/#bdr_monitor) role. @@ -60,15 +60,15 @@ PGD comprises several key architectural elements that work together to provide i All nodes in PGD are effectively data nodes. They vary only in their purpose in the cluster. - - **[Data nodes](../node_management/node_types/#data-nodes)**: Store and manage data, handle read and write operations, and participate in replication. + - **[Data nodes](../nodes/#data-nodes)**: Store and manage data, handle read and write operations, and participate in replication. There are then three types of node which, although built like a data node, have a specific purpose. These are: - - **[Subscriber-only nodes](../node_management/subscriber_only/#subscriber-only-nodes)**: Subscribe to changes from data nodes for read-only purposes, used in reporting or analytics. + - **[Subscriber-only nodes](../nodes/subscriber_only/#subscriber-only-nodes)**: Subscribe to changes from data nodes for read-only purposes, used in reporting or analytics. - - **[Witness nodes](../node_management/witness_nodes/)**: Participate in concensus proceses without storing data, aiding in achieving quorum and maintaining high availability. + - **[Witness nodes](../nodes/witness_nodes/)**: Participate in the consensus process without storing data, aiding in achieving quorum and maintaining high availability. - - **[Logical standby nodes](../node_management/logical_standby_nodes/)**: Act as standby nodes that can be promoted to data nodes if needed, ensuring high availability and disaster recovery. + - **[Logical standby nodes](../nodes/logical_standby_nodes/)**: Act as standby nodes that can be promoted to data nodes if needed, ensuring high availability and disaster recovery. ### Node roles @@ -76,7 +76,7 @@ Data nodes in a group can also take on particular roles to enable particular fea These roles are transient and can be transferred to any other capable node in the group if needed. These roles can include: - - **[Raft leader]()**: Arbitrates and manages consensus between a group's nodes. + - **Raft leader**: Arbitrates and manages consensus between a group's nodes. - **[Write leader](../terminology/#write-leader)**: Receives all write operations from PGD Proxy.