From 16b969d8e0bdf9786c643d287fc07e2a0743a7e1 Mon Sep 17 00:00:00 2001 From: Josh Heyer Date: Tue, 22 Apr 2025 15:08:01 +0000 Subject: [PATCH 001/145] Renamed 5.8 to 6.0 --- product_docs/docs/pgd/{5.8 => 6}/appusage/behavior.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/appusage/dml-ddl.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/appusage/extensions.mdx | 0 .../docs/pgd/{5.8 => 6}/appusage/feature-compatibility.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/appusage/index.mdx | 0 .../docs/pgd/{5.8 => 6}/appusage/nodes-with-differences.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/appusage/rules.mdx | 0 .../docs/pgd/{5.8 => 6}/appusage/table-access-methods.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/appusage/timing.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/backup.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cdc-failover.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/assess/index.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/cluster/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/cluster/show.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/cluster/verify.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/commit-scope/create.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/commit-scope/drop.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/commit-scope/index.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/commit-scope/show.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/commit-scope/update.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/completion/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/events/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/events/show.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/group/get-option.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/group/index.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/group/set-leader.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/group/set-option.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/group/show.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/groups/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/groups/list.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/index.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/node/get-option.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/node/index.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/node/set-option.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/node/show.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/node/upgrade.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/nodes/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/nodes/list.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/raft/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/raft/show.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/replication/index.mdx | 0 .../docs/pgd/{5.8 => 6}/cli/command_ref/replication/show.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/configuring_cli.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/discover_connections.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/installing/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/installing/linux.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/installing/macos.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/installing/tpa.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/cli/using_cli.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/commit-scopes/administering.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/commit-scopes/camo.mdx | 0 .../docs/pgd/{5.8 => 6}/commit-scopes/commit-scope-rules.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/commit-scopes/commit-scopes.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/commit-scopes/comparing.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/commit-scopes/degrading.mdx | 0 .../docs/pgd/{5.8 => 6}/commit-scopes/durabilityterminology.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/commit-scopes/group-commit.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/commit-scopes/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/commit-scopes/lag-control.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/commit-scopes/legacy-sync.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/commit-scopes/limitations.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/commit-scopes/origin_groups.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/commit-scopes/overview.mdx | 0 .../docs/pgd/{5.8 => 6}/commit-scopes/synchronous_commit.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/commit-scopes/timing.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/compatibility.mdx | 0 .../column-level-conflicts/01_overview_clcd.mdx | 0 .../column-level-conflicts/02_enabling_disabling.mdx | 0 .../conflict-management/column-level-conflicts/03_timestamps.mdx | 0 .../conflict-management/column-level-conflicts/index.mdx | 0 .../conflict-management/conflicts/00_conflicts_overview.mdx | 0 .../conflict-management/conflicts/02_types_of_conflict.mdx | 0 .../conflict-management/conflicts/03_conflict_detection.mdx | 0 .../conflict-management/conflicts/04_conflict_resolution.mdx | 0 .../conflict-management/conflicts/05_conflict_logging.mdx | 0 .../{5.8 => 6}/conflict-management/conflicts/06_live_compare.mdx | 0 .../docs/pgd/{5.8 => 6}/conflict-management/conflicts/index.mdx | 0 .../pgd/{5.8 => 6}/conflict-management/crdt/00_crdt_overview.mdx | 0 .../pgd/{5.8 => 6}/conflict-management/crdt/01_crdt_usage.mdx | 0 .../pgd/{5.8 => 6}/conflict-management/crdt/02_state-op-crdts.mdx | 0 .../pgd/{5.8 => 6}/conflict-management/crdt/03_crdt-disk-reqs.mdx | 0 .../{5.8 => 6}/conflict-management/crdt/04_crdt-vs-conflict.mdx | 0 .../pgd/{5.8 => 6}/conflict-management/crdt/05_crdt-reset.mdx | 0 .../{5.8 => 6}/conflict-management/crdt/06_crdt-implemented.mdx | 0 .../docs/pgd/{5.8 => 6}/conflict-management/crdt/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/conflict-management/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/data_migration/edbloader.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/data_migration/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/ddl/ddl-command-handling.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/ddl/ddl-locking.mdx | 0 .../docs/pgd/{5.8 => 6}/ddl/ddl-managing-with-pgd-replication.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/ddl/ddl-overview.mdx | 0 .../docs/pgd/{5.8 => 6}/ddl/ddl-pgd-functions-like-ddl.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/ddl/ddl-replication-options.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/ddl/ddl-role-manipulation.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/ddl/ddl-workarounds.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/ddl/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/decoding_worker.mdx | 0 .../pgd/{5.8 => 6}/deploy-config/deploy-cloudservice/index.mdx | 0 .../docs/pgd/{5.8 => 6}/deploy-config/deploy-kubernetes/index.mdx | 0 .../deploy-manual/deploying/01-provisioning-hosts.mdx | 0 .../deploy-config/deploy-manual/deploying/02-install-postgres.mdx | 0 .../deploy-manual/deploying/03-configuring-repositories.mdx | 0 .../deploy-manual/deploying/04-installing-software.mdx | 0 .../deploy-config/deploy-manual/deploying/05-creating-cluster.mdx | 0 .../deploy-config/deploy-manual/deploying/06-check-cluster.mdx | 0 .../deploy-manual/deploying/07-configure-proxies.mdx | 0 .../deploy-config/deploy-manual/deploying/08-using-pgd-cli.mdx | 0 .../deploy-config/deploy-manual/deploying/images/edbrepos2.0.png | 0 .../{5.8 => 6}/deploy-config/deploy-manual/deploying/index.mdx | 0 .../docs/pgd/{5.8 => 6}/deploy-config/deploy-manual/index.mdx | 0 .../deploy-config/deploy-tpa/deploying/01-configuring.mdx | 0 .../deploy-config/deploy-tpa/deploying/02-deploying.mdx | 0 .../pgd/{5.8 => 6}/deploy-config/deploy-tpa/deploying/index.mdx | 0 .../docs/pgd/{5.8 => 6}/deploy-config/deploy-tpa/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/deploy-config/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/known_issues.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/monitoring/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/monitoring/otel.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/monitoring/sql.mdx | 0 .../pgd/{5.8 => 6}/node_management/connections_dsns_and_ssl.mdx | 0 .../docs/pgd/{5.8 => 6}/node_management/creating_and_joining.mdx | 0 .../docs/pgd/{5.8 => 6}/node_management/creating_nodes.mdx | 0 .../docs/pgd/{5.8 => 6}/node_management/groups_and_subgroups.mdx | 0 .../pgd/{5.8 => 6}/node_management/heterogeneous_clusters.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/node_management/index.mdx | 0 .../pgd/{5.8 => 6}/node_management/maintainance_with_proxies.mdx | 0 .../docs/pgd/{5.8 => 6}/node_management/node_recovery.mdx | 0 .../pgd/{5.8 => 6}/node_management/removing_nodes_and_groups.mdx | 0 .../docs/pgd/{5.8 => 6}/node_management/replication_slots.mdx | 0 .../docs/pgd/{5.8 => 6}/node_management/viewing_topology.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/nodes/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/nodes/logical_standby_nodes.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/nodes/overview.mdx | 0 .../docs/pgd/{5.8 => 6}/nodes/subscriber_only/creating-so.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/nodes/subscriber_only/index.mdx | 0 .../docs/pgd/{5.8 => 6}/nodes/subscriber_only/joining-so.mdx | 0 .../docs/pgd/{5.8 => 6}/nodes/subscriber_only/optimizing-so.mdx | 0 .../docs/pgd/{5.8 => 6}/nodes/subscriber_only/overview.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/nodes/witness_nodes.mdx | 0 .../docs/pgd/{5.8 => 6}/overview/architecture-and-performance.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/overview/basic-architecture.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/overview/compared.mdx | 0 .../docs/pgd/{5.8 => 6}/overview/images/always_on_1x3_updated.png | 0 product_docs/docs/pgd/{5.8 => 6}/overview/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/parallelapply.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/planning/architectures.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/planning/choosing_server.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/planning/deployments.mdx | 0 .../pgd/{5.8 => 6}/planning/images/always-on-2x3-aa-updated.png | 0 .../docs/pgd/{5.8 => 6}/planning/images/always_on_1x3_updated.png | 0 .../pgd/{5.8 => 6}/planning/images/always_on_2x3_aa_updated.png | 0 product_docs/docs/pgd/{5.8 => 6}/planning/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/planning/limitations.mdx | 0 .../docs/pgd/{5.8 => 6}/planning/other_considerations.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/postgres-configuration.mdx | 0 .../docs/pgd/{5.8 => 6}/quickstart/connecting_applications.mdx | 0 .../docs/pgd/{5.8 => 6}/quickstart/further_explore_conflicts.mdx | 0 .../docs/pgd/{5.8 => 6}/quickstart/further_explore_failover.mdx | 0 .../pgd/{5.8 => 6}/quickstart/further_explore_replication.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/quickstart/images/4sessions.png | 0 .../pgd/{5.8 => 6}/quickstart/images/4sessionsinsertconflict.png | 0 .../pgd/{5.8 => 6}/quickstart/images/4sessionsupdateconflict.png | 0 .../docs/pgd/{5.8 => 6}/quickstart/images/4sshsessions.png | 0 product_docs/docs/pgd/{5.8 => 6}/quickstart/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/quickstart/next_steps.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/quickstart/quick_start_aws.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/quickstart/quick_start_cloud.mdx | 0 .../docs/pgd/{5.8 => 6}/quickstart/quick_start_docker.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/quickstart/quick_start_linux.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/autopartition.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/catalogs-internal.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/catalogs-visible.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/clcd.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/commit-scopes.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/conflict_functions.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/conflicts.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/functions-internal.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/functions.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/index.json | 0 product_docs/docs/pgd/{5.8 => 6}/reference/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/index.mdx.src | 0 .../docs/pgd/{5.8 => 6}/reference/nodes-management-interfaces.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/nodes.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/pgd-settings.mdx | 0 .../docs/pgd/{5.8 => 6}/reference/repsets-ddl-filtering.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/repsets-management.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/repsets-membership.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/routing.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/sequences.mdx | 0 .../docs/pgd/{5.8 => 6}/reference/streamtriggers/index.mdx | 0 .../docs/pgd/{5.8 => 6}/reference/streamtriggers/interfaces.mdx | 0 .../docs/pgd/{5.8 => 6}/reference/streamtriggers/rowfunctions.mdx | 0 .../docs/pgd/{5.8 => 6}/reference/streamtriggers/rowvariables.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/reference/testingandtuning.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/rel_notes/index.mdx | 0 .../docs/pgd/{5.8 => 6}/rel_notes/pgd_5.0.0_rel_notes.mdx | 0 .../docs/pgd/{5.8 => 6}/rel_notes/pgd_5.0.1_rel_notes.mdx | 0 .../docs/pgd/{5.8 => 6}/rel_notes/pgd_5.1.0_rel_notes.mdx | 0 .../docs/pgd/{5.8 => 6}/rel_notes/pgd_5.2.0_rel_notes.mdx | 0 .../docs/pgd/{5.8 => 6}/rel_notes/pgd_5.3.0_rel_notes.mdx | 0 .../docs/pgd/{5.8 => 6}/rel_notes/pgd_5.4.0_rel_notes.mdx | 0 .../docs/pgd/{5.8 => 6}/rel_notes/pgd_5.4.1_rel_notes.mdx | 0 .../docs/pgd/{5.8 => 6}/rel_notes/pgd_5.5.0_rel_notes.mdx | 0 .../docs/pgd/{5.8 => 6}/rel_notes/pgd_5.5.1_rel_notes.mdx | 0 .../docs/pgd/{5.8 => 6}/rel_notes/pgd_5.6.0_rel_notes.mdx | 0 .../docs/pgd/{5.8 => 6}/rel_notes/pgd_5.6.1_rel_notes.mdx | 0 .../docs/pgd/{5.8 => 6}/rel_notes/pgd_5.7.0_rel_notes.mdx | 0 .../docs/pgd/{5.8 => 6}/rel_notes/pgd_5.8.0_rel_notes.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/rel_notes/src/meta.yml | 0 product_docs/docs/pgd/{5.8 => 6}/rel_notes/src/relnote_5.6.0.yml | 0 product_docs/docs/pgd/{5.8 => 6}/rel_notes/src/relnote_5.6.1.yml | 0 product_docs/docs/pgd/{5.8 => 6}/rel_notes/src/relnote_5.7.0.yml | 0 product_docs/docs/pgd/{5.8 => 6}/rel_notes/src/relnote_5.8.0.yml | 0 product_docs/docs/pgd/{5.8 => 6}/repsets.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/routing/administering.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/routing/configuration.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/routing/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/routing/installing_proxy.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/routing/monitoring.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/routing/proxy.mdx | 0 .../pgd/{5.8 => 6}/routing/raft/01_raft_subgroups_and_tpa.mdx | 0 .../pgd/{5.8 => 6}/routing/raft/02_raft_subgroups_and_pgd_cli.mdx | 0 .../{5.8 => 6}/routing/raft/03_migrating_to_raft_subgroups.mdx | 0 .../pgd/{5.8 => 6}/routing/raft/04_raft_elections_in_depth.mdx | 0 .../pgd/{5.8 => 6}/routing/raft/images/PGD5sequencediagram.png | 0 .../pgd/{5.8 => 6}/routing/raft/images/Tmp6NodeRaftSubgroups.png | 0 product_docs/docs/pgd/{5.8 => 6}/routing/raft/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/routing/readonly.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/scaling.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/security/access-control.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/security/index.mdx | 0 .../docs/pgd/{5.8 => 6}/security/pgd-predefined-roles.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/security/role-management.mdx | 0 .../docs/pgd/{5.8 => 6}/security/roles-and-replication.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/security/roles.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/sequences.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/striggers.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/terminology.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/testingandtuning.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/transaction-streaming.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/tssnapshots.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/twophase.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/upgrades/app_upgrades.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/upgrades/compatibility.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/upgrades/index.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/upgrades/inplace_upgrade.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/upgrades/manual_overview.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/upgrades/tpa_overview.mdx | 0 product_docs/docs/pgd/{5.8 => 6}/upgrades/upgrade_paths.mdx | 0 .../docs/pgd/{5.8 => 6}/upgrades/upgrading_major_rolling.mdx | 0 253 files changed, 0 insertions(+), 0 deletions(-) rename product_docs/docs/pgd/{5.8 => 6}/appusage/behavior.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/appusage/dml-ddl.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/appusage/extensions.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/appusage/feature-compatibility.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/appusage/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/appusage/nodes-with-differences.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/appusage/rules.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/appusage/table-access-methods.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/appusage/timing.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/backup.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cdc-failover.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/assess/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/cluster/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/cluster/show.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/cluster/verify.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/commit-scope/create.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/commit-scope/drop.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/commit-scope/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/commit-scope/show.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/commit-scope/update.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/completion/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/events/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/events/show.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/group/get-option.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/group/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/group/set-leader.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/group/set-option.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/group/show.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/groups/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/groups/list.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/node/get-option.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/node/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/node/set-option.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/node/show.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/node/upgrade.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/nodes/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/nodes/list.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/raft/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/raft/show.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/replication/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/command_ref/replication/show.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/configuring_cli.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/discover_connections.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/installing/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/installing/linux.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/installing/macos.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/installing/tpa.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/cli/using_cli.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/administering.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/camo.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/commit-scope-rules.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/commit-scopes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/comparing.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/degrading.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/durabilityterminology.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/group-commit.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/lag-control.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/legacy-sync.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/limitations.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/origin_groups.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/overview.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/synchronous_commit.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/commit-scopes/timing.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/compatibility.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/column-level-conflicts/01_overview_clcd.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/column-level-conflicts/02_enabling_disabling.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/column-level-conflicts/03_timestamps.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/column-level-conflicts/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/conflicts/00_conflicts_overview.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/conflicts/02_types_of_conflict.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/conflicts/03_conflict_detection.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/conflicts/04_conflict_resolution.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/conflicts/05_conflict_logging.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/conflicts/06_live_compare.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/conflicts/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/crdt/00_crdt_overview.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/crdt/01_crdt_usage.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/crdt/02_state-op-crdts.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/crdt/03_crdt-disk-reqs.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/crdt/04_crdt-vs-conflict.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/crdt/05_crdt-reset.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/crdt/06_crdt-implemented.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/crdt/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/conflict-management/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/data_migration/edbloader.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/data_migration/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/ddl/ddl-command-handling.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/ddl/ddl-locking.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/ddl/ddl-managing-with-pgd-replication.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/ddl/ddl-overview.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/ddl/ddl-pgd-functions-like-ddl.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/ddl/ddl-replication-options.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/ddl/ddl-role-manipulation.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/ddl/ddl-workarounds.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/ddl/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/decoding_worker.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-cloudservice/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-kubernetes/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-manual/deploying/01-provisioning-hosts.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-manual/deploying/02-install-postgres.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-manual/deploying/03-configuring-repositories.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-manual/deploying/04-installing-software.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-manual/deploying/05-creating-cluster.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-manual/deploying/06-check-cluster.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-manual/deploying/08-using-pgd-cli.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-manual/deploying/images/edbrepos2.0.png (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-manual/deploying/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-manual/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-tpa/deploying/01-configuring.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-tpa/deploying/02-deploying.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-tpa/deploying/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/deploy-tpa/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/deploy-config/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/known_issues.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/monitoring/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/monitoring/otel.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/monitoring/sql.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/node_management/connections_dsns_and_ssl.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/node_management/creating_and_joining.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/node_management/creating_nodes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/node_management/groups_and_subgroups.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/node_management/heterogeneous_clusters.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/node_management/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/node_management/maintainance_with_proxies.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/node_management/node_recovery.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/node_management/removing_nodes_and_groups.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/node_management/replication_slots.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/node_management/viewing_topology.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/nodes/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/nodes/logical_standby_nodes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/nodes/overview.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/nodes/subscriber_only/creating-so.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/nodes/subscriber_only/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/nodes/subscriber_only/joining-so.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/nodes/subscriber_only/optimizing-so.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/nodes/subscriber_only/overview.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/nodes/witness_nodes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/overview/architecture-and-performance.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/overview/basic-architecture.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/overview/compared.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/overview/images/always_on_1x3_updated.png (100%) rename product_docs/docs/pgd/{5.8 => 6}/overview/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/parallelapply.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/planning/architectures.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/planning/choosing_server.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/planning/deployments.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/planning/images/always-on-2x3-aa-updated.png (100%) rename product_docs/docs/pgd/{5.8 => 6}/planning/images/always_on_1x3_updated.png (100%) rename product_docs/docs/pgd/{5.8 => 6}/planning/images/always_on_2x3_aa_updated.png (100%) rename product_docs/docs/pgd/{5.8 => 6}/planning/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/planning/limitations.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/planning/other_considerations.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/postgres-configuration.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/quickstart/connecting_applications.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/quickstart/further_explore_conflicts.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/quickstart/further_explore_failover.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/quickstart/further_explore_replication.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/quickstart/images/4sessions.png (100%) rename product_docs/docs/pgd/{5.8 => 6}/quickstart/images/4sessionsinsertconflict.png (100%) rename product_docs/docs/pgd/{5.8 => 6}/quickstart/images/4sessionsupdateconflict.png (100%) rename product_docs/docs/pgd/{5.8 => 6}/quickstart/images/4sshsessions.png (100%) rename product_docs/docs/pgd/{5.8 => 6}/quickstart/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/quickstart/next_steps.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/quickstart/quick_start_aws.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/quickstart/quick_start_cloud.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/quickstart/quick_start_docker.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/quickstart/quick_start_linux.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/autopartition.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/catalogs-internal.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/catalogs-visible.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/clcd.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/commit-scopes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/conflict_functions.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/conflicts.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/functions-internal.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/functions.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/index.json (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/index.mdx.src (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/nodes-management-interfaces.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/nodes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/pgd-settings.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/repsets-ddl-filtering.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/repsets-management.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/repsets-membership.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/routing.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/sequences.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/streamtriggers/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/streamtriggers/interfaces.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/streamtriggers/rowfunctions.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/streamtriggers/rowvariables.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/reference/testingandtuning.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/pgd_5.0.0_rel_notes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/pgd_5.0.1_rel_notes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/pgd_5.1.0_rel_notes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/pgd_5.2.0_rel_notes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/pgd_5.3.0_rel_notes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/pgd_5.4.0_rel_notes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/pgd_5.4.1_rel_notes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/pgd_5.5.0_rel_notes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/pgd_5.5.1_rel_notes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/pgd_5.6.0_rel_notes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/pgd_5.6.1_rel_notes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/pgd_5.7.0_rel_notes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/pgd_5.8.0_rel_notes.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/src/meta.yml (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/src/relnote_5.6.0.yml (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/src/relnote_5.6.1.yml (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/src/relnote_5.7.0.yml (100%) rename product_docs/docs/pgd/{5.8 => 6}/rel_notes/src/relnote_5.8.0.yml (100%) rename product_docs/docs/pgd/{5.8 => 6}/repsets.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/routing/administering.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/routing/configuration.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/routing/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/routing/installing_proxy.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/routing/monitoring.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/routing/proxy.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/routing/raft/01_raft_subgroups_and_tpa.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/routing/raft/02_raft_subgroups_and_pgd_cli.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/routing/raft/03_migrating_to_raft_subgroups.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/routing/raft/04_raft_elections_in_depth.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/routing/raft/images/PGD5sequencediagram.png (100%) rename product_docs/docs/pgd/{5.8 => 6}/routing/raft/images/Tmp6NodeRaftSubgroups.png (100%) rename product_docs/docs/pgd/{5.8 => 6}/routing/raft/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/routing/readonly.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/scaling.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/security/access-control.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/security/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/security/pgd-predefined-roles.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/security/role-management.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/security/roles-and-replication.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/security/roles.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/sequences.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/striggers.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/terminology.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/testingandtuning.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/transaction-streaming.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/tssnapshots.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/twophase.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/upgrades/app_upgrades.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/upgrades/compatibility.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/upgrades/index.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/upgrades/inplace_upgrade.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/upgrades/manual_overview.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/upgrades/tpa_overview.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/upgrades/upgrade_paths.mdx (100%) rename product_docs/docs/pgd/{5.8 => 6}/upgrades/upgrading_major_rolling.mdx (100%) diff --git a/product_docs/docs/pgd/5.8/appusage/behavior.mdx b/product_docs/docs/pgd/6/appusage/behavior.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/appusage/behavior.mdx rename to product_docs/docs/pgd/6/appusage/behavior.mdx diff --git a/product_docs/docs/pgd/5.8/appusage/dml-ddl.mdx b/product_docs/docs/pgd/6/appusage/dml-ddl.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/appusage/dml-ddl.mdx rename to product_docs/docs/pgd/6/appusage/dml-ddl.mdx diff --git a/product_docs/docs/pgd/5.8/appusage/extensions.mdx b/product_docs/docs/pgd/6/appusage/extensions.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/appusage/extensions.mdx rename to product_docs/docs/pgd/6/appusage/extensions.mdx diff --git a/product_docs/docs/pgd/5.8/appusage/feature-compatibility.mdx b/product_docs/docs/pgd/6/appusage/feature-compatibility.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/appusage/feature-compatibility.mdx rename to product_docs/docs/pgd/6/appusage/feature-compatibility.mdx diff --git a/product_docs/docs/pgd/5.8/appusage/index.mdx b/product_docs/docs/pgd/6/appusage/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/appusage/index.mdx rename to product_docs/docs/pgd/6/appusage/index.mdx diff --git a/product_docs/docs/pgd/5.8/appusage/nodes-with-differences.mdx b/product_docs/docs/pgd/6/appusage/nodes-with-differences.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/appusage/nodes-with-differences.mdx rename to product_docs/docs/pgd/6/appusage/nodes-with-differences.mdx diff --git a/product_docs/docs/pgd/5.8/appusage/rules.mdx b/product_docs/docs/pgd/6/appusage/rules.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/appusage/rules.mdx rename to product_docs/docs/pgd/6/appusage/rules.mdx diff --git a/product_docs/docs/pgd/5.8/appusage/table-access-methods.mdx b/product_docs/docs/pgd/6/appusage/table-access-methods.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/appusage/table-access-methods.mdx rename to product_docs/docs/pgd/6/appusage/table-access-methods.mdx diff --git a/product_docs/docs/pgd/5.8/appusage/timing.mdx b/product_docs/docs/pgd/6/appusage/timing.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/appusage/timing.mdx rename to product_docs/docs/pgd/6/appusage/timing.mdx diff --git a/product_docs/docs/pgd/5.8/backup.mdx b/product_docs/docs/pgd/6/backup.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/backup.mdx rename to product_docs/docs/pgd/6/backup.mdx diff --git a/product_docs/docs/pgd/5.8/cdc-failover.mdx b/product_docs/docs/pgd/6/cdc-failover.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cdc-failover.mdx rename to product_docs/docs/pgd/6/cdc-failover.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/assess/index.mdx b/product_docs/docs/pgd/6/cli/command_ref/assess/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/assess/index.mdx rename to product_docs/docs/pgd/6/cli/command_ref/assess/index.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/cluster/index.mdx b/product_docs/docs/pgd/6/cli/command_ref/cluster/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/cluster/index.mdx rename to product_docs/docs/pgd/6/cli/command_ref/cluster/index.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/cluster/show.mdx b/product_docs/docs/pgd/6/cli/command_ref/cluster/show.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/cluster/show.mdx rename to product_docs/docs/pgd/6/cli/command_ref/cluster/show.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/cluster/verify.mdx b/product_docs/docs/pgd/6/cli/command_ref/cluster/verify.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/cluster/verify.mdx rename to product_docs/docs/pgd/6/cli/command_ref/cluster/verify.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/commit-scope/create.mdx b/product_docs/docs/pgd/6/cli/command_ref/commit-scope/create.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/commit-scope/create.mdx rename to product_docs/docs/pgd/6/cli/command_ref/commit-scope/create.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/commit-scope/drop.mdx b/product_docs/docs/pgd/6/cli/command_ref/commit-scope/drop.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/commit-scope/drop.mdx rename to product_docs/docs/pgd/6/cli/command_ref/commit-scope/drop.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/commit-scope/index.mdx b/product_docs/docs/pgd/6/cli/command_ref/commit-scope/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/commit-scope/index.mdx rename to product_docs/docs/pgd/6/cli/command_ref/commit-scope/index.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/commit-scope/show.mdx b/product_docs/docs/pgd/6/cli/command_ref/commit-scope/show.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/commit-scope/show.mdx rename to product_docs/docs/pgd/6/cli/command_ref/commit-scope/show.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/commit-scope/update.mdx b/product_docs/docs/pgd/6/cli/command_ref/commit-scope/update.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/commit-scope/update.mdx rename to product_docs/docs/pgd/6/cli/command_ref/commit-scope/update.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/completion/index.mdx b/product_docs/docs/pgd/6/cli/command_ref/completion/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/completion/index.mdx rename to product_docs/docs/pgd/6/cli/command_ref/completion/index.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/events/index.mdx b/product_docs/docs/pgd/6/cli/command_ref/events/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/events/index.mdx rename to product_docs/docs/pgd/6/cli/command_ref/events/index.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/events/show.mdx b/product_docs/docs/pgd/6/cli/command_ref/events/show.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/events/show.mdx rename to product_docs/docs/pgd/6/cli/command_ref/events/show.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/group/get-option.mdx b/product_docs/docs/pgd/6/cli/command_ref/group/get-option.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/group/get-option.mdx rename to product_docs/docs/pgd/6/cli/command_ref/group/get-option.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/group/index.mdx b/product_docs/docs/pgd/6/cli/command_ref/group/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/group/index.mdx rename to product_docs/docs/pgd/6/cli/command_ref/group/index.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/group/set-leader.mdx b/product_docs/docs/pgd/6/cli/command_ref/group/set-leader.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/group/set-leader.mdx rename to product_docs/docs/pgd/6/cli/command_ref/group/set-leader.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/group/set-option.mdx b/product_docs/docs/pgd/6/cli/command_ref/group/set-option.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/group/set-option.mdx rename to product_docs/docs/pgd/6/cli/command_ref/group/set-option.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/group/show.mdx b/product_docs/docs/pgd/6/cli/command_ref/group/show.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/group/show.mdx rename to product_docs/docs/pgd/6/cli/command_ref/group/show.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/groups/index.mdx b/product_docs/docs/pgd/6/cli/command_ref/groups/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/groups/index.mdx rename to product_docs/docs/pgd/6/cli/command_ref/groups/index.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/groups/list.mdx b/product_docs/docs/pgd/6/cli/command_ref/groups/list.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/groups/list.mdx rename to product_docs/docs/pgd/6/cli/command_ref/groups/list.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/index.mdx b/product_docs/docs/pgd/6/cli/command_ref/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/index.mdx rename to product_docs/docs/pgd/6/cli/command_ref/index.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/node/get-option.mdx b/product_docs/docs/pgd/6/cli/command_ref/node/get-option.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/node/get-option.mdx rename to product_docs/docs/pgd/6/cli/command_ref/node/get-option.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/node/index.mdx b/product_docs/docs/pgd/6/cli/command_ref/node/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/node/index.mdx rename to product_docs/docs/pgd/6/cli/command_ref/node/index.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/node/set-option.mdx b/product_docs/docs/pgd/6/cli/command_ref/node/set-option.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/node/set-option.mdx rename to product_docs/docs/pgd/6/cli/command_ref/node/set-option.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/node/show.mdx b/product_docs/docs/pgd/6/cli/command_ref/node/show.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/node/show.mdx rename to product_docs/docs/pgd/6/cli/command_ref/node/show.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/node/upgrade.mdx b/product_docs/docs/pgd/6/cli/command_ref/node/upgrade.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/node/upgrade.mdx rename to product_docs/docs/pgd/6/cli/command_ref/node/upgrade.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/nodes/index.mdx b/product_docs/docs/pgd/6/cli/command_ref/nodes/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/nodes/index.mdx rename to product_docs/docs/pgd/6/cli/command_ref/nodes/index.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/nodes/list.mdx b/product_docs/docs/pgd/6/cli/command_ref/nodes/list.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/nodes/list.mdx rename to product_docs/docs/pgd/6/cli/command_ref/nodes/list.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/raft/index.mdx b/product_docs/docs/pgd/6/cli/command_ref/raft/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/raft/index.mdx rename to product_docs/docs/pgd/6/cli/command_ref/raft/index.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/raft/show.mdx b/product_docs/docs/pgd/6/cli/command_ref/raft/show.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/raft/show.mdx rename to product_docs/docs/pgd/6/cli/command_ref/raft/show.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/replication/index.mdx b/product_docs/docs/pgd/6/cli/command_ref/replication/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/replication/index.mdx rename to product_docs/docs/pgd/6/cli/command_ref/replication/index.mdx diff --git a/product_docs/docs/pgd/5.8/cli/command_ref/replication/show.mdx b/product_docs/docs/pgd/6/cli/command_ref/replication/show.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/command_ref/replication/show.mdx rename to product_docs/docs/pgd/6/cli/command_ref/replication/show.mdx diff --git a/product_docs/docs/pgd/5.8/cli/configuring_cli.mdx b/product_docs/docs/pgd/6/cli/configuring_cli.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/configuring_cli.mdx rename to product_docs/docs/pgd/6/cli/configuring_cli.mdx diff --git a/product_docs/docs/pgd/5.8/cli/discover_connections.mdx b/product_docs/docs/pgd/6/cli/discover_connections.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/discover_connections.mdx rename to product_docs/docs/pgd/6/cli/discover_connections.mdx diff --git a/product_docs/docs/pgd/5.8/cli/index.mdx b/product_docs/docs/pgd/6/cli/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/index.mdx rename to product_docs/docs/pgd/6/cli/index.mdx diff --git a/product_docs/docs/pgd/5.8/cli/installing/index.mdx b/product_docs/docs/pgd/6/cli/installing/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/installing/index.mdx rename to product_docs/docs/pgd/6/cli/installing/index.mdx diff --git a/product_docs/docs/pgd/5.8/cli/installing/linux.mdx b/product_docs/docs/pgd/6/cli/installing/linux.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/installing/linux.mdx rename to product_docs/docs/pgd/6/cli/installing/linux.mdx diff --git a/product_docs/docs/pgd/5.8/cli/installing/macos.mdx b/product_docs/docs/pgd/6/cli/installing/macos.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/installing/macos.mdx rename to product_docs/docs/pgd/6/cli/installing/macos.mdx diff --git a/product_docs/docs/pgd/5.8/cli/installing/tpa.mdx b/product_docs/docs/pgd/6/cli/installing/tpa.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/installing/tpa.mdx rename to product_docs/docs/pgd/6/cli/installing/tpa.mdx diff --git a/product_docs/docs/pgd/5.8/cli/using_cli.mdx b/product_docs/docs/pgd/6/cli/using_cli.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/cli/using_cli.mdx rename to product_docs/docs/pgd/6/cli/using_cli.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/administering.mdx b/product_docs/docs/pgd/6/commit-scopes/administering.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/administering.mdx rename to product_docs/docs/pgd/6/commit-scopes/administering.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/camo.mdx b/product_docs/docs/pgd/6/commit-scopes/camo.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/camo.mdx rename to product_docs/docs/pgd/6/commit-scopes/camo.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/commit-scope-rules.mdx b/product_docs/docs/pgd/6/commit-scopes/commit-scope-rules.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/commit-scope-rules.mdx rename to product_docs/docs/pgd/6/commit-scopes/commit-scope-rules.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/commit-scopes.mdx b/product_docs/docs/pgd/6/commit-scopes/commit-scopes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/commit-scopes.mdx rename to product_docs/docs/pgd/6/commit-scopes/commit-scopes.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/comparing.mdx b/product_docs/docs/pgd/6/commit-scopes/comparing.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/comparing.mdx rename to product_docs/docs/pgd/6/commit-scopes/comparing.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/degrading.mdx b/product_docs/docs/pgd/6/commit-scopes/degrading.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/degrading.mdx rename to product_docs/docs/pgd/6/commit-scopes/degrading.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/durabilityterminology.mdx b/product_docs/docs/pgd/6/commit-scopes/durabilityterminology.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/durabilityterminology.mdx rename to product_docs/docs/pgd/6/commit-scopes/durabilityterminology.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/group-commit.mdx b/product_docs/docs/pgd/6/commit-scopes/group-commit.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/group-commit.mdx rename to product_docs/docs/pgd/6/commit-scopes/group-commit.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/index.mdx b/product_docs/docs/pgd/6/commit-scopes/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/index.mdx rename to product_docs/docs/pgd/6/commit-scopes/index.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/lag-control.mdx b/product_docs/docs/pgd/6/commit-scopes/lag-control.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/lag-control.mdx rename to product_docs/docs/pgd/6/commit-scopes/lag-control.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/legacy-sync.mdx b/product_docs/docs/pgd/6/commit-scopes/legacy-sync.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/legacy-sync.mdx rename to product_docs/docs/pgd/6/commit-scopes/legacy-sync.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/limitations.mdx b/product_docs/docs/pgd/6/commit-scopes/limitations.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/limitations.mdx rename to product_docs/docs/pgd/6/commit-scopes/limitations.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/origin_groups.mdx b/product_docs/docs/pgd/6/commit-scopes/origin_groups.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/origin_groups.mdx rename to product_docs/docs/pgd/6/commit-scopes/origin_groups.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/overview.mdx b/product_docs/docs/pgd/6/commit-scopes/overview.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/overview.mdx rename to product_docs/docs/pgd/6/commit-scopes/overview.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/synchronous_commit.mdx b/product_docs/docs/pgd/6/commit-scopes/synchronous_commit.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/synchronous_commit.mdx rename to product_docs/docs/pgd/6/commit-scopes/synchronous_commit.mdx diff --git a/product_docs/docs/pgd/5.8/commit-scopes/timing.mdx b/product_docs/docs/pgd/6/commit-scopes/timing.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/commit-scopes/timing.mdx rename to product_docs/docs/pgd/6/commit-scopes/timing.mdx diff --git a/product_docs/docs/pgd/5.8/compatibility.mdx b/product_docs/docs/pgd/6/compatibility.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/compatibility.mdx rename to product_docs/docs/pgd/6/compatibility.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/column-level-conflicts/01_overview_clcd.mdx b/product_docs/docs/pgd/6/conflict-management/column-level-conflicts/01_overview_clcd.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/column-level-conflicts/01_overview_clcd.mdx rename to product_docs/docs/pgd/6/conflict-management/column-level-conflicts/01_overview_clcd.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/column-level-conflicts/02_enabling_disabling.mdx b/product_docs/docs/pgd/6/conflict-management/column-level-conflicts/02_enabling_disabling.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/column-level-conflicts/02_enabling_disabling.mdx rename to product_docs/docs/pgd/6/conflict-management/column-level-conflicts/02_enabling_disabling.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/column-level-conflicts/03_timestamps.mdx b/product_docs/docs/pgd/6/conflict-management/column-level-conflicts/03_timestamps.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/column-level-conflicts/03_timestamps.mdx rename to product_docs/docs/pgd/6/conflict-management/column-level-conflicts/03_timestamps.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/column-level-conflicts/index.mdx b/product_docs/docs/pgd/6/conflict-management/column-level-conflicts/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/column-level-conflicts/index.mdx rename to product_docs/docs/pgd/6/conflict-management/column-level-conflicts/index.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/conflicts/00_conflicts_overview.mdx b/product_docs/docs/pgd/6/conflict-management/conflicts/00_conflicts_overview.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/conflicts/00_conflicts_overview.mdx rename to product_docs/docs/pgd/6/conflict-management/conflicts/00_conflicts_overview.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/conflicts/02_types_of_conflict.mdx b/product_docs/docs/pgd/6/conflict-management/conflicts/02_types_of_conflict.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/conflicts/02_types_of_conflict.mdx rename to product_docs/docs/pgd/6/conflict-management/conflicts/02_types_of_conflict.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/conflicts/03_conflict_detection.mdx b/product_docs/docs/pgd/6/conflict-management/conflicts/03_conflict_detection.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/conflicts/03_conflict_detection.mdx rename to product_docs/docs/pgd/6/conflict-management/conflicts/03_conflict_detection.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/conflicts/04_conflict_resolution.mdx b/product_docs/docs/pgd/6/conflict-management/conflicts/04_conflict_resolution.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/conflicts/04_conflict_resolution.mdx rename to product_docs/docs/pgd/6/conflict-management/conflicts/04_conflict_resolution.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/conflicts/05_conflict_logging.mdx b/product_docs/docs/pgd/6/conflict-management/conflicts/05_conflict_logging.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/conflicts/05_conflict_logging.mdx rename to product_docs/docs/pgd/6/conflict-management/conflicts/05_conflict_logging.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/conflicts/06_live_compare.mdx b/product_docs/docs/pgd/6/conflict-management/conflicts/06_live_compare.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/conflicts/06_live_compare.mdx rename to product_docs/docs/pgd/6/conflict-management/conflicts/06_live_compare.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/conflicts/index.mdx b/product_docs/docs/pgd/6/conflict-management/conflicts/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/conflicts/index.mdx rename to product_docs/docs/pgd/6/conflict-management/conflicts/index.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/crdt/00_crdt_overview.mdx b/product_docs/docs/pgd/6/conflict-management/crdt/00_crdt_overview.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/crdt/00_crdt_overview.mdx rename to product_docs/docs/pgd/6/conflict-management/crdt/00_crdt_overview.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/crdt/01_crdt_usage.mdx b/product_docs/docs/pgd/6/conflict-management/crdt/01_crdt_usage.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/crdt/01_crdt_usage.mdx rename to product_docs/docs/pgd/6/conflict-management/crdt/01_crdt_usage.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/crdt/02_state-op-crdts.mdx b/product_docs/docs/pgd/6/conflict-management/crdt/02_state-op-crdts.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/crdt/02_state-op-crdts.mdx rename to product_docs/docs/pgd/6/conflict-management/crdt/02_state-op-crdts.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/crdt/03_crdt-disk-reqs.mdx b/product_docs/docs/pgd/6/conflict-management/crdt/03_crdt-disk-reqs.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/crdt/03_crdt-disk-reqs.mdx rename to product_docs/docs/pgd/6/conflict-management/crdt/03_crdt-disk-reqs.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/crdt/04_crdt-vs-conflict.mdx b/product_docs/docs/pgd/6/conflict-management/crdt/04_crdt-vs-conflict.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/crdt/04_crdt-vs-conflict.mdx rename to product_docs/docs/pgd/6/conflict-management/crdt/04_crdt-vs-conflict.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/crdt/05_crdt-reset.mdx b/product_docs/docs/pgd/6/conflict-management/crdt/05_crdt-reset.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/crdt/05_crdt-reset.mdx rename to product_docs/docs/pgd/6/conflict-management/crdt/05_crdt-reset.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/crdt/06_crdt-implemented.mdx b/product_docs/docs/pgd/6/conflict-management/crdt/06_crdt-implemented.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/crdt/06_crdt-implemented.mdx rename to product_docs/docs/pgd/6/conflict-management/crdt/06_crdt-implemented.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/crdt/index.mdx b/product_docs/docs/pgd/6/conflict-management/crdt/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/crdt/index.mdx rename to product_docs/docs/pgd/6/conflict-management/crdt/index.mdx diff --git a/product_docs/docs/pgd/5.8/conflict-management/index.mdx b/product_docs/docs/pgd/6/conflict-management/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/conflict-management/index.mdx rename to product_docs/docs/pgd/6/conflict-management/index.mdx diff --git a/product_docs/docs/pgd/5.8/data_migration/edbloader.mdx b/product_docs/docs/pgd/6/data_migration/edbloader.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/data_migration/edbloader.mdx rename to product_docs/docs/pgd/6/data_migration/edbloader.mdx diff --git a/product_docs/docs/pgd/5.8/data_migration/index.mdx b/product_docs/docs/pgd/6/data_migration/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/data_migration/index.mdx rename to product_docs/docs/pgd/6/data_migration/index.mdx diff --git a/product_docs/docs/pgd/5.8/ddl/ddl-command-handling.mdx b/product_docs/docs/pgd/6/ddl/ddl-command-handling.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/ddl/ddl-command-handling.mdx rename to product_docs/docs/pgd/6/ddl/ddl-command-handling.mdx diff --git a/product_docs/docs/pgd/5.8/ddl/ddl-locking.mdx b/product_docs/docs/pgd/6/ddl/ddl-locking.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/ddl/ddl-locking.mdx rename to product_docs/docs/pgd/6/ddl/ddl-locking.mdx diff --git a/product_docs/docs/pgd/5.8/ddl/ddl-managing-with-pgd-replication.mdx b/product_docs/docs/pgd/6/ddl/ddl-managing-with-pgd-replication.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/ddl/ddl-managing-with-pgd-replication.mdx rename to product_docs/docs/pgd/6/ddl/ddl-managing-with-pgd-replication.mdx diff --git a/product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx b/product_docs/docs/pgd/6/ddl/ddl-overview.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/ddl/ddl-overview.mdx rename to product_docs/docs/pgd/6/ddl/ddl-overview.mdx diff --git a/product_docs/docs/pgd/5.8/ddl/ddl-pgd-functions-like-ddl.mdx b/product_docs/docs/pgd/6/ddl/ddl-pgd-functions-like-ddl.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/ddl/ddl-pgd-functions-like-ddl.mdx rename to product_docs/docs/pgd/6/ddl/ddl-pgd-functions-like-ddl.mdx diff --git a/product_docs/docs/pgd/5.8/ddl/ddl-replication-options.mdx b/product_docs/docs/pgd/6/ddl/ddl-replication-options.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/ddl/ddl-replication-options.mdx rename to product_docs/docs/pgd/6/ddl/ddl-replication-options.mdx diff --git a/product_docs/docs/pgd/5.8/ddl/ddl-role-manipulation.mdx b/product_docs/docs/pgd/6/ddl/ddl-role-manipulation.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/ddl/ddl-role-manipulation.mdx rename to product_docs/docs/pgd/6/ddl/ddl-role-manipulation.mdx diff --git a/product_docs/docs/pgd/5.8/ddl/ddl-workarounds.mdx b/product_docs/docs/pgd/6/ddl/ddl-workarounds.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/ddl/ddl-workarounds.mdx rename to product_docs/docs/pgd/6/ddl/ddl-workarounds.mdx diff --git a/product_docs/docs/pgd/5.8/ddl/index.mdx b/product_docs/docs/pgd/6/ddl/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/ddl/index.mdx rename to product_docs/docs/pgd/6/ddl/index.mdx diff --git a/product_docs/docs/pgd/5.8/decoding_worker.mdx b/product_docs/docs/pgd/6/decoding_worker.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/decoding_worker.mdx rename to product_docs/docs/pgd/6/decoding_worker.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-cloudservice/index.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-cloudservice/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-cloudservice/index.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-cloudservice/index.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-kubernetes/index.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-kubernetes/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-kubernetes/index.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-kubernetes/index.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/01-provisioning-hosts.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/01-provisioning-hosts.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/01-provisioning-hosts.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/01-provisioning-hosts.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/02-install-postgres.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/02-install-postgres.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/02-install-postgres.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/02-install-postgres.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/03-configuring-repositories.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/03-configuring-repositories.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/03-configuring-repositories.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/03-configuring-repositories.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/04-installing-software.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/04-installing-software.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/04-installing-software.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/04-installing-software.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/05-creating-cluster.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/05-creating-cluster.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/05-creating-cluster.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/05-creating-cluster.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/06-check-cluster.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/06-check-cluster.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/06-check-cluster.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/06-check-cluster.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/08-using-pgd-cli.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/08-using-pgd-cli.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/08-using-pgd-cli.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/08-using-pgd-cli.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/images/edbrepos2.0.png b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/images/edbrepos2.0.png similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/images/edbrepos2.0.png rename to product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/images/edbrepos2.0.png diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/index.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-manual/deploying/index.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/index.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-manual/index.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-manual/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-manual/index.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-manual/index.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-tpa/deploying/01-configuring.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-tpa/deploying/01-configuring.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-tpa/deploying/01-configuring.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-tpa/deploying/01-configuring.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-tpa/deploying/02-deploying.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-tpa/deploying/02-deploying.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-tpa/deploying/02-deploying.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-tpa/deploying/02-deploying.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-tpa/deploying/index.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-tpa/deploying/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-tpa/deploying/index.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-tpa/deploying/index.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/deploy-tpa/index.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-tpa/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/deploy-tpa/index.mdx rename to product_docs/docs/pgd/6/deploy-config/deploy-tpa/index.mdx diff --git a/product_docs/docs/pgd/5.8/deploy-config/index.mdx b/product_docs/docs/pgd/6/deploy-config/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/deploy-config/index.mdx rename to product_docs/docs/pgd/6/deploy-config/index.mdx diff --git a/product_docs/docs/pgd/5.8/index.mdx b/product_docs/docs/pgd/6/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/index.mdx rename to product_docs/docs/pgd/6/index.mdx diff --git a/product_docs/docs/pgd/5.8/known_issues.mdx b/product_docs/docs/pgd/6/known_issues.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/known_issues.mdx rename to product_docs/docs/pgd/6/known_issues.mdx diff --git a/product_docs/docs/pgd/5.8/monitoring/index.mdx b/product_docs/docs/pgd/6/monitoring/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/monitoring/index.mdx rename to product_docs/docs/pgd/6/monitoring/index.mdx diff --git a/product_docs/docs/pgd/5.8/monitoring/otel.mdx b/product_docs/docs/pgd/6/monitoring/otel.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/monitoring/otel.mdx rename to product_docs/docs/pgd/6/monitoring/otel.mdx diff --git a/product_docs/docs/pgd/5.8/monitoring/sql.mdx b/product_docs/docs/pgd/6/monitoring/sql.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/monitoring/sql.mdx rename to product_docs/docs/pgd/6/monitoring/sql.mdx diff --git a/product_docs/docs/pgd/5.8/node_management/connections_dsns_and_ssl.mdx b/product_docs/docs/pgd/6/node_management/connections_dsns_and_ssl.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/node_management/connections_dsns_and_ssl.mdx rename to product_docs/docs/pgd/6/node_management/connections_dsns_and_ssl.mdx diff --git a/product_docs/docs/pgd/5.8/node_management/creating_and_joining.mdx b/product_docs/docs/pgd/6/node_management/creating_and_joining.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/node_management/creating_and_joining.mdx rename to product_docs/docs/pgd/6/node_management/creating_and_joining.mdx diff --git a/product_docs/docs/pgd/5.8/node_management/creating_nodes.mdx b/product_docs/docs/pgd/6/node_management/creating_nodes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/node_management/creating_nodes.mdx rename to product_docs/docs/pgd/6/node_management/creating_nodes.mdx diff --git a/product_docs/docs/pgd/5.8/node_management/groups_and_subgroups.mdx b/product_docs/docs/pgd/6/node_management/groups_and_subgroups.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/node_management/groups_and_subgroups.mdx rename to product_docs/docs/pgd/6/node_management/groups_and_subgroups.mdx diff --git a/product_docs/docs/pgd/5.8/node_management/heterogeneous_clusters.mdx b/product_docs/docs/pgd/6/node_management/heterogeneous_clusters.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/node_management/heterogeneous_clusters.mdx rename to product_docs/docs/pgd/6/node_management/heterogeneous_clusters.mdx diff --git a/product_docs/docs/pgd/5.8/node_management/index.mdx b/product_docs/docs/pgd/6/node_management/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/node_management/index.mdx rename to product_docs/docs/pgd/6/node_management/index.mdx diff --git a/product_docs/docs/pgd/5.8/node_management/maintainance_with_proxies.mdx b/product_docs/docs/pgd/6/node_management/maintainance_with_proxies.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/node_management/maintainance_with_proxies.mdx rename to product_docs/docs/pgd/6/node_management/maintainance_with_proxies.mdx diff --git a/product_docs/docs/pgd/5.8/node_management/node_recovery.mdx b/product_docs/docs/pgd/6/node_management/node_recovery.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/node_management/node_recovery.mdx rename to product_docs/docs/pgd/6/node_management/node_recovery.mdx diff --git a/product_docs/docs/pgd/5.8/node_management/removing_nodes_and_groups.mdx b/product_docs/docs/pgd/6/node_management/removing_nodes_and_groups.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/node_management/removing_nodes_and_groups.mdx rename to product_docs/docs/pgd/6/node_management/removing_nodes_and_groups.mdx diff --git a/product_docs/docs/pgd/5.8/node_management/replication_slots.mdx b/product_docs/docs/pgd/6/node_management/replication_slots.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/node_management/replication_slots.mdx rename to product_docs/docs/pgd/6/node_management/replication_slots.mdx diff --git a/product_docs/docs/pgd/5.8/node_management/viewing_topology.mdx b/product_docs/docs/pgd/6/node_management/viewing_topology.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/node_management/viewing_topology.mdx rename to product_docs/docs/pgd/6/node_management/viewing_topology.mdx diff --git a/product_docs/docs/pgd/5.8/nodes/index.mdx b/product_docs/docs/pgd/6/nodes/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/nodes/index.mdx rename to product_docs/docs/pgd/6/nodes/index.mdx diff --git a/product_docs/docs/pgd/5.8/nodes/logical_standby_nodes.mdx b/product_docs/docs/pgd/6/nodes/logical_standby_nodes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/nodes/logical_standby_nodes.mdx rename to product_docs/docs/pgd/6/nodes/logical_standby_nodes.mdx diff --git a/product_docs/docs/pgd/5.8/nodes/overview.mdx b/product_docs/docs/pgd/6/nodes/overview.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/nodes/overview.mdx rename to product_docs/docs/pgd/6/nodes/overview.mdx diff --git a/product_docs/docs/pgd/5.8/nodes/subscriber_only/creating-so.mdx b/product_docs/docs/pgd/6/nodes/subscriber_only/creating-so.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/nodes/subscriber_only/creating-so.mdx rename to product_docs/docs/pgd/6/nodes/subscriber_only/creating-so.mdx diff --git a/product_docs/docs/pgd/5.8/nodes/subscriber_only/index.mdx b/product_docs/docs/pgd/6/nodes/subscriber_only/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/nodes/subscriber_only/index.mdx rename to product_docs/docs/pgd/6/nodes/subscriber_only/index.mdx diff --git a/product_docs/docs/pgd/5.8/nodes/subscriber_only/joining-so.mdx b/product_docs/docs/pgd/6/nodes/subscriber_only/joining-so.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/nodes/subscriber_only/joining-so.mdx rename to product_docs/docs/pgd/6/nodes/subscriber_only/joining-so.mdx diff --git a/product_docs/docs/pgd/5.8/nodes/subscriber_only/optimizing-so.mdx b/product_docs/docs/pgd/6/nodes/subscriber_only/optimizing-so.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/nodes/subscriber_only/optimizing-so.mdx rename to product_docs/docs/pgd/6/nodes/subscriber_only/optimizing-so.mdx diff --git a/product_docs/docs/pgd/5.8/nodes/subscriber_only/overview.mdx b/product_docs/docs/pgd/6/nodes/subscriber_only/overview.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/nodes/subscriber_only/overview.mdx rename to product_docs/docs/pgd/6/nodes/subscriber_only/overview.mdx diff --git a/product_docs/docs/pgd/5.8/nodes/witness_nodes.mdx b/product_docs/docs/pgd/6/nodes/witness_nodes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/nodes/witness_nodes.mdx rename to product_docs/docs/pgd/6/nodes/witness_nodes.mdx diff --git a/product_docs/docs/pgd/5.8/overview/architecture-and-performance.mdx b/product_docs/docs/pgd/6/overview/architecture-and-performance.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/overview/architecture-and-performance.mdx rename to product_docs/docs/pgd/6/overview/architecture-and-performance.mdx diff --git a/product_docs/docs/pgd/5.8/overview/basic-architecture.mdx b/product_docs/docs/pgd/6/overview/basic-architecture.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/overview/basic-architecture.mdx rename to product_docs/docs/pgd/6/overview/basic-architecture.mdx diff --git a/product_docs/docs/pgd/5.8/overview/compared.mdx b/product_docs/docs/pgd/6/overview/compared.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/overview/compared.mdx rename to product_docs/docs/pgd/6/overview/compared.mdx diff --git a/product_docs/docs/pgd/5.8/overview/images/always_on_1x3_updated.png b/product_docs/docs/pgd/6/overview/images/always_on_1x3_updated.png similarity index 100% rename from product_docs/docs/pgd/5.8/overview/images/always_on_1x3_updated.png rename to product_docs/docs/pgd/6/overview/images/always_on_1x3_updated.png diff --git a/product_docs/docs/pgd/5.8/overview/index.mdx b/product_docs/docs/pgd/6/overview/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/overview/index.mdx rename to product_docs/docs/pgd/6/overview/index.mdx diff --git a/product_docs/docs/pgd/5.8/parallelapply.mdx b/product_docs/docs/pgd/6/parallelapply.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/parallelapply.mdx rename to product_docs/docs/pgd/6/parallelapply.mdx diff --git a/product_docs/docs/pgd/5.8/planning/architectures.mdx b/product_docs/docs/pgd/6/planning/architectures.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/planning/architectures.mdx rename to product_docs/docs/pgd/6/planning/architectures.mdx diff --git a/product_docs/docs/pgd/5.8/planning/choosing_server.mdx b/product_docs/docs/pgd/6/planning/choosing_server.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/planning/choosing_server.mdx rename to product_docs/docs/pgd/6/planning/choosing_server.mdx diff --git a/product_docs/docs/pgd/5.8/planning/deployments.mdx b/product_docs/docs/pgd/6/planning/deployments.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/planning/deployments.mdx rename to product_docs/docs/pgd/6/planning/deployments.mdx diff --git a/product_docs/docs/pgd/5.8/planning/images/always-on-2x3-aa-updated.png b/product_docs/docs/pgd/6/planning/images/always-on-2x3-aa-updated.png similarity index 100% rename from product_docs/docs/pgd/5.8/planning/images/always-on-2x3-aa-updated.png rename to product_docs/docs/pgd/6/planning/images/always-on-2x3-aa-updated.png diff --git a/product_docs/docs/pgd/5.8/planning/images/always_on_1x3_updated.png b/product_docs/docs/pgd/6/planning/images/always_on_1x3_updated.png similarity index 100% rename from product_docs/docs/pgd/5.8/planning/images/always_on_1x3_updated.png rename to product_docs/docs/pgd/6/planning/images/always_on_1x3_updated.png diff --git a/product_docs/docs/pgd/5.8/planning/images/always_on_2x3_aa_updated.png b/product_docs/docs/pgd/6/planning/images/always_on_2x3_aa_updated.png similarity index 100% rename from product_docs/docs/pgd/5.8/planning/images/always_on_2x3_aa_updated.png rename to product_docs/docs/pgd/6/planning/images/always_on_2x3_aa_updated.png diff --git a/product_docs/docs/pgd/5.8/planning/index.mdx b/product_docs/docs/pgd/6/planning/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/planning/index.mdx rename to product_docs/docs/pgd/6/planning/index.mdx diff --git a/product_docs/docs/pgd/5.8/planning/limitations.mdx b/product_docs/docs/pgd/6/planning/limitations.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/planning/limitations.mdx rename to product_docs/docs/pgd/6/planning/limitations.mdx diff --git a/product_docs/docs/pgd/5.8/planning/other_considerations.mdx b/product_docs/docs/pgd/6/planning/other_considerations.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/planning/other_considerations.mdx rename to product_docs/docs/pgd/6/planning/other_considerations.mdx diff --git a/product_docs/docs/pgd/5.8/postgres-configuration.mdx b/product_docs/docs/pgd/6/postgres-configuration.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/postgres-configuration.mdx rename to product_docs/docs/pgd/6/postgres-configuration.mdx diff --git a/product_docs/docs/pgd/5.8/quickstart/connecting_applications.mdx b/product_docs/docs/pgd/6/quickstart/connecting_applications.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/quickstart/connecting_applications.mdx rename to product_docs/docs/pgd/6/quickstart/connecting_applications.mdx diff --git a/product_docs/docs/pgd/5.8/quickstart/further_explore_conflicts.mdx b/product_docs/docs/pgd/6/quickstart/further_explore_conflicts.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/quickstart/further_explore_conflicts.mdx rename to product_docs/docs/pgd/6/quickstart/further_explore_conflicts.mdx diff --git a/product_docs/docs/pgd/5.8/quickstart/further_explore_failover.mdx b/product_docs/docs/pgd/6/quickstart/further_explore_failover.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/quickstart/further_explore_failover.mdx rename to product_docs/docs/pgd/6/quickstart/further_explore_failover.mdx diff --git a/product_docs/docs/pgd/5.8/quickstart/further_explore_replication.mdx b/product_docs/docs/pgd/6/quickstart/further_explore_replication.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/quickstart/further_explore_replication.mdx rename to product_docs/docs/pgd/6/quickstart/further_explore_replication.mdx diff --git a/product_docs/docs/pgd/5.8/quickstart/images/4sessions.png b/product_docs/docs/pgd/6/quickstart/images/4sessions.png similarity index 100% rename from product_docs/docs/pgd/5.8/quickstart/images/4sessions.png rename to product_docs/docs/pgd/6/quickstart/images/4sessions.png diff --git a/product_docs/docs/pgd/5.8/quickstart/images/4sessionsinsertconflict.png b/product_docs/docs/pgd/6/quickstart/images/4sessionsinsertconflict.png similarity index 100% rename from product_docs/docs/pgd/5.8/quickstart/images/4sessionsinsertconflict.png rename to product_docs/docs/pgd/6/quickstart/images/4sessionsinsertconflict.png diff --git a/product_docs/docs/pgd/5.8/quickstart/images/4sessionsupdateconflict.png b/product_docs/docs/pgd/6/quickstart/images/4sessionsupdateconflict.png similarity index 100% rename from product_docs/docs/pgd/5.8/quickstart/images/4sessionsupdateconflict.png rename to product_docs/docs/pgd/6/quickstart/images/4sessionsupdateconflict.png diff --git a/product_docs/docs/pgd/5.8/quickstart/images/4sshsessions.png b/product_docs/docs/pgd/6/quickstart/images/4sshsessions.png similarity index 100% rename from product_docs/docs/pgd/5.8/quickstart/images/4sshsessions.png rename to product_docs/docs/pgd/6/quickstart/images/4sshsessions.png diff --git a/product_docs/docs/pgd/5.8/quickstart/index.mdx b/product_docs/docs/pgd/6/quickstart/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/quickstart/index.mdx rename to product_docs/docs/pgd/6/quickstart/index.mdx diff --git a/product_docs/docs/pgd/5.8/quickstart/next_steps.mdx b/product_docs/docs/pgd/6/quickstart/next_steps.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/quickstart/next_steps.mdx rename to product_docs/docs/pgd/6/quickstart/next_steps.mdx diff --git a/product_docs/docs/pgd/5.8/quickstart/quick_start_aws.mdx b/product_docs/docs/pgd/6/quickstart/quick_start_aws.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/quickstart/quick_start_aws.mdx rename to product_docs/docs/pgd/6/quickstart/quick_start_aws.mdx diff --git a/product_docs/docs/pgd/5.8/quickstart/quick_start_cloud.mdx b/product_docs/docs/pgd/6/quickstart/quick_start_cloud.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/quickstart/quick_start_cloud.mdx rename to product_docs/docs/pgd/6/quickstart/quick_start_cloud.mdx diff --git a/product_docs/docs/pgd/5.8/quickstart/quick_start_docker.mdx b/product_docs/docs/pgd/6/quickstart/quick_start_docker.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/quickstart/quick_start_docker.mdx rename to product_docs/docs/pgd/6/quickstart/quick_start_docker.mdx diff --git a/product_docs/docs/pgd/5.8/quickstart/quick_start_linux.mdx b/product_docs/docs/pgd/6/quickstart/quick_start_linux.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/quickstart/quick_start_linux.mdx rename to product_docs/docs/pgd/6/quickstart/quick_start_linux.mdx diff --git a/product_docs/docs/pgd/5.8/reference/autopartition.mdx b/product_docs/docs/pgd/6/reference/autopartition.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/autopartition.mdx rename to product_docs/docs/pgd/6/reference/autopartition.mdx diff --git a/product_docs/docs/pgd/5.8/reference/catalogs-internal.mdx b/product_docs/docs/pgd/6/reference/catalogs-internal.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/catalogs-internal.mdx rename to product_docs/docs/pgd/6/reference/catalogs-internal.mdx diff --git a/product_docs/docs/pgd/5.8/reference/catalogs-visible.mdx b/product_docs/docs/pgd/6/reference/catalogs-visible.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/catalogs-visible.mdx rename to product_docs/docs/pgd/6/reference/catalogs-visible.mdx diff --git a/product_docs/docs/pgd/5.8/reference/clcd.mdx b/product_docs/docs/pgd/6/reference/clcd.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/clcd.mdx rename to product_docs/docs/pgd/6/reference/clcd.mdx diff --git a/product_docs/docs/pgd/5.8/reference/commit-scopes.mdx b/product_docs/docs/pgd/6/reference/commit-scopes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/commit-scopes.mdx rename to product_docs/docs/pgd/6/reference/commit-scopes.mdx diff --git a/product_docs/docs/pgd/5.8/reference/conflict_functions.mdx b/product_docs/docs/pgd/6/reference/conflict_functions.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/conflict_functions.mdx rename to product_docs/docs/pgd/6/reference/conflict_functions.mdx diff --git a/product_docs/docs/pgd/5.8/reference/conflicts.mdx b/product_docs/docs/pgd/6/reference/conflicts.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/conflicts.mdx rename to product_docs/docs/pgd/6/reference/conflicts.mdx diff --git a/product_docs/docs/pgd/5.8/reference/functions-internal.mdx b/product_docs/docs/pgd/6/reference/functions-internal.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/functions-internal.mdx rename to product_docs/docs/pgd/6/reference/functions-internal.mdx diff --git a/product_docs/docs/pgd/5.8/reference/functions.mdx b/product_docs/docs/pgd/6/reference/functions.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/functions.mdx rename to product_docs/docs/pgd/6/reference/functions.mdx diff --git a/product_docs/docs/pgd/5.8/reference/index.json b/product_docs/docs/pgd/6/reference/index.json similarity index 100% rename from product_docs/docs/pgd/5.8/reference/index.json rename to product_docs/docs/pgd/6/reference/index.json diff --git a/product_docs/docs/pgd/5.8/reference/index.mdx b/product_docs/docs/pgd/6/reference/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/index.mdx rename to product_docs/docs/pgd/6/reference/index.mdx diff --git a/product_docs/docs/pgd/5.8/reference/index.mdx.src b/product_docs/docs/pgd/6/reference/index.mdx.src similarity index 100% rename from product_docs/docs/pgd/5.8/reference/index.mdx.src rename to product_docs/docs/pgd/6/reference/index.mdx.src diff --git a/product_docs/docs/pgd/5.8/reference/nodes-management-interfaces.mdx b/product_docs/docs/pgd/6/reference/nodes-management-interfaces.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/nodes-management-interfaces.mdx rename to product_docs/docs/pgd/6/reference/nodes-management-interfaces.mdx diff --git a/product_docs/docs/pgd/5.8/reference/nodes.mdx b/product_docs/docs/pgd/6/reference/nodes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/nodes.mdx rename to product_docs/docs/pgd/6/reference/nodes.mdx diff --git a/product_docs/docs/pgd/5.8/reference/pgd-settings.mdx b/product_docs/docs/pgd/6/reference/pgd-settings.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/pgd-settings.mdx rename to product_docs/docs/pgd/6/reference/pgd-settings.mdx diff --git a/product_docs/docs/pgd/5.8/reference/repsets-ddl-filtering.mdx b/product_docs/docs/pgd/6/reference/repsets-ddl-filtering.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/repsets-ddl-filtering.mdx rename to product_docs/docs/pgd/6/reference/repsets-ddl-filtering.mdx diff --git a/product_docs/docs/pgd/5.8/reference/repsets-management.mdx b/product_docs/docs/pgd/6/reference/repsets-management.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/repsets-management.mdx rename to product_docs/docs/pgd/6/reference/repsets-management.mdx diff --git a/product_docs/docs/pgd/5.8/reference/repsets-membership.mdx b/product_docs/docs/pgd/6/reference/repsets-membership.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/repsets-membership.mdx rename to product_docs/docs/pgd/6/reference/repsets-membership.mdx diff --git a/product_docs/docs/pgd/5.8/reference/routing.mdx b/product_docs/docs/pgd/6/reference/routing.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/routing.mdx rename to product_docs/docs/pgd/6/reference/routing.mdx diff --git a/product_docs/docs/pgd/5.8/reference/sequences.mdx b/product_docs/docs/pgd/6/reference/sequences.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/sequences.mdx rename to product_docs/docs/pgd/6/reference/sequences.mdx diff --git a/product_docs/docs/pgd/5.8/reference/streamtriggers/index.mdx b/product_docs/docs/pgd/6/reference/streamtriggers/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/streamtriggers/index.mdx rename to product_docs/docs/pgd/6/reference/streamtriggers/index.mdx diff --git a/product_docs/docs/pgd/5.8/reference/streamtriggers/interfaces.mdx b/product_docs/docs/pgd/6/reference/streamtriggers/interfaces.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/streamtriggers/interfaces.mdx rename to product_docs/docs/pgd/6/reference/streamtriggers/interfaces.mdx diff --git a/product_docs/docs/pgd/5.8/reference/streamtriggers/rowfunctions.mdx b/product_docs/docs/pgd/6/reference/streamtriggers/rowfunctions.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/streamtriggers/rowfunctions.mdx rename to product_docs/docs/pgd/6/reference/streamtriggers/rowfunctions.mdx diff --git a/product_docs/docs/pgd/5.8/reference/streamtriggers/rowvariables.mdx b/product_docs/docs/pgd/6/reference/streamtriggers/rowvariables.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/streamtriggers/rowvariables.mdx rename to product_docs/docs/pgd/6/reference/streamtriggers/rowvariables.mdx diff --git a/product_docs/docs/pgd/5.8/reference/testingandtuning.mdx b/product_docs/docs/pgd/6/reference/testingandtuning.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/reference/testingandtuning.mdx rename to product_docs/docs/pgd/6/reference/testingandtuning.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/index.mdx b/product_docs/docs/pgd/6/rel_notes/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/index.mdx rename to product_docs/docs/pgd/6/rel_notes/index.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/pgd_5.0.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.0.0_rel_notes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/pgd_5.0.0_rel_notes.mdx rename to product_docs/docs/pgd/6/rel_notes/pgd_5.0.0_rel_notes.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/pgd_5.0.1_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.0.1_rel_notes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/pgd_5.0.1_rel_notes.mdx rename to product_docs/docs/pgd/6/rel_notes/pgd_5.0.1_rel_notes.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/pgd_5.1.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.1.0_rel_notes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/pgd_5.1.0_rel_notes.mdx rename to product_docs/docs/pgd/6/rel_notes/pgd_5.1.0_rel_notes.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/pgd_5.2.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.2.0_rel_notes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/pgd_5.2.0_rel_notes.mdx rename to product_docs/docs/pgd/6/rel_notes/pgd_5.2.0_rel_notes.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/pgd_5.3.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.3.0_rel_notes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/pgd_5.3.0_rel_notes.mdx rename to product_docs/docs/pgd/6/rel_notes/pgd_5.3.0_rel_notes.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/pgd_5.4.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.4.0_rel_notes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/pgd_5.4.0_rel_notes.mdx rename to product_docs/docs/pgd/6/rel_notes/pgd_5.4.0_rel_notes.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/pgd_5.4.1_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.4.1_rel_notes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/pgd_5.4.1_rel_notes.mdx rename to product_docs/docs/pgd/6/rel_notes/pgd_5.4.1_rel_notes.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/pgd_5.5.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.5.0_rel_notes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/pgd_5.5.0_rel_notes.mdx rename to product_docs/docs/pgd/6/rel_notes/pgd_5.5.0_rel_notes.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/pgd_5.5.1_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.5.1_rel_notes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/pgd_5.5.1_rel_notes.mdx rename to product_docs/docs/pgd/6/rel_notes/pgd_5.5.1_rel_notes.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/pgd_5.6.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.6.0_rel_notes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/pgd_5.6.0_rel_notes.mdx rename to product_docs/docs/pgd/6/rel_notes/pgd_5.6.0_rel_notes.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/pgd_5.6.1_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.6.1_rel_notes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/pgd_5.6.1_rel_notes.mdx rename to product_docs/docs/pgd/6/rel_notes/pgd_5.6.1_rel_notes.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/pgd_5.7.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.7.0_rel_notes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/pgd_5.7.0_rel_notes.mdx rename to product_docs/docs/pgd/6/rel_notes/pgd_5.7.0_rel_notes.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/pgd_5.8.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.8.0_rel_notes.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/pgd_5.8.0_rel_notes.mdx rename to product_docs/docs/pgd/6/rel_notes/pgd_5.8.0_rel_notes.mdx diff --git a/product_docs/docs/pgd/5.8/rel_notes/src/meta.yml b/product_docs/docs/pgd/6/rel_notes/src/meta.yml similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/src/meta.yml rename to product_docs/docs/pgd/6/rel_notes/src/meta.yml diff --git a/product_docs/docs/pgd/5.8/rel_notes/src/relnote_5.6.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_5.6.0.yml similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/src/relnote_5.6.0.yml rename to product_docs/docs/pgd/6/rel_notes/src/relnote_5.6.0.yml diff --git a/product_docs/docs/pgd/5.8/rel_notes/src/relnote_5.6.1.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_5.6.1.yml similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/src/relnote_5.6.1.yml rename to product_docs/docs/pgd/6/rel_notes/src/relnote_5.6.1.yml diff --git a/product_docs/docs/pgd/5.8/rel_notes/src/relnote_5.7.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_5.7.0.yml similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/src/relnote_5.7.0.yml rename to product_docs/docs/pgd/6/rel_notes/src/relnote_5.7.0.yml diff --git a/product_docs/docs/pgd/5.8/rel_notes/src/relnote_5.8.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_5.8.0.yml similarity index 100% rename from product_docs/docs/pgd/5.8/rel_notes/src/relnote_5.8.0.yml rename to product_docs/docs/pgd/6/rel_notes/src/relnote_5.8.0.yml diff --git a/product_docs/docs/pgd/5.8/repsets.mdx b/product_docs/docs/pgd/6/repsets.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/repsets.mdx rename to product_docs/docs/pgd/6/repsets.mdx diff --git a/product_docs/docs/pgd/5.8/routing/administering.mdx b/product_docs/docs/pgd/6/routing/administering.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/routing/administering.mdx rename to product_docs/docs/pgd/6/routing/administering.mdx diff --git a/product_docs/docs/pgd/5.8/routing/configuration.mdx b/product_docs/docs/pgd/6/routing/configuration.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/routing/configuration.mdx rename to product_docs/docs/pgd/6/routing/configuration.mdx diff --git a/product_docs/docs/pgd/5.8/routing/index.mdx b/product_docs/docs/pgd/6/routing/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/routing/index.mdx rename to product_docs/docs/pgd/6/routing/index.mdx diff --git a/product_docs/docs/pgd/5.8/routing/installing_proxy.mdx b/product_docs/docs/pgd/6/routing/installing_proxy.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/routing/installing_proxy.mdx rename to product_docs/docs/pgd/6/routing/installing_proxy.mdx diff --git a/product_docs/docs/pgd/5.8/routing/monitoring.mdx b/product_docs/docs/pgd/6/routing/monitoring.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/routing/monitoring.mdx rename to product_docs/docs/pgd/6/routing/monitoring.mdx diff --git a/product_docs/docs/pgd/5.8/routing/proxy.mdx b/product_docs/docs/pgd/6/routing/proxy.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/routing/proxy.mdx rename to product_docs/docs/pgd/6/routing/proxy.mdx diff --git a/product_docs/docs/pgd/5.8/routing/raft/01_raft_subgroups_and_tpa.mdx b/product_docs/docs/pgd/6/routing/raft/01_raft_subgroups_and_tpa.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/routing/raft/01_raft_subgroups_and_tpa.mdx rename to product_docs/docs/pgd/6/routing/raft/01_raft_subgroups_and_tpa.mdx diff --git a/product_docs/docs/pgd/5.8/routing/raft/02_raft_subgroups_and_pgd_cli.mdx b/product_docs/docs/pgd/6/routing/raft/02_raft_subgroups_and_pgd_cli.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/routing/raft/02_raft_subgroups_and_pgd_cli.mdx rename to product_docs/docs/pgd/6/routing/raft/02_raft_subgroups_and_pgd_cli.mdx diff --git a/product_docs/docs/pgd/5.8/routing/raft/03_migrating_to_raft_subgroups.mdx b/product_docs/docs/pgd/6/routing/raft/03_migrating_to_raft_subgroups.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/routing/raft/03_migrating_to_raft_subgroups.mdx rename to product_docs/docs/pgd/6/routing/raft/03_migrating_to_raft_subgroups.mdx diff --git a/product_docs/docs/pgd/5.8/routing/raft/04_raft_elections_in_depth.mdx b/product_docs/docs/pgd/6/routing/raft/04_raft_elections_in_depth.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/routing/raft/04_raft_elections_in_depth.mdx rename to product_docs/docs/pgd/6/routing/raft/04_raft_elections_in_depth.mdx diff --git a/product_docs/docs/pgd/5.8/routing/raft/images/PGD5sequencediagram.png b/product_docs/docs/pgd/6/routing/raft/images/PGD5sequencediagram.png similarity index 100% rename from product_docs/docs/pgd/5.8/routing/raft/images/PGD5sequencediagram.png rename to product_docs/docs/pgd/6/routing/raft/images/PGD5sequencediagram.png diff --git a/product_docs/docs/pgd/5.8/routing/raft/images/Tmp6NodeRaftSubgroups.png b/product_docs/docs/pgd/6/routing/raft/images/Tmp6NodeRaftSubgroups.png similarity index 100% rename from product_docs/docs/pgd/5.8/routing/raft/images/Tmp6NodeRaftSubgroups.png rename to product_docs/docs/pgd/6/routing/raft/images/Tmp6NodeRaftSubgroups.png diff --git a/product_docs/docs/pgd/5.8/routing/raft/index.mdx b/product_docs/docs/pgd/6/routing/raft/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/routing/raft/index.mdx rename to product_docs/docs/pgd/6/routing/raft/index.mdx diff --git a/product_docs/docs/pgd/5.8/routing/readonly.mdx b/product_docs/docs/pgd/6/routing/readonly.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/routing/readonly.mdx rename to product_docs/docs/pgd/6/routing/readonly.mdx diff --git a/product_docs/docs/pgd/5.8/scaling.mdx b/product_docs/docs/pgd/6/scaling.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/scaling.mdx rename to product_docs/docs/pgd/6/scaling.mdx diff --git a/product_docs/docs/pgd/5.8/security/access-control.mdx b/product_docs/docs/pgd/6/security/access-control.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/security/access-control.mdx rename to product_docs/docs/pgd/6/security/access-control.mdx diff --git a/product_docs/docs/pgd/5.8/security/index.mdx b/product_docs/docs/pgd/6/security/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/security/index.mdx rename to product_docs/docs/pgd/6/security/index.mdx diff --git a/product_docs/docs/pgd/5.8/security/pgd-predefined-roles.mdx b/product_docs/docs/pgd/6/security/pgd-predefined-roles.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/security/pgd-predefined-roles.mdx rename to product_docs/docs/pgd/6/security/pgd-predefined-roles.mdx diff --git a/product_docs/docs/pgd/5.8/security/role-management.mdx b/product_docs/docs/pgd/6/security/role-management.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/security/role-management.mdx rename to product_docs/docs/pgd/6/security/role-management.mdx diff --git a/product_docs/docs/pgd/5.8/security/roles-and-replication.mdx b/product_docs/docs/pgd/6/security/roles-and-replication.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/security/roles-and-replication.mdx rename to product_docs/docs/pgd/6/security/roles-and-replication.mdx diff --git a/product_docs/docs/pgd/5.8/security/roles.mdx b/product_docs/docs/pgd/6/security/roles.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/security/roles.mdx rename to product_docs/docs/pgd/6/security/roles.mdx diff --git a/product_docs/docs/pgd/5.8/sequences.mdx b/product_docs/docs/pgd/6/sequences.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/sequences.mdx rename to product_docs/docs/pgd/6/sequences.mdx diff --git a/product_docs/docs/pgd/5.8/striggers.mdx b/product_docs/docs/pgd/6/striggers.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/striggers.mdx rename to product_docs/docs/pgd/6/striggers.mdx diff --git a/product_docs/docs/pgd/5.8/terminology.mdx b/product_docs/docs/pgd/6/terminology.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/terminology.mdx rename to product_docs/docs/pgd/6/terminology.mdx diff --git a/product_docs/docs/pgd/5.8/testingandtuning.mdx b/product_docs/docs/pgd/6/testingandtuning.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/testingandtuning.mdx rename to product_docs/docs/pgd/6/testingandtuning.mdx diff --git a/product_docs/docs/pgd/5.8/transaction-streaming.mdx b/product_docs/docs/pgd/6/transaction-streaming.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/transaction-streaming.mdx rename to product_docs/docs/pgd/6/transaction-streaming.mdx diff --git a/product_docs/docs/pgd/5.8/tssnapshots.mdx b/product_docs/docs/pgd/6/tssnapshots.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/tssnapshots.mdx rename to product_docs/docs/pgd/6/tssnapshots.mdx diff --git a/product_docs/docs/pgd/5.8/twophase.mdx b/product_docs/docs/pgd/6/twophase.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/twophase.mdx rename to product_docs/docs/pgd/6/twophase.mdx diff --git a/product_docs/docs/pgd/5.8/upgrades/app_upgrades.mdx b/product_docs/docs/pgd/6/upgrades/app_upgrades.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/upgrades/app_upgrades.mdx rename to product_docs/docs/pgd/6/upgrades/app_upgrades.mdx diff --git a/product_docs/docs/pgd/5.8/upgrades/compatibility.mdx b/product_docs/docs/pgd/6/upgrades/compatibility.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/upgrades/compatibility.mdx rename to product_docs/docs/pgd/6/upgrades/compatibility.mdx diff --git a/product_docs/docs/pgd/5.8/upgrades/index.mdx b/product_docs/docs/pgd/6/upgrades/index.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/upgrades/index.mdx rename to product_docs/docs/pgd/6/upgrades/index.mdx diff --git a/product_docs/docs/pgd/5.8/upgrades/inplace_upgrade.mdx b/product_docs/docs/pgd/6/upgrades/inplace_upgrade.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/upgrades/inplace_upgrade.mdx rename to product_docs/docs/pgd/6/upgrades/inplace_upgrade.mdx diff --git a/product_docs/docs/pgd/5.8/upgrades/manual_overview.mdx b/product_docs/docs/pgd/6/upgrades/manual_overview.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/upgrades/manual_overview.mdx rename to product_docs/docs/pgd/6/upgrades/manual_overview.mdx diff --git a/product_docs/docs/pgd/5.8/upgrades/tpa_overview.mdx b/product_docs/docs/pgd/6/upgrades/tpa_overview.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/upgrades/tpa_overview.mdx rename to product_docs/docs/pgd/6/upgrades/tpa_overview.mdx diff --git a/product_docs/docs/pgd/5.8/upgrades/upgrade_paths.mdx b/product_docs/docs/pgd/6/upgrades/upgrade_paths.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/upgrades/upgrade_paths.mdx rename to product_docs/docs/pgd/6/upgrades/upgrade_paths.mdx diff --git a/product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx b/product_docs/docs/pgd/6/upgrades/upgrading_major_rolling.mdx similarity index 100% rename from product_docs/docs/pgd/5.8/upgrades/upgrading_major_rolling.mdx rename to product_docs/docs/pgd/6/upgrades/upgrading_major_rolling.mdx From 69b0326c955c2c29c34093f522637c2c3d5b7c84 Mon Sep 17 00:00:00 2001 From: Josh Earlenbaugh Date: Mon, 31 Mar 2025 12:13:36 -0400 Subject: [PATCH 002/145] Fixed version to 6.0.0 --- product_docs/docs/pgd/6/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/6/index.mdx b/product_docs/docs/pgd/6/index.mdx index 8507b232839..6d7ff0964ce 100644 --- a/product_docs/docs/pgd/6/index.mdx +++ b/product_docs/docs/pgd/6/index.mdx @@ -54,7 +54,7 @@ categories: - /edb-postgres-ai/platforms-and-tools/high-availability/ pdf: true directoryDefaults: - version: "5.8.0" + version: "6.0.0" --- From fec5fef162a17123286435fe86db07b10220d489 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Tue, 1 Apr 2025 20:10:33 +0000 Subject: [PATCH 003/145] update generated release notes --- product_docs/docs/pgd/6/rel_notes/index.mdx | 2 +- product_docs/docs/pgd/6/rel_notes/pgd_5.6.0_rel_notes.mdx | 2 +- product_docs/docs/pgd/6/rel_notes/pgd_5.6.1_rel_notes.mdx | 2 +- product_docs/docs/pgd/6/rel_notes/pgd_5.7.0_rel_notes.mdx | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/product_docs/docs/pgd/6/rel_notes/index.mdx b/product_docs/docs/pgd/6/rel_notes/index.mdx index 5834d3be413..eca32de02b3 100644 --- a/product_docs/docs/pgd/6/rel_notes/index.mdx +++ b/product_docs/docs/pgd/6/rel_notes/index.mdx @@ -17,7 +17,7 @@ navigation: - pgd_5.1.0_rel_notes - pgd_5.0.1_rel_notes - pgd_5.0.0_rel_notes -originalFilePath: product_docs/docs/pgd/5.8/rel_notes/src/meta.yml +originalFilePath: product_docs/docs/pgd/6.0/rel_notes/src/meta.yml editTarget: originalFilePath --- diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.6.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.6.0_rel_notes.mdx index e3171bef93b..2dfe49c5252 100644 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.6.0_rel_notes.mdx +++ b/product_docs/docs/pgd/6/rel_notes/pgd_5.6.0_rel_notes.mdx @@ -1,7 +1,7 @@ --- title: EDB Postgres Distributed 5.6.0 release notes navTitle: Version 5.6.0 -originalFilePath: product_docs/docs/pgd/5.8/rel_notes/src/relnote_5.6.0.yml +originalFilePath: product_docs/docs/pgd/6.0/rel_notes/src/relnote_5.6.0.yml editTarget: originalFilePath --- diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.6.1_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.6.1_rel_notes.mdx index a758841cb3a..3e2e0e8a153 100644 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.6.1_rel_notes.mdx +++ b/product_docs/docs/pgd/6/rel_notes/pgd_5.6.1_rel_notes.mdx @@ -1,7 +1,7 @@ --- title: EDB Postgres Distributed 5.6.1 release notes navTitle: Version 5.6.1 -originalFilePath: product_docs/docs/pgd/5.8/rel_notes/src/relnote_5.6.1.yml +originalFilePath: product_docs/docs/pgd/6.0/rel_notes/src/relnote_5.6.1.yml editTarget: originalFilePath --- diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.7.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.7.0_rel_notes.mdx index 094d7ebc4e8..f7d3977f589 100644 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.7.0_rel_notes.mdx +++ b/product_docs/docs/pgd/6/rel_notes/pgd_5.7.0_rel_notes.mdx @@ -1,7 +1,7 @@ --- title: EDB Postgres Distributed 5.7.0 release notes navTitle: Version 5.7.0 -originalFilePath: product_docs/docs/pgd/5.8/rel_notes/src/relnote_5.7.0.yml +originalFilePath: product_docs/docs/pgd/6.0/rel_notes/src/relnote_5.7.0.yml editTarget: originalFilePath --- From ed69b9072eedf9d5446191889b72743096763eff Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Mon, 7 Apr 2025 12:48:17 +0100 Subject: [PATCH 004/145] DOCS-1364-Updates-for-alter-column-type Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/ddl/ddl-command-handling.mdx | 50 +++----- .../docs/pgd/6/ddl/ddl-workarounds.mdx | 114 +----------------- 2 files changed, 20 insertions(+), 144 deletions(-) diff --git a/product_docs/docs/pgd/6/ddl/ddl-command-handling.mdx b/product_docs/docs/pgd/6/ddl/ddl-command-handling.mdx index 1e28441c179..ed2aa7fa368 100644 --- a/product_docs/docs/pgd/6/ddl/ddl-command-handling.mdx +++ b/product_docs/docs/pgd/6/ddl/ddl-command-handling.mdx @@ -250,32 +250,12 @@ subcommands aren't supported. Some variants of `ALTER TABLE` currently aren't allowed on a PGD node: -- `ADD COLUMN ... DEFAULT (non-immutable expression)` — This is not allowed because - it currently results in different data on different nodes. See - [Adding a column](ddl-workarounds/#adding-a-column) for a suggested workaround. - You can override this behavior using `bdr.permit_unsafe_commands` if you're sure the command is - safe. - `ALTER COLUMN ... SET STORAGE external` — Is rejected if the column is one of the columns of the replica identity for the table. You can override this behavior using `bdr.permit_unsafe_commands` if you're sure the command is safe. - `RENAME` — Can't rename an Autopartitioned table. - `SET SCHEMA` — Can't set the schema of an Autopartitioned table. -- `ALTER COLUMN ... TYPE` — Changing a column's type isn't supported if the - command causes the whole table to be rewritten, which occurs when the change - isn't binary coercible. - Binary coercible changes might be allowed only one way. For example, - the change from `VARCHAR(128)` to `VARCHAR(256)` is binary coercible and therefore - allowed, whereas the change `VARCHAR(256)` to `VARCHAR(128)` isn't binary coercible - and therefore normally disallowed. Nonreplicated `ALTER COLUMN ... TYPE`, - can be allowed if the column is automatically castable to the new type - (it doesn't contain the `USING` clause). An example follows. - Table rewrites hold an - AccessExclusiveLock for extended periods on larger tables, so such commands - are likely to be infeasible on highly available databases in any case. - See [Changing a column's type](ddl-workarounds/#changing-a-columns-type) for a suggested workaround. - This can be overriden using `bdr.permit_unsafe_commands` if user is sure the command is - safe. - `ALTER TABLE ... ADD FOREIGN KEY` — Isn't supported if current user doesn't have permission to read the referenced table or if the referenced table has RLS restrictions enabled that the current user can't bypass. @@ -289,7 +269,7 @@ ALTER TABLE foo ADD expiry_date timestamptz DEFAULT timestamp '2100-01-01 00:00:00' NOT NULL; ``` -Starting in PGD 3.7.4, you can add certain types of constraints, such as `CHECK` and +You can add certain types of constraints, such as `CHECK` and `FOREIGN KEY` constraints, without taking a DML lock. But this requires a two-step process of first creating a `NOT VALID` constraint and then validating the constraint in a separate transaction with the `ALTER TABLE ... VALIDATE CONSTRAINT` @@ -303,20 +283,20 @@ for more details. The following variants of `ALTER TABLE` take only DDL lock and not a DML lock: -- `ALTER TABLE ... ADD COLUMN ... (immutable) DEFAULT` -- `ALTER TABLE ... ALTER COLUMN ... SET DEFAULT expression` -- `ALTER TABLE ... ALTER COLUMN ... DROP DEFAULT` -- `ALTER TABLE ... ALTER COLUMN ... TYPE` if it doesn't require rewrite -- `ALTER TABLE ... ALTER COLUMN ... SET STATISTICS` -- `ALTER TABLE ... VALIDATE CONSTRAINT` -- `ALTER TABLE ... ATTACH PARTITION` -- `ALTER TABLE ... DETACH PARTITION` -- `ALTER TABLE ... ENABLE TRIGGER` (`ENABLE REPLICA TRIGGER` still takes a DML lock) -- `ALTER TABLE ... CLUSTER ON` -- `ALTER TABLE ... SET WITHOUT CLUSTER` -- `ALTER TABLE ... SET ( storage_parameter = value [, ... ] )` -- `ALTER TABLE ... RESET ( storage_parameter = [, ... ] )` -- `ALTER TABLE ... OWNER TO` +- `ALTER TABLE ... ADD COLUMN ... (immutable) DEFAULT` +- `ALTER TABLE ... ALTER COLUMN ... SET DEFAULT expression` +- `ALTER TABLE ... ALTER COLUMN ... DROP DEFAULT` +- `ALTER TABLE ... ALTER COLUMN ... TYPE` if it doesn't require rewrite +- `ALTER TABLE ... ALTER COLUMN ... SET STATISTICS` +- `ALTER TABLE ... VALIDATE CONSTRAINT` +- `ALTER TABLE ... ATTACH PARTITION` +- `ALTER TABLE ... DETACH PARTITION` +- `ALTER TABLE ... ENABLE TRIGGER` (`ENABLE REPLICA TRIGGER` still takes a DML lock) +- `ALTER TABLE ... CLUSTER ON` +- `ALTER TABLE ... SET WITHOUT CLUSTER` +- `ALTER TABLE ... SET ( storage_parameter = value [, ... ] )` +- `ALTER TABLE ... RESET ( storage_parameter = [, ... ] )` +- `ALTER TABLE ... OWNER TO` All other variants of `ALTER TABLE` take a DML lock on the table being modified. Some variants of `ALTER TABLE` have restrictions, noted below. diff --git a/product_docs/docs/pgd/6/ddl/ddl-workarounds.mdx b/product_docs/docs/pgd/6/ddl/ddl-workarounds.mdx index 921110deb78..d80bd07d9db 100644 --- a/product_docs/docs/pgd/6/ddl/ddl-workarounds.mdx +++ b/product_docs/docs/pgd/6/ddl/ddl-workarounds.mdx @@ -13,15 +13,16 @@ locking. You can add `CHECK` and `FOREIGN KEY` constraints without requiring a DML lock. This involves a two-step process: -- `ALTER TABLE ... ADD CONSTRAINT ... NOT VALID` -- `ALTER TABLE ... VALIDATE CONSTRAINT` +- `ALTER TABLE ... ADD CONSTRAINT ... NOT VALID` +- `ALTER TABLE ... VALIDATE CONSTRAINT` Execute these steps in two different transactions. Both of these steps take DDL lock only on the table and hence can be run even when one or more nodes are down. But to validate a constraint, PGD must ensure that: -- All nodes in the cluster see the `ADD CONSTRAINT` command. -- The node validating the constraint applied replication changes from all other nodes prior to + +- All nodes in the cluster see the `ADD CONSTRAINT` command. +- The node validating the constraint applied replication changes from all other nodes prior to creating the NOT VALID constraint on those nodes. So even though the new mechanism doesn't need all nodes @@ -34,108 +35,3 @@ The new facility requires the cluster to run with Raft protocol version 24 and later. If the Raft protocol isn't yet upgraded, the old mechanism is used, resulting in a DML lock request. -## Adding a column - -To add a column with a volatile default, run these commands in -separate transactions: - -```sql - ALTER TABLE mytable ADD COLUMN newcolumn coltype; -- Note the lack of DEFAULT or NOT NULL - - ALTER TABLE mytable ALTER COLUMN newcolumn DEFAULT volatile-expression; - - BEGIN; - SELECT bdr.global_lock_table('mytable'); - UPDATE mytable SET newcolumn = default-expression; - COMMIT; -``` - -This approach splits schema changes and row changes into separate transactions that -PGD can execute and results in consistent data across all nodes in a -PGD group. - -For best results, batch the update into chunks so that you don't update more than -a few tens or hundreds of thousands of rows at once. You can do this using -a `PROCEDURE` with embedded transactions. - -The last batch of changes must run in a transaction that -takes a global DML lock on the table. Otherwise you can miss rows -that are inserted concurrently into the table on other nodes. - -If required, you can run `ALTER TABLE mytable ALTER COLUMN newcolumn NOT NULL;` after the `UPDATE` has finished. - -## Changing a column's type - -Changing a column's type can cause PostgreSQL to rewrite a table. In some cases, though, you can avoid this rewriting. -For example: - -```sql -CREATE TABLE foo (id BIGINT PRIMARY KEY, description VARCHAR(128)); -ALTER TABLE foo ALTER COLUMN description TYPE VARCHAR(20); -``` - -You can rewrite this statement to avoid a table rewrite by making the -restriction a table constraint rather than a datatype change. The constraint can -then be validated in a subsequent command to avoid long locks, if you want. - -```sql -CREATE TABLE foo (id BIGINT PRIMARY KEY, description VARCHAR(128)); -ALTER TABLE foo - ALTER COLUMN description TYPE varchar, - ADD CONSTRAINT description_length_limit CHECK (length(description) <= 20) NOT VALID; -ALTER TABLE foo VALIDATE CONSTRAINT description_length_limit; -``` - -If the validation fails, then you can `UPDATE` just the failing rows. -You can use this technique for `TEXT` and `VARCHAR` using `length()` or with -`NUMERIC` datatype using `scale()`. - -In the general case for changing column type, first add a column of the desired type: - -``` -ALTER TABLE mytable ADD COLUMN newcolumn newtype; -``` - -Create a trigger defined as `BEFORE INSERT OR UPDATE ON mytable FOR EACH ROW ..`. -Creating ths trigger assigns `NEW.newcolumn` to `NEW.oldcolumn` so that new writes to the -table update the new column. - -`UPDATE` the table in batches to copy the value of `oldcolumn` to -`newcolumn` using a `PROCEDURE` with embedded transactions. Batching the work -helps reduce replication lag if it's a big table. Updating by range of -IDs or whatever method you prefer is fine. Alternatively, you can update the whole table in one pass for -smaller tables. - -`CREATE INDEX ...` any required indexes on the new column. It's safe to -use `CREATE INDEX ... CONCURRENTLY` individually without DDL replication -on each node to reduce lock durations. - -`ALTER` the column to add a `NOT NULL` and `CHECK` constraints, if required. - -1. `BEGIN` a transaction. -1. `DROP` the trigger you added. -1. `ALTER TABLE` to add any `DEFAULT` required on the column. -1. `DROP` the old column. -1. `ALTER TABLE mytable RENAME COLUMN newcolumn TO oldcolumn`. -1. `COMMIT`. - -!!! Note - Because you're dropping a column, you might have to re-create views, procedures, - and so on that depend on the table. Be careful if you `CASCADE` drop the column, - as you must be sure to re-create everything that referred to it. - -#### Changing other types - -The `ALTER TYPE` statement is replicated, but affected tables aren't locked. - -When you use this DDL, ensure that the statement has successfully -executed on all nodes before using the new type. You can achieve this using -the [`bdr.wait_slot_confirm_lsn()`](/pgd/latest/reference/functions#bdrwait_slot_confirm_lsn) function. - -This example ensures that the DDL is written to all nodes before using the new value -in DML statements: - -``` -ALTER TYPE contact_method ADD VALUE 'email'; -SELECT bdr.wait_slot_confirm_lsn(NULL, NULL); -``` From cd8a5c5b99ed8ed5691e16c358318273b31f3216 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Mon, 7 Apr 2025 12:48:37 +0100 Subject: [PATCH 005/145] Release Notes bumped to 6.0.0 Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/rel_notes/index.mdx | 38 +- .../pgd/6/rel_notes/pgd_5.0.0_rel_notes.mdx | 44 --- .../pgd/6/rel_notes/pgd_5.0.1_rel_notes.mdx | 14 - .../pgd/6/rel_notes/pgd_5.1.0_rel_notes.mdx | 64 ---- .../pgd/6/rel_notes/pgd_5.2.0_rel_notes.mdx | 56 --- .../pgd/6/rel_notes/pgd_5.3.0_rel_notes.mdx | 77 ---- .../pgd/6/rel_notes/pgd_5.4.0_rel_notes.mdx | 74 ---- .../pgd/6/rel_notes/pgd_5.4.1_rel_notes.mdx | 22 -- .../pgd/6/rel_notes/pgd_5.5.0_rel_notes.mdx | 82 ---- .../pgd/6/rel_notes/pgd_5.5.1_rel_notes.mdx | 20 - .../pgd/6/rel_notes/pgd_5.6.0_rel_notes.mdx | 166 -------- .../pgd/6/rel_notes/pgd_5.6.1_rel_notes.mdx | 92 ----- .../pgd/6/rel_notes/pgd_5.7.0_rel_notes.mdx | 123 ------ .../pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx | 33 ++ .../docs/pgd/6/rel_notes/src/meta.yml | 59 +-- .../pgd/6/rel_notes/src/relnote_5.6.0.yml | 355 ------------------ .../pgd/6/rel_notes/src/relnote_5.6.1.yml | 157 -------- .../pgd/6/rel_notes/src/relnote_5.7.0.yml | 306 --------------- .../pgd/6/rel_notes/src/relnote_6.0.0.yml | 39 ++ 19 files changed, 83 insertions(+), 1738 deletions(-) delete mode 100644 product_docs/docs/pgd/6/rel_notes/pgd_5.0.0_rel_notes.mdx delete mode 100644 product_docs/docs/pgd/6/rel_notes/pgd_5.0.1_rel_notes.mdx delete mode 100644 product_docs/docs/pgd/6/rel_notes/pgd_5.1.0_rel_notes.mdx delete mode 100644 product_docs/docs/pgd/6/rel_notes/pgd_5.2.0_rel_notes.mdx delete mode 100644 product_docs/docs/pgd/6/rel_notes/pgd_5.3.0_rel_notes.mdx delete mode 100644 product_docs/docs/pgd/6/rel_notes/pgd_5.4.0_rel_notes.mdx delete mode 100644 product_docs/docs/pgd/6/rel_notes/pgd_5.4.1_rel_notes.mdx delete mode 100644 product_docs/docs/pgd/6/rel_notes/pgd_5.5.0_rel_notes.mdx delete mode 100644 product_docs/docs/pgd/6/rel_notes/pgd_5.5.1_rel_notes.mdx delete mode 100644 product_docs/docs/pgd/6/rel_notes/pgd_5.6.0_rel_notes.mdx delete mode 100644 product_docs/docs/pgd/6/rel_notes/pgd_5.6.1_rel_notes.mdx delete mode 100644 product_docs/docs/pgd/6/rel_notes/pgd_5.7.0_rel_notes.mdx create mode 100644 product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx delete mode 100644 product_docs/docs/pgd/6/rel_notes/src/relnote_5.6.0.yml delete mode 100644 product_docs/docs/pgd/6/rel_notes/src/relnote_5.6.1.yml delete mode 100644 product_docs/docs/pgd/6/rel_notes/src/relnote_5.7.0.yml create mode 100644 product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml diff --git a/product_docs/docs/pgd/6/rel_notes/index.mdx b/product_docs/docs/pgd/6/rel_notes/index.mdx index eca32de02b3..7f86d82ad04 100644 --- a/product_docs/docs/pgd/6/rel_notes/index.mdx +++ b/product_docs/docs/pgd/6/rel_notes/index.mdx @@ -1,42 +1,18 @@ --- -title: EDB Postgres Distributed 5 release notes +title: EDB Postgres Distributed 6 release notes navTitle: Release notes -description: Release notes for EDB Postgres Distributed 5 and later +description: Release notes for EDB Postgres Distributed 6 and later indexCards: none navigation: - - pgd_5.8.0_rel_notes - - pgd_5.7.0_rel_notes - - pgd_5.6.1_rel_notes - - pgd_5.6.0_rel_notes - - pgd_5.5.1_rel_notes - - pgd_5.5.0_rel_notes - - pgd_5.4.1_rel_notes - - pgd_5.4.0_rel_notes - - pgd_5.3.0_rel_notes - - pgd_5.2.0_rel_notes - - pgd_5.1.0_rel_notes - - pgd_5.0.1_rel_notes - - pgd_5.0.0_rel_notes + - pgd_6.0.0_rel_notes originalFilePath: product_docs/docs/pgd/6.0/rel_notes/src/meta.yml editTarget: originalFilePath --- -The EDB Postgres Distributed documentation describes the latest version of EDB Postgres Distributed 5, including minor releases and patches. The release notes provide information on what was new in each release. For new functionality introduced in a minor or patch release, the content also indicates the release that introduced the feature. +The EDB Postgres Distributed documentation describes the latest version of EDB Postgres Distributed 6, including minor releases and patches. The release notes provide information on what was new in each release. For new functionality introduced in a minor or patch release, the content also indicates the release that introduced the feature. -| Release Date | EDB Postgres Distributed | BDR extension | PGD CLI | PGD Proxy | -|---|---|---|---|---| -| 22 May 2025 | [5.8.0](./pgd_5.8.0_rel_notes) | 5.8.0 | 5.8.0 | 5.8.0 | -| 25 Feb 2025 | [5.7.0](./pgd_5.7.0_rel_notes) | 5.7.0 | 5.7.0 | 5.7.0 | -| 25 Nov 2024 | [5.6.1](./pgd_5.6.1_rel_notes) | 5.6.1 | 5.6.1 | 5.6.1 | -| 15 Oct 2024 | [5.6.0](./pgd_5.6.0_rel_notes) | 5.6.0 | 5.6.0 | 5.6.0 | -| 31 May 2024 | [5.5.1](./pgd_5.5.1_rel_notes) | 5.5.1 | 5.5.0 | 5.5.0 | -| 16 May 2024 | [5.5.0](./pgd_5.5.0_rel_notes) | 5.5.0 | 5.5.0 | 5.5.0 | -| 03 April 2024 | [5.4.1](./pgd_5.4.1_rel_notes) | 5.4.1 | 5.4.0 | 5.4.0 | -| 05 March 2024 | [5.4.0](./pgd_5.4.0_rel_notes) | 5.4.0 | 5.4.0 | 5.4.0 | -| 14 November 2023 | [5.3.0](./pgd_5.3.0_rel_notes) | 5.3.0 | 5.3.0 | 5.3.0 | -| 04 August 2023 | [5.2.0](./pgd_5.2.0_rel_notes) | 5.2.0 | 5.2.0 | 5.2.0 | -| 16 May 2023 | [5.1.0](./pgd_5.1.0_rel_notes) | 5.1.0 | 5.1.0 | 5.1.0 | -| 21 Mar 2023 | [5.0.1](./pgd_5.0.1_rel_notes) | 5.0.0 | 5.0.1 | 5.0.1 | -| 21 Feb 2023 | [5.0.0](./pgd_5.0.0_rel_notes) | 5.0.0 | 5.0.0 | 5.0.0 | +| Release Date | EDB Postgres Distributed | BDR extension | PGD CLI | +|---|---|---|---| +| 01 Jun 2025 | [6.0.0](./pgd_6.0.0_rel_notes) | 6.0.0 | 6.0.0 | diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.0.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.0.0_rel_notes.mdx deleted file mode 100644 index 8de3704586c..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.0.0_rel_notes.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "EDB Postgres Distributed 5.0.0 release notes" -navTitle: "Version 5.0.0" ---- - -Released: 21 Feb 2023 - -EDB Postgres Distributed version 5.0.0 is a is a new major version of EDB Postgres Distributed. -This version brings major new features and compatibility changes. - -The highlights of this release include: - - * Flexible deployment architectures - * Enhanced routing capabilities - * Unified replication durability configuration - * Support for EDB Advanced Storage Pack - * Support for TDE with EDB Postgres Advanced 15 and EDB Postgres Extended 15 - * Integration with OpenTelemetry - * Improved transaction tracking performance (Group Commit, CAMO) - * Postgres 12 to 15 compatiblity - - -| Component | Version | Type | Description | -|-----------|---------|---------|-------------| -| PGD | 5.0.0 | Feature | Flexible Deployment Architectures
Redefined Always-ON to support wider variety of deployments.
| -| BDR | 5.0.0 | Feature | Enhanced routing capabilities
BDR cluster elects a write leader for every group (and associated location) using per group Raft when routing is enabled for the group. It takes care of write leader failover and provides SQL commands to change a write leader.
| -| BDR | 5.0.0 | Feature | Support for EDB Advanced Storage Pack
[EDB Advanced Storage Pack](/pg_extensions/advanced_storage_pack/) provides advanced storage options for PostgreSQL databases in the form of table access method (TAM) extensions. These storage options can enhance the performance and reliability of databases without requiring application changes.
| -| BDR | 5.0.0 | Feature | Unified replication durability configuration
The durability options such as Group Commit, CAMO, Eager Replication or Lag Control are now all configured through commit scope configuration.
| -| BDR | 5.0.0 | Feature | EDB Postgres Advanced and EDB Postgres Extended TDE support
EDB Postgres Distributed 5 fully supports the [Transparent Data Encryption](/tde/latest) feature in EDB Postgres Advanced and EDB Postgres Extended.
| -| BDR | 5.0.0 | Feature | Integration with OpenTelemetry
BDR extension can now send monitoring metrics as well as traces to the OpenTelemetry collector for better integration with existing monitoring solutions.
| -| BDR | 5.0.0 | Feature | Postgres 15 compatibility
EDB Postgres Distributed 5 is compatible with Postgres 12 to 15.
| -| BDR | 5.0.0 | Feature | Improved Cluster Event Management
The `bdr.worker_errors` and `bdr.state_journal_details` view were replaced by unified `bdr.event_summary` which also include changes in Raft role for the local node. In the future additional events may be added to it.
| -| BDR | 5.0.0 | Change | Improved transaction tracking performance
Transaction tracking now uses shared memory instead of `bdr.internal_node_pre_commit` catalog which considerably improves performance as it does not incur additional I/O.
| -| BDR | 5.0.0 | Feature | Support non-default replication sets with Decoding Worker
Allows Decoding Worker feature to be used in clusters using non-default replication sets like asymmetric replication setup.
| -| BDR | 5.0.0 | Feature | Add support for HASH partitioning in Autopartition
Extend autopartition/autoscale to support HASH partitioning. Many of things that are required for RANGE partitioning are not needed for HASH partitioning. For example, we expect to create all HASH partitions in one go (at least for the current work; later we may change this). We don't expect HASH partitions to be moved to a different tablespace or dropped. So data retention policies don't apply for HASH partitioning.
| -| BDR | 5.0.0 | Feature | Add a new benchmarking utility `pgd_bench`
The utility supports benchmarking CAMO transactions and in future releases will be used for benchmarking PGD specific workloads.
| -| BDR | 5.0.0 | Change | Nodes now have a node kind
This better differentiates different kinds of nodes such as data, witness, subscriber-only and standby.
-| BDR | 5.0.0 | Change | Separate Task Management from Autopartition
In this release, the autopartition work queue mechanism has been moved to a separate module called Task Manager (taskmgr). The task manager is responsible for creating new tasks and executing the ones created by the local node or the task manager leader node. The autopartition worker is thus renamed as taskmgr worker process in this release.

In the older PGD releases, the Raft leader was responsible for creating new work items. But that creates a problem because a witness node can become a Raft leader while it does not have the full view of the cluster objects. In this release, we have introduced a concept of Task Manager Leader node. The node is selected automatically by PGD, but for upgraded clusters, its important to set the `node_kind` property for all nodes in the cluster. The user is expected to do this manually after upgrading to the latest PGD version by calling bdr.alter_node_kind() SQL function for each node.
| -| BDR | 5.0.0 | Deprecation | `bdr.assess_lock_statement` and `bdr.assess_update_replica_identity` are deprecated. | -| Proxy | 5.0.0 | Feature | PGD built-in proxy
A TCP layer 4, pass through proxy for PGD cluster using routing capabilities of BDR.

| -| CLI | 5.0.0 | Feature | PGD cluster verification
CLI supports two new commands `verify-settings` and `verify-cluster`. `verify-settings` verifies the PostgreSQL configuration of each node in a PGD cluster against the recommendations. `verify-cluster` verifies the PGD cluster architectures against the flexible architecture deployment recommendations.

-| CLI | 5.0.0 | Feature | Proxy management and configuration
`pgd` supports `create-proxy`, `delete proxy`, `set-group-options`, `set-node-options`, `set-proxy-options`, `show-proxies`, `show-groups` and `switchover` to configure and manage Proxy per group.
| -| CLI | 5.0.0 | Change | Remove `show-camo` command and remove CAMO check from `check-health` command. Support for `commit scopes` in CLI will be added in a future release.| -| CLI | 5.0.0 | Change | Modify output of `show-nodes` and `show-raft` commands to accomodate routing capabilities. | diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.0.1_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.0.1_rel_notes.mdx deleted file mode 100644 index 4c2be1d67c7..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.0.1_rel_notes.mdx +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: "EDB Postgres Distributed 5.0.1 release notes" -navTitle: "Version 5.0.1" ---- - -Released: 21 Mar 2023 - -EDB Postgres Distributed version 5.0.1 is a patch version of EDB Postgres Distributed. -This version addresses security vulnerabilities in dependencies for PGD-Proxy and PGD-CLI. - -| Component | Version | Type | Description | -|-----------|---------|---------|-------------| -| CLI | 5.0.1 | Change | Upgrade 3rd party dependencies to fix Github dependabot alerts | -| Proxy | 5.0.1 | Change | Upgrade 3rd party dependencies to fix Github dependabot alerts | diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.1.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.1.0_rel_notes.mdx deleted file mode 100644 index ebadaa671bb..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.1.0_rel_notes.mdx +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: "EDB Postgres Distributed 5.1.0 release notes" -navTitle: "Version 5.1.0" ---- - -Released: 16 May 2023 - -EDB Postgres Distributed version 5.1.0 is a minor version of EDB Postgres Distributed. -This version addresses security vulnerabilities in dependencies for PGD Proxy and PGD CLI. - -## Highlights of EDB Postgres Distributed 5.1 - -* **Synchronous Commit** is now available in PGD’s unified COMMIT SCOPE syntax. Modeled on Postgres’s legacy synchronous commit option, PGD Synchronous Commit allows DBAs to take advantage of the finer-grained commit and sync management. This addition complements the existing Group Commit, CAMO, and Lag Control commit scope options. - -* Fixes to **priority-based proxy routing** now enable better handling of failover. You can now configure the grace period for proxies through PGD CLI, allowing you to tune proxy response to losing the Raft leader. To accompany that, Raft events are visible in the PGD CLI’s `show-events` command, showing the event, source, and subtype. - -* **`bdr.drop_node_group()`** adds support for removing empty node groups using the PGD SQL interface. - -!!! Important Recommended upgrade - We recommend that users of PGD 5.0 upgrade to PGD 5.1. - -!!! Note PostgreSQL version compatibility -This version is required for EDB Postgres Advanced Server versions 12.15, 13.11, 14.8, and later. -!!! - - -| Component | Version | Type | Description | -|-----------|---------|-----------------|--------------| -| BDR | 5.1.0 | Feature | Added pid to the log message emitted upon writer process death. | -| BDR | 5.1.0 | Feature | Added group name in the bdr.event_summary view. | -| BDR | 5.1.0 | Feature | Added SLES support. SLES 15sp4 is now supported. | -| BDR | 5.1.0 | Feature | Added subscription status column to the group subscription summary view.
This feature allows you to distinguish whether NULL values are due to a node being down or a subscription being disabled.| -| BDR | 5.1.0 | Feature | Added NOT group filter to Group Commit.
This feature allows you to invert the meaning of a group filter to include all nodes except the ones in specified groups.| -| BDR | 5.1.0 | Feature | Added `bdr.drop_node_group`.
You can now drop empty node groups.| -| BDR | 5.1.0 | Feature | Added SYNCHRONOUS_COMMIT to commit scopes.
This feature allows dynamic synchronous_commit-like behavior for replication.| -| BDR | 5.1.0 | Feature | Added event_node_name column to `bdr.event_summary`. | -| BDR | 5.1.0 | Feature | Added write leader election to event history.
Added information about the node that's elected as a write leader for each group in the event_history catalog. Also improved the reporting of raft instance ids in the event_detail of event_history.| -| BDR | 5.1.0 | Feature | Added ability to allow exporting and importing of other Raft instance snapshots.
This feature allows exporting and importing snapshots for other instances and not only top Raft instances.| -| BDR | 5.1.0 | Bug fix | Fixed memory leak in consensus process. (RT91830) | -| BDR | 5.1.0 | Bug fix | Fixed issue where a node can be inconsistent with the group after rejoining.
If a node was part of a subgroup, parted, and then rejoined to the group, it could be inconsistent with the group. The changes from some nodes of the group were replayed from a wrong starting point, resulting in potential data loss. | -| BDR | 5.1.0 | Bug fix | Fixed join and replication when SDW and standby_slot_names are set. (RT89702, RT89536)| -| BDR | 5.1.0 | Bug fix | Fixed spurious warnings when processing sequence options. (RT90668) | -| BDR | 5.1.0 | Bug fix | Fixed upgrades for nodes with CRDTs. | -| BDR | 5.1.0 | Bug fix | Adjusted lag tracking parameters for LCRs from pg_stat_replication. | -| BDR | 5.1.0 | Bug fix | Adjusted node routing options defaults based on node kind.
This change is related only to the display of the information and not the behavior. For example, witness nodes aren't marked as candidates for receiving writes. | -| BDR | 5.1.0 | Bug fix | All sequences are now converted to "distributed" during create node. | -| BDR | 5.1.0 | Bug fix | Fixed streaming transactions with `standby_slot_names`.
This might have led to a subscriber-only node getting ahead of a data node. | -| BDR | 5.1.0 | Bug fix | Made priority work properly for routing selection.
Previously, node priority was working only if there wasn't a previous leader, which is never the case on failover.| -| BDR | 5.1.0 | Bug fix | Fixed the recording of its join as complete for the first node. | -| BDR | 5.1.0 | Bug fix | Disabled tracing by default.
Tracing was enabled only for initial debugging and was meant to be disabled before 5.0 release. | -| BDR | 5.1.0 | Bug fix | Added support for reload configuration for the pglogical receiver.
When the server receives a reload signal, the pglogical receiver reloads and applies the configuration changes. | -| BDR | 5.1.0 | Bug fix | Improved missing instance error message in `bdr.monitor_group_raft()`. | -| BDR | 5.1.0 | Bug fix | Implemented consistent use of tcp keepalives across all BDR connections.
This change added the following GUCs:
`bdr.global_connection_timeout`
`bdr.global_keepalives`
`bdr.global_keepalives_idle`
`bdr.global_keepalives_interval`
`bdr.global_keepalives_count`
`bdr.global_tcp_user_timeout`
The defaults are set to fairly conservative values and are subject to adjustments in the future patches. | -| BDR | 5.1.0 | Bug fix | Closed Raft connections on no activity after a timeout.
This uses wal_sender_timeout/wal_receiver_timeout underneath. | -| BDR | 5.1.0 | Bug fix | Made backends that receive Raft messages easily identifiable.
Added information in the log message related to Raft backends. | -| BDR | 5.1.0 | Bug fix | Fixed issue whereby Parallel Apply might slow down under heavy load. -| BDR | 5.1.0 | Enhancement | Restarting sync workers is now avoided.
This fix is to prevent the node join from failing when config changes are made that signal the restart of subscription workers. | -| PGD Proxy | 5.1.0 | Enhancement | `application_name` is now set to proxy name if it wasn't set by the user in the connection string for internal db connections. | -| PGD Proxy | 5.1.0 | Enhancement | Implemented the new `consensus_grace_period` proxy option, which is the duration for which a proxy continues to route to the current write leader (if it's available) upon loss of a Raft leader. If the new Raft leader isn't elected during this period, the proxy stops routing. If set to `0s`, the proxy stops routing immediately. | -| PGD Proxy | 5.1.0 | Bug fix | Changed from blocking when write leader is unavailable to closing the new client connections. | -| CLI | 5.1.0 | Enhancement | Enhanced the `show-events` command to show Raft events, event source and subtype. | -| CLI | 5.1.0 | Enhancement | Improved clockskew estimation in `show-clockskew` and `check-health` commands. | -| CLI | 5.1.0 | Feature | Added support to view and set `consensus_grace_period` proxy option. | -| Utilities | 1.1.0 | Bug fix | Implemented handling of uninitialized physical replication slots issue. | \ No newline at end of file diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.2.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.2.0_rel_notes.mdx deleted file mode 100644 index e45207586d6..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.2.0_rel_notes.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "EDB Postgres Distributed 5.2.0 release notes" -navTitle: "Version 5.2.0" ---- - -Released: 04 Aug 2023 - -EDB Postgres Distributed version 5.2.0 is a minor version of EDB Postgres Distributed. - -## Highlights of EDB Postgres Distributed 5.2.0 - -* Parallel Apply is now available for PGD’s Commit at Most Once (CAMO) synchronous commit scope and improving replication performance. -* Parallel Apply for native Postgres asynchronous and synchronous replication has been improved for workloads where the same key is being modified concurrently by multiple transactions to maintain commit sequence and avoid deadlocks. -* PGD Proxy has added HTTP(S) APIs to allow the health of the proxy to be monitored directly for readiness and liveness. See [Proxy health check](../routing/monitoring/#proxy-health-check). - -!!! Important Recommended upgrade - We recommend that users of PGD 5.1 upgrade to PGD 5.2. - -!!! Note PostgreSQL version compatibility -This version is required for EDB Postgres Advanced Server versions 12.15, 13.11, 14.8, and later. -!!! - - -| Component | Version | Type | Description | -|-----------|---------|-----------------|--------------| -| BDR | 5.2.0 | Feature | Added Parallel Apply for synchronous commit scopes with CAMO. | -| BDR | 5.2.0 | Feature | Allow multiple SYNCHRONOUS_COMMIT clauses in a commit scope rule. | -| BDR | 5.2.0 | Enhancement | BDR extension now allows transaction streaming with SYNCHRONOUS_COMMIT and LAG CONTROL commit scopes. | -| BDR | 5.2.0 | Enhancement | Improved handling of concurrent workloads with Parallel Apply. | -| BDR | 5.2.0 | Enhancement | Modified `bdr.stat_subscription` for new columns. | -| BDR | 5.2.0 | Bug fix | Fixed an issue by allowing a logical join of node if there are foreign key constraints violations. (RT91745) | -| BDR | 5.2.0 | Bug fix | Changed `group_raft_details` view to avoid deadlock possibility. | -| BDR | 5.2.0 | Bug fix | Fixed an issue by adding ability to log the extension upgrade. | -| BDR | 5.2.0 | Bug fix | Added check for conflicting node names. | -| BDR | 5.2.0 | Bug fix | Fixed a crash during Raft manual snapshot restore. | -| BDR | 5.2.0 | Bug fix | Fixed an issue whereby BDR extension was attempting to establish consensus connections to parting or parted nodes. | -| BDR | 5.2.0 | Bug fix | Fixed `tcp_user_timeout` GUC to use the correct unit. | -| BDR | 5.2.0 | Bug fix | Fixed the consensus snapshot compatibility with PGD 3.7. (RT93022) | -| BDR | 5.2.0 | Bug fix | Fixed an issue whereby a crash occurred when BDR extension is used with pgaudit. | -| BDR | 5.2.0 | Bug fix | Fixed an issue by skipping parting synchronization to witness node. | -| BDR | 5.2.0 | Bug fix | Fixed an issue by now generating correct keepalive parameters in connection strings. | -| BDR | 5.2.0 | Bug fix | Enabled various scenarios of switching nodes between groups and their subgroups, for example, transition node from a group to any of the nested subgroups.| -| BDR | 5.2.0 | Bug fix | Reduced the amount of WAL produced by consensus on idle server. | -| BDR | 5.2.0 | Bug fix | Fixed deadlock on autopartition catalogs when a concurrent `DROP EXTENSION` is executing. | -| BDR | 5.2.0 | Bug fix | Fixed sporadic failure when dropping extension after node restart | -| BDR | 5.2.0 | Bug fix | Added a workaround for crash due to pgaudit bug. | -| BDR | 5.2.0 | Bug fix | Fixed deadlock between consensus and global monitoring queries. | -| BDR | 5.2.0 | Bug fix | Fixed query cancellation propagation across `bdr.run_on_all_nodes`. | -| BDR | 5.2.0 | Bug fix | Fixed an issue by disallowing invoking `bdr.run_on_nodes()`, `bdr.run_on_group()` and `bdr.run_on_all_nodes()` on parted nodes. | -| CLI | 5.2.0 | Enhancement | Added new GUCs verification in `verify-settings` command. | -| CLI | 5.2.0 | Bug fix | Fixed an issue by truncating the long value of GUC in tabular output of `verify-settings`. | -| CLI | 5.2.0 | Bug fix | Fixed `connect_timeout` issue when `sslmode=allow` or `sslmode=prefer` by upgrading database driver library version. | -| Proxy | 5.2.0 | Feature | Added HTTP(S) APIs for Proxy health check. | -| Proxy | 5.2.0 | Enhancement | Improved route change events handling mechanism. | -| Proxy | 5.2.0 | Enhancement | Added retry mechanism on consensus query error. | -| Proxy | 5.2.0 | Bug fix | Fixed `connect_timeout` issue when `sslmode=allow` or `sslmode=prefer` by upgrading database driver library version. | diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.3.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.3.0_rel_notes.mdx deleted file mode 100644 index 012322c6942..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.3.0_rel_notes.mdx +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: "EDB Postgres Distributed 5.3.0 release notes" -navTitle: "Version 5.3.0" ---- - -Released: 14 Nov 2023 - -EDB Postgres Distributed version 5.3.0 is a minor version of EDB Postgres Distributed. - -!!! Important Recommended upgrade -We recommend that all users of PGD 5 upgrade to PGD 5.3. See [PGD/TPA upgrades](../upgrades/tpa_overview) for details. -!!! - -## Highlights of EDB Postgres Distributed 5.3.0 - -* Support for PostgreSQL 16 server, EDB Postgres Extended Server 16, and EDB Postgres Advanced Server 16 - -## Compatibility - -!!! Note EDB Server version compatibility -This version requires the recently released Postgres versions 14.10, 15.4, -or 16.1 (or later) of EDB Postgres Advanced Server or EDB Postgres Extended -Server. No such restrictions exist for PostgreSQL Server. - -Package managers on Debian, RHEL, and SLES pull in the required EDB Postgres Advanced Server or EDB Postgres Extended -upgrades with an upgrade of EDB Postgres Distributed. -!!! - -## Features - -| Component | Version | Description | Addresses | -|-----------|---------|-------------|-----------| -| PGD | 5.3.0 | Added support for PostgreSQL 16 server, EDB Postgres Extended Server 16, and EDB Postgres Advanced Server 16. | | - -## Enhancements - -| Component | Version |Description | Addresses | -|-----------|---------|-------------|-----------| -| Proxy | 5.3.0 | Added the default service unit file to package | | -| BDR | 5.3.0 | Dependencies on EDB Postgres Advanced Server or EDB Postgres Extended are now reflected in packages. | | - -## Bug fixes - -| Component | Version |Description | Addresses | -|-----------|---------|-------------|-----------| -| BDR | 5.3.0 | Ensure that the WalSender process doesn't request locks on the partitions, thus avoiding a deadlock with user process waiting on sync commit. | RT97952 | -| BDR | 5.3.0 | Consider only CAMO transactions to be asynchronous when the CAMO setup was degraded to local mode. This solves the split-brain problem when deciding fate of transactions that happened during failover. | RT78928 | -| BDR | 5.3.0 | Handle partitions with different attribute numbers when batch inserting. | RT99115 | -| BDR | 5.3.0 | Fixed unsafe CAMO decisions in remote_write mode. || -| BDR | 5.3.0 | Taskmgr process now respects SIGINT. || -| BDR | 5.3.0 | Speeded up manager process startup by limiting the amount of WAL read for loading commit decisions. || -| BDR | 5.3.0 | Physical joins now clean up stale records in `bdr.taskmgr_local_work_queue`. || -| BDR | 5.3.0 | Fixed a bug in copying `bdr.autopartition_rules` during logical join. || -| BDR | 5.3.0 | Override `bdr.ddl_replication=off` in taskmgr worker. || -| BDR | 5.3.0 | Avoid a potential deadlock between `bdr.autopartition_wait_for_partitions()` and taskmgr. || -| BDR | 5.3.0 | Fixed writer missing updates in streaming mode with TDE enabled. || -| BDR | 5.3.0 | Block new EDB Postgres Advanced Server automatic partitioning on PGD cluster. || -| BDR | 5.3.0 | Allow existing automatically partitioned tables when cluster is created or upgraded. || -| BDR | 5.3.0 | Block PGD autopartition on EDB Postgras Advanced Server INTERVAL partitioned table. || -| BDR | 5.3.0 | Ensure that replication doesn't break when `bdr.autopartition()` is invoked on a mixed version cluster running with 3.7.23 and 4.3.3/5.3 || -| BDR | 5.3.0 | Fixed default selective replication behavior for data groups. The data groups are supposed to publish only replication sets of the group or any parent groups by default, which mirrors what they subscribe to. || -| BDR | 5.3.0 | Fixed memory leak in LCR file TDE encryption. || -| BDR | 5.3.0 | Fixed memory leak in streaming transaction processing. || -| BDR | 5.3.0 | Allow force parting of nodes that are already being parted normally. || -| BDR | 5.3.0 | PART_CATCHUP is now more resilient to replication slot and node_catchup_info conflict. || -| BDR | 5.3.0 | Fixed row filter failure for partitions created after a table column was dropped. | RT95149 | -| BDR | 5.3.0 | Avoid aborting a group commit transaction on receiving the first abort response. The other nodes are given a chance to respond, and transaction can succeed if the required responses are received. || -| BDR | 5.3.0 | Ensure that replication receiver worker reloads configuration correctly when `pg_reload_conf()` is called. || -| BDR | 5.3.0 | Prevent duplicate Raft request ID generation which could break replication. || -| BDR | 5.3.0 | Fixed several rare memory access issues that could potentially cause crashes of workers. || -| BDR | 5.3.0 | Fixed issue where explicit 2PC transactions aborted earlier when encountering conflicts. | RT92897 | -| CLI | 5.3.0 | Fixed `verify-settings` command if the `shared_preload_libraries` GUC contains file path. || -| CLI | 5.3.0 | Show replslots status as `Critical` in `check-health` command when PGD cluster is reduced to just a witness node. | | -| Proxy | 5.3.0 | Always set the server connection close behavior (setLinger(0)). Earlier it was set only on client error. | | -| Proxy | 5.3.0 | Fixed the logs fill up issue when all nodes are down in a PGD cluster | | -| Utilities | 1.2.0 | Removed the preupgrade step in `bdr_pg_upgrade` that sets the CONNECTION LIMIT to 0 at database level | | - diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.4.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.4.0_rel_notes.mdx deleted file mode 100644 index 2ba18fc19cf..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.4.0_rel_notes.mdx +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: "EDB Postgres Distributed 5.4.0 release notes" -navTitle: "Version 5.4.0" ---- - -Released: 05 Mar 2024 - -EDB Postgres Distributed version 5.4.0 is a minor version of EDB Postgres Distributed. - -!!! Important Recommended upgrade -We recommend that all users of PGD 5 upgrade to PGD 5.4. See [PGD/TPA upgrades](../upgrades/tpa_overview) for details. -!!! - - -## Highlights of EDB Postgres Distributed 5.4.0 - -Highlights of this 5.4.0 release include improvements to: - -* Group Commit, aiming to optimize performance by minimizing the effect of a node's downtime and simplifying overall operating of PGD clusters. -* `apply_delay`, enabling the creation of a delayed read-only [replica](/pgd/latest/nodes/subscriber_only/overview/) for additional options for disaster recovery and to mitigate the impact of human error, such as accidental DROP table statements. - -## Compatibility - -!!! Note EDB Server version compatibility -This version requires the recently released Postgres versions 14.10, 15.4, -or 16.1 (or later) of EDB Postgres Advanced Server or EDB Postgres Extended -Server. No such restrictions exist for PostgreSQL Server. - -Package managers on Debian, RHEL, and SLES pull in the required EDB Postgres -Advanced Server or EDB Postgres Extended upgrades with an upgrade of EDB -Postgres Distributed. -!!! - -## Features - -| Component | Version | Description | Addresses | -|-----------|---------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------| -| BDR | 5.4.0 | PGD now automatically detects and synchronizes all available nodes to the furthest ahead node for transactions originating from failed or disconnected node. | | -| BDR | 5.4.0 | PGD now automatically resolves pending Group Commit transactions when the originating node fails or disconnects, ensuring uninterrupted transaction processing within the cluster. | | -| BDR | 5.4.0 | Added ability to set the `apply_delay` group option on subgroups, enabling adding of delayed subscriber-only nodes. | | -| BDR | 5.4.0 | Loading data using EDB\*Loader (except direct mode) is now supported. | | - -## Bug fixes - -| Component | Version | Description | Addresses | -|-----------|---------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------| -| BDR | 5.4.0 | Fixed memory leaks when running a query on some or all nodes. | | -| BDR | 5.4.0 | Resolved an issue of high CPU usage for consensus processes. | RT97649 | -| BDR | 5.4.0 | Improved WAL retention logic when a part_node occurs. | | -| BDR | 5.4.0 | Witness nodes will now automatically not synchronize structure when joining a group. | | -| BDR | 5.4.0 | bdr.create_node() / bdr.alter_node() now give a hint when an invalid node kind is used. | | -| BDR | 5.4.0 | Fixed transactions PREPARE/COMMIT/ABORT order with Parallel Apply enabled. | | -| BDR | 5.4.0 | DDL replication now takes into account more of the Postgres configuration options that are set in the original session or transaction to provide more consistent results of the DDL execution. Added `standard_conforming_strings`, `edb_redwood_date`, `default_with_rowids`, and `check_function_bodies`. | | -| BDR | 5.4.0 | Improved `pgd_bench` cluster initialization and command line help output. | | -| BDR | 5.4.0 | Restoring a node group from a consensus snapshot now correctly applies option changes (number of writers, streaming, and apply_delay) to local subscriptions. | | -| BDR | 5.4.0 | Fixed debug logging of pg_ctl enabling output capture for debugging purposes in `bdr_init_physical`. | | -| BDR | 5.4.0 | Fixed assertion failure when TargetColumnMissing conflict occurs in a Group Commit transaction. | | -| BDR | 5.4.0 | Fixed detection of UpdateOriginChange conflict to be more accurate. | | -| BDR | 5.4.0 | Added support for timeout for normal Group Commit transaction. | | -| BDR | 5.4.0 | Fixed error handling in writer when there are lock timeouts, conflicts, or deadlocks with and without Group Commit transactions. | | -| BDR | 5.4.0 | Now allow the origin of Group Commit transactions to wait for responses from all the required nodes before taking an abort decision. | | -| BDR | 5.4.0 | Eager transactions abort correctly after Raft was disabled or not working and has recovered. | RT101055 | -| BDR | 5.4.0 | Increased default `bdr.raft_keep_min_entries` to 1000 from 100. | | -| BDR | 5.4.0 | Now allow the origin of Group Commit transactions to wait for responses from all the required nodes before taking an abort decision. | | -| BDR | 5.4.0 | Now run ANALYZE on the internal Raft tables. | RT97735 | -| BDR | 5.4.0 | Fixed segfault in I2PC concurrent abort case. | RT93962 | -| BDR | 5.4.0 | Now avoid bypassing other extensions in BdrProcessUtility when processing COPY..TO. | RT99345 | -| BDR | 5.4.0 | Ensured that consensus connection are handled correctly. | RT97649 | -| BDR | 5.4.0 | Fixed memory leaks while running monitoring queries. | RT99231, RT95314 | -| BDR | 5.4.0 | The `bdr.metrics_otel_http_url` and `bdr.trace_otel_http_url` options are now validated at assignment time. | | -| BDR | 5.4.0 | When `bdr.metrics_otel_http_url` and `bdr.trace_otel_http_url` don't include paths, `/v1/metrics` and `/v1/traces` are used, respectively. | | -| BDR | 5.4.0 | Setting `bdr.trace_enable` to `true` is no longer required to enable OTEL metrics collection. | | -| Proxy | 5.4.0 | Now use route_dsn and perform sslpassword processing while extracting write leader address. | RT99700 | -| Proxy | 5.4.0 | Now log client and server addresses at debug level in proxy logs. | | diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.4.1_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.4.1_rel_notes.mdx deleted file mode 100644 index 9db05402b11..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.4.1_rel_notes.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "EDB Postgres Distributed 5.4.1 release notes" -navTitle: "Version 5.4.1" ---- - -Released: 03 Apr 2024 - -EDB Postgres Distributed version 5.4.1 is a patch release containing bug fixes for EDB Postgres Distributed. - -!!! Important Recommended upgrade -We recommend that all users of PGD 5 upgrade to PGD 5.4.1. See [PGD/TPA upgrades](../upgrades/tpa_overview) for details. -!!! - - -## Bug fixes - -| Component | Version | Description | Tickets | -|-----------|---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------| -| BDR | 5.4.1 |
Fixed WAL retention logic to prevent disk space issues on a PGD node with version 5.4.0 and Postgres 16, PGE 16, and EDB Postgres Advanced Server 16.
A fix was implemented to ensure proper cleanup of write-ahead logs (WAL) even after reaching a size of 4 GB on a node. A change in version 5.4.0 resulted in WAL being retained indefinitely after reaching this threshold. This issue is specific to PGD 5.4.0 in conjunction with Postgres 16, PGE 16, and EDB Postgres Advanced Server 16.
| | - - - diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.5.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.5.0_rel_notes.mdx deleted file mode 100644 index 7b47fd026e0..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.5.0_rel_notes.mdx +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: "EDB Postgres Distributed 5.5.0 release notes" -navTitle: "Version 5.5.0" ---- - -Released: 16 May 2024 - -EDB Postgres Distributed version 5.5.0 is a minor version of EDB Postgres Distributed. - -!!! Important Recommended upgrade -We recommend that all users of PGD 5 upgrade to PGD 5.5. See [PGD/TPA upgrades](../upgrades/tpa_overview) for details. -!!! - - -## Highlights of EDB Postgres Distributed 5.5.0 - -Highlights of this 5.5.0 release include: - -* Read scalability enhancements in PGD Proxy which allow [read-only queries to be routed](/pgd/latest/routing/readonly/) to nodes that are members of a read-only pool. This feature can improve the overall performance of the PGD cluster. - -## Compatibility - -!!! Note EDB server version compatibility -This version requires the recently released Postgres versions 14.10, 15.4, -or 16.1 (or later) of EDB Postgres Advanced Server or EDB Postgres Extended -Server. No such restrictions exist for Community Postgres Server. - -Package managers on Debian, RHEL, and SLES pull in the required EDB Postgres -Advanced Server or EDB Postgres Extended upgrades with an upgrade of EDB -Postgres Distributed. -!!! - -## Features - -| Component | Version | Description | Ticket | -|-----------|---------|------------------------------------------------------------------------------------------------|--------| -| BDR | 5.5.0 | Added support for read-only proxy routing. | | -| BDR | 5.5.0 | Improved stability of routing leader selection by using Raft heartbeat for connectivity check. | | -| CLI | 5.5.0 | Added PGD CLI binaries for macOS. | | -| Proxy | 5.5.0 | Added support for read-only proxy routing. | | - - -## Enhancements - -| Component | Version | Description | Ticket | -|-----------|---------|--------------------------------------------------------------------------------------------------------------------------------------------------------|----------------| -| BDR | 5.5.0 | Improved bulk INSERT/UPDATE/DELETE performance by sending multiple messages together in a group rather than individually. | | -| BDR | 5.5.0 | Changes received by the writer now aren't saved to a temporary file. | | -| BDR | 5.5.0 | BDR now logs completion of an extension upgrade. | | -| BDR | 5.5.0 | Added restrictions for group commit options. | | -| BDR | 5.5.0 | Each autopartition task is now executed in its own transaction. | RT101407/35476 | -| BDR | 5.5.0 | DETACH CONCURRENTLY is now used to drop partitions. | RT101407/35476 | -| BDR | 5.5.0 | Node group creation on a node bad state is now disallowed. | | -| BDR | 5.5.0 | Granted additional object permissions to role `bdr_read_all_stats`. | | -| BDR | 5.5.0 | Improved stability of manager worker and Raft consensus by not throwing error on non-fatal dynamic shared memory read failures. | | -| BDR | 5.5.0 | Improved stability of Raft consensus and workers by handling dynamic shared memory errors in the right place. | | -| BDR | 5.5.0 | The number of changes processed by writer in a large transaction is now exposed in [`bdr.writers`](/pgd/latest/reference/catalogs-visible#bdrwriters). | | -| BDR | 5.5.0 | `bdr_init_physical` now stops the initial replication connection and starts it only when needed. | RT102828/35305 | -| BDR | 5.5.0 | `bdr_superuser` is now granted use of `pg_file_settings` and `pg_show_all_file_settings()`. | | -| CLI | 5.5.0 | Added new read scalability related options to JSON output of `show-proxies ` and `show-groups` commands. | | -| CLI | 5.5.0 | Added new option called `proxy-mode` to `create-proxy` command for read scalability support. | | -| CLI | 5.5.0 | Added Raft leader in tabular output of `show-groups` command. | | - - -## Bug fixes - -| Component | Version | Description | Ticket | -|-----------|---------|------------------------------------------------------------------------------------------------------------------------------|----------------| -| BDR | 5.5.0 | Improved handling of node group configuration parameter "check_constraints". | RT99956/31896 | -| BDR | 5.5.0 | Fixed incorrect parsing of pre-commit message that caused nodes to diverge on commit decision for group commit transactions. | | -| BDR | 5.5.0 | Fixed an issue to prevent potential segfault in `bdr.monitor_group_versions()` | RT102290/34051 | -| BDR | 5.5.0 | BDR now correctly elects a new leader when the current leader gets route_writes turned off. | | -| BDR | 5.5.0 | `bdr.remove_commit_scope()` now handles non-existent commit scope. | | -| BDR | 5.5.0 | An improved queue flush process now prevents unexpected writer terminations. | RT98966/35447 | -| BDR | 5.5.0 | Fixed multi-row conflict accidentally deleting the wrong tuple multiple times . | | -| BDR | 5.5.0 | Fixed receiver to send status update when writer is blocked, avoiding slot disconnect. | | -| BDR | 5.5.0 | Fixed minor memory leak during `bdr_join_node_group_sql`. | | -| BDR | 5.5.0 | Node joining with witness and standby nodes as source nodes is now disallowed. | | -| BDR | 5.5.0 | Now use `bdr.default_sequence_kind` when updating sequence kind of existing sequences upon node creation. | | -| BDR | 5.5.0 | Fixed a bug preventing some trusted extension management commands (CREATE/ALTER) from being replicated. | | -| BDR | 5.5.0 | Fixed a non-critical segfault which could occur in upgrades from BDR 3.7. | | -| BDR | 5.5.0 | Fixed an issue to manage rights elevation for trusted extensions. | | diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.5.1_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.5.1_rel_notes.mdx deleted file mode 100644 index 4379675a399..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.5.1_rel_notes.mdx +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "EDB Postgres Distributed 5.5.1 release notes" -navTitle: "Version 5.5.1" ---- - -Released: 31 May 2024 - -EDB Postgres Distributed version 5.5.1 is a patch release containing bug fixes for EDB Postgres Distributed. - -!!! Important Recommended upgrade -We recommend that all users of PGD 5 upgrade to PGD 5.5.1. See [PGD/TPA upgrades](../upgrades/tpa_overview) for details. -!!! - - -## Bug fixes - -| Component | Version | Description | Ticket | -|-----------|---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------| -| BDR | 5.5.1 |
Fixed potential data inconsistency issue with mixed-version usage during a rolling upgrade.
Backward-incompatible change in PGD 5.5.0 may lead to inconsistencies when replicating from a newer PGD 5.5.0 node to an older version of the PGD node, specifically during the mixed-mode rolling upgrade.
This release addresses a backward-compatibility issue in mixed-version operation, enabling seamless rolling upgrades.
| | -| BDR | 5.5.1 |
Disabled auto-triggering of node sync by default.
Automatically triggered synchronization of data from a down node caused issues by failing to resume once it came back up. As a precautionary measure, the feature is now disabled by default (PGD setting [`bdr.enable_auto_sync_reconcile`](/pgd/latest/reference/pgd-settings#bdrenable_auto_sync_reconcile)).
| 11510 | diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.6.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.6.0_rel_notes.mdx deleted file mode 100644 index 2dfe49c5252..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.6.0_rel_notes.mdx +++ /dev/null @@ -1,166 +0,0 @@ ---- -title: EDB Postgres Distributed 5.6.0 release notes -navTitle: Version 5.6.0 -originalFilePath: product_docs/docs/pgd/6.0/rel_notes/src/relnote_5.6.0.yml -editTarget: originalFilePath ---- - -Released: 15 October 2024 - -EDB Postgres Distributed 5.6.0 includes a number of enhancements and bug fixes. - -## Highlights - -- Improved observability with new monitoring functions and SQL views. -- Improvements to commit scopes including: - - GROUP COMMIT and SYNCHRONOUS COMMIT support graceful degrading using DEGRADE ON. - - ORIGIN_GROUP support and commit scope inheritance simplify commit scope creation. - - Improved synchronous commit behavior around deadlocks. - - Metrics for commit scope performance and state. -- Optimized Topology support for Subscriber-only groups and nodes. (preview) -- Improved Postgres compliance with support for: - - Exclusion Constraints - - REINDEX replications - - createrole_self_grant - - column reference in DEFAULT expressions - - CREATE SCHEMA AUTHORIZATION -- Streaming Transaction support with Decoding Worker. - -## Enhancements - - - - - - - - - - - - - - - - - - - - - - - - - - -
ComponentVersionDescriptionAddresses
BDR5.6.0
Decoding Worker supports Streaming Transactions

One of the main advantages of streaming is that the WAL sender sends the partial transaction before it commits, which reduces replication lag. Now, with streaming support, the WAL decoder does the same thing, but it streams to the LCRs segments. Eventually, the WAL sender will read the LCRs and mimic the same behavior of streaming large transactions before they commit. This provides the benefits of decoding worker, such as reduced CPU and disk space, as well as the benefits of streaming, such as reduced lag and disk space, since ".spill" files are not generated. -The WAL decoder always streams the transaction to LCRs, but based on downstream requests, the WAL sender either streams the transaction or just mimics the normal BEGIN..COMMIT scenario. -In addition to the normal LCRs segment files, we create streaming files with the starting names TR_TXN_<file-name-format> and CAS_TXN_<file-name-format> for each streamed transaction.

-
BDR5.6.0
Introduce several new monitoring views

There are several view providing new information as well as making some -existing information easier to discover:

-
    -
  • bdr.stat_commit_scope : Cumulative statistics for commit scopes.
    • -
  • bdr.stat_commit_scope_state : Information about current use of commit scopes by backends.
    • -
  • bdr.stat_receiver : Per subscription receiver statistics.
    • -
  • bdr.stat_writer : Per writer statistics. There can be multiple writers for each subscription. This also includes additional information about the currently applied transaction.
    • -
  • bdr.stat_raft_state : The state of the Raft consensus on the local node.
    • -
  • bdr.stat_raft_followers_state : The state of the followers on the Raft leader node (empty on other nodes), also includes approximate clock drift between nodes.
    • -
  • bdr.stat_worker : Detailed information about PGD workers, including what the operation manager worker is currently doing.
    • -
  • bdr.stat_routing_state : The state of the connection routing which PGD Proxy uses to route the connections.
    • -
  • bdr.stat_routing_candidate_state : Information about routing candidate nodes on the Raft leader node (empty on other nodes).
    • -
-
BDR5.6.0
Support conflict detection for exclusion constraints

This allows defining EXCLUDE constraint on table replicated by PGD either with -CREATE TABLE or with ALTER TABLE and uses similar conflict detection to resolve -conflicts as for UNIQUE constraints.

-
BDR5.6.0
Detect and resolve deadlocks between synchronous replication wait-for-disconnected sessions and replication writer.

This will cancel synchronous replication wait on disconnected sessions if it deadlocks against replication, preventing deadlocks on failovers when using synchronous replication. This only affects commit scopes, not synchronous replication configured via synchronous_standby_names.

-
BDR5.6.0
Add bdr.bdr_show_all_file_settings() and bdr.bdr_file_settings view

Fix: Correct privileges for bdr_superuser. Creating wrapper SECURITY DEFINER functions in the bdr schema and granting access to bdr_superuser to use those:

-
    -
  • bdr.bdr_show_all_file_settings
    • -
  • bdr.bdr_file_settings
    • -
-
BDR5.6.0
Add create/drop_commit_scope functions

Add functions for creating and dropping commit scopes that will eventually deprecate the non-standard functions for adding and removing commit scopes. Notify the user that these will be deprecated in a future version, suggesting the use of the new versions.

-
BDR5.6.0
Grant additional object permissions to role "bdr_monitor".

Permissions for the following objects have been updated to include SELECT permissions for role "bdr_monitor": bdr.node_config

-
BDR5.6.0
Add bdr.raft_vacuum_interval and bdr.raft_vacuum_full_interval GUCs to control frequency of automatic Raft catalog vacuuming.

This update introduces GUCs to regulate the frequency of automatic vacuuming on the specified catalogs. The GUC bdr.raft_vacuum_interval determines the frequency at which tables are examined for VACUUM and ANALYZE. Autovacuum GUCs and table reloptions are utilized to ascertain the necessity of VACUUM/ANALYZE. -The bdr.raft_vacuum_full_interval initiates VACUUM FULL on the tables. Users have the ability to deactivate VACUUM FULL if regular VACUUM suffices to manage bloat.

-
40412
BDR5.6.0
Add "node_name" to "bdr.node_config_summary"

Add "node_name" to the view "bdr.node_config_summary". This makes it consistent with other summary views, which report the name of the object (node, group, etc.) for which the summary is being generated.

-
BDR5.6.0
bdr_init_physical: improve local node connection failure logging

Ensure that bdr_init_physical emits details about connection failure if the "--local-dsn" parameter is syntactically correct but invalid, e.g., due to an incorrect host or port setting.

-
BDR5.6.0
bdr_config: add PG_FLAVOR output

bdr_config now shows the PostgreSQL "flavor" which BDR was built against, one of:

-
    -
  • COMMUNITY
    • -
  • EPAS
    • -
  • EXTENDED
    • -
  • BDRPG
    • -
-
BDR5.6.0
Enhance warning messages

Enhance messages issued during DML and DDL lock acquisition.

-
BDR5.6.0
Do not send Raft snapshot very aggressively

Avoid sending Raft snapshots too frequently as it can slow down follower nodes. Limit the snapshot rate to once in every election timeout, unless there is no other communication between the nodes, in which case send a snapshot every 1/3rd of the election timeout. This will help all nodes keep pace with the leader and improve CPU utilization.

-
37725
BDR5.6.0
Group-Specific Configuration Options

It is now possible to set akk top-level and subgroup level options. The following options are available for top-both groups:

-
    -
  • check_constraints
    • -
  • enable_wal_decoder
    • -
  • num_writers
    • -
  • streaming_mode
    • -
  • enable_raft -Subgroups inherit settings from their parent group, but can override them if set in the subgroup.
    • -
-
37725
BDR5.6.0
Subscriber-only node groups have a leader

Subscriber-only node groups have a leader elected by top-level Raft. There is now a bdr.leader catalog that tracks leadership of subgroups and subscriber-only nodes. If the node that is the leader of a subscriber-only node group goes down or becomes unreachable, a new leader is elected from that group.

-
BDR5.6.0
Optimized topology for subscriber-only nodes via the leader of the subscriber-only node group

Subscriber-only nodes earlier used to have subscriptions to each data node. Now if optimized topology is enabled, only the leaders of subscriber-only node groups have subscriptions to routing leaders of data node subsgroups. The subscriber only nodegroup leaders route data to other nodes of that subscriber-only nodegroup. This reduces the load on all data nodes so they do not have to send data to all subscriber-only nodes. The GUC bdr.force_full_mesh=off enables this optimized topology. This GUC variable is on by default, retaining pre-5.6.0 behavior.

-
BDR5.6.0
Introduce new subscription types to support optimized topology

New subscription types that forward data from all nodes of the subgroup via a routing leader (mode: l), and those that forward data from the entire cluster via a subscriber-only group leader (mode: w) are introduced.

-
BDR5.6.0
Introduce version number and timestamp for write leader

A write leader has a version. Every time a new leader is elected, the version is incremented and timestamp noted via Raft. This is to build a foundation for better conflict resolution.

-
BDR5.6.0
Allow use of column reference in DEFAULT expressions

Using column references in default expressions is now supported, this is particularly -useful with generated columns, for example: -ALTER TABLE gtest_tableoid ADD COLUMN c regclass GENERATED ALWAYS AS (tableoid) STORED;

-
BDR5.6.0
Support replication of REINDEX

Both REINDEX and REINDEX CONCURRENTLY are now replicated commands.

-
BDR5.6.0
Fix receiver worker being stuck when exiting

Receiver worker could get stuck when exiting, waiting for a writer that never -actually started. This could on rare occasions break replication after -configuration changes until Postgres was restarted.

-
BDR5.6.0
Reduce performance impact of PGD specific configuration parameters that are sent to client

Changes to values of variables bdr.last_committed_lsn, transaction_id -and bdr.local_node_id are automatically reported to clients when using -CAMO or GROUP COMMIT. This has now been optimized to use less resources.

-
BDR5.6.0
Allow use of commit scopes defined in parent groups

When there is a commit scope defined for top-level group, it can be used by -any node in a subgroup and does not need to be redefined for every subgroup -anymore. This is particularly useful when combined with ORIGIN\_GROUP -keyword to reduce the complexity of commit scope setup.

-
PGD CLI5.6.0
Use bdr.bdr_file_settings view in verify-settings

Use bdr.bdr_file_settings view to get the current settings for the proxy.

-
- - -## Bug Fixes - - - - - - - - - - - - - - - - -
ComponentVersionDescriptionAddresses
BDR5.6.0
Fixed buffer overrun in the writer

Include an extra zero byte at the end of a column value allocation in shared memory queue insert/update/delete messages.

-
98966
BDR5.6.0Fixes for some race conditions to prevent node sync from entering a hung state with the main subscription disabled.
BDR5.6.0
Do not accidentally drop the autopartition rule when a column of the autopartitioned table is dropped.

When ALTER TABLE .. DROP COLUMN is used, the object_access_hook is fired with classId set to RelationRelationId, but the subId is set to the attribute number to differentiate it from the DROP TABLE command.

-

Therefore, we need to check the subId field to make sure that we are not performing actions that should only be triggered when a table is dropped.

-
40258
BDR5.6.0
Adjust bdr.alter_table_conflict_detection() to propagate correctly to all nodes

Ensure that the propagation of bdr.alter_table_conflict_detection() (as well as the related, deprecated bdr.column_timestamps_(en|dis)able() functions) is carried out correctly to all logical standbys. Previously, this propagation did not occur if the logical standby was not directly attached to the node on which the functions were executed.

-
40258
BDR5.6.0
Prevent a node group from being created with a duplicate name

Ensure that a nodegroup is not inadvertently created with the same name as an existing nodegroup. Failure to do so may result in a complete shutdown of the top-level Raft on all nodes, with no possibility of recovery.

-
BDR5.6.0
Prevent spurious "local info ... not found" errors when parting nodes

Handle the absence of the expected node record gracefully when a node is being removed, the local node record might have already been deleted, but an attempt could be made to update it anyway. This resulted in harmless "BDR node local info for node ... not found" errors.

-
BDR5.6.0
Prevent a corner-case situation from being misdiagnosed as a PGD version problem

Improve Raft error messages to handle cases where nodes may not be correctly participating in Raft.

-
BDR5.6.0
Handling duplicate requests in RAFT preventing protocol breakage

When processing RAFT entries, it's crucial to handle duplicate requests properly to prevent Raft protocol issues. Duplicate requests can occur when a client retries a request that has already been accepted and applied by the Raft leader. The problem arose when the leader failed to detect the duplicate request due to historical evidence being pruned.

-
37725
BDR5.6.0
Handling Raft Snapshots: Consensus Log

When installing or importing a Raft snapshot, discard the consensus log unless it contains an entry matching the snapshot's last included entry and term.

-
37725
BDR5.6.0
Be more restrictive about which index to use during replication for REPLICA IDENTITY FULL tables

This fixes various index related errors during replication like: -'could not lookup equality operator for type, optype in opfamily' -or 'function "amgettuple" is not defined for index "brinidx"'

-
BDR5.6.0
Support createrole_self_grant

The createrole_self_grant configuration option affects inherited grants -by newly created roles. In previous versions CREATE ROLE/CREATE USER -replication would not take this into consideration, resulting in different -role privileges on different nodes.

-
BDR5.6.0
Allow CREATE SCHEMA AUTHORIZATION ... combined with other create operations

Previously, this would throw "cannot change current role within security-restricted operation" error

-
BDR5.6.0
Use base type instead of domain type while casting values

This prevents errors when replicating UPDATEs for domains defined as NOT VALID -where tables contain data which would not be allowed by current definition -of such domain.

-
Utilities5.6.0bdr_pg_upgrade - Create logical slot with twophase set to true for PG 14+
- - diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.6.1_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.6.1_rel_notes.mdx deleted file mode 100644 index 3e2e0e8a153..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.6.1_rel_notes.mdx +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: EDB Postgres Distributed 5.6.1 release notes -navTitle: Version 5.6.1 -originalFilePath: product_docs/docs/pgd/6.0/rel_notes/src/relnote_5.6.1.yml -editTarget: originalFilePath ---- - -Released: 25 November 2024 - -EDB Postgres Distributed 5.6.1 includes a number of enhancements and bug fixes. - -## Highlights - -- Postgres 17 support -- ARM64 processor support - -## Features - - - - -
ComponentVersionDescriptionAddresses
BDR5.6.1
Added Postgres 17 support

Support for Postgres 17 has been added for all flavors (PostgreSQL, EDB Postgres Extended, -and EDB Postgres Advanced Server) starting with version 17.2.

-
BDR5.6.1
Added ARM64 processor Support

Support ARM architecture for EDB Postgres Distributed on Debian 12 and RHEL 9.

-
- - -## Enhancements - - - - - - -
ComponentVersionDescriptionAddresses
BDR5.6.1
Added bdr.wait_node_confirm_lsn().

The function bdr.wait_node_confirm_lsn() has been introduced to wait until a specific node -reaches a designated Log Sequence Number (LSN). It first checks the confirmed_flush_lsn of -the replication slot for the specified node. If that information is not available, the function -connects to the node and queries pg_replication_origin_progress(), using the invoking node as -the origin. -If the nodename parameter is NULL, the function will wait for all nodes to reach the specified -LSN. If the target LSN is NULL, it will wait for the current wal_flush_lsn.

-
BDR5.6.1
Improvements made in SO Node Management and Progress Tracking.

An update addresses the movement of group slots in SO nodes, ensuring they don't appear as peers in -progress updates. Improvements include enhanced watermark management for SO leaders in the Optimized Topology -configuration, where write leaders now include watermarks in their updates. Watermarks are broadcasted -to simplify progress tracking on idle clusters. The peer progress mapping for SO nodes has been corrected, -and the tap test for group slot movement has been revised. -Additionally, the bdr_get_all_origins function now considers SO node origins.

-
BDR5.6.1
LSN Progress in Optimized Topology Configurations is now communicated.

While there are no connections from non-leader data nodes to subscriber-only nodes in an optimized -topology configuration, the LSN progress of all data nodes is periodically communicated to these -subscriber-only nodes through logical replication.

-
BDR5.6.1
Some DDL commands are now allowed by bdr.permit_unsafe_commands when set.

The bdr.permit_unsafe_commands parameter now allows some DDL commands that were previously disallowed. Specifically ALTER COLUMN...TYPE...USING can now be permitted if the user knows the operation is safe.

-
- - -## Bug Fixes - - - - - - - - - - -
ComponentVersionDescriptionAddresses
BDR5.6.1
Addressed walsender crash that happend during configuration reload.

Ensure that pglogical GUCs are overridden only when operating within the pglogical worker. -If this is not the case, MyPGLogicalWorker will be NULL, resulting in a segmentation fault -when the walsender attempts a configuration reload from the -pgl_wait_for_standby_confirmation() function.

-
42100
BDR5.6.1
Fixed unintended eager connection related to consensus connections among Subscriber Only group members

The msgbroker module used to establish consensus connections lazily, meaning that connections -were created only when the first message was sent to a specific destination. This method -negatively affected the latency of Raft leader elections. The behavior was modified to create -connections to consensus peers eagerly. However, this change resulted in an unintended -consequence: a fully meshed consensus network among subscriber-only nodes, which may conflict -with customer network designs. This patch keeps the eager connection setup but limits it to -voting nodes only, reverting to a lazy connection setup for non-voting nodes.

-
42041
BDR5.6.1
Fixed autopatition task scheduling.

To improve reliability, shuffle the scheduling of autopartition tasks. This way, tasks -that are prone to failure won't consistently impact the success of other tasks.

-
41998
BDR5.6.1
Fixed parting subscription with standbys.

The parting subscription used to hang, failing to wait for standbys when the -bdr.standby_slot_names parameter was defined.

-
41821
BDR5.6.1
Fixed parting SO node with multiple origins.

All relevant origins must be removed when parting SO node. -With Optimized Topology, parting an SO node should result in removing all origins it -has, not just the one related to its SO group leader. -When parting a data node, even though there is no subscription to it -from SO node, the origin should be removed. -DO not make SO node target of a part catchup subscription when Optimized Topology is enabled.

-
BDR5.6.1
Stopped creation of slots for subscriber only nodes on witness nodes.

Subscriber only nodes should not have slots on witness nodes.

-
BDR5.6.1
Ensure no waiting for DEGRADE timeout when in an already degraded state.

When using commit scope with DEGRADE clause, if system detects that it's in degraded state, transactions should start in the DEGRADE mode. This ensures that the timeout is not applied on every commit.

-
PGD Proxy5.6.1
Fixed routing strategy for read nodes.

Corrected routing strategy for read nodes after a network partition.

-
- - diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_5.7.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_5.7.0_rel_notes.mdx deleted file mode 100644 index f7d3977f589..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/pgd_5.7.0_rel_notes.mdx +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: EDB Postgres Distributed 5.7.0 release notes -navTitle: Version 5.7.0 -originalFilePath: product_docs/docs/pgd/6.0/rel_notes/src/relnote_5.7.0.yml -editTarget: originalFilePath ---- - -Released: 25 February 2025 - -Updated: 26 March 2025 - -EDB Postgres Distributed 5.7.0 includes a number of enhancements and bug fixes. - -## Highlights - -- **Improved 3rd Party CDC Tool Integration**: PGD 5.7.0 now supports [failover of logical slots used by CDC tools](/pgd/latest/cdc-failover) with standard plugins (such as test_decoding, pgoutput, and wal2json) within a PGD cluster. This enhancement eliminates the need for 3rd party subscribers to reseed their tables during a lead Primary change. -- **PGD Compatibility Assessment**: Ensure a seamless migration to PGD with the new [Assess](/pgd/latest/cli/command_ref/assess/) command in the PGD CLI. This tool proactively reports any PostgreSQL incompatibilities—especially those affecting logical replication—so you can address them before upgrading to PGD. -- **Upgrade PGD and Postgres with a Single Command**: Leverage the new [`pgd node upgrade`](/pgd/latest/cli/command_ref/node/upgrade -) command in the PGD CLI to upgrade a node to the latest versions of PGD and Postgres. -- **Ubuntu 24.04 supported**: PGD 5.7.0 now supports Ubuntu 24.04. (23 March 2025) - -## Features - - - - - - - - - -
ComponentVersionDescriptionAddresses
BDR5.7.0
Added support for failover slots for logical replication.

When a PGD node fails or becomes unavailable, consumers can now continue to consume changes from some other node in the cluster. The feature can be turned on by setting the top group option failover_slot_scope to global. The consumer needs to handle duplicate transactions, but PGD -guarantees that every transaction is decoded and sent at least once.

-
BDR5.7.0Ensured that the `remote_commit_time` and `remote_commit_lsn` are properly reported in the conflict reports.42273
PGD CLI5.7.0
Added new CLI command structure for easier access.

The new CLI command structure is more intuitive and easier to use. The new structure is a "noun-verb" format, where the noun is the object you want to work with and the verb is the action you want to perform. Full details are available in the CLI command reference.

-
PGD CLI5.7.0
Added a new local assesment feature for local non-PGD nodes to the CLI

The new feature allows you to assess the local node for compatibility with PGD. The feature is available as pgd assess. Full details are available in the CLI command reference.

-
PGD CLI5.7.0
Added pgd node upgrade functionality to the PGD CLI.

The new command allows you to upgrade a node to the latest version of PGD and Postgres. It integrates the operation of bdr_pg_upgrade into the CLI and is run locally. See pgd node upgrade and inplace upgrades for more information.

-
BDR5.7.0
Fixed an issue whereby concurrent joins of subscriber-only nodes occasionally stopped responding.

A node could end up waiting for the local state of another concurrently joined node to advance, which caused the system to stop responding.

-
42964
BDR5.7.0
Ubuntu 24.04 is now supported.

Packages are now available for Ubuntu 24.04 for all PGD components.

-
- - -## Enhancements - - - - - - - - - - - -
ComponentVersionDescriptionAddresses
BDR5.7.0
Narrowed down bdr.node_slots output to list only relevant slots.

The slots are displayed based on the node type, its role, and the cluster topology.

-
BDR5.7.0Added `target_type` column to `bdr.node_slots` view to indicate slot purpose/status.
BDR5.7.0
Improved performance of DML and other operations on partitioned tables.

Many code paths touching partitioned tables were performing costly checks to support additional table access methods. This code was adjusted to make the most common case (heap) the fastest.

-
BDR5.7.0
Improved bdr_init_physical to be able to run without superuser.

Now only the bdr_superuser is required.

-
PGD CLI5.7.0
Added new CLI commands for adding removing and updating commit scopes.

The new commands are pgd commit-scope show, pgd commit-scope create, pgd commit-scope update and pgd commit-scope drop. Full details are available in the CLI command reference.

-
PGD CLI5.7.0
Added support for legacy CLI command structure in the updated PGD CLI.

The legacy CLI command structure is still supported in the updated PGD CLI. The legacy command support is available for a limited time and will be removed in a future release. It is implemented as a wrapper around the new commands.

-
PGD CLI5.7.0
Added new subcommands to PGD CLI node and group for getting options.

The new subcommands are pgd node get-options and pgd group get-options. Full details are available in the CLI command reference.

-
PGD CLI5.7.0
Added new output formatting options psql and markdown to the PGD CLI.

The new options allow you to format the output of the CLI commands in a psql-like or markdown format. Format options are now json, psql, modern, markdown, simple and defaults to simple.

-
BDR5.7.0
Removed redundant WARNING when executing ALTER SEQUENCE.

The message now only appears when creating the sequence.

-
- - -## Bug Fixes - - - - - - - - - - - - - - - - - - - - -
ComponentVersionDescriptionAddresses
BDR5.7.0Fixed a server panic by ensuring that catalog lookups aren't performed in a callback that gets called very late in the commit cycle.
BDR5.7.0Fixed an unintentional timed wait for a synchronous logical replication that resulted in unusually high latency for some transactions.42273
BDR5.7.0
The bdr.group_camo_details view now only lists data nodes belonging to the CAMO group.

The bdr.group_camo_details view now only lists data nodes belonging to the CAMO commit scope group. Previously, the view could include data nodes were not part of the CAMO group, logical standby nodes, Subscriber-Only nodes and witness nodes.

-
45354
BDR5.7.0
Improved PostgreSQL 17 compatibility.

Internal tables managed by autopartition that were created before the upgrade to PG17 were missing a rowtype entry into pg_depend. This issue caused errors after upgrading to PG17.

-
44401
BDR5.7.0
Fixed a bug where parting stopped responding with consensus timeout or consensus errors.

This fix also ensures parting doesn't stop responding when any of the nodes restart when part is in progress. Origin LSNs don't show up as 0/0 in log messages.

-
42056
BDR5.7.0
Fixed a memory leak in a global hook.

This bug could cause memory to leak even if bdr.so is just loaded and the extension isn't installed.

-
43678
BDR5.7.0
Fixed a bug where subgroup member part prevented new nodes from joining.

This fix ensures that if a subgroup member is parted while Raft subgroup routing is active, then another node can subsequently join that subgroup.

-
BDR5.7.0
Fixed a case where galloc sequence overflow wasn't being caught correctly.

This bug resulted in nextval call being stuck.

-
44755
BDR5.7.0
Fixed group slot movement for witness and data nodes in presence of subscriber-only nodes and witness nodes.

For PGD 5.6.0 and later, there are no subscriptions from a subscriber-only node to a witness node. This caused a problem with movement of group slot on data nodes and witness nodes in the presence of subscriber-only nodes in the cluster. This bug could cause WAL to be held on both witness nodes and data nodes when there's a subscriber-only node in the cluster.

-
BDR5.7.0Fixed a bug where conflict resolution functions were executed also on the witness nodes.
BDR5.7.0
Fixed a bug where bdr_init_physical stopped responding when synchronous_commit is set to remote_write/remote_apply.

bdr_init_physical disables synchronous replication on a new node by resetting synchronous_standby_names to an empty string. A warning message reminds you to set synchronous_standby_names as needed.

-
44760
PGD Proxy5.7.0
Fixed proxy regression by improving dsn name support for read nodes

A regression in the way read nodes were identified in the proxy in 6.5.1 was fixed -by enabling support for different values in the dsn field's host and the node_name.

-
BDR5.7.0
Fixed a bug to handle additional replication sets on witness nodes.

The witness node now only cares about the top replication set and thus allows it to miss replications sets and not error out.

-
41776, 44527
BDR5.7.0
Changed origin deletion to be done asynchronously when optimized topology is enabled.

In an optimized topology, origin names now use the generation ID of the node. This fixes an inconsistency in which some transactions can be lost or sent twice when a node is parted.

-
BDR5.7.0
Fixed a crash during upgrades in a mixed-version cluster.

Upgrading from versions earlier than 5.6.0 to 5.6.0 and later in a mixed-version cluster with a standby or a node joining/parting could cause a crash.

-
BDR5.7.0
Unsupported ALTER TABLE command on materialized views is no longer replicated.

Replication no longer becomes stuck when the command is issued.

-
BDR5.7.0Disallowed `GRANT` on BDR objects to non-BDR users.
BDR5.7.0Improved maintenance of the `bdr.leader` table.
- - -## Deprecations - - - - -
ComponentVersionDescriptionAddresses
PGD CLI5.7.0
Deprecated proxy commands in new PGD CLI command structure.

The proxy commands are deprecated in the new CLI command structure. The proxy commands are still available in the legacy CLI command structure. Proxy options can be set using the pgd group set-option command.

-
PGD CLI5.7.0
Removed yaml output as an option in PGD CLI

The yaml output option is removed from the PGD CLI. The json output option is still available.

-
- - -## Other - - - -
ComponentVersionDescriptionAddresses
BDR5.7.0
Added a GUC to support upgrade to 5.7.0 for clusters with optimized topology (a preview feature).

An upgrade to 5.7.0 from clusters that have bdr.force_full_mesh set to off to enable optimized topology -(a preview feature) must first set this GUC to on and then upgrade. After the entire cluster upgrades, -this GUC can be set to off again to enable optimized topology. -Having this GUC set to off during upgrade isn't supported.

-
- - diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx new file mode 100644 index 00000000000..0ed80b837fc --- /dev/null +++ b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx @@ -0,0 +1,33 @@ +--- +title: EDB Postgres Distributed 6.0.0 release notes +navTitle: Version 6.0.0 +originalFilePath: product_docs/docs/pgd/6.0/rel_notes/src/relnote_6.0.0.yml +editTarget: originalFilePath +--- + +Released: 1 June 2025 + +EDB Postgres Distributed 6.0.0 includes new features, and many enhancements and bug fixes. + +## Highlights + +- RBD + +## Enhancements + + + + +
ComponentVersionDescriptionAddresses
BDR6.0.0
Table rewriting ALTER TABLE... ALTER COLUMN calls are now supported.

Changing a column's type command which causes the whole table to be rewritten and the change isn't binary coercible is now supported:

+
CREATE TABLE foo (c1 int,c2 int, c3 int, c4 box, UNIQUE(c1, c2) INCLUDE(c3,c4));
+ALTER TABLE foo ALTER c1 TYPE bigint; – results into table rewrite
+
+

This also includes support for ALTER TYPE when using the USING clause:

+
CREATE TABLE foo (id serial primary key,data text);
+ALTER TABLE foo ALTER data TYPE BYTEA USING data::bytea;
+
+

Table rewrites can hold an AccessExclusiveLock for extended periods on larger tables.

+
BDR6.0.0
Restrictions on non-immutable ALTER TABLE... ADD COLUMN calls have been removed.

The restrictions on non-immutable ALTER TABLE... ADD COLUMN calls have been removed.

+
+ + diff --git a/product_docs/docs/pgd/6/rel_notes/src/meta.yml b/product_docs/docs/pgd/6/rel_notes/src/meta.yml index 966a486f925..ab3bca8f2e0 100644 --- a/product_docs/docs/pgd/6/rel_notes/src/meta.yml +++ b/product_docs/docs/pgd/6/rel_notes/src/meta.yml @@ -2,10 +2,10 @@ product: EDB Postgres Distributed shortname: pgd -title: EDB Postgres Distributed 5 release notes -description: Release notes for EDB Postgres Distributed 5 and later +title: EDB Postgres Distributed 6 release notes +description: Release notes for EDB Postgres Distributed 6 and later intro: | - The EDB Postgres Distributed documentation describes the latest version of EDB Postgres Distributed 5, including minor releases and patches. The release notes provide information on what was new in each release. For new functionality introduced in a minor or patch release, the content also indicates the release that introduced the feature. + The EDB Postgres Distributed documentation describes the latest version of EDB Postgres Distributed 6, including minor releases and patches. The release notes provide information on what was new in each release. For new functionality introduced in a minor or patch release, the content also indicates the release that introduced the feature. columns: - 0: label: Release Date @@ -19,55 +19,4 @@ columns: - 3: label: "PGD CLI" key: "$PGD CLI" -- 4: - label: "PGD Proxy" - key: "$PGD Proxy" -components: [ "BDR", "PGD CLI", "PGD Proxy", "Utilities" ] -precursor: -- date: 31 May 2024 - version: "5.5.1" - "BDR": "5.5.1" - "PGD CLI": 5.5.0 - "PGD Proxy": 5.5.0 -- date: 16 May 2024 - version: "5.5.0" - "BDR": 5.5.0 - "PGD CLI": 5.5.0 - "PGD Proxy": 5.5.0 -- date: 03 April 2024 - version: "5.4.1" - "BDR": 5.4.1 - "PGD CLI": 5.4.0 - "PGD Proxy": 5.4.0 -- date: 05 March 2024 - version: "5.4.0" - "BDR": 5.4.0 - "PGD CLI": 5.4.0 - "PGD Proxy": 5.4.0 -- date: 14 November 2023 - version: "5.3.0" - "BDR": 5.3.0 - "PGD CLI": 5.3.0 - "PGD Proxy": 5.3.0 -- date: 04 August 2023 - version: "5.2.0" - "BDR": 5.2.0 - "PGD CLI": 5.2.0 - "PGD Proxy": 5.2.0 -- date: 16 May 2023 - version: "5.1.0" - "BDR": 5.1.0 - "PGD CLI": 5.1.0 - "PGD Proxy": 5.1.0 -- date: 21 Mar 2023 - version: "5.0.1" - "BDR": 5.0.0 - "PGD CLI": 5.0.1 - "PGD Proxy": 5.0.1 -- date: 21 Feb 2023 - version: "5.0.0" - "BDR": 5.0.0 - "PGD CLI": 5.0.0 - "PGD Proxy": 5.0.0 - - \ No newline at end of file +components: [ "BDR", "PGD CLI", "Utilities" ] diff --git a/product_docs/docs/pgd/6/rel_notes/src/relnote_5.6.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_5.6.0.yml deleted file mode 100644 index f51a4e4d786..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/src/relnote_5.6.0.yml +++ /dev/null @@ -1,355 +0,0 @@ -# yaml-language-server: $schema=https://raw.githubusercontent.com/EnterpriseDB/docs/refs/heads/develop/tools/automation/generators/relgen/relnote-schema.json -product: EDB Postgres Distributed -version: 5.6.0 -date: 15 October 2024 -components: - "BDR": 5.6.0 - "PGD CLI": 5.6.0 - "PGD Proxy": 5.6.0 - "Utilities": 5.6.0 -intro: | - EDB Postgres Distributed 5.6.0 includes a number of enhancements and bug fixes. -highlights: | - - Improved observability with new monitoring functions and SQL views. - - Improvements to commit scopes including: - - GROUP COMMIT and SYNCHRONOUS COMMIT support graceful degrading using DEGRADE ON. - - ORIGIN_GROUP support and commit scope inheritance simplify commit scope creation. - - Improved synchronous commit behavior around deadlocks. - - Metrics for commit scope performance and state. - - Optimized Topology support for Subscriber-only groups and nodes. (preview) - - Improved Postgres compliance with support for: - - Exclusion Constraints - - REINDEX replications - - createrole_self_grant - - column reference in DEFAULT expressions - - CREATE SCHEMA AUTHORIZATION - - Streaming Transaction support with Decoding Worker. -relnotes: -- relnote: Decoding Worker supports Streaming Transactions - component: BDR - details: | - One of the main advantages of streaming is that the WAL sender sends the partial transaction before it commits, which reduces replication lag. Now, with streaming support, the WAL decoder does the same thing, but it streams to the LCRs segments. Eventually, the WAL sender will read the LCRs and mimic the same behavior of streaming large transactions before they commit. This provides the benefits of decoding worker, such as reduced CPU and disk space, as well as the benefits of streaming, such as reduced lag and disk space, since ".spill" files are not generated. - The WAL decoder always streams the transaction to LCRs, but based on downstream requests, the WAL sender either streams the transaction or just mimics the normal BEGIN..COMMIT scenario. - In addition to the normal LCRs segment files, we create streaming files with the starting names `TR_TXN_` and `CAS_TXN_` for each streamed transaction. - jira: BDR-5123 - addresses: "" - type: Enhancement - impact: High -- relnote: Introduce several new monitoring views - component: BDR - details: | - There are several view providing new information as well as making some - existing information easier to discover: - - [`bdr.stat_commit_scope`](/pgd/latest/reference/catalogs-visible#bdrstat_commit_scope) : Cumulative statistics for commit scopes. - - [`bdr.stat_commit_scope_state`](/pgd/latest/reference/catalogs-visible#bdrstat_commit_scope_state) : Information about current use of commit scopes by backends. - - [`bdr.stat_receiver`](/pgd/latest/reference/catalogs-visible#bdrstat_receiver) : Per subscription receiver statistics. - - [`bdr.stat_writer`](/pgd/latest/reference/catalogs-visible#bdrstat_writer) : Per writer statistics. There can be multiple writers for each subscription. This also includes additional information about the currently applied transaction. - - [`bdr.stat_raft_state`](/pgd/latest/reference/catalogs-visible#bdrstat_raft_state) : The state of the Raft consensus on the local node. - - [`bdr.stat_raft_followers_state`](/pgd/latest/reference/catalogs-visible#bdrstat_raft_followers_state) : The state of the followers on the Raft leader node (empty on other nodes), also includes approximate clock drift between nodes. - - [`bdr.stat_worker`](/pgd/latest/reference/catalogs-visible#bdrstat_worker) : Detailed information about PGD workers, including what the operation manager worker is currently doing. - - [`bdr.stat_routing_state`](/pgd/latest/reference/catalogs-visible#bdrstat_routing_state) : The state of the connection routing which PGD Proxy uses to route the connections. - - [`bdr.stat_routing_candidate_state`](/pgd/latest/reference/catalogs-visible#bdrstat_routing_candidate_state) : Information about routing candidate nodes on the Raft leader node (empty on other nodes). - jira: BDR-5316 - type: Enhancement - impact: High -- relnote: Support conflict detection for exclusion constraints - component: BDR - details: | - This allows defining `EXCLUDE` constraint on table replicated by PGD either with - `CREATE TABLE` or with `ALTER TABLE` and uses similar conflict detection to resolve - conflicts as for `UNIQUE` constraints. - jira: BDR-4851 - type: Enhancement - impact: High -- relnote: Fixed buffer overrun in the writer - component: BDR - details: | - Include an extra zero byte at the end of a column value allocation in shared memory queue insert/update/delete messages. - jira: BDR-5188 - addresses: 98966 - type: Bug Fix - impact: High -- relnote: Fixes for some race conditions to prevent node sync from entering a hung state with the main subscription disabled. - component: BDR - jira: BDR-5041 - addresses: "" - type: Bug Fix - impact: High -- relnote: Detect and resolve deadlocks between synchronous replication wait-for-disconnected sessions and replication writer. - component: BDR - details: | - This will cancel synchronous replication wait on disconnected sessions if it deadlocks against replication, preventing deadlocks on failovers when using synchronous replication. This only affects commit scopes, not synchronous replication configured via `synchronous_standby_names`. - jira: BDR-5445, BDR-5445, BDR-4104 - addresses: "" - type: Enhancement - impact: High -- relnote: Do not accidentally drop the autopartition rule when a column of the autopartitioned table is dropped. - component: BDR - details: | - When ALTER TABLE .. DROP COLUMN is used, the object_access_hook is fired with `classId` set to RelationRelationId, but the `subId` is set to the attribute number to differentiate it from the DROP TABLE command. - - Therefore, we need to check the subId field to make sure that we are not performing actions that should only be triggered when a table is dropped. - jira: BDR-5418 - addresses: 40258 - type: Bug Fix - impact: High -- relnote: Adjust `bdr.alter_table_conflict_detection()` to propagate correctly to all nodes - component: BDR - details: | - Ensure that the propagation of `bdr.alter_table_conflict_detection()` (as well as the related, deprecated `bdr.column_timestamps_(en|dis)able()` functions) is carried out correctly to all logical standbys. Previously, this propagation did not occur if the logical standby was not directly attached to the node on which the functions were executed. - jira: BDR-3850 - addresses: 40258 - type: Bug Fix - impact: High -- relnote: Prevent a node group from being created with a duplicate name - component: BDR - details: | - Ensure that a nodegroup is not inadvertently created with the same name as an existing nodegroup. Failure to do so may result in a complete shutdown of the top-level Raft on all nodes, with no possibility of recovery. - jira: BDR-5355 - addresses: "" - type: Bug Fix - impact: High -- relnote: Add bdr.bdr_show_all_file_settings() and bdr.bdr_file_settings view - component: BDR - details: | - Fix: Correct privileges for bdr_superuser. Creating wrapper SECURITY DEFINER functions in the bdr schema and granting access to bdr_superuser to use those: - - bdr.bdr_show_all_file_settings - - bdr.bdr_file_settings - jira: BDR-5070 - addresses: "" - type: Enhancement - impact: High -- relnote: Add create/drop_commit_scope functions - component: BDR - details: | - Add functions for creating and dropping commit scopes that will eventually deprecate the non-standard functions for adding and removing commit scopes. Notify the user that these will be deprecated in a future version, suggesting the use of the new versions. - jira: BDR-4073 - addresses: "" - type: Enhancement - impact: High -- relnote: Grant additional object permissions to role "bdr_monitor". - component: BDR - details: | - Permissions for the following objects have been updated to include SELECT permissions for role "bdr_monitor": bdr.node_config - jira: BDR-4885, BDR-5354 - addresses: "" - type: Enhancement - impact: High -- relnote: Add `bdr.raft_vacuum_interval` and `bdr.raft_vacuum_full_interval` GUCs to control frequency of automatic Raft catalog vacuuming. - component: BDR - details: | - This update introduces GUCs to regulate the frequency of automatic vacuuming on the specified catalogs. The GUC `bdr.raft_vacuum_interval` determines the frequency at which tables are examined for VACUUM and ANALYZE. Autovacuum GUCs and table reloptions are utilized to ascertain the necessity of VACUUM/ANALYZE. - The `bdr.raft_vacuum_full_interval` initiates VACUUM FULL on the tables. Users have the ability to deactivate VACUUM FULL if regular VACUUM suffices to manage bloat. - jira: BDR-5424 - addresses: 40412 - type: Enhancement - impact: High -- relnote: Prevent spurious "local info ... not found" errors when parting nodes - component: BDR - details: | - Handle the absence of the expected node record gracefully when a node is being removed, the local node record might have already been deleted, but an attempt could be made to update it anyway. This resulted in harmless "BDR node local info for node ... not found" errors. - jira: BDR-5350 - addresses: "" - type: Bug Fix - impact: High -- relnote: Prevent a corner-case situation from being misdiagnosed as a PGD version problem - component: BDR - details: | - Improve Raft error messages to handle cases where nodes may not be correctly participating in Raft. - jira: BDR-5362 - addresses: "" - type: Bug Fix - impact: High -- relnote: Add "node_name" to "bdr.node_config_summary" - component: BDR - details: | - Add "node_name" to the view "bdr.node_config_summary". This makes it consistent with other summary views, which report the name of the object (node, group, etc.) for which the summary is being generated. - jira: BDR-4818 - addresses: "" - type: Enhancement - impact: High -- relnote: "bdr_init_physical: improve local node connection failure logging" - component: BDR - details: | - Ensure that bdr_init_physical emits details about connection failure if the "--local-dsn" parameter is syntactically correct but invalid, e.g., due to an incorrect host or port setting. - jira: - addresses: "" - type: Enhancement - impact: High -- relnote: "`bdr_config`: add PG_FLAVOR output" - component: BDR - details: | - `bdr_config` now shows the PostgreSQL "flavor" which BDR was built against, one of: - - COMMUNITY - - EPAS - - EXTENDED - - BDRPG - jira: BDR-4428 - addresses: - type: Enhancement - impact: High -- relnote: Enhance warning messages - component: BDR - details: | - Enhance messages issued during DML and DDL lock acquisition. - jira: BDR-4200 - addresses: "" - type: Enhancement - impact: High -- relnote: Handling duplicate requests in RAFT preventing protocol breakage - component: BDR - details: | - When processing RAFT entries, it's crucial to handle duplicate requests properly to prevent Raft protocol issues. Duplicate requests can occur when a client retries a request that has already been accepted and applied by the Raft leader. The problem arose when the leader failed to detect the duplicate request due to historical evidence being pruned. - jira: BDR-5275, BDR-4091 - addresses: 37725 - type: Bug Fix - impact: High -- relnote: "Handling Raft Snapshots: Consensus Log" - component: BDR - details: | - When installing or importing a Raft snapshot, discard the consensus log unless it contains an entry matching the snapshot's last included entry and term. - jira: BDR-5285 - addresses: 37725 - type: Bug Fix - impact: High -- relnote: Do not send Raft snapshot very aggressively - component: BDR - details: | - Avoid sending Raft snapshots too frequently as it can slow down follower nodes. Limit the snapshot rate to once in every election timeout, unless there is no other communication between the nodes, in which case send a snapshot every 1/3rd of the election timeout. This will help all nodes keep pace with the leader and improve CPU utilization. - jira: BDR-5288 - addresses: 37725 - type: Enhancement - impact: High -- relnote: Group-Specific Configuration Options - component: BDR - details: | - It is now possible to set akk top-level and subgroup level options. The following options are available for top-both groups: - - check\_constraints - - enable\_wal\_decoder - - num\_writers - - streaming\_mode - - enable\_raft - Subgroups inherit settings from their parent group, but can override them if set in the subgroup. - jira: BDR-4954 - addresses: 37725 - type: Enhancement - impact: High -- relnote: Subscriber-only node groups have a leader - component: BDR - details: | - Subscriber-only node groups have a leader elected by top-level Raft. There is now a bdr.leader catalog that tracks leadership of subgroups and subscriber-only nodes. If the node that is the leader of a subscriber-only node group goes down or becomes unreachable, a new leader is elected from that group. - jira: BDR-5089 - type: Enhancement - impact: High -- relnote: Optimized topology for subscriber-only nodes via the leader of the subscriber-only node group - component: BDR - details: | - Subscriber-only nodes earlier used to have subscriptions to each data node. Now if optimized topology is enabled, only the leaders of subscriber-only node groups have subscriptions to routing leaders of data node subsgroups. The subscriber only nodegroup leaders route data to other nodes of that subscriber-only nodegroup. This reduces the load on all data nodes so they do not have to send data to all subscriber-only nodes. The GUC `bdr.force_full_mesh=off` enables this optimized topology. This GUC variable is on by default, retaining pre-5.6.0 behavior. - jira: BDR-5214 - type: Enhancement - impact: High -- relnote: Introduce new subscription types to support optimized topology - component: BDR - details: | - New subscription types that forward data from all nodes of the subgroup via a routing leader (mode: l), and those that forward data from the entire cluster via a subscriber-only group leader (mode: w) are introduced. - jira: BDR-5186 - type: Enhancement - impact: High -- relnote: Introduce version number and timestamp for write leader - component: BDR - details: | - A write leader has a version. Every time a new leader is elected, the version is incremented and timestamp noted via Raft. This is to build a foundation for better conflict resolution. - jira: BDR-3589 - type: Enhancement - impact: High -- relnote: Be more restrictive about which index to use during replication for REPLICA IDENTITY FULL tables - component: BDR - details: | - This fixes various index related errors during replication like: - 'could not lookup equality operator for type, optype in opfamily' - or 'function "amgettuple" is not defined for index "brinidx"' - jira: BDR-5523 , BDR-5361 - type: Bug Fix - impact: High -- relnote: Allow use of column reference in DEFAULT expressions - component: BDR - details: | - Using column references in default expressions is now supported, this is particularly - useful with generated columns, for example: - `ALTER TABLE gtest_tableoid ADD COLUMN c regclass GENERATED ALWAYS AS (tableoid) STORED;` - jira: BDR-5385 - type: Enhancement - impact: High -- relnote: Support `createrole_self_grant` - component: BDR - details: | - The `createrole_self_grant` configuration option affects inherited grants - by newly created roles. In previous versions `CREATE ROLE`/`CREATE USER` - replication would not take this into consideration, resulting in different - role privileges on different nodes. - jira: BDR-5403 - type: Bug fix - impact: High -- relnote: Allow `CREATE SCHEMA AUTHORIZATION ...` combined with other create operations - component: BDR - details: | - Previously, this would throw "cannot change current role within security-restricted operation" error - jira: BDR-5368 - type: Bug fix - impact: High -- relnote: Support replication of REINDEX - component: BDR - details: | - Both REINDEX and REINDEX CONCURRENTLY are now replicated commands. - jira: BDR-5363 - type: Enhancement - impact: High -- relnote: Use base type instead of domain type while casting values - component: BDR - details: | - This prevents errors when replicating UPDATEs for domains defined as NOT VALID - where tables contain data which would not be allowed by current definition - of such domain. - jira: BDR-5369 - type: Bug fix - impact: High -- relnote: Fix receiver worker being stuck when exiting - component: BDR - details: | - Receiver worker could get stuck when exiting, waiting for a writer that never - actually started. This could on rare occasions break replication after - configuration changes until Postgres was restarted. - jira: - type: Enhancement - impact: High -- relnote: Reduce performance impact of PGD specific configuration parameters that are sent to client - component: BDR - details: | - Changes to values of variables `bdr.last_committed_lsn`, `transaction_id` - and `bdr.local_node_id` are automatically reported to clients when using - CAMO or GROUP COMMIT. This has now been optimized to use less resources. - jira: BDR-3212 - type: Enhancement - impact: High -- relnote: Allow use of commit scopes defined in parent groups - component: BDR - details: | - When there is a commit scope defined for top-level group, it can be used by - any node in a subgroup and does not need to be redefined for every subgroup - anymore. This is particularly useful when combined with `ORIGIN\_GROUP` - keyword to reduce the complexity of commit scope setup. - jira: BDR-5433 - type: Enhancement - impact: High -- relnote: bdr_pg_upgrade - Create logical slot with twophase set to true for PG 14+ - component: Utilities - jira: BDR-5306 - type: Bug Fix - impact: High -- relnote: Use bdr.bdr_file_settings view in verify-settings - component: PGD CLI - details: | - Use bdr.bdr_file_settings view to get the current settings for the proxy. - jira: BDR-5049 - type: Enhancement - impact: High \ No newline at end of file diff --git a/product_docs/docs/pgd/6/rel_notes/src/relnote_5.6.1.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_5.6.1.yml deleted file mode 100644 index f2722a32ac9..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/src/relnote_5.6.1.yml +++ /dev/null @@ -1,157 +0,0 @@ -# yaml-language-server: $schema=https://raw.githubusercontent.com/EnterpriseDB/docs/refs/heads/develop/tools/automation/generators/relgen/relnote-schema.json -product: EDB Postgres Distributed -version: 5.6.1 -date: 25 November 2024 -components: - "BDR": 5.6.1 - "PGD CLI": 5.6.1 - "PGD Proxy": 5.6.1 - "Utilities": 5.6.1 -intro: | - EDB Postgres Distributed 5.6.1 includes a number of enhancements and bug fixes. -highlights: | - - Postgres 17 support - - ARM64 processor support -relnotes: -- relnote: Added Postgres 17 support - component: BDR - details: | - Support for Postgres 17 has been added for all flavors (PostgreSQL, EDB Postgres Extended, - and EDB Postgres Advanced Server) starting with version 17.2. - jira: BDR-5410 - addresses: "" - type: Feature - impact: High -- relnote: Added ARM64 processor Support - component: BDR - details: | - Support ARM architecture for EDB Postgres Distributed on Debian 12 and RHEL 9. - jira: BDR-5410 - addresses: "" - type: Feature - impact: High -- relnote: Addressed walsender crash that happend during configuration reload. - component: BDR - details: | - Ensure that pglogical GUCs are overridden only when operating within the pglogical worker. - If this is not the case, MyPGLogicalWorker will be NULL, resulting in a segmentation fault - when the walsender attempts a configuration reload from the - pgl_wait_for_standby_confirmation() function. - jira: BDR-5661 - addresses: "42100" - type: Bug-fix - impact: High -- relnote: Fixed unintended eager connection related to consensus connections among Subscriber Only group members - component: BDR - details: | - The msgbroker module used to establish consensus connections lazily, meaning that connections - were created only when the first message was sent to a specific destination. This method - negatively affected the latency of Raft leader elections. The behavior was modified to create - connections to consensus peers eagerly. However, this change resulted in an unintended - consequence: a fully meshed consensus network among subscriber-only nodes, which may conflict - with customer network designs. This patch keeps the eager connection setup but limits it to - voting nodes only, reverting to a lazy connection setup for non-voting nodes. - jira: BDR-5666 - addresses: "42041" - type: Bug-fix - impact: High -- relnote: Fixed autopatition task scheduling. - component: BDR - details: | - To improve reliability, shuffle the scheduling of autopartition tasks. This way, tasks - that are prone to failure won't consistently impact the success of other tasks. - jira: BDR-5638 - addresses: "41998" - type: Bug-fix - impact: High -- relnote: Fixed parting subscription with standbys. - component: BDR - details: | - The parting subscription used to hang, failing to wait for standbys when the - bdr.standby_slot_names parameter was defined. - jira: BDR-5658 - addresses: "41821" - type: Bug-fix - impact: High -- relnote: Added `bdr.wait_node_confirm_lsn()`. - component: BDR - details: | - The function `bdr.wait_node_confirm_lsn()` has been introduced to wait until a specific node - reaches a designated Log Sequence Number (LSN). It first checks the `confirmed_flush_lsn` of - the replication slot for the specified node. If that information is not available, the function - connects to the node and queries `pg_replication_origin_progress()`, using the invoking node as - the origin. - If the `nodename` parameter is NULL, the function will wait for all nodes to reach the specified - LSN. If the `target` LSN is NULL, it will wait for the current `wal_flush_lsn`. - jira: BDR-5200 - addresses: "" - type: Enhancement - impact: High -- relnote: Improvements made in SO Node Management and Progress Tracking. - component: BDR - details: | - An update addresses the movement of group slots in SO nodes, ensuring they don't appear as peers in - progress updates. Improvements include enhanced watermark management for SO leaders in the Optimized Topology - configuration, where write leaders now include watermarks in their updates. Watermarks are broadcasted - to simplify progress tracking on idle clusters. The peer progress mapping for SO nodes has been corrected, - and the tap test for group slot movement has been revised. - Additionally, the `bdr_get_all_origins` function now considers SO node origins. - jira: BDR-5549 - addresses: "" - type: Enhancement - impact: High -- relnote: LSN Progress in Optimized Topology Configurations is now communicated. - component: BDR - details: | - While there are no connections from non-leader data nodes to subscriber-only nodes in an optimized - topology configuration, the LSN progress of all data nodes is periodically communicated to these - subscriber-only nodes through logical replication. - jira: BDR-5549 - addresses: "" - type: Enhancement - impact: High -- relnote: Fixed parting SO node with multiple origins. - component: BDR - details: | - All relevant origins must be removed when parting SO node. - With Optimized Topology, parting an SO node should result in removing all origins it - has, not just the one related to its SO group leader. - When parting a data node, even though there is no subscription to it - from SO node, the origin should be removed. - DO not make SO node target of a part catchup subscription when Optimized Topology is enabled. - jira: BDR-5552 - addresses: "" - type: Bug-fix - impact: High -- relnote: Stopped creation of slots for subscriber only nodes on witness nodes. - component: BDR - details: | - Subscriber only nodes should not have slots on witness nodes. - jira: BDR-5618 - addresses: "" - type: Bug-fix - impact: High -- relnote: Some DDL commands are now allowed by `bdr.permit_unsafe_commands` when set. - component: BDR - details: | - The `bdr.permit_unsafe_commands` parameter now allows some DDL commands that were previously disallowed. Specifically `ALTER COLUMN...TYPE...USING` can now be permitted if the user knows the operation is safe. - jira: "" - addresses: "" - type: Enhancement - impact: High -- relnote: Ensure no waiting for DEGRADE timeout when in an already degraded state. - component: BDR - details: | - When using commit scope with DEGRADE clause, if system detects that it's in degraded state, transactions should start in the DEGRADE mode. This ensures that the timeout is not applied on every commit. - jira: BDR-5651 - addresses: "" - type: Bug-fix - impact: High -- relnote: Fixed routing strategy for read nodes. - component: PGD Proxy - details: | - Corrected routing strategy for read nodes after a network partition. - jira: BDR-5216 - addresses: "" - type: Bug-fix - impact: Medium diff --git a/product_docs/docs/pgd/6/rel_notes/src/relnote_5.7.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_5.7.0.yml deleted file mode 100644 index cf310d475e5..00000000000 --- a/product_docs/docs/pgd/6/rel_notes/src/relnote_5.7.0.yml +++ /dev/null @@ -1,306 +0,0 @@ -# yaml-language-server: $schema=https://raw.githubusercontent.com/EnterpriseDB/docs/refs/heads/develop/tools/automation/generators/relgen/relnote-schema.json -product: EDB Postgres Distributed -version: 5.7.0 -date: 25 February 2025 -updated: 26 March 2025 -components: - "BDR": 5.7.0 - "PGD CLI": 5.7.0 - "PGD Proxy": 5.7.0 - "Utilities": 5.7.0 -intro: | - EDB Postgres Distributed 5.7.0 includes a number of enhancements and bug fixes. -highlights: | - - **Improved 3rd Party CDC Tool Integration**: PGD 5.7.0 now supports [failover of logical slots used by CDC tools](/pgd/latest/cdc-failover) with standard plugins (such as test_decoding, pgoutput, and wal2json) within a PGD cluster. This enhancement eliminates the need for 3rd party subscribers to reseed their tables during a lead Primary change. - - **PGD Compatibility Assessment**: Ensure a seamless migration to PGD with the new [Assess](/pgd/latest/cli/command_ref/assess/) command in the PGD CLI. This tool proactively reports any PostgreSQL incompatibilities—especially those affecting logical replication—so you can address them before upgrading to PGD. - - **Upgrade PGD and Postgres with a Single Command**: Leverage the new [`pgd node upgrade`](/pgd/latest/cli/command_ref/node/upgrade - ) command in the PGD CLI to upgrade a node to the latest versions of PGD and Postgres. - - **Ubuntu 24.04 supported**: PGD 5.7.0 now supports Ubuntu 24.04. (23 March 2025) -relnotes: -- relnote: Improved performance of DML and other operations on partitioned tables. - component: BDR - details: | - Many code paths touching partitioned tables were performing costly checks to support additional table access methods. This code was adjusted to make the most common case (heap) the fastest. - jira: BDR-5860 - addresses: "" - type: Enhancement - impact: Medium -- relnote: Unsupported `ALTER TABLE` command on materialized views is no longer replicated. - component: BDR - details: | - Replication no longer becomes stuck when the command is issued. - jira: BDR-5997 - addresses: "" - type: Bug Fix - impact: Lowest -- relnote: Improved PostgreSQL 17 compatibility. - component: BDR - details: | - Internal tables managed by autopartition that were created before the upgrade to PG17 were missing a `rowtype` entry into `pg_depend`. This issue caused errors after upgrading to PG17. - jira: BDR-5893 - addresses: 44401 - type: Bug Fix - impact: Medium -- relnote: Removed redundant `WARNING` when executing `ALTER SEQUENCE`. - component: BDR - details: | - The message now only appears when creating the sequence. - jira: BDR-6066 - addresses: "" - type: Enhancement - impact: Lowest -- relnote: Fixed a server panic by ensuring that catalog lookups aren't performed in a callback that gets called very late in the commit cycle. - component: BDR - jira: BDR-5832 - addresses: "" - type: Bug Fix - impact: High -- relnote: Fixed an unintentional timed wait for a synchronous logical replication that resulted in unusually high latency for some transactions. - component: BDR - jira: BDR-5809 - addresses: 42273 - type: Bug Fix - impact: High -- relnote: Added support for failover slots for logical replication. - component: BDR - details: | - When a PGD node fails or becomes unavailable, consumers can now continue to consume changes from some other node in the cluster. The feature can be turned on by setting the top group option `failover_slot_scope` to `global`. The consumer needs to handle duplicate transactions, but PGD - guarantees that every transaction is decoded and sent at least once. - jira: BDR-5673, BDR-5925 - addresses: "" - type: Feature - impact: High -- relnote: Ensured that the `remote_commit_time` and `remote_commit_lsn` are properly reported in the conflict reports. - component: BDR - jira: BDR-5808 - addresses: 42273 - type: Feature - impact: High -- relnote: Fixed an issue whereby concurrent joins of subscriber-only nodes occasionally stopped responding. - component: BDR - details: | - A node could end up waiting for the local state of another concurrently joined node to advance, which caused the system to stop responding. - jira: BDR-5789 - addresses: 42964 - type: Feature - impact: Medium -- relnote: Fixed a bug where parting stopped responding with consensus timeout or consensus errors. - component: BDR - details: | - This fix also ensures parting doesn't stop responding when any of the nodes restart when part is in progress. Origin LSNs don't show up as 0/0 in log messages. - jira: BDR-5777 - addresses: 42056 - type: Bug Fix - impact: Medium -- relnote: Fixed a memory leak in a global hook. - component: BDR - details: | - This bug could cause memory to leak even if `bdr.so` is just loaded and the extension isn't installed. - jira: BDR-5821 - addresses: 43678 - type: Bug Fix - impact: Medium -- relnote: Fixed a bug where subgroup member part prevented new nodes from joining. - component: BDR - details: | - This fix ensures that if a subgroup member is parted while Raft subgroup routing is active, then another node can subsequently join that subgroup. - jira: BDR-5781 - addresses: "" - type: Bug Fix - impact: Medium -- relnote: Fixed a case where galloc sequence overflow wasn't being caught correctly. - component: BDR - details: | - This bug resulted in `nextval` call being stuck. - jira: BDR-5930 - addresses: 44755 - type: Bug Fix - impact: Medium -- relnote: Fixed group slot movement for witness and data nodes in presence of subscriber-only nodes and witness nodes. - component: BDR - details: | - For PGD 5.6.0 and later, there are no subscriptions from a subscriber-only node to a witness node. This caused a problem with movement of group slot on data nodes and witness nodes in the presence of subscriber-only nodes in the cluster. This bug could cause WAL to be held on both witness nodes and data nodes when there's a subscriber-only node in the cluster. - jira: BDR-5992 - addresses: - type: Bug Fix - impact: Medium -- relnote: Disallowed `GRANT` on BDR objects to non-BDR users. - component: BDR - jira: BDR-5759 - addresses: "" - type: Bug Fix - impact: Lowest -- relnote: Improved `bdr_init_physical` to be able to run without superuser. - component: BDR - details: | - Now only the `bdr_superuser` is required. - jira: BDR-5231 - addresses: "" - type: Enhancement - impact: Medium -- relnote: Fixed a bug where conflict resolution functions were executed also on the witness nodes. - component: BDR - jira: BDR-5807 - addresses: "" - type: Bug Fix - impact: Medium -- relnote: Fixed a bug to handle additional replication sets on witness nodes. - component: BDR - details: | - The witness node now only cares about the top replication set and thus allows it to miss replications sets and not error out. - jira: BDR-5880 - addresses: "41776, 44527" - type: Bug Fix - impact: Low -- relnote: Improved maintenance of the `bdr.leader` table. - component: BDR - jira: BDR-5703 - addresses: "" - type: Bug Fix - impact: Lowest -- relnote: Narrowed down `bdr.node_slots` output to list only relevant slots. - component: BDR - details: | - The slots are displayed based on the node type, its role, and the cluster topology. - jira: BDR-5253 - addresses: "" - type: Enhancement - impact: High -- relnote: Added `target_type` column to `bdr.node_slots` view to indicate slot purpose/status. - component: BDR - jira: BDR-5253 - addresses: "" - type: Enhancement - impact: High -- relnote: Fixed a bug where `bdr_init_physical` stopped responding when `synchronous_commit` is set to `remote_write/remote_apply`. - component: BDR - details: | - `bdr_init_physical` disables synchronous replication on a new node by resetting `synchronous_standby_names` to an empty string. A warning message reminds you to set `synchronous_standby_names` as needed. - jira: BDR-5918 - addresses: 44760 - type: Bug Fix - impact: Medium -- relnote: Added a GUC to support upgrade to 5.7.0 for clusters with optimized topology (a preview feature). - component: BDR - details: | - An upgrade to 5.7.0 from clusters that have `bdr.force_full_mesh` set to `off` to enable optimized topology - (a preview feature) must first set this GUC to `on` and then upgrade. After the entire cluster upgrades, - this GUC can be set to `off` again to enable optimized topology. - Having this GUC set to `off` during upgrade isn't supported. - jira: BDR-5872 - addresses: "" - type: Other - impact: Low -- relnote: Changed origin deletion to be done asynchronously when optimized topology is enabled. - component: BDR - details: | - In an optimized topology, origin names now use the generation ID of the node. This fixes an inconsistency in which some transactions can be lost or sent twice when a node is parted. - jira: BDR-5872 - addresses: "" - type: Bug Fix - impact: Low -- relnote: Fixed a crash during upgrades in a mixed-version cluster. - component: BDR - details: | - Upgrading from versions earlier than 5.6.0 to 5.6.0 and later in a mixed-version cluster with a standby or a node joining/parting could cause a crash. - jira: BDR-6087 - addresses: "" - type: Bug Fix - impact: Low -- relnote: Added new CLI command structure for easier access. - component: PGD CLI - details: | - The new CLI command structure is more intuitive and easier to use. The new structure is a "noun-verb" format, where the noun is the object you want to work with and the verb is the action you want to perform. Full details are available in [the CLI command reference](/pgd/latest/cli/command_ref). - jira: "" - addresses: "" - type: Feature - impact: High -- relnote: Added new CLI commands for adding removing and updating commit scopes. - component: PGD CLI - details: | - The new commands are `pgd commit-scope show`, `pgd commit-scope create`, `pgd commit-scope update` and `pgd commit-scope drop`. Full details are available in [the CLI command reference](/pgd/latest/cli/command_ref). - jira: "" - addresses: "" - type: Enhancement - impact: Medium -- relnote: Added support for legacy CLI command structure in the updated PGD CLI. - component: PGD CLI - details: | - The legacy CLI command structure is still supported in the updated PGD CLI. The legacy command support is available for a limited time and will be removed in a future release. It is implemented as a wrapper around the new commands. - jira: "" - addresses: "" - type: Enhancement - impact: Medium -- relnote: Added a new local assesment feature for local non-PGD nodes to the CLI - component: PGD CLI - details: | - The new feature allows you to assess the local node for compatibility with PGD. The feature is available as `pgd assess`. Full details are available in [the CLI command reference](/pgd/latest/cli/command_ref). - jira: "" - addresses: "" - type: Feature - impact: High -- relnote: Added `pgd node upgrade` functionality to the PGD CLI. - component: PGD CLI - details: | - The new command allows you to upgrade a node to the latest version of PGD and Postgres. It integrates the operation of `bdr_pg_upgrade` into the CLI and is run locally. See [pgd node upgrade](/pgd/latest/cli/command_ref/node/upgrade) and [inplace upgrades](/pgd/latest/upgrades/inplace_upgrade) for more information. - jira: "" - addresses: "" - type: Feature - impact: High -- relnote: Added new subcommands to PGD CLI `node` and `group` for getting options. - component: PGD CLI - details: | - The new subcommands are `pgd node get-options` and `pgd group get-options`. Full details are available in [the CLI command reference](/pgd/latest/cli/command_ref). - jira: "" - addresses: "" - type: Enhancement - impact: Medium -- relnote: Deprecated proxy commands in new PGD CLI command structure. - component: PGD CLI - details: | - The proxy commands are deprecated in the new CLI command structure. The proxy commands are still available in the legacy CLI command structure. Proxy options can be set using the `pgd group set-option` command. - jira: "" - addresses: "" - type: Deprecation - impact: Medium -- relnote: Added new output formatting options `psql` and `markdown` to the PGD CLI. - component: PGD CLI - details: | - The new options allow you to format the output of the CLI commands in a psql-like or markdown format. Format options are now `json`, `psql`, `modern`, `markdown`, `simple` and defaults to `simple`. - jira: "" - addresses: "" - type: Enhancement - impact: Medium -- relnote: Removed `yaml` output as an option in PGD CLI - component: PGD CLI - details: | - The `yaml` output option is removed from the PGD CLI. The `json` output option is still available. - jira: "" - addresses: "" - type: Deprecation - impact: Low -- relnote: Fixed proxy regression by improving dsn name support for read nodes - component: PGD Proxy - details: | - A regression in the way read nodes were identified in the proxy in 6.5.1 was fixed - by enabling support for different values in the `dsn` field's host and the node_name. - jira: BDR-5795 - addresses: "" - type: Bug Fix - impact: Medium -- relnote: The `bdr.group_camo_details` view now only lists data nodes belonging to the CAMO group. - component: BDR - details: | - The `bdr.group_camo_details` view now only lists data nodes belonging to the CAMO commit scope group. Previously, the view could include data nodes were not part of the CAMO group, logical standby nodes, Subscriber-Only nodes and witness nodes. - jira: BDR-6049 - addresses: 45354 - type: Bug Fix - impact: High -- relnote: Ubuntu 24.04 is now supported. - component: BDR - details: | - Packages are now available for Ubuntu 24.04 for all PGD components. - jira: BDR-5790 - addresses: "" - type: Feature - impact: Medium diff --git a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml new file mode 100644 index 00000000000..981731482ac --- /dev/null +++ b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml @@ -0,0 +1,39 @@ +# yaml-language-server: $schema=https://raw.githubusercontent.com/EnterpriseDB/docs/refs/heads/develop/tools/automation/generators/relgen/relnote-schema.json +product: EDB Postgres Distributed +version: 6.0.0 +date: 1 June 2025 +components: + "BDR": 6.0.0 + "PGD CLI": 6.0.0 + "Utilities": 6.0.0 +intro: | + EDB Postgres Distributed 6.0.0 includes new features, and many enhancements and bug fixes. +highlights: | + - TBD +relnotes: +- relnote: Table rewriting `ALTER TABLE... ALTER COLUMN` calls are now supported. + component: BDR + details: | + Changing a column's type command which causes the whole table to be rewritten and the change isn't binary coercible is now supported: + ```sql + CREATE TABLE foo (c1 int,c2 int, c3 int, c4 box, UNIQUE(c1, c2) INCLUDE(c3,c4)); + ALTER TABLE foo ALTER c1 TYPE bigint; – results into table rewrite + ``` + This also includes support for `ALTER TYPE` when using the `USING` clause: + ```sql + CREATE TABLE foo (id serial primary key,data text); + ALTER TABLE foo ALTER data TYPE BYTEA USING data::bytea; + ``` + Table rewrites can hold an AccessExclusiveLock for extended periods on larger tables. + jira: BDR-5724 + addresses: "" + type: Enhancement + impact: Medium +- relnote: Restrictions on non-immutable `ALTER TABLE... ADD COLUMN` calls have been removed. + component: BDR + details: | + The restrictions on non-immutable `ALTER TABLE... ADD COLUMN` calls have been removed. + jira: BDR-5395 + addresses: "" + type: Enhancement + impact: Medium From 9d3be79a455edd8af5d08068ad7e20cc8e035726 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Mon, 7 Apr 2025 12:26:25 +0000 Subject: [PATCH 006/145] update generated release notes --- product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx index 0ed80b837fc..3150e600159 100644 --- a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx +++ b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx @@ -11,7 +11,7 @@ EDB Postgres Distributed 6.0.0 includes new features, and many enhancements and ## Highlights -- RBD +- TBD ## Enhancements From a88b51bb39aba523587564092254253ff3faf469 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 17 Apr 2025 09:30:58 +0100 Subject: [PATCH 007/145] Cleared out release notes and old pgd proxy docs started connection manager Signed-off-by: Dj Walker-Morgan --- .../6.0/connection-manager/configuring.mdx | 34 +++++ .../docs/pgd/6.0/connection-manager/index.mdx | 7 + .../pgd/6.0/rel_notes/pgd_6.0.0_rel_notes.mdx | 23 ++++ .../pgd/6.0/rel_notes/src/relnote_6.0.0.yml | 16 +++ product_docs/docs/pgd/6/rel_notes/index.mdx | 6 +- .../docs/pgd/6/rel_notes/src/meta.yml | 7 - .../docs/pgd/6/routing/administering.mdx | 51 ------- .../docs/pgd/6/routing/configuration.mdx | 79 ----------- product_docs/docs/pgd/6/routing/index.mdx | 30 ---- .../docs/pgd/6/routing/installing_proxy.mdx | 129 ------------------ .../docs/pgd/6/routing/monitoring.mdx | 61 --------- product_docs/docs/pgd/6/routing/proxy.mdx | 105 -------------- .../raft/01_raft_subgroups_and_tpa.mdx | 114 ---------------- .../raft/02_raft_subgroups_and_pgd_cli.mdx | 36 ----- .../raft/03_migrating_to_raft_subgroups.mdx | 30 ---- .../raft/04_raft_elections_in_depth.mdx | 22 --- .../raft/images/PGD5sequencediagram.png | 3 - .../raft/images/Tmp6NodeRaftSubgroups.png | 3 - .../docs/pgd/6/routing/raft/index.mdx | 45 ------ product_docs/docs/pgd/6/routing/readonly.mdx | 114 ---------------- 20 files changed, 83 insertions(+), 832 deletions(-) create mode 100644 product_docs/docs/pgd/6.0/connection-manager/configuring.mdx create mode 100644 product_docs/docs/pgd/6.0/connection-manager/index.mdx create mode 100644 product_docs/docs/pgd/6.0/rel_notes/pgd_6.0.0_rel_notes.mdx create mode 100644 product_docs/docs/pgd/6.0/rel_notes/src/relnote_6.0.0.yml delete mode 100644 product_docs/docs/pgd/6/routing/administering.mdx delete mode 100644 product_docs/docs/pgd/6/routing/configuration.mdx delete mode 100644 product_docs/docs/pgd/6/routing/index.mdx delete mode 100644 product_docs/docs/pgd/6/routing/installing_proxy.mdx delete mode 100644 product_docs/docs/pgd/6/routing/monitoring.mdx delete mode 100644 product_docs/docs/pgd/6/routing/proxy.mdx delete mode 100644 product_docs/docs/pgd/6/routing/raft/01_raft_subgroups_and_tpa.mdx delete mode 100644 product_docs/docs/pgd/6/routing/raft/02_raft_subgroups_and_pgd_cli.mdx delete mode 100644 product_docs/docs/pgd/6/routing/raft/03_migrating_to_raft_subgroups.mdx delete mode 100644 product_docs/docs/pgd/6/routing/raft/04_raft_elections_in_depth.mdx delete mode 100644 product_docs/docs/pgd/6/routing/raft/images/PGD5sequencediagram.png delete mode 100644 product_docs/docs/pgd/6/routing/raft/images/Tmp6NodeRaftSubgroups.png delete mode 100644 product_docs/docs/pgd/6/routing/raft/index.mdx delete mode 100644 product_docs/docs/pgd/6/routing/readonly.mdx diff --git a/product_docs/docs/pgd/6.0/connection-manager/configuring.mdx b/product_docs/docs/pgd/6.0/connection-manager/configuring.mdx new file mode 100644 index 00000000000..0fc56afdf06 --- /dev/null +++ b/product_docs/docs/pgd/6.0/connection-manager/configuring.mdx @@ -0,0 +1,34 @@ +--- +title: Configuring Connection Manager +description: How to configure Connection Manager +--- + +## Configuring Connection Manager + +Connection Manager takes its configuration from the PGD Group options for the group the node is a member of. + +| Option | Description | +|-----------------------------------|---------------------------------------------------------------------------------------------------------------------------| +| listen_address | which local addresses it should listen on for client connections, defaults to Postgres' listen_address | +| read_write_port | which port to listen on for read-write connections, defaults to Postgres' port + 1000 (usually 6432) | +| read_only_port | which port to listen on for read-only connections, defaults to Postgres' port + 1001 (usually 6433) | +| http_port | which http port to listen for REST API calls (for integration purposes), defaults to Postgres' port + 1002 (usually 6434) | +| use_https | whether http listener should use HTTPS, if enabled, the server certificate is used to TLS | +| read_write_max_client_connections | maximum read-write client connections allowed, defaults to max_connections | +| read_write_max_server_connections | maximum read-write connections that will be opened to server, defaults to max_connections | +| read_only_max_client_connections | maximum read-only client connections allowed, defaults to max_connections | +| read_only_max_server_connections | maximum read-only connections that will be opened to server, defaults to max_connections | +| read_write_consensus_timeout | how long to wait on loss of consensus before read-write connections are no longer accepted | +| read_only_consensus_timeout | how long to wait on loss of consensus before read-only connections are no longer accepted | +| read_write_max_client_connections | maximum read-write client connections allowed, defaults to max_connections | +| read_write_max_server_connections | maximum read-write connections that will be opened to server, defaults to max_connections | +| read_only_max_client_connections | maximum read-only client connections allowed, defaults to max_connections | +| read_only_max_server_connections | maximum read-only connections that will be opened to server, defaults to max_connections | +| read_write_consensus_timeout | how long to wait on loss of consensus before read-write connections are no longer accepted | +| read_only_consensus_timeout | how long to wait on loss of consensus before read-only connections are no longer accepted | + + +## Configuring authentication + +Connection Manager is configured through Postgres's own `pg_hba.conf` file. + diff --git a/product_docs/docs/pgd/6.0/connection-manager/index.mdx b/product_docs/docs/pgd/6.0/connection-manager/index.mdx new file mode 100644 index 00000000000..af39a842aca --- /dev/null +++ b/product_docs/docs/pgd/6.0/connection-manager/index.mdx @@ -0,0 +1,7 @@ +--- +title: Connection Manager +description: How to configure and use PGD's integrated Connection Manager +--- + +PGD 6.0 introduces a new Connection Manager which replaces the previous proxy solution with an integrated approach using a background worker to expose read-write, read-only and http-status network interfaces in PGD. + diff --git a/product_docs/docs/pgd/6.0/rel_notes/pgd_6.0.0_rel_notes.mdx b/product_docs/docs/pgd/6.0/rel_notes/pgd_6.0.0_rel_notes.mdx new file mode 100644 index 00000000000..a579b30fed9 --- /dev/null +++ b/product_docs/docs/pgd/6.0/rel_notes/pgd_6.0.0_rel_notes.mdx @@ -0,0 +1,23 @@ +--- +title: EDB Postgres Distributed 6.0.0 release notes +navTitle: Version 6.0.0 +originalFilePath: product_docs/docs/pgd/6.0/rel_notes/src/relnote_6.0.0.yml +editTarget: originalFilePath +--- + +Released: 15 May 2025 + +EDB Postgres Distributed 6.0.0 is a major update to PGD and sees the introduction on Essential and Extended editions. + +## Highlights + +- Connection Manager replaces PGD Proxy. + +## Features + + + +
DescriptionAddresses
Connection Manager replaces PGD Proxy

The connection manager is a new component that replaces the PGD Proxy. It is responsible for managing connections to the database and routing them to the appropriate nodes in the cluster. The connection manager provides improved performance, scalability, and reliability compared to the previous PGD Proxy.

+
+ + diff --git a/product_docs/docs/pgd/6.0/rel_notes/src/relnote_6.0.0.yml b/product_docs/docs/pgd/6.0/rel_notes/src/relnote_6.0.0.yml new file mode 100644 index 00000000000..990f14d1fa4 --- /dev/null +++ b/product_docs/docs/pgd/6.0/rel_notes/src/relnote_6.0.0.yml @@ -0,0 +1,16 @@ +# yaml-language-server: $schema=https://raw.githubusercontent.com/EnterpriseDB/docs/refs/heads/develop/tools/automation/generators/relgen/relnote-schema.json +product: EDB Postgres Distributed +version: 6.0.0 +date: 15 May 2025 +intro: | + EDB Postgres Distributed 6.0.0 is a major update to PGD and sees the introduction on Essential and Extended editions. +highlights: | + - Connection Manager replaces PGD Proxy. +relnotes: +- relnote: Connection Manager replaces PGD Proxy + details: | + The connection manager is a new component that replaces the PGD Proxy. It is responsible for managing connections to the database and routing them to the appropriate nodes in the cluster. The connection manager provides improved performance, scalability, and reliability compared to the previous PGD Proxy. + jira: BDR-5123 + addresses: "" + type: Feature + impact: High diff --git a/product_docs/docs/pgd/6/rel_notes/index.mdx b/product_docs/docs/pgd/6/rel_notes/index.mdx index 7f86d82ad04..82245054188 100644 --- a/product_docs/docs/pgd/6/rel_notes/index.mdx +++ b/product_docs/docs/pgd/6/rel_notes/index.mdx @@ -13,6 +13,6 @@ editTarget: originalFilePath The EDB Postgres Distributed documentation describes the latest version of EDB Postgres Distributed 6, including minor releases and patches. The release notes provide information on what was new in each release. For new functionality introduced in a minor or patch release, the content also indicates the release that introduced the feature. -| Release Date | EDB Postgres Distributed | BDR extension | PGD CLI | -|---|---|---|---| -| 01 Jun 2025 | [6.0.0](./pgd_6.0.0_rel_notes) | 6.0.0 | 6.0.0 | +| Release Date | EDB Postgres Distributed | +|---|---| +| 15 May 2025 | [6.0.0](./pgd_6.0.0_rel_notes) | diff --git a/product_docs/docs/pgd/6/rel_notes/src/meta.yml b/product_docs/docs/pgd/6/rel_notes/src/meta.yml index ab3bca8f2e0..18245a44d0b 100644 --- a/product_docs/docs/pgd/6/rel_notes/src/meta.yml +++ b/product_docs/docs/pgd/6/rel_notes/src/meta.yml @@ -13,10 +13,3 @@ columns: - 1: label: "EDB Postgres Distributed" key: version-link -- 2: - label: "BDR extension" - key: "$BDR" -- 3: - label: "PGD CLI" - key: "$PGD CLI" -components: [ "BDR", "PGD CLI", "Utilities" ] diff --git a/product_docs/docs/pgd/6/routing/administering.mdx b/product_docs/docs/pgd/6/routing/administering.mdx deleted file mode 100644 index ca8631f0b24..00000000000 --- a/product_docs/docs/pgd/6/routing/administering.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Administering PGD Proxy -navTitle: Administering ---- - -## Switching the write leader - -Switching the write leader is a manual operation that you can perform to change the node that's the write leader. -It can be useful when you want to perform maintenance on the current write leader node or when you want to change the write leader for any other reason. -When changing write leader, there are two modes: `strict` and `fast`. -In `strict` mode, the lag is checked before switching the write leader. It waits until the lag is less than `route_writer_max_lag` before starting the switchover. This is the default. -In `fast` mode, the write leader is switched immediately. -You can also set a timeout parameter to specify the time when the method is strict. (Defaults to 30s) - -!!!Note -The set-leader operation is not a guaranteed operation. If, due to a timeout or for other reasons, the switch to the given target node fails, PGD may elect another node as write leader in its place. This other node can include the current write leader node. PGD always tries to elect a new write leader if the set-leader operation fails. -!!! - -### Using SQL - -You can perform a switchover operation that explicitly changes the node that's the write leader to another node. - -Use the [`bdr.routing_leadership_transfer()`](/pgd/latest/reference/routing#bdrrouting_leadership_transfer) function. - -For example, to switch the write leader to node `node1` in group `group1`, use the following SQL command: - -```sql -SELECT bdr.routing_leadership_transfer('group1', 'node1','strict','10s'); -``` - -This command switches the write leader using `strict` mode and waits for up to 10 seconds for the switchover to complete. Those are default settings, so you can omit them, as follows: - -```sql -SELECT bdr.routing_leadership_transfer('group1', 'node1'); -``` - -### Using PGD CLI - -You can use the [`group set-leader`](/pgd/latest/cli/command_ref/group/set-leader/) command to perform a switchover operation. - -For example, to switch the write leader from node `node1` to node `node2` in group `group1`, use the following command: - -```sh -pgd group group1 set-leader node1 --strict --timeout 10s -``` - -This command switches the write leader using `strict` mode and waits for up to 10 seconds for the switchover to complete in strict mode. Those are default settings, so you can omit them, as follows: - -```sh -pgd group group1 set-leader node1 -``` diff --git a/product_docs/docs/pgd/6/routing/configuration.mdx b/product_docs/docs/pgd/6/routing/configuration.mdx deleted file mode 100644 index 3e11ee0964c..00000000000 --- a/product_docs/docs/pgd/6/routing/configuration.mdx +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: "PGD Proxy configuration" -navTitle: "Configuration" ---- - -## Group-level configuration - -Configuring the routing is done either through SQL interfaces or through -PGD CLI. - -You can enable routing decisions by calling the [`bdr.alter_node_group_option()`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_group_option) function. -For example: - -```text -SELECT bdr.alter_node_group_option('region1-group', 'enable_proxy_routing', 'true') -``` - -You can disable it by setting the same option to `false`. - -Additional group-level options affect the routing decisions: - -- `route_writer_max_lag` — Maximum lag in bytes of the new write candidate to be - selected as write leader. If no candidate passes this, no writer is - selected automatically. -- `route_reader_max_lag` — Maximum lag in bytes for a node to be considered a viable - read-only node (PGD 5.5.0 and later). - -## Node-level configuration - -Set per-node configuration of routing using [`bdr.alter_node_option()`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_option). The -available options that affect routing are: - -- `route_dsn` — The dsn used by proxy to connect to this node. -- `route_priority` — Relative routing priority of the node against other nodes in - the same node group. Used only when electing a write leader. -- `route_fence` — Determines whether the node is fenced from routing. When fenced, the node can't receive connections - from PGD Proxy. It therefore can't become the write leader or be available in the read-only node pool. -- `route_writes` — Determines whether writes can be routed to this node, that is, whether the node - can become write leader. -- `route_reads` — Determines whether read-only connections can be routed to this node (PGD 5.5.0 and later). - -## Proxy-level configuration - -You can configure the proxies using SQL interfaces. - -### Creating and dropping proxy configurations - -You can add a proxy configuration using [`bdr.create_proxy`](/pgd/latest/reference/routing#bdrcreate_proxy). -For example, `SELECT bdr.create_proxy('region1-proxy1', 'region1-group');` -creates the default configuration for a proxy named `region1-proxy1` in the PGD group `region1-group`. - -The name of the proxy given here must be same as the name given in the proxy configuration file. - -You can remove a proxy configuration using `SELECT bdr.drop_proxy('region1-proxy1')`. -Dropping a proxy deactivates it. - -### Altering proxy configurations - -You can configure options for each proxy using the [`bdr.alter_proxy_option()`](/pgd/latest/reference/routing#bdralter_proxy_option) function. - -The available options are: - -- `listen_address` — Address for the proxy to listen on. -- `listen_port` — Port for the proxy to listen on. -- `max_client_conn` — Maximum number of connections for the proxy to accept. -- `max_server_conn` — Maximum number of connections the proxy can make to the - Postgres node. -- `server_conn_timeout` — Connection timeout for server connections. -- `server_conn_keepalive` — Keepalive interval for server connections. -- `consensus_grace_period` — Duration for which proxy continues to route even upon loss -of a Raft leader. If set to `0s`, proxy stops routing immediately. -- `read_listen_address` — Address for the read-only proxy to listen on. -- `read_listen_port` — Port for the read-only proxy to listen on. -- `read_max_client_conn` — Maximum number of connections for the read-only proxy to accept. -- `read_max_server_conn` — Maximum number of connections the read-only proxy can make to the - Postgres node. -- `read_server_conn_keepalive` — Keepalive interval for read-only server connections. -- `read_server_conn_timeout` — Connection timeout for read-only server connections. -- `read_consensus_grace_period` — Duration for which read-only proxy continues to route even upon loss of a Raft leader. diff --git a/product_docs/docs/pgd/6/routing/index.mdx b/product_docs/docs/pgd/6/routing/index.mdx deleted file mode 100644 index 27308c310ab..00000000000 --- a/product_docs/docs/pgd/6/routing/index.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "PGD Proxy" -navTitle: "PGD Proxy" -indexCards: none -description: How to use PGD Proxy to maintain consistent connections to the PGD cluster. -navigation: - - proxy - - installing_proxy - - configuration - - administering - - monitoring - - readonly - - raft ---- - -Managing application connections is an important part of high availability. PGD Proxy offers a way to manage connections to the EDB Postgres Distributed cluster. It acts as a proxy layer between the client application and the Postgres database. - -* [PGD Proxy overview](/pgd/latest/routing/proxy) provides an overview of the PGD Proxy, its processes, and how it interacts with the EDB Postgres Distributed cluster. - -* [Installing the PGD Proxy service](/pgd/latest/routing/installing_proxy) covers installation of the PGD Proxy service on a host. - -* [Configuring PGD Proxy](/pgd/latest/routing/configuration) details the three levels (group, node, and proxy) of configuration on a cluster that control how the PGD Proxy service behaves. - -* [Administering PGD Proxy](/pgd/latest/routing/administering) shows how to switch the write leader and manage the PGD Proxy. - -* [Monitoring PGD Proxy](/pgd/latest/routing/monitoring) looks at how to monitor PGD Proxy through the cluster and at a service level. - -* [Read-only routing](/pgd/latest/routing/readonly) explains how the read-only routing feature in PGD Proxy enables read scalability. - -* [Raft](/pgd/latest/routing/raft) provides an overview of the Raft consensus mechanism used to coordinate PGD Proxy. diff --git a/product_docs/docs/pgd/6/routing/installing_proxy.mdx b/product_docs/docs/pgd/6/routing/installing_proxy.mdx deleted file mode 100644 index 4d0876270da..00000000000 --- a/product_docs/docs/pgd/6/routing/installing_proxy.mdx +++ /dev/null @@ -1,129 +0,0 @@ ---- -title: "Installing PGD Proxy" -navTitle: "Installing PGD Proxy" ---- - -## Installing PGD Proxy - -You can use two methods to install and configure PGD Proxy to manage an EDB Postgres Distributed cluster. The recommended way to install and configure PGD Proxy is to use the EDB Trusted Postgres Architect (TPA) utility for cluster deployment and management. - -### Installing through TPA - -If the PGD cluster is being deployed through TPA, then TPA installs and configures PGD Proxy automatically as per the recommended architecture. If you want to install PGD Proxy on any other node in a PGD cluster, then you need to attach the pgd-proxy role to that instance in the TPA configuration file. Also set the `bdr_child_group` parameter before deploying, as this example shows. See [Trusted Postgres Architect](../deploy-config/deploy-tpa/) for more information. - -```yaml -- Name: proxy-a1 - location: a - node: 4 - role: - - pgd-proxy - vars: - bdr_child_group: group_a - volumes: - - device_name: /dev/sdf - volume_type: none -``` - -#### Configuration - -PGD Proxy connects to the PGD database for its internal operations, like getting proxy options and getting write leader details. Therefore, it needs a list of endpoints/dsn to connect to PGD nodes. PGD Proxy expects these configurations in a local config file `pgd-proxy-config.yml`. Following is a working example of the `pgd-proxy-config.yml` file: - -```yaml -log-level: debug -cluster: - name: cluster-name - endpoints: - - "host=bdr-a1 port=5432 dbname=bdrdb user=pgdproxy" - - "host=bdr-a3 port=5432 dbname=bdrdb user=pgdproxy" - - "host=bdr-a2 port=5432 dbname=bdrdb user=pgdproxy" - proxy: - name: "proxy-a1" -``` - -By default, in the cluster created through TPA, `pgd-proxy-config.yml` is located in the `/etc/edb/pgd-proxy` directory. PGD Proxy searches for `pgd-proxy-config.yml` in the following locations. Precedence order is high to low. - - 1. `/etc/edb/pgd-proxy` (default) - 2. `$HOME/.edb/pgd-proxy` - -If you rename the file or move it to another location, specify the new name and location using the optional `-f` or `--config-file` flag when starting a service. See the [sample service file](#pgd-proxy-service). - -You can set the log level for the PGD Proxy service using the top-level config parameter `log-level`, as shown in the sample config. The valid values for `log-level` are `debug`, `info`, `warn`, and `error`. - -`cluster.endpoints` and `cluster.proxy.name` are mandatory fields in the config file. PGD Proxy always tries to connect to the first endpoint in the list. If it fails, it tries the next endpoint, and so on. - -PGD Proxy uses endpoints given in the local config file only at proxy startup. After that, PGD Proxy retrieves the list of actual endpoints (route_dsn) from the PGD Proxy catalog. Therefore, the node option `route_dsn` must be set for each PGD Proxy node. See [route_dsn](configuration) for more information. - -##### Configuring health check - -PGD Proxy provides [HTTP(S) health check APIs](monitoring/#proxy-health-check). If the health checks are required, you can enable them by adding the following configuration parameters to the pgd-proxy configuration file. By default, it's disabled. - -```yaml -cluster: - name: cluster-name - endpoints: - - "host=bdr-a1 port=5432 dbname=bdrdb user=pgdproxy " - - "host=bdr-a3 port=5432 dbname=bdrdb user=pgdproxy " - - "host=bdr-a2 port=5432 dbname=bdrdb user=pgdproxy " - proxy: - name: "proxy-a1" - endpoint: "host=proxy-a1 port=6432 dbname=bdrdb user=pgdproxy " - http: - enable: true - host: "0.0.0.0" - port: 8080 - secure: false - cert_file: "" - key_file: "" - probes: - timeout: 10s -``` - -You can enable the API by adding the config `cluster.proxy.http.enable: true`. When enabled, an HTTP server listens on the default port, `8080`, with a 10-second `timeout` and no HTTPS support. - -To enable HTTPS, set the config parameter `cluster.proxy.http.secure: true`. If it's set to `true`, you must also set the `cert_file` and `key_file`. - -The `cluster.proxy.endpoint` is an endpoint used by the proxy to connect to the current write leader as part of its checks. When `cluster.proxy.http.enable` is `true`, `cluster.proxy.endpoint` must also be set. It can be the same as BDR node [routing_dsn](configuration), where host is `listen_address` and port is `listen_port` [proxy options](configuration). If required, you can add connection string parameters in this endpoint, like `sslmode`, `sslrootcert`, `user`, and so on. - -#### PGD Proxy user - -The database user specified in the endpoint doesn't need to be a superuser. Typically, in the TPA environment, pgdproxy is an OS user as well as a database user with the bdr_superuser role. - -#### PGD Proxy service - -We recommend running PGD Proxy as a systemd service. The `pgd-proxy` service unit file is located at `/etc/systemd/system/pgd-proxy.service` by default. Following is the sample service file created by TPA: - -```text -[Unit] -Description=PGD Proxy - -[Service] -Type=simple -User=pgdproxy -Group=pgdproxy -Restart=on-failure -RestartSec=1s -ExecStart=/usr/bin/pgd-proxy -f /etc/edb/pgd-proxy/pgd-proxy-config.yml -StandardOutput=syslog -StandardError=syslog -SyslogIdentifier=pgd-proxy - -[Install] -WantedBy=multi-user.target -``` - -Use these commands to manage the `pgd-proxy` service: - -```sh -systemctl status pgd-proxy -systemctl stop pgd-proxy -systemctl restart pgd-proxy -``` - -### Installing manually - -You can manually install PGD Proxy on any Linux machine using `.deb` and `.rpm` packages available from the PGD repository. The package name is `edb-pgd5-proxy`. For example: - -```sh -# for Debian -sudo apt-get install edb-pgd5-proxy -``` diff --git a/product_docs/docs/pgd/6/routing/monitoring.mdx b/product_docs/docs/pgd/6/routing/monitoring.mdx deleted file mode 100644 index d8383e276be..00000000000 --- a/product_docs/docs/pgd/6/routing/monitoring.mdx +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: Monitoring PGD Proxy -navTitle: Monitoring ---- - -You cam monitor proxies at the cluster and group level or at the process level. - -## Monitoring through the cluster - -### Using SQL - -The current configuration of every group is visible in the [`bdr.node_group_routing_config_summary`](/pgd/latest/reference/catalogs-internal#bdrnode_group_routing_config_summary) view. - -The [`bdr.node_routing_config_summary`](/pgd/latest/reference/catalogs-internal#bdrnode_routing_config_summary) view shows current per-node routing configuration. - -[`bdr.proxy_config_summary`](/pgd/latest/reference/catalogs-internal#bdrproxy_config_summary) shows per-proxy configuration. - -## Monitoring at the process level - -### Proxy health check - -PGD Proxy provides the following HTTP(S) health check API endpoints. The API endpoints respond to `GET` requests. You need to enable and configure the endpoints before using them. See [Configuration](installing_proxy#configuring-health-check). - -| Endpoint | Description | -| --- | --- | -| `/health/is-ready` | Checks if the proxy can successfully route connections to the current write leader. | -| `/health/is-live` | Checks if the proxy is running. | -| `/health/is-write-ready` | Checks if the proxy can successfully route connections to the current write leader (PGD 5.5.0 and later). | -| `/health/is-read-only-ready` | Checks if the proxy can successfully route read-only connections (PGD 5.5.0 and later). | - -#### Readiness - -On receiving a valid `GET` request: - -* When in default (write) mode, the proxy checks if it can successfully route connections to the current write leader. -* When in read-only mode, the proxy checks if it can successfully route read-only connections. -* When in any mode, the proxy first checks if it can successfully route connections to the current write leader. If it can, the check is successful. If not, it checks if it can route a read-only connection. If it can, the check is successful. If not, the check fails. - -If the check returns successfully, the API responds with a body containing `true` and an HTTP status code `200 (OK)`. Otherwise, it returns a body containing `false` with the HTTP status code `500 (Internal Server Error)`. - -#### Liveness - -Liveness checks return either `true` with HTTP status code `200 (OK)` or an error. They never return `false` because the HTTP server listening for the request is stopped if the PGD Proxy service fails to start or exits. - -## Proxy log location - -Proxies also write logs to system logging where they can be monitored with other system services. - -### syslog - -- Debian based - `/var/log/syslog` -- Red Hat based - `/var/log/messages` - -Use the `journalctl` command to filter and view logs for troubleshooting PGD Proxy. The following are sample commands for quick reference: - -```sh -journalctl -u pgd-proxy -n100 -f -journalctl -u pgd-proxy --since today -journalctl -u pgd-proxy --since "10 min ago" -journalctl -u pgd-proxy --since "2022-10-20 16:21:50" --until "2022-10-20 16:21:55" -``` \ No newline at end of file diff --git a/product_docs/docs/pgd/6/routing/proxy.mdx b/product_docs/docs/pgd/6/routing/proxy.mdx deleted file mode 100644 index ec697d56914..00000000000 --- a/product_docs/docs/pgd/6/routing/proxy.mdx +++ /dev/null @@ -1,105 +0,0 @@ ---- -title: "EDB Postgres Distributed Proxy overview" -navTitle: "PGD Proxy overview" -indexCards: simple -directoryDefaults: - description: "The PGD Proxy service acts as a proxy layer between the client application and Postgres for your PGD cluster." ---- - - -Especially with asynchronous replication, having a consistent write leader node is -important to avoid conflicts and guarantee availability for the application. - -The two parts to EDB Postgres Distributed's proxy layer are: - -* Proxy configuration and routing information, which is maintained by the PGD consensus mechanism. -* The PGD Proxy service, which is installed on a host. It connects to the PGD cluster, where it reads its configuration and listens for changes to the routing information. - -This layer is normally installed in a highly available configuration (at least two instances of the proxy service per PGD group). - -Once configured, the PGD Proxy service monitors routing changes as decided by the EDB Postgres Distributed cluster. It acts on these changes to ensure that connections are consistently routed to the correct nodes. - -Configuration changes to the PGD Proxy service are made through the PGD cluster. -The PGD Proxy service reads its configuration from the PGD cluster, but the proxy service must be restarted to apply those changes. - -The information about currently selected write and read nodes is visible in -`bdr.node_group_routing_summary`. This is a node-local view: the proxy -always reads from Raft leader to get a current and consistent view. - -## Leader selection - -The write leader is selected by the current Raft leader for the group the proxy is part of. -This could be the Raft leader for a subgroup or leader for the entire cluster. -The leader is selected from candidate nodes that are reachable and meet the criteria based -on the configuration as described in [PGD Proxy cluster configuration](#pgd-proxy-cluster-configuration). To be a viable candidate, the node must have -`route_writes` enabled and `route_fence` disabled and be within `route_writer_max_lag` -(if enabled) from the previous leader. The candidates are ordered by their `route_priority` -in descending order and by the lag from the previous leader in ascending order. - -The new leader selection process is started either when there's no existing leader currently -or when -connectivity is lost to the existing leader. (If there's no existing write leader, it could be because there were no valid candidates or because Raft was down.) - -A node is considered connected if the last Raft protocol message received from the leader -isn't older than Raft election timeout -(see [Internal settings - Raft timeouts](../reference/pgd-settings#internal-settings---raft-timeouts)). - -Since the Raft leader is sending heartbeat 3 times every election timeout limit, the leader -node needs to miss the reply to 3 heartbeats before it's considered disconnected. - -## PGD Proxy cluster configuration - -The PGD cluster always has at least one top-level group and one data group. PGD elects the write leader for each data group that has the `enable_proxy_routing` and `enable_raft` options set to true. - -The cluster also maintains proxy configurations for each group. Each configuration has a name and is associated with a group. You can attach a proxy to a top-level group or data group. You can attach multiple proxies to each group. -When a PGD Proxy service starts running on a host, it has a name in its local configuration file and it connects to a node in a group. From there, it uses the name to look up its complete configuration as stored on the group. - -## PGD Proxy service - -The EDB Postgres Distributed Proxy (PGD Proxy) service is a process that acts as an abstraction layer between the client application and Postgres. It interfaces with the PGD consensus mechanism to get the identity of the current write leader node and redirects traffic to that node. It also optionally supports a read-only mode where it can route read-only queries to nodes that aren't the write leader, improving the overall performance of the cluster. - -PGD Proxy is a TCP layer 4 proxy. - -## How they work together - -Upon starting, PGD Proxy connects to one of the endpoints given in the local config file. It fetches: - -- DB connection information for all nodes. -- Proxy options like listen address, listen port. -- Routing details including the current write leader in default mode, read nodes in read-only mode, or both in any mode. - -The endpoints given in the config file are used only at startup. After that, actual endpoints are taken from the PGD catalog's `route_dsn` field in [`bdr.node_routing_config_summary`](/pgd/latest/reference/catalogs-internal#bdrnode_routing_config_summary). - -PGD manages write leader election. PGD Proxy interacts with PGD to get write leader change events notifications on Postgres notify/listen channels and routes client traffic to the current write leader. PGD Proxy disconnects all existing client connections on write leader change or when write leader is unavailable. Write leader election is a Raft-backed activity and is subject to Raft leader availability. PGD Proxy closes the new client connections if the write leader is unavailable. - -PGD Proxy responds to write leader change events that can be categorized into two modes of operation: *failover* and *switchover*. - -Automatic transfer of write leadership from the current write leader node to a new node in the event of Postgres or operating system crash is called *failover*. PGD elects a new write leader when the current write leader goes down or becomes unresponsive. Once the new write leader is elected by PGD, PGD Proxy closes existing client connections to the old write leader and redirects new client connections to the newly elected write leader. - -User-controlled, manual transfer of write leadership from the current write leader to a new target leader is called *switchover*. Switchover is triggered through the [PGD CLI group set-leader](/pgd/latest/cli/command_ref/group/set-leader/) command. The command is submitted to PGD, which attempts to elect the given target node as the new write leader. Similar to failover, PGD Proxy closes existing client connections and redirects new client connections to the newly elected write leader. This is useful during server maintenance, for example, if the current write leader node needs to be stopped for maintenance like a server update or OS patch update. - -If the proxy is configured to support read-only routing, it can route read-only queries to a pool of nodes that aren't the write leader. The pool of nodes is maintained by the PGD cluster and proxies listen for changes to the pool. When the pool changes, the proxy updates its routing configuration and starts routing read-only queries to the new pool of nodes and disconnecting existing client connections to nodes that have left the pool. - -### Consensus grace period - -PGD Proxy provides the `consensus_grace_period` proxy option that can be used to configure the routing behavior upon loss of a Raft leader. PGD Proxy continues to route to the current write leader (if it's available) for this duration. If the new Raft leader isn't elected during this period, the proxy stops routing. If set to `0s`, PGD Proxy stops routing immediately. - -The main purpose of this option is to allow users to configure the write behavior when the Raft leader is lost. When the Raft leader isn't present in the cluster, it's not always guaranteed that the current write leader seen by the proxy is the correct one. In some cases, like network partition in the following example, it's possible that the two write leaders may be seen by two different proxies attached to the same group, increasing the chances of write conflicts. If this isn't the behavior you want, then you can set the previously mentioned `consensus_grace_period` to 0s. This setting configures the proxy to stop routing and closes existing open connections immediately when it detects the Raft leader is lost. - -#### Network partition example - -Consider a 3-data-node group with a proxy on each data node. In this case, if the current write leader gets network partitioned or isolated, then the data nodes present in the majority partition elect a new write leader. If `consensus_grace_period` is set to a non-zero value, for example, `10s`, then the proxy present on the previous write leader continues to route writes for this duration. - -In this case, if the grace period is kept too high, then writes continue to happen on the two write leaders. This condition increases the chances of write conflicts. - -Having said that, most of the time, upon loss of the current Raft leader, the new Raft leader gets elected by BDR within a few seconds if more than half of the nodes (quorum) are still up. Hence, if the Raft leader is down but the write leader is still up, then proxy can be configured to allow routing by keeping `consensus_grace_period` to a non-zero, positive value. The proxy waits for the Raft leader to get elected during this period before stopping routing. This might be helpful in some cases where availability is more important. - -### Read consensus grace period - -Similar to the `consensus_grace_period`, a `read_consensus_grace_period` option is available for read-only routing. This option can be used to configure the routing behavior upon loss of a Raft leader for read-only queries. PGD Proxy continues to route to the current read nodes for this duration. If the new Raft leader isn't elected during this period, the proxy stops routing read-only queries. If set to `0s`, PGD Proxy stops routing read-only queries immediately. - -### Multi-host connection strings - -The PostgreSQL C client library (libpq) allows you to specify multiple host names in a single connection string for simple failover. This ability is also supported by client libraries (drivers) in some other programming languages. It works well for failing over across PGD Proxy instances that are down or inaccessible. - -If an application connects to a proxy instance that doesn't have access to a write leader, the connection will simply fail. No other hosts in the multi-host connection string will be tried. This behavior is consistent with the behavior of PostgreSQL client libraries with other proxies like HAProxy or pgbouncer. Access to a write leader requires the group the instance is part of has been able to select a write leader for the group. diff --git a/product_docs/docs/pgd/6/routing/raft/01_raft_subgroups_and_tpa.mdx b/product_docs/docs/pgd/6/routing/raft/01_raft_subgroups_and_tpa.mdx deleted file mode 100644 index d43f87bc205..00000000000 --- a/product_docs/docs/pgd/6/routing/raft/01_raft_subgroups_and_tpa.mdx +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: "Creating Raft subgroups using TPA" ---- - -The `TPAexec configure` command enables Raft subgroups if the `--enable_proxy_routing local` option is set. TPA uses the term *locations* to reflect the common use case of subgroups that map to physical/regional domains. When the configuration is generated, the location name given is stored under the generated group name, which is based on the location name. - -## Creating Raft subgroups using TPA - -This example creates a two-location cluster with three data nodes in each location. The nodes in each location are part of a PGD Raft subgroup for the location. - -The top-level group's name is `pgdgroup`. - -The top-level group has two locations: `us_east` and `us_west`. These locations are mapped to two subgroups: `us_east_subgroup` and `us_west_subgroup`. - -Each location has four nodes: three data nodes and a barman backup node. The three data nodes also cohost PGD Proxy. The configuration can be visualized like this: - -![6 Node Cluster with 2 Raft Subgroups](images/Tmp6NodeRaftSubgroups.png) - -The barman nodes don't participate in the subgroup and, by extension, the Raft group. They're therefore not shown. This diagram is a snapshot of a potential state of the cluster with the West Raft group having selected west_1 as write leader and west_2 as its own Raft leader. On the East, east_1 is write leader while east_3 is Raft leader. The entire cluster is contained within the top-level Raft group. There, west_3 is currently Raft leader. - -To create this configuration, you run: - -``` -tpaexec configure pgdgroup --architecture PGD-Always-ON --location-names us_east us_west --data-nodes-per-location 3 --epas 16 --no-redwood --enable_proxy_routing local --hostnames-from hostnames.txt -``` - -Where `hostnames.txt` contains: - -``` -east1 -east2 -east3 -eastbarman -west1 -west2 -west3 -westbarman -``` - -## The configuration file - -The generated `config.yml` file has a `bdr_node_groups` section that contains the top-level group `pgdgroup` and the two subgroups `us_east_subgroup` and `us_west_subgroup`. Each of those subgroups has a location set (`us_east` and `us_west`) and two other options that are set to true: - -- `enable_raft`, which activates the subgroup Raft in the subgroup -- `enable_proxy_routing`, which enables the pgd_proxy routers to route traffic to the subgroup’s write leader - -Here's an example generated by the sample tpaexec command: - - -``` -cluster_vars: - apt_repository_list: [] - bdr_database: bdrdb - bdr_node_group: pgdgroup - bdr_node_groups: - - name: pgdgroup - - name: us_east_subgroup - options: - enable_proxy_routing: true - enable_raft: true - location: us_east - parent_group_name: pgdgroup - - name: us_west_subgroup - options: - enable_proxy_routing: true - enable_raft: true - location: us_west - parent_group_name: pgdgroup - bdr_version: '5' -``` - -Every node instance has an entry in the instances list. In that entry, `bdr_child_group` appears in the variables section, set to the subgroup the node belongs to. Here's an example generated by the sample tpaexec command: - -``` -instances: -- Name: east1 - backup: eastbarman - location: us_east - node: 1 - role: - - bdr - - pgd-proxy - vars: - bdr_child_group: us_east_subgroup - bdr_node_options: - route_priority: 100 -- Name: east2 - location: us_east - node: 2 - role: - - bdr - - pgd-proxy - vars: - bdr_child_group: us_east_subgroup - bdr_node_options: - route_priority: 100 -- Name: east3 - location: us_east - node: 3 - role: - - bdr - - pgd-proxy - vars: - bdr_child_group: us_east_subgroup - bdr_node_options: - route_priority: 100 -- Name: eastbarman - location: us_east - node: 4 - role: - - barman -``` - -The one node in this location that doesn't have a `bdr_child_group` setting is the barman node because it doesn't participate in the Raft decision-making process. diff --git a/product_docs/docs/pgd/6/routing/raft/02_raft_subgroups_and_pgd_cli.mdx b/product_docs/docs/pgd/6/routing/raft/02_raft_subgroups_and_pgd_cli.mdx deleted file mode 100644 index 2942fbdf400..00000000000 --- a/product_docs/docs/pgd/6/routing/raft/02_raft_subgroups_and_pgd_cli.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Working with Raft subgroups and PGD CLI" ---- - -You can view the status of your nodes and subgroups with the [pgd](../../cli/) CLI command. The examples here assume a cluster as configured in [Creating Raft subgroups with TPA](01_raft_subgroups_and_tpa). - -## Viewing nodes with pgd - -The pgd command is `show-nodes`. -```shell -pgd nodes list -__OUTPUT__ -Node Name Group Name Node Kind Join State Node Status ---------- ---------- --------- ---------- ------------ -east1 us_east data ACTIVE Up -east2 us_east data ACTIVE Up -east3 us_east data ACTIVE Up -west1 us_west data ACTIVE Up -west2 us_west data ACTIVE Up -west3 us_west data ACTIVE Up -``` - -## Viewing groups (and subgroups) with pgd - -To show the groups in a PGD deployment, along with their names and some attributes, use the PGD CLI command `groups list.` - -``` -pgd groups list -__OUTPUT__ -Group Name Parent Group Name Group Type Nodes ----------- ----------------- ---------- ----- -pgdgroup global 0 -us_east pgdgroup data 3 -us_west pgdgroup data 3 -``` - diff --git a/product_docs/docs/pgd/6/routing/raft/03_migrating_to_raft_subgroups.mdx b/product_docs/docs/pgd/6/routing/raft/03_migrating_to_raft_subgroups.mdx deleted file mode 100644 index 9b661025c7e..00000000000 --- a/product_docs/docs/pgd/6/routing/raft/03_migrating_to_raft_subgroups.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Migrating to Raft subgroups ---- - -You can introduce Raft subgroups in a running PGD installation. - - -## Migrating to Raft subgroups (using SQL only) - -To enable Raft subgroups to an existing cluster, these configuration steps are needed: - -* Identify the top-level group for all nodes in the PGD cluster. An existing cluster already has a top-level group that all nodes belong to. -* Create a subgroup for each location. Use `bdr.create_node_group` with a `parent_group_name` argument that gives the top-level group as its value. -* Add each node at each location to their location’s subgroup using `bdr.switch_node_group()`. -* Alter each of the location’s subgroups to enable Raft for the group. Use `bdr.alter_node_group_option()`, setting the `enable_raft` option to `true`. - -### Enabling subgroup Raft node group (using SQL only) - -```sql -SELECT bdr.alter_node_group_option('$group_name', 'enable_raft', 'true'); -``` - - \ No newline at end of file diff --git a/product_docs/docs/pgd/6/routing/raft/04_raft_elections_in_depth.mdx b/product_docs/docs/pgd/6/routing/raft/04_raft_elections_in_depth.mdx deleted file mode 100644 index e4bb9d78662..00000000000 --- a/product_docs/docs/pgd/6/routing/raft/04_raft_elections_in_depth.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Raft elections in depth ---- - -The selection of a write leader in PGD relies on PGD's Raft mechanism. The Raft mechanism is completely internal to PGD's BDR Postgres extension and operates transparently. The nodes within a group begin by establishing a Raft leader within the nodes of the group. - -## Node interaction - -With the Raft leader established, the leader then queries the catalog to see if a write leader for proxy routing was designated. - -If no write leader is designated, the Raft leader takes steps to designate a new write leader. The process starts by querying all the nodes in the group to establish their state. The resulting list of nodes is then filtered for ineligible nodes (for example, witness nodes) and prioritized. The first/top entry on the list is then set as the new write leader in the Raft log. - -## Proxy interaction - -All proxies initially connect any data node in their group. This behavior allows them to query the catalog for the current write leader and begin routing connections to that node. - -They connect to the Raft leader and listen for changes to the catalog entry for write leader. When notified of a change in write leader, they reconfigure routing and send connections to the new write leader. - -Both the node and proxy interaction are shown on the following sequence diagram. Two nodes and one proxy are involved, coordinating which node will be write leader and the proxy waiting to learn which node is write leader. - -![Sequence Diagram](images/PGD5sequencediagram.png) - diff --git a/product_docs/docs/pgd/6/routing/raft/images/PGD5sequencediagram.png b/product_docs/docs/pgd/6/routing/raft/images/PGD5sequencediagram.png deleted file mode 100644 index 147b4ac32c0..00000000000 --- a/product_docs/docs/pgd/6/routing/raft/images/PGD5sequencediagram.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:7490ca693b1b776cd49f7c28ed397c7808282f6f21f3e3cea316a3df0940eb65 -size 59400 diff --git a/product_docs/docs/pgd/6/routing/raft/images/Tmp6NodeRaftSubgroups.png b/product_docs/docs/pgd/6/routing/raft/images/Tmp6NodeRaftSubgroups.png deleted file mode 100644 index 9b839191f38..00000000000 --- a/product_docs/docs/pgd/6/routing/raft/images/Tmp6NodeRaftSubgroups.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:ae888b4eb72a94468b7a6b84b39aad08b7a26e3a02bae87cbf7540b932069c1a -size 233200 diff --git a/product_docs/docs/pgd/6/routing/raft/index.mdx b/product_docs/docs/pgd/6/routing/raft/index.mdx deleted file mode 100644 index 6f017cd5739..00000000000 --- a/product_docs/docs/pgd/6/routing/raft/index.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- - -title: Proxies, Raft, and Raft subgroups - ---- - -PGD manages its metadata using a Raft model where a top-level group spans all the data nodes in the PGD installation. A Raft leader is elected by the top-level group and propagates the state of the top-level group to all the other nodes in the group. - -!!! Hint What is Raft? -Raft is an industry-accepted algorithm for making decisions though achieving *consensus* from a group of separate nodes in a distributed system. -!!! - -For certain operations in the top-level group, it's essential that a Raft leader must be both established and connected. Examples of these operations include adding and removing nodes and allocating ranges for [galloc](../../sequences/#pgd-global-sequences) sequences. - -It also means that an absolute majority of nodes in the top-level group (one half of them plus one) must be able to reach each other. So, in a top-level group with five nodes, at least three of the nodes must be reachable by each other to establish a Raft leader. - -## Proxy routing - -One function that also uses Raft is proxy routing. Proxy routing requires that the proxies can coordinate writing to a data node within their group of nodes. This data node is the write leader. If the write leader goes offline, the proxies need to be able to switch to a new write leader, selected by the data nodes, to maintain continuity for connected applications. - -You can configure proxy routing on a per-node group basis in PGD 5, but the recommended configurations are *global* and *local* routing. - -## Global routing - -Global routing uses the top-level group to manage the proxy routing. All writable data nodes (not witness or subscribe-only nodes) in the group are eligible to become write leader for all proxies. Connections to proxies within the top-level group will be routed to data nodes within the top-level group. - -With global routing, there's only one write leader for the entire top-level group. - -## Local routing - -Local routing uses subgroups, often mapped to locations, to manage the proxy routing within the subgroup. Local routing is often used for geographical separation of writes. It's important for them to continue routing even when the top-level consensus is lost. - -That's because PGD allows queries and asynchronous data manipulation (DMLs) to work even when the top-level consensus is lost. But using the top-level consensus, as is the case with global routing, means that new write leaders can't be elected when that consensus is lost. Local groups can't rely on the top-level consensus without adding an independent consensus mechanism and its added complexity. - -PGD 5 introduced subgroup Raft support to elegantly address this issue. Subgroup Raft support allows the subgroups in a PGD top-level group to elect the leaders they need independently. They do this by forming devolved Raft groups that can elect write leaders independent of other subgroups or the top-level Raft consensus. Connections to proxies in the subgroup then route to data nodes within the subgroup. - -With local routing, there's a write leader for each subgroup. - - -## More information - -* [Raft subgroups and TPA](01_raft_subgroups_and_tpa) shows how Raft subgroups can be enabled in PGD when deploying with Trusted Postgres Architect. -* [Raft subgroups and PGD CLI](02_raft_subgroups_and_pgd_cli) shows how the PGD CLI reports on the presence and status of Raft subgroups. -* [Migrating to Raft subgroups](03_migrating_to_raft_subgroups) is a guide to migrating existing installations and enabling Raft subgroups without TPA. -* [Raft elections in depth](04_raft_elections_in_depth) looks in detail at how the write leader is elected using Raft. \ No newline at end of file diff --git a/product_docs/docs/pgd/6/routing/readonly.mdx b/product_docs/docs/pgd/6/routing/readonly.mdx deleted file mode 100644 index 5d4e6013266..00000000000 --- a/product_docs/docs/pgd/6/routing/readonly.mdx +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: Read-only routing with PGD Proxy -navTitle: Read-only routing ---- - -## Background - -By default, PGD Proxy routes connections to the currently selected write leader in the cluster. This allows the write traffic conflicts to be rapidly and consistently resolved. Just routing everything to a single node, the write leader, is a natural fit for traditional high-availability deployments where system throughput is typically limited to the throughput of what a single node can handle. - -But for some use cases, this behavior also means that clients that are only querying the data are also placing a load on the current write leader. It's possible this read-only workload could be equally well served by one of the non-write-leader nodes in the cluster. - - -If you could move traffic that has read-only queries to the non-write leader nodes, you could, at least in theory, handle a throughput which could be a multiple of a single nodes capability. -An approach like this, though, usually requires changes to applications so that they are aware of details of cluster topology and the current node status to detect the write leader. - -## Read-only routing in PGD Proxy - -From PGD 5.5.0, PGD Proxy addresses this requirement to utilize read capacity while minimizing application exposure to the cluster status. It does this by offering a new `read_listen_port` on proxies that complement the existing listen port. Proxies can be configured with either or both of these ports. - -When a proxy is configured with a `read_listen_port`, connections to that particular port are routed to available data nodes that aren't the current write leader. If an application only queries and reads from the database, using a `read_listen_port` ensures that your queries aren't answered by the write leader. - -Because PGD Proxy is a TCP Layer 4 proxy, it doesn't interfere with traffic passing through it. That means that it can't detect attempts to write passing through the `read_listen_port` connections. As it can't distinguish between a SELECT or an INSERT, it's possible to write through a read-only port. - -The active-active nature of PGD means that any write operation will be performed and replicated, and conflict resolution may or may not have to take place. It's up to the application to avoid this and make sure that it uses only `read_listen_ports` for read-only traffic. - -Where available, the problem can be mitigated on the client side by passing [`default_transaction_read_only=on`](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-DEFAULT-TRANSACTION-READ-ONLY) in the connection string or equivalent for the driver in use. - -### Valid read-only nodes - -Only data nodes that aren't the write leader are valid as read-only nodes. For reference, the following node types aren't eligible to be a read-only node: - -* Witness nodes, because they don't contain data -* Logical standbys, because they're standbys and prioritize replicating -* Subscriber-only nodes - -## Creating a proxy configuration - -SQL proxy creation functions in PGD take an optional `proxy_mode` parameter. You can set this parameter to one of the following values: - -* `default` — This is the default value. It creates a proxy that can handle traffic that follows the write leader on port 6432. -* `read-only` — This option creates a read-only proxy that routes traffic to nodes that aren't the write leader. It handles this read-only traffic only on port 6433. -* `any` — This option creates create a proxy that can handle both read-only and write-leader-following traffic on separate ports: 6432 for write-leader-following traffic and 6433 for read-only traffic. - -PGD CLI proxy creation passes the `proxy_mode` value using the `--proxy-mode` flag. - -### Creating a read-only proxy - -#### Using SQL - -To create a new read-only proxy, use the `bdr.create_proxy` function: - -```sql -SELECT bdr.create_proxy('proxy-ro1','group-a','read-only'); -``` - -This command creates a read-only proxy named `proxy-ro1` in group `group-a`. By default, it listens on port 6433 for read-only traffic. - -#### Using PGD CLI - -To create a new read-only proxy, use the `pgd create-proxy` command with the optional `--proxy-mode` flag set to `read-only`: - -```sh -pgd create-proxy --proxy-name proxy-ro1 --node-group group-a --proxy-mode read-only -``` - -## Configuring running proxies - -!!! Note -After changing a proxy's configuration, restart the proxy to make the changes take effect. -!!! - -You activate read-only routing on a proxy by setting the `read_listen_port` option to a port number. This port number is the port on which the proxy will listen for read-only traffic. -If the proxy already has a `listen_port` set, then the proxy will listen on both ports, routing read/write and read-only traffic respectively on each port. -This is equivalent to creating a proxy with `proxy-mode` set to `any`. - -If you set a `read_listen_port` on a proxy and then set the `listen_port` to 0, the proxy listens only on the `read_listen_port` and routes only read-only traffic. -This is equivalent to creating a proxy with `proxy-mode` set to `read-only`. -The configuration elements related to the read/write port are cleared (set to null). - -If you set a `listen_port` on a proxy and then set the `read_listen_port` to 0, the proxy listens only on the `listen_port` and routes only read/write traffic. -This is equivalent to creating a proxy with `proxy-mode` set to `default`. -The configuration elements related to the read-only port are cleared (set to null). - -### Configuring using SQL - -To configure a read-only proxy port on a proxy, use the `bdr.alter_proxy_options` function: - -```sql -SELECT bdr.alter_proxy_options('proxy-a1','read_listen_port','6433'); -``` - -This command configures a read-only proxy port on port 6433 in the proxy-a1 configuration. - -To remove the read-only proxy, set the port to 0: - -```sql -SELECT bdr.alter_proxy_options('proxy-a1','read_listen_port','0'); -``` - -### Configuring using PGD CLI - -To configure a read-only proxy port on a proxy, use the `pgd alter-proxy` command: - -```sh -pgd set-proxy-options --proxy-name proxy-a1 --option read_listen_port=6433 -``` - -This command configures a read-only proxy port on port 6433 in the proxy-a1 configuration. - -To remove the read-only proxy, set the port to 0: - -```sh -pgd set-proxy-options --proxy-name proxy-a1 --option read_listen_port=0 -``` From 3017ae727addeff920e0b2eab801ac649ad0c420 Mon Sep 17 00:00:00 2001 From: Josh Earlenbaugh Date: Wed, 16 Apr 2025 15:31:04 -0400 Subject: [PATCH 008/145] updated compatibility table and upgrades page minimally. --- product_docs/docs/pgd/6/compatibility.mdx | 2 -- product_docs/docs/pgd/6/upgrades/compatibility.mdx | 3 +-- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/product_docs/docs/pgd/6/compatibility.mdx b/product_docs/docs/pgd/6/compatibility.mdx index d8e9893d57f..89e348c855f 100644 --- a/product_docs/docs/pgd/6/compatibility.mdx +++ b/product_docs/docs/pgd/6/compatibility.mdx @@ -16,8 +16,6 @@ The following table shows the major versions of PostgreSQL and each version of E | 16 | [5.3+](/pgd/5.6/) | | | 15 | [5](/pgd/5.6/) | | | 14 | [5](/pgd/5.6/) | [4](/pgd/4/) | -| 13 | [5](/pgd/5.6/) | [4](/pgd/4/) | -| 12 | [5](/pgd/5.6/) | [4](/pgd/4/) | EDB recommends that you use the latest minor version of any Postgres major version with a supported PGD. diff --git a/product_docs/docs/pgd/6/upgrades/compatibility.mdx b/product_docs/docs/pgd/6/upgrades/compatibility.mdx index ac30086652a..ae938f4467f 100644 --- a/product_docs/docs/pgd/6/upgrades/compatibility.mdx +++ b/product_docs/docs/pgd/6/upgrades/compatibility.mdx @@ -2,8 +2,7 @@ title: Compatibility changes --- -Many changes in PGD 5 aren't backward compatible with -PGD 4 or PGD 3.7. +Upgrading BDR from 4.x to 6.x is possible. ## Connection routing From da8b8e073aa59717b560bc1831f97b54a5d42459 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 17 Apr 2025 09:45:59 +0100 Subject: [PATCH 009/145] Finished up updating bdr.stat_activity Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/reference/catalogs-visible.mdx | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/6/reference/catalogs-visible.mdx b/product_docs/docs/pgd/6/reference/catalogs-visible.mdx index 86a001035d2..1734157ad67 100644 --- a/product_docs/docs/pgd/6/reference/catalogs-visible.mdx +++ b/product_docs/docs/pgd/6/reference/catalogs-visible.mdx @@ -892,7 +892,14 @@ for internal PGD bookkeeping. Dynamic activity for each backend or worker process. This contains the same information as [`pg_stat_activity`](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW), except `wait_event` -is set correctly when the wait relates to PGD. +is set correctly when the wait relates to PGD and the following Connection Manager related fields are added: + +| Name | Type | Description | +|------------------------------------|---------|------------------------------------------------------------------------------------------------------------------| +| connection_manager_client_addr | inet | IP address of the client connection | +| connection_manager_client_port | int | The source port of client connected to connection manager (if the connection is done through connection manager) | +| connection_manager_client_hostname | text | Hostname of the client connection (if the connection is done through connection manager) | +| session_read_only | boolean | Whether the session is a read-only; connected to read-only port of the connection manager | ### `bdr.stat_commit_scope` From a62aa6abd9e0cca1a1a35de4d3c5d94ecfcda04d Mon Sep 17 00:00:00 2001 From: Ricardo Ferreira Date: Thu, 17 Apr 2025 17:47:32 +0100 Subject: [PATCH 010/145] Routing (and raft) is enabled by default on datagroups. Changed relevant docs to reflect the new default for `enable_routing` and `enable_raft`. --- .../deploying/07-configure-proxies.mdx | 40 ++++--------------- .../reference/nodes-management-interfaces.mdx | 22 +++++----- 2 files changed, 18 insertions(+), 44 deletions(-) diff --git a/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx index 0bee3e06b9a..b9176256e26 100644 --- a/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx +++ b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx @@ -3,8 +3,8 @@ title: Step 7 - Configure proxies navTitle: Configure proxies deepToC: true redirects: - - /pgd/latest/install-admin/admin-manual/installing/07-configure-proxies/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-manual/installing/07-configure-proxies/ #generated for pgd deploy-config-planning reorg + - /pgd/latest/install-admin/admin-manual/installing/07-configure-proxies/ #generated for pgd deploy-config-planning reorg + - /pgd/latest/admin-manual/installing/07-configure-proxies/ #generated for pgd deploy-config-planning reorg --- ## Configure proxies @@ -21,8 +21,7 @@ It's best practice to configure PGD Proxy for clusters to enable this behavior. To set up a proxy, you need to first prepare the cluster and subgroup the proxies will be working with by: -* Logging in and setting the `enable_raft` and `enable_proxy_routing` node group options to `true` for the subgroup. Use [`bdr.alter_node_group_option`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_group_option), passing the subgroup name, option name, and new value as parameters. -* Create as many uniquely named proxies as you plan to deploy using [`bdr.create_proxy`](/pgd/latest/reference/routing#bdrcreate_proxy) and passing the new proxy name and the subgroup to attach it to. The [`bdr.create_proxy`](/pgd/latest/reference/routing#bdrcreate_proxy) does not create a proxy, but creates a space for a proxy to register itself with the cluster. The space contains configuration values which can be modified later. Initially it is configured with default proxy options such as setting the `listen_address` to `0.0.0.0`. +* Log in and create as many uniquely named proxies as you plan to deploy using [`bdr.create_proxy`](/pgd/latest/reference/routing#bdrcreate_proxy) and passing the new proxy name and the subgroup to attach it to. The [`bdr.create_proxy`](/pgd/latest/reference/routing#bdrcreate_proxy) does not create a proxy, but creates a space for a proxy to register itself with the cluster. The space contains configuration values which can be modified later. Initially it is configured with default proxy options such as setting the `listen_address` to `0.0.0.0`. * Configure proxy routes to each node by setting route_dsn for each node in the subgroup. The route_dsn is the connection string that the proxy should use to connect to that node. Use [`bdr.alter_node_option`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_option) to set the route_dsn for each node in the subgroup. * Create a pgdproxy user on the cluster with a password or other authentication. @@ -44,32 +43,7 @@ Further detail on all these steps is included in the worked example. ## Preparing for proxies -For proxies to function, the `dc1` subgroup must enable Raft and routing. - -Log in to any node in the cluster, using psql to connect to the `bdrdb` database as the enterprisedb user. Execute: - -```sql -SELECT bdr.alter_node_group_option('dc1', 'enable_raft', 'true'); -SELECT bdr.alter_node_group_option('dc1', 'enable_proxy_routing', 'true'); -``` - -You can use the [`bdr.node_group_summary`](/pgd/latest/reference/catalogs-visible#bdrnode_group_summary) view to check the status of options previously set with `bdr.alter_node_group_option()`: - -```sql -SELECT node_group_name, enable_proxy_routing, enable_raft - FROM bdr.node_group_summary - WHERE parent_group_name IS NOT NULL; -__OUTPUT__ - node_group_name | enable_proxy_routing | enable_raft ------------------+----------------------+------------- - dc1 | t | t -(1 row) - -bdrdb=# -``` - - -Next, create a PGD proxy within the cluster using the `bdr.create_proxy` function. +Create a PGD proxy within the cluster using the `bdr.create_proxy` function. This function takes two parameters: the proxy's unique name and the group you want it to be a proxy for. In this example, you want a proxy on each host in the `dc1` subgroup: @@ -94,7 +68,7 @@ __OUTPUT__ bdrdb=# ``` - + ## Create a pgdproxy user on the database Create a user named pgdproxy and give it a password. This example uses `proxysecret`. @@ -238,7 +212,7 @@ When running, it shows `Active: (running)` in the opening details. ## Test the proxy -At this point, connecting to the PGD Proxy port on any host in the cluster results in the connection being routed to the current write lead node. +At this point, connecting to the PGD Proxy port on any host in the cluster results in the connection being routed to the current write lead node. For example, and assuming you've installed the proxy on all three hosts, then connecting to the proxy on host-three results in the connection being routed to node-one. @@ -265,7 +239,7 @@ __OUTPUT__ bdrdb# ``` -You should have connected to the current write leader of the subgroup. +You should have connected to the current write leader of the subgroup. You can confirm that by querying which node is the write leader for the subgroup you're connected to: ```sql diff --git a/product_docs/docs/pgd/6/reference/nodes-management-interfaces.mdx b/product_docs/docs/pgd/6/reference/nodes-management-interfaces.mdx index bb0d052fe90..01a886cd6d0 100644 --- a/product_docs/docs/pgd/6/reference/nodes-management-interfaces.mdx +++ b/product_docs/docs/pgd/6/reference/nodes-management-interfaces.mdx @@ -28,7 +28,7 @@ bdr.alter_node_group_option(node_group_name text, `config_value` is parsed into the data type appropriate for the option. -The table shows the group options that can be changed using this function. +The table shows the group options that can be changed using this function. | Name | Type | Description | |---------------------------|------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| @@ -36,7 +36,7 @@ The table shows the group options that can be changed using this function. | `check_constraints` | `boolean` | Whether the apply process checks the constraints when writing replicated data. We recommend keeping the default value or you risk data loss. Valid values are `on` or `off`. Default is `on`. | | `default_commit_scope` | `text` | The commit scope to use by default, initially the `local` commit scope. This option applies only to the top-level node group. You can use individual rules for different origin groups of the same commit scope. See [Origin groups](../commit-scopes/origin_groups) for more details. | | `enable_proxy_routing` | `boolean` | Where [`pgd-proxy`](../routing/proxy) through the group leader is enabled for given group. Valid values are `on` or `off`. Default is `off`. | -| `enable_raft` | `boolean` | Whether group has its own Raft consensus. This option is necessary for setting `enable_proxy_routing` to `on`. This option is always `on` for the top-level group. Valid values are `on` or `off`. Default is `off` for subgroups. | +| `enable_raft` | `boolean` | Whether group has its own Raft consensus. This option is necessary for setting `enable_proxy_routing` to `on`. Valid values are `on` or `off`. Default is `on` for datagroups. | | `enable_wal_decoder` | `boolean` | Enables/disables the decoding worker process. You can't enable the decoding worker process if `streaming_mode` is already enabled. Valid values are `on` or `off`. Default is `off`. | | `location` | `text` | Information about group location. This option is purely metadata for monitoring. Default is `''` (empty string). | | `num_writers` | `integer` | Number of parallel writers for the subscription backing this node group. Valid values are `-1` or a positive integer. `-1` means the value specified by the GUC [`bdr.writers_per_subscription`](pgd-settings#bdrwriters_per_subscription) is used. `-1` is the default. | @@ -127,7 +127,7 @@ The node options you can change using this function are: ## `bdr.alter_subscription_enable` -Enables either the specified subscription or all the subscriptions of the local PGD node. +Enables either the specified subscription or all the subscriptions of the local PGD node. This is also known as resume subscription. No error is thrown if the subscription is already enabled. Returns the number of subscriptions affected by this operation. @@ -159,9 +159,9 @@ by a background process after the transaction has committed. ## `bdr.alter_subscription_disable` -Disables either the specified subscription or all the subscriptions of the local PGD node. -Optionally, it can also immediately stop all the workers associated with the disabled subscriptions. -This is also known as pause subscription. +Disables either the specified subscription or all the subscriptions of the local PGD node. +Optionally, it can also immediately stop all the workers associated with the disabled subscriptions. +This is also known as pause subscription. No error is thrown if the subscription is already disabled. Returns the number of subscriptions affected by this operation. @@ -229,8 +229,8 @@ the transaction. ## `bdr.create_node_group` -Creates a PGD node group. -By default, the local node joins the group as the only member. +Creates a PGD node group. +By default, the local node joins the group as the only member. You can add more nodes to the group with [`bdr.join_node_group()`](#bdrjoin_node_group). ### Synopsis @@ -282,7 +282,7 @@ bdr.drop_node_group(node_group_name text) ### Notes This function passes a request to the group consensus mechanism to drop the group. -The function isn't transactional. The dropping process happens in the background, and you can't roll it back. +The function isn't transactional. The dropping process happens in the background, and you can't roll it back. ## `bdr.join_node_group` @@ -463,7 +463,7 @@ The changes made are replicated globally by the consensus mechanism. The function isn't transactional. The switching process happens in the background and you can't roll it back. The changes are visible only to the local transaction if `wait_for_completion` was set to `true` or by calling `bdr.wait_for_join_completion` later. -The local node changes membership from its current subgroup to another subgroup in the same PGD node group without needing to part the cluster. +The local node changes membership from its current subgroup to another subgroup in the same PGD node group without needing to part the cluster. The node's kind must match that of existing nodes in the target subgroup. Node switching doesn't hold any locks in the PGD group. @@ -499,7 +499,7 @@ Changes the configuration parameters of an existing PGD group. Options with NULL value (default for all of them) aren't modified. !!! Warning - This function exists only for compatibility with PGD4 and 3.7. + This function exists only for compatibility with PGD4 and 3.7. Use [`bdr.alter_node_group_option`](#bdralter_node_group_option) instead. ### Synopsis From fc967e7823d97438941bfcf9607eea0a5729caf1 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Tue, 22 Apr 2025 15:38:24 +0000 Subject: [PATCH 011/145] update generated release notes --- product_docs/docs/pgd/6/rel_notes/index.mdx | 4 ++-- product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/product_docs/docs/pgd/6/rel_notes/index.mdx b/product_docs/docs/pgd/6/rel_notes/index.mdx index 82245054188..70d827f7faa 100644 --- a/product_docs/docs/pgd/6/rel_notes/index.mdx +++ b/product_docs/docs/pgd/6/rel_notes/index.mdx @@ -5,7 +5,7 @@ description: Release notes for EDB Postgres Distributed 6 and later indexCards: none navigation: - pgd_6.0.0_rel_notes -originalFilePath: product_docs/docs/pgd/6.0/rel_notes/src/meta.yml +originalFilePath: product_docs/docs/pgd/6/rel_notes/src/meta.yml editTarget: originalFilePath --- @@ -15,4 +15,4 @@ The EDB Postgres Distributed documentation describes the latest version of EDB P | Release Date | EDB Postgres Distributed | |---|---| -| 15 May 2025 | [6.0.0](./pgd_6.0.0_rel_notes) | +| 01 Jun 2025 | [6.0.0](./pgd_6.0.0_rel_notes) | diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx index 3150e600159..2c68d0dbc1f 100644 --- a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx +++ b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx @@ -1,7 +1,7 @@ --- title: EDB Postgres Distributed 6.0.0 release notes navTitle: Version 6.0.0 -originalFilePath: product_docs/docs/pgd/6.0/rel_notes/src/relnote_6.0.0.yml +originalFilePath: product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml editTarget: originalFilePath --- @@ -15,8 +15,8 @@ EDB Postgres Distributed 6.0.0 includes new features, and many enhancements and ## Enhancements - - - - - + + + - + - + - + - + @@ -62,42 +62,42 @@ Not all server features work with all commit scopes. This table shows the ones t ## Commit scope/commit scope interoperability -Although you can't mix commit scopes, you can [combine rules](../commit-scopes/commit-scope-rules/#combining-rules) with an `AND` operator. This table shows where commit scopes can be combined. +Although you can't mix commit scopes, you can [combine rules](/pgd/latest/reference/commit-scopes/commit-scope-rules/#combining-rules) with an `AND` operator. This table shows where commit scopes can be combined.
ComponentVersionDescriptionAddresses
BDR6.0.0
Table rewriting ALTER TABLE... ALTER COLUMN calls are now supported.

Changing a column's type command which causes the whole table to be rewritten and the change isn't binary coercible is now supported:

+ + -
DescriptionAddresses
Table rewriting ALTER TABLE... ALTER COLUMN calls are now supported.

Changing a column's type command which causes the whole table to be rewritten and the change isn't binary coercible is now supported:

CREATE TABLE foo (c1 int,c2 int, c3 int, c4 box, UNIQUE(c1, c2) INCLUDE(c3,c4));
 ALTER TABLE foo ALTER c1 TYPE bigint; – results into table rewrite
@@ -26,7 +26,7 @@ ALTER TABLE foo ALTER data TYPE BYTEA USING data::bytea;

Table rewrites can hold an AccessExclusiveLock for extended periods on larger tables.

BDR6.0.0
Restrictions on non-immutable ALTER TABLE... ADD COLUMN calls have been removed.

The restrictions on non-immutable ALTER TABLE... ADD COLUMN calls have been removed.

+
Restrictions on non-immutable ALTER TABLE... ADD COLUMN calls have been removed.

The restrictions on non-immutable ALTER TABLE... ADD COLUMN calls have been removed.

From e3f70dd85d42a5c4f9494b494c260341a3df60c0 Mon Sep 17 00:00:00 2001 From: Ian Barwick Date: Tue, 22 Apr 2025 17:28:14 +0900 Subject: [PATCH 012/145] PGD: remove reference to "pause_in_standby" This deprecated parameter was removed from function bdr.join_node_group() in PGD 6. DOCS-1449. --- product_docs/docs/pgd/6/nodes/logical_standby_nodes.mdx | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/product_docs/docs/pgd/6/nodes/logical_standby_nodes.mdx b/product_docs/docs/pgd/6/nodes/logical_standby_nodes.mdx index a18d28fe430..2e318f3464d 100644 --- a/product_docs/docs/pgd/6/nodes/logical_standby_nodes.mdx +++ b/product_docs/docs/pgd/6/nodes/logical_standby_nodes.mdx @@ -14,11 +14,14 @@ A master node can have zero, one, or more logical standby nodes. location is always preferred. Logical standby nodes are nodes that are held in a state of continual recovery, -constantly updating until they're required. This behavior is similar to how Postgres physical standbys operate while using logical replication for better performance. [`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) has the `pause_in_standby` -option to make the node stay in halfway-joined as a logical standby node. +constantly updating until they're required. This behavior is similar to how Postgres physical +standbys operate, while using logical replication for better performance. Logical standby nodes receive changes but don't send changes made locally to other nodes. +A logical standby is created by specifying the `node_kind` as `standby` when creating +the node with [`bdr.create_node`](/pgd/latest/reference/nodes-management-interfaces#bdrpromote_node). + Later, if you want, use [`bdr.promote_node`](/pgd/latest/reference/nodes-management-interfaces#bdrpromote_node) to move the logical standby into a full, normal send/receive node. From eea4bd34a4b0f88684913b9e896b43941d1b35ab Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan <126472455+djw-m@users.noreply.github.com> Date: Thu, 24 Apr 2025 09:22:53 +0000 Subject: [PATCH 013/145] Fixed reference --- .../docs/pgd/6/reference/nodes-management-interfaces.mdx | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/nodes-management-interfaces.mdx b/product_docs/docs/pgd/6/reference/nodes-management-interfaces.mdx index 01a886cd6d0..d9a45887a29 100644 --- a/product_docs/docs/pgd/6/reference/nodes-management-interfaces.mdx +++ b/product_docs/docs/pgd/6/reference/nodes-management-interfaces.mdx @@ -294,7 +294,6 @@ Joins the local node to an already existing PGD group. bdr.join_node_group ( join_target_dsn text, node_group_name text DEFAULT NULL, - pause_in_standby boolean DEFAULT NULL, wait_for_completion boolean DEFAULT true, synchronize_structure text DEFAULT 'all' ) @@ -308,19 +307,13 @@ bdr.join_node_group ( | `node_group_name` | Optional name of the PGD group. Defaults to NULL, which tries to detect the group name from information present on the source node. | | `wait_for_completion` | Wait for the join process to complete before returning. Defaults to `true`. | | `synchronize_structure` | Specifies whether to perform database structure (schema) synchronization during the join. `all`, the default setting, synchronizes the complete database structure. `none` does not synchronize any structure. However, data will still be synchronized, meaning the database structure must already be present on the joining node. Note that by design, neither schema nor data will ever be synchronized to witness nodes. | -| `pause_in_standby` | Optionally tells the join process to join only as a logical standby node, which can be later promoted to a full member. This option is deprecated and will be disabled or removed in future versions of PGD. | - -!!! Warning - `pause_in_standby` is deprecated since BDR 5.0. The recommended way to create - a logical standby is to set `node_kind` to `standby` when creating the node - with [`bdr.create_node`](#bdrcreate_node). If `wait_for_completion` is specified as `false`, the function call returns as soon as the joining procedure starts. You can see the progress of the join in the log files and the [`bdr.event_summary`](/pgd/latest/reference/catalogs-internal#bdrevent_summary) information view. You can call the function [`bdr.wait_for_join_completion()`](#bdrwait_for_join_completion) after `bdr.join_node_group()` to wait for the join operation to complete. -It can emit progress information if called with `verbose_progress` set to `true`. +It can emit progress information if [`bdr.wait_for_join_completion()`](#bdrwait_for_join_completion) is called with `verbose_progress` set to `true`. ### Notes From 67d607a82959dad3473a8724c39f3959611e5ad0 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 17 Apr 2025 13:42:21 +0100 Subject: [PATCH 014/145] reference format fixes Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/reference/catalogs-visible.mdx | 83 +- product_docs/docs/pgd/6/reference/index.json | 752 +++++++++--------- product_docs/docs/pgd/6/reference/index.mdx | 5 + 3 files changed, 458 insertions(+), 382 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/catalogs-visible.mdx b/product_docs/docs/pgd/6/reference/catalogs-visible.mdx index 1734157ad67..c45ca693be8 100644 --- a/product_docs/docs/pgd/6/reference/catalogs-visible.mdx +++ b/product_docs/docs/pgd/6/reference/catalogs-visible.mdx @@ -894,6 +894,8 @@ Dynamic activity for each backend or worker process. This contains the same information as [`pg_stat_activity`](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW), except `wait_event` is set correctly when the wait relates to PGD and the following Connection Manager related fields are added: +### `bdr.stat_activity` additional columns + | Name | Type | Description | |------------------------------------|---------|------------------------------------------------------------------------------------------------------------------| | connection_manager_client_addr | inet | IP address of the client connection | @@ -936,6 +938,71 @@ A view of information about the current use of commit scopes by backends. | waiting_commit_confirmations| integer | The number of COMMIT confirmations that are still needed by the operation | waiting_lsn_confirmations| integer | The number of LSN confirmations that are still needed by the operation +### `bdr.stat_connection_manager` + +A view contianing statistics for the connection manager on this node. + +#### `bdr.stat_connection_manager` columns + +| Column | Type | Description | +|------------------|--------|-----------------------------------------| +| ntotal_rw_conns | bigint | Total number of read-write connections | +| ntotal_ro_conns | bigint | Total number of read-only connections | +| nactive_rw_conns | int | Number of active read-write connections | +| nactive_ro_conns | int | Number of active read-only connections | + +### `bdr.stat_connection_manager_connections` + +A view containing information about the connections to the connection manager. + +#### `bdr.stat_connection_manager_connections` columns + +| Column | Type | Description | +|-------------------------------|--------|---------------------------------------------------------------------------------------------------------| +| connection_manager_client_addr | text |IP address of the client connected to the connection manager. | +| connection_manager_client_port | int | TCP port number that the client is using for communication with the connection manager. | +| connection_manager_addr | text | IP address of the connection manager node. | +| connection_manager_port | int | TCP port number that the connection manager is using to communicate with the Postgres node. | +| session_read_only | boolean| Whether the session is read-only or not. | +| client_uses_tls | boolean| Whether the client is using TLS to connect to the connection manager node, or not. | + +### `bdr.stat_connection_manager_node_stats` + +A view containing information about server connection statistics for the connection manager on this node. + +#### `bdr.stat_connection_manager_node_stats` columns + +| Column | Type | Description | +|----------------------|---------|--------------------------------------------------------| +| node_id | oid | OID of the node | +| node_name | name | Name of the node | +| route_rw_connections | boolean | Whether read-write connections are routed to this node | +| route_ro_connections | boolean | Whether read-only connections are routed to this node | +| ntotal_rw_conns | bigint | Total number of read-write connections | +| ntotal_ro_conns | bigint | Total number of read-only connections | +| nactive_rw_conns | int | Number of active read-write connections | +| nactive_ro_conns | int | Number of active read-only connections | + +### `bdr.stat_connection_manager_hba_file_rules` + +A view that shows only the only valid and supported rules the connection manager is using from the HBA file (pg_hba.conf) and information about those rules. + +#### `bdr.stat_connection_manager_hba_file_rules` columns + +| Column | Type | Description | +|--------------|---------|----------------------------------------------------------------------------------------------------------------------| +| rule_number | integer | Rule number. This indicates the order in which each rule is considered until a match is found during authentication. | +| file_name | text | Name of the file containing this rule. | +| line_number | integer | Line number of this rule in the file referenced in file_name. | +| type | text | Type of connection. | +| database | text[] | List of database names this rule applies to. | +| user_name | text[] | List of user names this rule applies to | +| address | text | Host name or IP address, or one of all, samehost, or samenet, or null for local connections. | +| netmask | text | IP address mask, or null if not applicable. | +| auth_method | text | Authentication method. | +| auth_options | text | Options specified for authentication method, if any. | + + ### `bdr.stat_raft_followers_state` A view of the state of the raft leader's followers on the Raft leader node (empty on other nodes). @@ -944,14 +1011,14 @@ A view of the state of the raft leader's followers on the Raft leader node (empt | Column | Type | Description | | ------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | -| group_name | name | The group this information is for (each group can have a separate consensus configured) -| node_name | name | Name of the follower node -| sent_commit_index | bigint | Latest Raft index sent to the follower node -| match_index | bigint | Raft index we expect to match the next response from the follower node -| last_message_time | timestamp with time zone | Last message (any, including requests) seen from the follower node -| last_heartbeat_send_time| timestamp with time zone| Last time the leader sent heartbeat to the follower node -| last_heartbeat_response_time| Lasat time the leader has seen a heartbeat response from the follower node -| approx_clock_drift_ms| bigint | Approximate clock drift seen by the leader against the follower node in milliseconds +| group_name | name | The group this information is for (each group can have a separate consensus configured). +| node_name | name | Name of the follower node. +| sent_commit_index | bigint | Latest Raft index sent to the follower node. +| match_index | bigint | Raft index we expect to match the next response from the follower node. +| last_message_time | timestamp with time zone | Last message (any, including requests) seen from the follower node. +| last_heartbeat_send_time| timestamp with time zone| Last time the leader sent heartbeat to the follower node. +| last_heartbeat_response_time| timestamp with time zone | Last time the leader has seen a heartbeat response from the follower node. +| approx_clock_drift_ms| bigint | Approximate clock drift seen by the leader against the follower node in milliseconds. ### `bdr.stat_raft_state` diff --git a/product_docs/docs/pgd/6/reference/index.json b/product_docs/docs/pgd/6/reference/index.json index cfee353bdf6..7b48fd0ad9e 100644 --- a/product_docs/docs/pgd/6/reference/index.json +++ b/product_docs/docs/pgd/6/reference/index.json @@ -1,376 +1,380 @@ { - "bdrcamo_decision_journal": "/pgd/5.8/reference/catalogs-visible#bdrcamo_decision_journal", - "bdrcommit_scopes": "/pgd/5.8/reference/catalogs-visible#bdrcommit_scopes", - "bdrconflict_history": "/pgd/5.8/reference/catalogs-visible#bdrconflict_history", - "bdrconflict_history_summary": "/pgd/5.8/reference/catalogs-visible#bdrconflict_history_summary", - "bdrconsensus_kv_data": "/pgd/5.8/reference/catalogs-visible#bdrconsensus_kv_data", - "bdrcrdt_handlers": "/pgd/5.8/reference/catalogs-visible#bdrcrdt_handlers", - "bdrddl_replication": "/pgd/5.8/reference/pgd-settings#bdrddl_replication", - "bdrdepend": "/pgd/5.8/reference/catalogs-visible#bdrdepend", - "bdrfailover_replication_slots": "/pgd/5.8/reference/catalogs-visible#bdrfailover_replication_slots", - "bdrglobal_consensus_journal": "/pgd/5.8/reference/catalogs-visible#bdrglobal_consensus_journal", - "bdrglobal_consensus_journal_details": "/pgd/5.8/reference/catalogs-visible#bdrglobal_consensus_journal_details", - "bdrglobal_consensus_response_journal": "/pgd/5.8/reference/catalogs-visible#bdrglobal_consensus_response_journal", - "bdrglobal_lock": "/pgd/5.8/reference/catalogs-visible#bdrglobal_lock", - "bdrglobal_locks": "/pgd/5.8/reference/catalogs-visible#bdrglobal_locks", - "bdrgroup_camo_details": "/pgd/5.8/reference/catalogs-visible#bdrgroup_camo_details", - "bdrgroup_raft_details": "/pgd/5.8/reference/catalogs-visible#bdrgroup_raft_details", - "bdrgroup_replslots_details": "/pgd/5.8/reference/catalogs-visible#bdrgroup_replslots_details", - "bdrgroup_subscription_summary": "/pgd/5.8/reference/catalogs-visible#bdrgroup_subscription_summary", - "bdrgroup_versions_details": "/pgd/5.8/reference/catalogs-visible#bdrgroup_versions_details", - "bdrleader": "/pgd/5.8/reference/catalogs-visible#bdrleader", - "bdrlocal_consensus_snapshot": "/pgd/5.8/reference/catalogs-visible#bdrlocal_consensus_snapshot", - "bdrlocal_consensus_state": "/pgd/5.8/reference/catalogs-visible#bdrlocal_consensus_state", - "bdrlocal_node": "/pgd/5.8/reference/catalogs-visible#bdrlocal_node", - "bdrlocal_node_summary": "/pgd/5.8/reference/catalogs-visible#bdrlocal_node_summary", - "bdrlocal_sync_status": "/pgd/5.8/reference/catalogs-visible#bdrlocal_sync_status", - "bdrnode": "/pgd/5.8/reference/catalogs-visible#bdrnode", - "bdrnode_catchup_info": "/pgd/5.8/reference/catalogs-visible#bdrnode_catchup_info", - "bdrnode_catchup_info_details": "/pgd/5.8/reference/catalogs-visible#bdrnode_catchup_info_details", - "bdrnode_conflict_resolvers": "/pgd/5.8/reference/catalogs-visible#bdrnode_conflict_resolvers", - "bdrnode_group": "/pgd/5.8/reference/catalogs-visible#bdrnode_group", - "bdrnode_group_replication_sets": "/pgd/5.8/reference/catalogs-visible#bdrnode_group_replication_sets", - "bdrnode_group_summary": "/pgd/5.8/reference/catalogs-visible#bdrnode_group_summary", - "bdrnode_local_info": "/pgd/5.8/reference/catalogs-visible#bdrnode_local_info", - "bdrnode_log_config": "/pgd/5.8/reference/catalogs-visible#bdrnode_log_config", - "bdrnode_peer_progress": "/pgd/5.8/reference/catalogs-visible#bdrnode_peer_progress", - "bdrnode_replication_rates": "/pgd/5.8/reference/catalogs-visible#bdrnode_replication_rates", - "bdrnode_slots": "/pgd/5.8/reference/catalogs-visible#bdrnode_slots", - "bdrnode_summary": "/pgd/5.8/reference/catalogs-visible#bdrnode_summary", - "bdrqueue": "/pgd/5.8/reference/catalogs-visible#bdrqueue", - "bdrreplication_set": "/pgd/5.8/reference/catalogs-visible#bdrreplication_set", - "bdrreplication_set_table": "/pgd/5.8/reference/catalogs-visible#bdrreplication_set_table", - "bdrreplication_set_ddl": "/pgd/5.8/reference/catalogs-visible#bdrreplication_set_ddl", - "bdrreplication_sets": "/pgd/5.8/reference/catalogs-visible#bdrreplication_sets", - "bdrschema_changes": "/pgd/5.8/reference/catalogs-visible#bdrschema_changes", - "bdrsequence_alloc": "/pgd/5.8/reference/catalogs-visible#bdrsequence_alloc", - "bdrsequences": "/pgd/5.8/reference/catalogs-visible#bdrsequences", - "bdrstat_activity": "/pgd/5.8/reference/catalogs-visible#bdrstat_activity", - "bdrstat_commit_scope": "/pgd/5.8/reference/catalogs-visible#bdrstat_commit_scope", - "bdrstat_commit_scope_state": "/pgd/5.8/reference/catalogs-visible#bdrstat_commit_scope_state", - "bdrstat_raft_followers_state": "/pgd/5.8/reference/catalogs-visible#bdrstat_raft_followers_state", - "bdrstat_raft_state": "/pgd/5.8/reference/catalogs-visible#bdrstat_raft_state", - "bdrstat_receiver": "/pgd/5.8/reference/catalogs-visible#bdrstat_receiver", - "bdrstat_relation": "/pgd/5.8/reference/catalogs-visible#bdrstat_relation", - "bdrstat_routing_candidate_state": "/pgd/5.8/reference/catalogs-visible#bdrstat_routing_candidate_state", - "bdrstat_routing_state": "/pgd/5.8/reference/catalogs-visible#bdrstat_routing_state", - "bdrstat_subscription": "/pgd/5.8/reference/catalogs-visible#bdrstat_subscription", - "bdrstat_worker": "/pgd/5.8/reference/catalogs-visible#bdrstat_worker", - "bdrstat_writer": "/pgd/5.8/reference/catalogs-visible#bdrstat_writer", - "bdrsubscription": "/pgd/5.8/reference/catalogs-visible#bdrsubscription", - "bdrsubscription_summary": "/pgd/5.8/reference/catalogs-visible#bdrsubscription_summary", - "bdrtables": "/pgd/5.8/reference/catalogs-visible#bdrtables", - "bdrtaskmgr_work_queue": "/pgd/5.8/reference/catalogs-visible#bdrtaskmgr_work_queue", - "bdrtaskmgr_workitem_status": "/pgd/5.8/reference/catalogs-visible#bdrtaskmgr_workitem_status", - "bdrtaskmgr_local_work_queue": "/pgd/5.8/reference/catalogs-visible#bdrtaskmgr_local_work_queue", - "bdrtaskmgr_local_workitem_status": "/pgd/5.8/reference/catalogs-visible#bdrtaskmgr_local_workitem_status", - "bdrtrigger": "/pgd/5.8/reference/catalogs-visible#bdrtrigger", - "bdrtriggers": "/pgd/5.8/reference/catalogs-visible#bdrtriggers", - "bdrworkers": "/pgd/5.8/reference/catalogs-visible#bdrworkers", - "bdrwriters": "/pgd/5.8/reference/catalogs-visible#bdrwriters", - "bdrworker_tasks": "/pgd/5.8/reference/catalogs-visible#bdrworker_tasks", - "bdrbdr_version": "/pgd/5.8/reference/functions#bdrbdr_version", - "bdrbdr_version_num": "/pgd/5.8/reference/functions#bdrbdr_version_num", - "bdrget_relation_stats": "/pgd/5.8/reference/functions#bdrget_relation_stats", - "bdrget_subscription_stats": "/pgd/5.8/reference/functions#bdrget_subscription_stats", - "bdrlocal_node_id": "/pgd/5.8/reference/functions#bdrlocal_node_id", - "bdrlast_committed_lsn": "/pgd/5.8/reference/functions#bdrlast_committed_lsn", - "transaction_id": "/pgd/5.8/reference/functions#transaction_id", - "bdris_node_connected": "/pgd/5.8/reference/functions#bdris_node_connected", - "bdris_node_ready": "/pgd/5.8/reference/functions#bdris_node_ready", - "bdrconsensus_disable": "/pgd/5.8/reference/functions#bdrconsensus_disable", - "bdrconsensus_enable": "/pgd/5.8/reference/functions#bdrconsensus_enable", - "bdrconsensus_proto_version": "/pgd/5.8/reference/functions#bdrconsensus_proto_version", - "bdrconsensus_snapshot_export": "/pgd/5.8/reference/functions#bdrconsensus_snapshot_export", - "bdrconsensus_snapshot_import": "/pgd/5.8/reference/functions#bdrconsensus_snapshot_import", - "bdrconsensus_snapshot_verify": "/pgd/5.8/reference/functions#bdrconsensus_snapshot_verify", - "bdrget_consensus_status": "/pgd/5.8/reference/functions#bdrget_consensus_status", - "bdrget_raft_status": "/pgd/5.8/reference/functions#bdrget_raft_status", - "bdrraft_leadership_transfer": "/pgd/5.8/reference/functions#bdrraft_leadership_transfer", - "bdrwait_slot_confirm_lsn": "/pgd/5.8/reference/functions#bdrwait_slot_confirm_lsn", - "bdrwait_node_confirm_lsn": "/pgd/5.8/reference/functions#bdrwait_node_confirm_lsn", - "bdrwait_for_apply_queue": "/pgd/5.8/reference/functions#bdrwait_for_apply_queue", - "bdrget_node_sub_receive_lsn": "/pgd/5.8/reference/functions#bdrget_node_sub_receive_lsn", - "bdrget_node_sub_apply_lsn": "/pgd/5.8/reference/functions#bdrget_node_sub_apply_lsn", - "bdrreplicate_ddl_command": "/pgd/5.8/reference/functions#bdrreplicate_ddl_command", - "bdrrun_on_all_nodes": "/pgd/5.8/reference/functions#bdrrun_on_all_nodes", - "bdrrun_on_nodes": "/pgd/5.8/reference/functions#bdrrun_on_nodes", - "bdrrun_on_group": "/pgd/5.8/reference/functions#bdrrun_on_group", - "bdrglobal_lock_table": "/pgd/5.8/reference/functions#bdrglobal_lock_table", - "bdrwait_for_xid_progress": "/pgd/5.8/reference/functions#bdrwait_for_xid_progress", - "bdrlocal_group_slot_name": "/pgd/5.8/reference/functions#bdrlocal_group_slot_name", - "bdrnode_group_type": "/pgd/5.8/reference/functions#bdrnode_group_type", - "bdralter_node_kind": "/pgd/5.8/reference/functions#bdralter_node_kind", - "bdralter_subscription_skip_changes_upto": "/pgd/5.8/reference/functions#bdralter_subscription_skip_changes_upto", - "bdrglobal_advisory_lock": "/pgd/5.8/reference/functions#bdrglobal_advisory_lock", - "bdrglobal_advisory_unlock": "/pgd/5.8/reference/functions#bdrglobal_advisory_unlock", - "bdrmonitor_group_versions": "/pgd/5.8/reference/functions#bdrmonitor_group_versions", - "bdrmonitor_group_raft": "/pgd/5.8/reference/functions#bdrmonitor_group_raft", - "bdrmonitor_local_replslots": "/pgd/5.8/reference/functions#bdrmonitor_local_replslots", - "bdrwal_sender_stats": "/pgd/5.8/reference/functions#bdrwal_sender_stats", - "bdrget_decoding_worker_stat": "/pgd/5.8/reference/functions#bdrget_decoding_worker_stat", - "bdrlag_control": "/pgd/5.8/reference/functions#bdrlag_control", - "bdris_camo_partner_connected": "/pgd/5.8/reference/functions#bdris_camo_partner_connected", - "bdris_camo_partner_ready": "/pgd/5.8/reference/functions#bdris_camo_partner_ready", - "bdrget_configured_camo_partner": "/pgd/5.8/reference/functions#bdrget_configured_camo_partner", - "bdrwait_for_camo_partner_queue": "/pgd/5.8/reference/functions#bdrwait_for_camo_partner_queue", - "bdrcamo_transactions_resolved": "/pgd/5.8/reference/functions#bdrcamo_transactions_resolved", - "bdrlogical_transaction_status": "/pgd/5.8/reference/functions#bdrlogical_transaction_status", - "bdradd_commit_scope": "/pgd/5.8/reference/functions#bdradd_commit_scope", - "bdrcreate_commit_scope": "/pgd/5.8/reference/functions#bdrcreate_commit_scope", - "bdralter_commit_scope": "/pgd/5.8/reference/functions#bdralter_commit_scope", - "bdrdrop_commit_scope": "/pgd/5.8/reference/functions#bdrdrop_commit_scope", - "bdrremove_commit_scope": "/pgd/5.8/reference/functions#bdrremove_commit_scope", - "bdrdefault_conflict_detection": "/pgd/5.8/reference/pgd-settings#bdrdefault_conflict_detection", - "bdrdefault_sequence_kind": "/pgd/5.8/reference/pgd-settings#bdrdefault_sequence_kind", - "bdrdefault_replica_identity": "/pgd/5.8/reference/pgd-settings#bdrdefault_replica_identity", - "bdrrole_replication": "/pgd/5.8/reference/pgd-settings#bdrrole_replication", - "bdrddl_locking": "/pgd/5.8/reference/pgd-settings#bdrddl_locking", - "bdrtruncate_locking": "/pgd/5.8/reference/pgd-settings#bdrtruncate_locking", - "bdrglobal_lock_max_locks": "/pgd/5.8/reference/pgd-settings#bdrglobal_lock_max_locks", - "bdrglobal_lock_timeout": "/pgd/5.8/reference/pgd-settings#bdrglobal_lock_timeout", - "bdrglobal_lock_statement_timeout": "/pgd/5.8/reference/pgd-settings#bdrglobal_lock_statement_timeout", - "bdrglobal_lock_idle_timeout": "/pgd/5.8/reference/pgd-settings#bdrglobal_lock_idle_timeout", - "bdrlock_table_locking": "/pgd/5.8/reference/pgd-settings#bdrlock_table_locking", - "bdrpredictive_checks": "/pgd/5.8/reference/pgd-settings#bdrpredictive_checks", - "bdrreplay_progress_frequency": "/pgd/5.8/reference/pgd-settings#bdrreplay_progress_frequency", - "bdrstandby_slot_names": "/pgd/5.8/reference/pgd-settings#bdrstandby_slot_names", - "bdrwriters_per_subscription": "/pgd/5.8/reference/pgd-settings#bdrwriters_per_subscription", - "bdrmax_writers_per_subscription": "/pgd/5.8/reference/pgd-settings#bdrmax_writers_per_subscription", - "bdrxact_replication": "/pgd/5.8/reference/pgd-settings#bdrxact_replication", - "bdrpermit_unsafe_commands": "/pgd/5.8/reference/pgd-settings#bdrpermit_unsafe_commands", - "bdrbatch_inserts": "/pgd/5.8/reference/pgd-settings#bdrbatch_inserts", - "bdrmaximum_clock_skew": "/pgd/5.8/reference/pgd-settings#bdrmaximum_clock_skew", - "bdrmaximum_clock_skew_action": "/pgd/5.8/reference/pgd-settings#bdrmaximum_clock_skew_action", - "bdraccept_connections": "/pgd/5.8/reference/pgd-settings#bdraccept_connections", - "bdrstandby_slots_min_confirmed": "/pgd/5.8/reference/pgd-settings#bdrstandby_slots_min_confirmed", - "bdrwriter_input_queue_size": "/pgd/5.8/reference/pgd-settings#bdrwriter_input_queue_size", - "bdrwriter_output_queue_size": "/pgd/5.8/reference/pgd-settings#bdrwriter_output_queue_size", - "bdrmin_worker_backoff_delay": "/pgd/5.8/reference/pgd-settings#bdrmin_worker_backoff_delay", - "bdrcrdt_raw_value": "/pgd/5.8/reference/pgd-settings#bdrcrdt_raw_value", - "bdrcommit_scope": "/pgd/5.8/reference/pgd-settings#bdrcommit_scope", - "bdrcamo_local_mode_delay": "/pgd/5.8/reference/pgd-settings#bdrcamo_local_mode_delay", - "bdrcamo_enable_client_warnings": "/pgd/5.8/reference/pgd-settings#bdrcamo_enable_client_warnings", - "bdrdefault_streaming_mode": "/pgd/5.8/reference/pgd-settings#bdrdefault_streaming_mode", - "bdrlag_control_max_commit_delay": "/pgd/5.8/reference/pgd-settings#bdrlag_control_max_commit_delay", - "bdrlag_control_max_lag_size": "/pgd/5.8/reference/pgd-settings#bdrlag_control_max_lag_size", - "bdrlag_control_max_lag_time": "/pgd/5.8/reference/pgd-settings#bdrlag_control_max_lag_time", - "bdrlag_control_min_conforming_nodes": "/pgd/5.8/reference/pgd-settings#bdrlag_control_min_conforming_nodes", - "bdrlag_control_commit_delay_adjust": "/pgd/5.8/reference/pgd-settings#bdrlag_control_commit_delay_adjust", - "bdrlag_control_sample_interval": "/pgd/5.8/reference/pgd-settings#bdrlag_control_sample_interval", - "bdrlag_control_commit_delay_start": "/pgd/5.8/reference/pgd-settings#bdrlag_control_commit_delay_start", - "bdrtimestamp_snapshot_keep": "/pgd/5.8/reference/pgd-settings#bdrtimestamp_snapshot_keep", - "bdrdebug_level": "/pgd/5.8/reference/pgd-settings#bdrdebug_level", - "bdrtrace_level": "/pgd/5.8/reference/pgd-settings#bdrtrace_level", - "bdrtrack_subscription_apply": "/pgd/5.8/reference/pgd-settings#bdrtrack_subscription_apply", - "bdrtrack_relation_apply": "/pgd/5.8/reference/pgd-settings#bdrtrack_relation_apply", - "bdrtrack_apply_lock_timing": "/pgd/5.8/reference/pgd-settings#bdrtrack_apply_lock_timing", - "bdrenable_wal_decoder": "/pgd/5.8/reference/pgd-settings#bdrenable_wal_decoder", - "bdrreceive_lcr": "/pgd/5.8/reference/pgd-settings#bdrreceive_lcr", - "bdrlcr_cleanup_interval": "/pgd/5.8/reference/pgd-settings#bdrlcr_cleanup_interval", - "bdrglobal_connection_timeout": "/pgd/5.8/reference/pgd-settings#bdrglobal_connection_timeout", - "bdrglobal_keepalives": "/pgd/5.8/reference/pgd-settings#bdrglobal_keepalives", - "bdrglobal_keepalives_idle": "/pgd/5.8/reference/pgd-settings#bdrglobal_keepalives_idle", - "bdrglobal_keepalives_interval": "/pgd/5.8/reference/pgd-settings#bdrglobal_keepalives_interval", - "bdrglobal_keepalives_count": "/pgd/5.8/reference/pgd-settings#bdrglobal_keepalives_count", - "bdrglobal_tcp_user_timeout": "/pgd/5.8/reference/pgd-settings#bdrglobal_tcp_user_timeout", - "bdrforce_full_mesh": "/pgd/5.8/reference/pgd-settings#bdrforce_full_mesh", - "bdrraft_global_election_timeout": "/pgd/5.8/reference/pgd-settings#bdrraft_global_election_timeout", - "bdrraft_group_election_timeout": "/pgd/5.8/reference/pgd-settings#bdrraft_group_election_timeout", - "bdrraft_response_timeout": "/pgd/5.8/reference/pgd-settings#bdrraft_response_timeout", - "bdrraft_keep_min_entries": "/pgd/5.8/reference/pgd-settings#bdrraft_keep_min_entries", - "bdrraft_log_min_apply_duration": "/pgd/5.8/reference/pgd-settings#bdrraft_log_min_apply_duration", - "bdrraft_log_min_message_duration": "/pgd/5.8/reference/pgd-settings#bdrraft_log_min_message_duration", - "bdrraft_group_max_connections": "/pgd/5.8/reference/pgd-settings#bdrraft_group_max_connections", - "bdrbackwards_compatibility": "/pgd/5.8/reference/pgd-settings#bdrbackwards_compatibility", - "bdrtrack_replication_estimates": "/pgd/5.8/reference/pgd-settings#bdrtrack_replication_estimates", - "bdrlag_tracker_apply_rate_weight": "/pgd/5.8/reference/pgd-settings#bdrlag_tracker_apply_rate_weight", - "bdrenable_auto_sync_reconcile": "/pgd/5.8/reference/pgd-settings#bdrenable_auto_sync_reconcile", - "list-of-node-states": "/pgd/5.8/reference/nodes#list-of-node-states", - "node-management-commands": "/pgd/5.8/reference/nodes#node-management-commands", - "bdr_init_physical": "/pgd/5.8/reference/nodes#bdr_init_physical", - "bdr_config": "/pgd/5.8/reference/nodes#bdr_config", - "bdralter_node_group_option": "/pgd/5.8/reference/nodes-management-interfaces#bdralter_node_group_option", - "bdralter_node_interface": "/pgd/5.8/reference/nodes-management-interfaces#bdralter_node_interface", - "bdralter_node_option": "/pgd/5.8/reference/nodes-management-interfaces#bdralter_node_option", - "bdralter_subscription_enable": "/pgd/5.8/reference/nodes-management-interfaces#bdralter_subscription_enable", - "bdralter_subscription_disable": "/pgd/5.8/reference/nodes-management-interfaces#bdralter_subscription_disable", - "bdrcreate_node": "/pgd/5.8/reference/nodes-management-interfaces#bdrcreate_node", - "bdrcreate_node_group": "/pgd/5.8/reference/nodes-management-interfaces#bdrcreate_node_group", - "bdrdrop_node_group": "/pgd/5.8/reference/nodes-management-interfaces#bdrdrop_node_group", - "bdrjoin_node_group": "/pgd/5.8/reference/nodes-management-interfaces#bdrjoin_node_group", - "bdrpart_node": "/pgd/5.8/reference/nodes-management-interfaces#bdrpart_node", - "bdrpromote_node": "/pgd/5.8/reference/nodes-management-interfaces#bdrpromote_node", - "bdrswitch_node_group": "/pgd/5.8/reference/nodes-management-interfaces#bdrswitch_node_group", - "bdrwait_for_join_completion": "/pgd/5.8/reference/nodes-management-interfaces#bdrwait_for_join_completion", - "bdralter_node_group_config": "/pgd/5.8/reference/nodes-management-interfaces#bdralter_node_group_config", - "bdrcreate_proxy": "/pgd/5.8/reference/routing#bdrcreate_proxy", - "bdralter_proxy_option": "/pgd/5.8/reference/routing#bdralter_proxy_option", - "bdrdrop_proxy": "/pgd/5.8/reference/routing#bdrdrop_proxy", - "bdrrouting_leadership_transfer": "/pgd/5.8/reference/routing#bdrrouting_leadership_transfer", - "cs.commit-scope-syntax": "/pgd/5.8/reference/commit-scopes#commit-scope-syntax", - "cs.commit_scope_degrade_operation": "/pgd/5.8/reference/commit-scopes#commit_scope_degrade_operation", - "cs.commit-scope-targets": "/pgd/5.8/reference/commit-scopes#commit-scope-targets", - "cs.origin_group": "/pgd/5.8/reference/commit-scopes#origin_group", - "cs.commit-scope-groups": "/pgd/5.8/reference/commit-scopes#commit-scope-groups", - "cs.any": "/pgd/5.8/reference/commit-scopes#any", - "cs.any-not": "/pgd/5.8/reference/commit-scopes#any-not", - "cs.majority": "/pgd/5.8/reference/commit-scopes#majority", - "cs.majority-not": "/pgd/5.8/reference/commit-scopes#majority-not", - "cs.all": "/pgd/5.8/reference/commit-scopes#all", - "cs.all-not": "/pgd/5.8/reference/commit-scopes#all-not", - "cs.confirmation-level": "/pgd/5.8/reference/commit-scopes#confirmation-level", - "cs.on-received": "/pgd/5.8/reference/commit-scopes#on-received", - "cs.on-replicated": "/pgd/5.8/reference/commit-scopes#on-replicated", - "cs.on-durable": "/pgd/5.8/reference/commit-scopes#on-durable", - "cs.on-visible": "/pgd/5.8/reference/commit-scopes#on-visible", - "cs.commit-scope-kinds": "/pgd/5.8/reference/commit-scopes#commit-scope-kinds", - "cs.synchronous-commit": "/pgd/5.8/reference/commit-scopes#synchronous-commit", - "cs.degrade-on-parameters": "/pgd/5.8/reference/commit-scopes#degrade-on-parameters", - "cs.group-commit": "/pgd/5.8/reference/commit-scopes#group-commit", - "cs.group-commit-parameters": "/pgd/5.8/reference/commit-scopes#group-commit-parameters", - "cs.abort-on-parameters": "/pgd/5.8/reference/commit-scopes#abort-on-parameters", - "cs.transaction_tracking-settings": "/pgd/5.8/reference/commit-scopes#transaction_tracking-settings", - "cs.conflict_resolution-settings": "/pgd/5.8/reference/commit-scopes#conflict_resolution-settings", - "cs.commit_decision-settings": "/pgd/5.8/reference/commit-scopes#commit_decision-settings", - "cs.commit_scope_degrade_operation-settings": "/pgd/5.8/reference/commit-scopes#commit_scope_degrade_operation-settings", - "cs.camo": "/pgd/5.8/reference/commit-scopes#camo", - "cs.lag-control": "/pgd/5.8/reference/commit-scopes#lag-control", - "cs.lag-control-parameters": "/pgd/5.8/reference/commit-scopes#lag-control-parameters", - "conflict-detection": "/pgd/5.8/reference/conflicts#conflict-detection", - "list-of-conflict-types": "/pgd/5.8/reference/conflicts#list-of-conflict-types", - "conflict-resolution": "/pgd/5.8/reference/conflicts#conflict-resolution", - "list-of-conflict-resolvers": "/pgd/5.8/reference/conflicts#list-of-conflict-resolvers", - "default-conflict-resolvers": "/pgd/5.8/reference/conflicts#default-conflict-resolvers", - "list-of-conflict-resolutions": "/pgd/5.8/reference/conflicts#list-of-conflict-resolutions", - "conflict-logging": "/pgd/5.8/reference/conflicts#conflict-logging", - "bdralter_table_conflict_detection": "/pgd/5.8/reference/conflict_functions#bdralter_table_conflict_detection", - "bdralter_node_set_conflict_resolver": "/pgd/5.8/reference/conflict_functions#bdralter_node_set_conflict_resolver", - "bdralter_node_set_log_config": "/pgd/5.8/reference/conflict_functions#bdralter_node_set_log_config", - "bdrcreate_replication_set": "/pgd/5.8/reference/repsets-management#bdrcreate_replication_set", - "bdralter_replication_set": "/pgd/5.8/reference/repsets-management#bdralter_replication_set", - "bdrdrop_replication_set": "/pgd/5.8/reference/repsets-management#bdrdrop_replication_set", - "bdralter_node_replication_sets": "/pgd/5.8/reference/repsets-management#bdralter_node_replication_sets", - "bdrreplication_set_add_table": "/pgd/5.8/reference/repsets-membership#bdrreplication_set_add_table", - "bdrreplication_set_remove_table": "/pgd/5.8/reference/repsets-membership#bdrreplication_set_remove_table", - "bdrreplication_set_add_ddl_filter": "/pgd/5.8/reference/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter", - "bdrreplication_set_remove_ddl_filter": "/pgd/5.8/reference/repsets-ddl-filtering#bdrreplication_set_remove_ddl_filter", - "pgd_bench": "/pgd/5.8/reference/testingandtuning#pgd_bench", - "bdralter_sequence_set_kind": "/pgd/5.8/reference/sequences#bdralter_sequence_set_kind", - "bdrextract_timestamp_from_snowflakeid": "/pgd/5.8/reference/sequences#bdrextract_timestamp_from_snowflakeid", - "bdrextract_nodeid_from_snowflakeid": "/pgd/5.8/reference/sequences#bdrextract_nodeid_from_snowflakeid", - "bdrextract_localseqid_from_snowflakeid": "/pgd/5.8/reference/sequences#bdrextract_localseqid_from_snowflakeid", - "bdrtimestamp_to_snowflakeid": "/pgd/5.8/reference/sequences#bdrtimestamp_to_snowflakeid", - "bdrextract_timestamp_from_timeshard": "/pgd/5.8/reference/sequences#bdrextract_timestamp_from_timeshard", - "bdrextract_nodeid_from_timeshard": "/pgd/5.8/reference/sequences#bdrextract_nodeid_from_timeshard", - "bdrextract_localseqid_from_timeshard": "/pgd/5.8/reference/sequences#bdrextract_localseqid_from_timeshard", - "bdrtimestamp_to_timeshard": "/pgd/5.8/reference/sequences#bdrtimestamp_to_timeshard", - "bdrgalloc_chunk_info": "/pgd/5.8/reference/sequences#bdrgalloc_chunk_info", - "bdrgen_ksuuid_v2": "/pgd/5.8/reference/sequences#bdrgen_ksuuid_v2", - "bdrksuuid_v2_cmp": "/pgd/5.8/reference/sequences#bdrksuuid_v2_cmp", - "bdrextract_timestamp_from_ksuuid_v2": "/pgd/5.8/reference/sequences#bdrextract_timestamp_from_ksuuid_v2", - "bdrgen_ksuuid": "/pgd/5.8/reference/sequences#bdrgen_ksuuid", - "bdruuid_v1_cmp": "/pgd/5.8/reference/sequences#bdruuid_v1_cmp", - "bdrextract_timestamp_from_ksuuid": "/pgd/5.8/reference/sequences#bdrextract_timestamp_from_ksuuid", - "bdrautopartition": "/pgd/5.8/reference/autopartition#bdrautopartition", - "bdrdrop_autopartition": "/pgd/5.8/reference/autopartition#bdrdrop_autopartition", - "bdrautopartition_wait_for_partitions": "/pgd/5.8/reference/autopartition#bdrautopartition_wait_for_partitions", - "bdrautopartition_wait_for_partitions_on_all_nodes": "/pgd/5.8/reference/autopartition#bdrautopartition_wait_for_partitions_on_all_nodes", - "bdrautopartition_find_partition": "/pgd/5.8/reference/autopartition#bdrautopartition_find_partition", - "bdrautopartition_enable": "/pgd/5.8/reference/autopartition#bdrautopartition_enable", - "bdrautopartition_disable": "/pgd/5.8/reference/autopartition#bdrautopartition_disable", - "internal-functions": "/pgd/5.8/reference/autopartition#internal-functions", - "bdrautopartition_create_partition": "/pgd/5.8/reference/autopartition#bdrautopartition_create_partition", - "bdrautopartition_drop_partition": "/pgd/5.8/reference/autopartition#bdrautopartition_drop_partition", - "bdrcreate_conflict_trigger": "/pgd/5.8/reference/streamtriggers/interfaces#bdrcreate_conflict_trigger", - "bdrcreate_transform_trigger": "/pgd/5.8/reference/streamtriggers/interfaces#bdrcreate_transform_trigger", - "bdrdrop_trigger": "/pgd/5.8/reference/streamtriggers/interfaces#bdrdrop_trigger", - "bdrtrigger_get_row": "/pgd/5.8/reference/streamtriggers/rowfunctions#bdrtrigger_get_row", - "bdrtrigger_get_committs": "/pgd/5.8/reference/streamtriggers/rowfunctions#bdrtrigger_get_committs", - "bdrtrigger_get_xid": "/pgd/5.8/reference/streamtriggers/rowfunctions#bdrtrigger_get_xid", - "bdrtrigger_get_type": "/pgd/5.8/reference/streamtriggers/rowfunctions#bdrtrigger_get_type", - "bdrtrigger_get_conflict_type": "/pgd/5.8/reference/streamtriggers/rowfunctions#bdrtrigger_get_conflict_type", - "bdrtrigger_get_origin_node_id": "/pgd/5.8/reference/streamtriggers/rowfunctions#bdrtrigger_get_origin_node_id", - "bdrri_fkey_on_del_trigger": "/pgd/5.8/reference/streamtriggers/rowfunctions#bdrri_fkey_on_del_trigger", - "tg_name": "/pgd/5.8/reference/streamtriggers/rowvariables#tg_name", - "tg_when": "/pgd/5.8/reference/streamtriggers/rowvariables#tg_when", - "tg_level": "/pgd/5.8/reference/streamtriggers/rowvariables#tg_level", - "tg_op": "/pgd/5.8/reference/streamtriggers/rowvariables#tg_op", - "tg_relid": "/pgd/5.8/reference/streamtriggers/rowvariables#tg_relid", - "tg_table_name": "/pgd/5.8/reference/streamtriggers/rowvariables#tg_table_name", - "tg_table_schema": "/pgd/5.8/reference/streamtriggers/rowvariables#tg_table_schema", - "tg_nargs": "/pgd/5.8/reference/streamtriggers/rowvariables#tg_nargs", - "tg_argv": "/pgd/5.8/reference/streamtriggers/rowvariables#tg_argv", - "bdrautopartition_partitions": "/pgd/5.8/reference/catalogs-internal#bdrautopartition_partitions", - "bdrautopartition_rules": "/pgd/5.8/reference/catalogs-internal#bdrautopartition_rules", - "bdrddl_epoch": "/pgd/5.8/reference/catalogs-internal#bdrddl_epoch", - "bdrevent_history": "/pgd/5.8/reference/catalogs-internal#bdrevent_history", - "bdrevent_summary": "/pgd/5.8/reference/catalogs-internal#bdrevent_summary", - "bdrlocal_leader_change": "/pgd/5.8/reference/catalogs-internal#bdrlocal_leader_change", - "bdrnode_config": "/pgd/5.8/reference/catalogs-internal#bdrnode_config", - "bdrnode_config_summary": "/pgd/5.8/reference/catalogs-internal#bdrnode_config_summary", - "bdrnode_group_config": "/pgd/5.8/reference/catalogs-internal#bdrnode_group_config", - "bdrnode_group_routing_config_summary": "/pgd/5.8/reference/catalogs-internal#bdrnode_group_routing_config_summary", - "bdrnode_group_routing_info": "/pgd/5.8/reference/catalogs-internal#bdrnode_group_routing_info", - "bdrnode_group_routing_summary": "/pgd/5.8/reference/catalogs-internal#bdrnode_group_routing_summary", - "bdrnode_routing_config_summary": "/pgd/5.8/reference/catalogs-internal#bdrnode_routing_config_summary", - "bdrproxy_config": "/pgd/5.8/reference/catalogs-internal#bdrproxy_config", - "bdrproxy_config_summary": "/pgd/5.8/reference/catalogs-internal#bdrproxy_config_summary", - "bdrsequence_kind": "/pgd/5.8/reference/catalogs-internal#bdrsequence_kind", - "bdrsync_node_requests": "/pgd/5.8/reference/catalogs-internal#bdrsync_node_requests", - "bdrsync_node_requests_summary": "/pgd/5.8/reference/catalogs-internal#bdrsync_node_requests_summary", - "bdrbdr_get_commit_decisions": "/pgd/5.8/reference/functions-internal#bdrbdr_get_commit_decisions", - "bdrbdr_track_commit_decision": "/pgd/5.8/reference/functions-internal#bdrbdr_track_commit_decision", - "bdrconsensus_kv_fetch": "/pgd/5.8/reference/functions-internal#bdrconsensus_kv_fetch", - "bdrconsensus_kv_store": "/pgd/5.8/reference/functions-internal#bdrconsensus_kv_store", - "bdrdecode_message_payload": "/pgd/5.8/reference/functions-internal#bdrdecode_message_payload", - "bdrdecode_message_response_payload": "/pgd/5.8/reference/functions-internal#bdrdecode_message_response_payload", - "bdrdifference_fix_origin_create": "/pgd/5.8/reference/functions-internal#bdrdifference_fix_origin_create", - "bdrdifference_fix_session_reset": "/pgd/5.8/reference/functions-internal#bdrdifference_fix_session_reset", - "bdrdifference_fix_session_setup": "/pgd/5.8/reference/functions-internal#bdrdifference_fix_session_setup", - "bdrdifference_fix_xact_set_avoid_conflict": "/pgd/5.8/reference/functions-internal#bdrdifference_fix_xact_set_avoid_conflict", - "bdrdrop_node": "/pgd/5.8/reference/functions-internal#bdrdrop_node", - "bdrget_global_locks": "/pgd/5.8/reference/functions-internal#bdrget_global_locks", - "bdrget_node_conflict_resolvers": "/pgd/5.8/reference/functions-internal#bdrget_node_conflict_resolvers", - "bdrget_slot_flush_timestamp": "/pgd/5.8/reference/functions-internal#bdrget_slot_flush_timestamp", - "bdrinternal_alter_sequence_set_kind": "/pgd/5.8/reference/functions-internal#bdrinternal_alter_sequence_set_kind", - "bdrinternal_replication_set_add_table": "/pgd/5.8/reference/functions-internal#bdrinternal_replication_set_add_table", - "bdrinternal_replication_set_remove_table": "/pgd/5.8/reference/functions-internal#bdrinternal_replication_set_remove_table", - "bdrinternal_submit_join_request": "/pgd/5.8/reference/functions-internal#bdrinternal_submit_join_request", - "bdrisolation_test_session_is_blocked": "/pgd/5.8/reference/functions-internal#bdrisolation_test_session_is_blocked", - "bdrlocal_node_info": "/pgd/5.8/reference/functions-internal#bdrlocal_node_info", - "bdrmsgb_connect": "/pgd/5.8/reference/functions-internal#bdrmsgb_connect", - "bdrmsgb_deliver_message": "/pgd/5.8/reference/functions-internal#bdrmsgb_deliver_message", - "bdrnode_catchup_state_name": "/pgd/5.8/reference/functions-internal#bdrnode_catchup_state_name", - "bdrnode_kind_name": "/pgd/5.8/reference/functions-internal#bdrnode_kind_name", - "bdrpeer_state_name": "/pgd/5.8/reference/functions-internal#bdrpeer_state_name", - "bdrpg_xact_origin": "/pgd/5.8/reference/functions-internal#bdrpg_xact_origin", - "bdrrequest_replay_progress_update": "/pgd/5.8/reference/functions-internal#bdrrequest_replay_progress_update", - "bdrreset_relation_stats": "/pgd/5.8/reference/functions-internal#bdrreset_relation_stats", - "bdrreset_subscription_stats": "/pgd/5.8/reference/functions-internal#bdrreset_subscription_stats", - "bdrresynchronize_table_from_node": "/pgd/5.8/reference/functions-internal#bdrresynchronize_table_from_node", - "bdrseq_currval": "/pgd/5.8/reference/functions-internal#bdrseq_currval", - "bdrseq_lastval": "/pgd/5.8/reference/functions-internal#bdrseq_lastval", - "bdrseq_nextval": "/pgd/5.8/reference/functions-internal#bdrseq_nextval", - "bdrshow_subscription_status": "/pgd/5.8/reference/functions-internal#bdrshow_subscription_status", - "bdrshow_workers": "/pgd/5.8/reference/functions-internal#bdrshow_workers", - "bdrshow_writers": "/pgd/5.8/reference/functions-internal#bdrshow_writers", - "bdrsync_status_name": "/pgd/5.8/reference/functions-internal#bdrsync_status_name", - "bdrtaskmgr_set_leader": "/pgd/5.8/reference/functions-internal#bdrtaskmgr_set_leader", - "bdrtaskmgr_get_last_completed_workitem": "/pgd/5.8/reference/functions-internal#bdrtaskmgr_get_last_completed_workitem", - "bdrtaskmgr_work_queue_check_status": "/pgd/5.8/reference/functions-internal#bdrtaskmgr_work_queue_check_status", - "bdrpglogical_proto_version_ranges": "/pgd/5.8/reference/functions-internal#bdrpglogical_proto_version_ranges", - "bdrget_min_required_replication_slots": "/pgd/5.8/reference/functions-internal#bdrget_min_required_replication_slots", - "bdrget_min_required_worker_processes": "/pgd/5.8/reference/functions-internal#bdrget_min_required_worker_processes", - "bdrstat_get_activity": "/pgd/5.8/reference/functions-internal#bdrstat_get_activity", - "bdrworker_role_id_name": "/pgd/5.8/reference/functions-internal#bdrworker_role_id_name", - "bdrlag_history": "/pgd/5.8/reference/functions-internal#bdrlag_history", - "bdrget_raft_instance_by_nodegroup": "/pgd/5.8/reference/functions-internal#bdrget_raft_instance_by_nodegroup", - "bdrmonitor_camo_on_all_nodes": "/pgd/5.8/reference/functions-internal#bdrmonitor_camo_on_all_nodes", - "bdrmonitor_raft_details_on_all_nodes": "/pgd/5.8/reference/functions-internal#bdrmonitor_raft_details_on_all_nodes", - "bdrmonitor_replslots_details_on_all_nodes": "/pgd/5.8/reference/functions-internal#bdrmonitor_replslots_details_on_all_nodes", - "bdrmonitor_subscription_details_on_all_nodes": "/pgd/5.8/reference/functions-internal#bdrmonitor_subscription_details_on_all_nodes", - "bdrmonitor_version_details_on_all_nodes": "/pgd/5.8/reference/functions-internal#bdrmonitor_version_details_on_all_nodes", - "bdrnode_group_member_info": "/pgd/5.8/reference/functions-internal#bdrnode_group_member_info", - "bdrcolumn_timestamps_create": "/pgd/5.8/reference/clcd#bdrcolumn_timestamps_create" + "bdrcamo_decision_journal": "/pgd/6.0/reference/catalogs-visible#bdrcamo_decision_journal", + "bdrcommit_scopes": "/pgd/6.0/reference/catalogs-visible#bdrcommit_scopes", + "bdrconflict_history": "/pgd/6.0/reference/catalogs-visible#bdrconflict_history", + "bdrconflict_history_summary": "/pgd/6.0/reference/catalogs-visible#bdrconflict_history_summary", + "bdrconsensus_kv_data": "/pgd/6.0/reference/catalogs-visible#bdrconsensus_kv_data", + "bdrcrdt_handlers": "/pgd/6.0/reference/catalogs-visible#bdrcrdt_handlers", + "bdrddl_replication": "/pgd/6.0/reference/pgd-settings#bdrddl_replication", + "bdrdepend": "/pgd/6.0/reference/catalogs-visible#bdrdepend", + "bdrfailover_replication_slots": "/pgd/6.0/reference/catalogs-visible#bdrfailover_replication_slots", + "bdrglobal_consensus_journal": "/pgd/6.0/reference/catalogs-visible#bdrglobal_consensus_journal", + "bdrglobal_consensus_journal_details": "/pgd/6.0/reference/catalogs-visible#bdrglobal_consensus_journal_details", + "bdrglobal_consensus_response_journal": "/pgd/6.0/reference/catalogs-visible#bdrglobal_consensus_response_journal", + "bdrglobal_lock": "/pgd/6.0/reference/catalogs-visible#bdrglobal_lock", + "bdrglobal_locks": "/pgd/6.0/reference/catalogs-visible#bdrglobal_locks", + "bdrgroup_camo_details": "/pgd/6.0/reference/catalogs-visible#bdrgroup_camo_details", + "bdrgroup_raft_details": "/pgd/6.0/reference/catalogs-visible#bdrgroup_raft_details", + "bdrgroup_replslots_details": "/pgd/6.0/reference/catalogs-visible#bdrgroup_replslots_details", + "bdrgroup_subscription_summary": "/pgd/6.0/reference/catalogs-visible#bdrgroup_subscription_summary", + "bdrgroup_versions_details": "/pgd/6.0/reference/catalogs-visible#bdrgroup_versions_details", + "bdrleader": "/pgd/6.0/reference/catalogs-visible#bdrleader", + "bdrlocal_consensus_snapshot": "/pgd/6.0/reference/catalogs-visible#bdrlocal_consensus_snapshot", + "bdrlocal_consensus_state": "/pgd/6.0/reference/catalogs-visible#bdrlocal_consensus_state", + "bdrlocal_node": "/pgd/6.0/reference/catalogs-visible#bdrlocal_node", + "bdrlocal_node_summary": "/pgd/6.0/reference/catalogs-visible#bdrlocal_node_summary", + "bdrlocal_sync_status": "/pgd/6.0/reference/catalogs-visible#bdrlocal_sync_status", + "bdrnode": "/pgd/6.0/reference/catalogs-visible#bdrnode", + "bdrnode_catchup_info": "/pgd/6.0/reference/catalogs-visible#bdrnode_catchup_info", + "bdrnode_catchup_info_details": "/pgd/6.0/reference/catalogs-visible#bdrnode_catchup_info_details", + "bdrnode_conflict_resolvers": "/pgd/6.0/reference/catalogs-visible#bdrnode_conflict_resolvers", + "bdrnode_group": "/pgd/6.0/reference/catalogs-visible#bdrnode_group", + "bdrnode_group_replication_sets": "/pgd/6.0/reference/catalogs-visible#bdrnode_group_replication_sets", + "bdrnode_group_summary": "/pgd/6.0/reference/catalogs-visible#bdrnode_group_summary", + "bdrnode_local_info": "/pgd/6.0/reference/catalogs-visible#bdrnode_local_info", + "bdrnode_log_config": "/pgd/6.0/reference/catalogs-visible#bdrnode_log_config", + "bdrnode_peer_progress": "/pgd/6.0/reference/catalogs-visible#bdrnode_peer_progress", + "bdrnode_replication_rates": "/pgd/6.0/reference/catalogs-visible#bdrnode_replication_rates", + "bdrnode_slots": "/pgd/6.0/reference/catalogs-visible#bdrnode_slots", + "bdrnode_summary": "/pgd/6.0/reference/catalogs-visible#bdrnode_summary", + "bdrqueue": "/pgd/6.0/reference/catalogs-visible#bdrqueue", + "bdrreplication_set": "/pgd/6.0/reference/catalogs-visible#bdrreplication_set", + "bdrreplication_set_table": "/pgd/6.0/reference/catalogs-visible#bdrreplication_set_table", + "bdrreplication_set_ddl": "/pgd/6.0/reference/catalogs-visible#bdrreplication_set_ddl", + "bdrreplication_sets": "/pgd/6.0/reference/catalogs-visible#bdrreplication_sets", + "bdrschema_changes": "/pgd/6.0/reference/catalogs-visible#bdrschema_changes", + "bdrsequence_alloc": "/pgd/6.0/reference/catalogs-visible#bdrsequence_alloc", + "bdrsequences": "/pgd/6.0/reference/catalogs-visible#bdrsequences", + "bdrstat_activity": "/pgd/6.0/reference/catalogs-visible#bdrstat_activity", + "bdrstat_activity-additional-columns": "/pgd/6.0/reference/catalogs-visible#bdrstat_activity-additional-columns", + "bdrstat_commit_scope": "/pgd/6.0/reference/catalogs-visible#bdrstat_commit_scope", + "bdrstat_commit_scope_state": "/pgd/6.0/reference/catalogs-visible#bdrstat_commit_scope_state", + "bdrstat_connection_manager": "/pgd/6.0/reference/catalogs-visible#bdrstat_connection_manager", + "bdrstat_connection_manager_connections": "/pgd/6.0/reference/catalogs-visible#bdrstat_connection_manager_connections", + "bdrstat_connection_manager_node_stats": "/pgd/6.0/reference/catalogs-visible#bdrstat_connection_manager_node_stats", + "bdrstat_connection_manager_hba_file_rules": "/pgd/6.0/reference/catalogs-visible#bdrstat_connection_manager_hba_file_rules", + "bdrstat_raft_followers_state": "/pgd/6.0/reference/catalogs-visible#bdrstat_raft_followers_state", + "bdrstat_raft_state": "/pgd/6.0/reference/catalogs-visible#bdrstat_raft_state", + "bdrstat_receiver": "/pgd/6.0/reference/catalogs-visible#bdrstat_receiver", + "bdrstat_relation": "/pgd/6.0/reference/catalogs-visible#bdrstat_relation", + "bdrstat_routing_candidate_state": "/pgd/6.0/reference/catalogs-visible#bdrstat_routing_candidate_state", + "bdrstat_routing_state": "/pgd/6.0/reference/catalogs-visible#bdrstat_routing_state", + "bdrstat_subscription": "/pgd/6.0/reference/catalogs-visible#bdrstat_subscription", + "bdrstat_worker": "/pgd/6.0/reference/catalogs-visible#bdrstat_worker", + "bdrstat_writer": "/pgd/6.0/reference/catalogs-visible#bdrstat_writer", + "bdrsubscription": "/pgd/6.0/reference/catalogs-visible#bdrsubscription", + "bdrsubscription_summary": "/pgd/6.0/reference/catalogs-visible#bdrsubscription_summary", + "bdrtables": "/pgd/6.0/reference/catalogs-visible#bdrtables", + "bdrtaskmgr_work_queue": "/pgd/6.0/reference/catalogs-visible#bdrtaskmgr_work_queue", + "bdrtaskmgr_workitem_status": "/pgd/6.0/reference/catalogs-visible#bdrtaskmgr_workitem_status", + "bdrtaskmgr_local_work_queue": "/pgd/6.0/reference/catalogs-visible#bdrtaskmgr_local_work_queue", + "bdrtaskmgr_local_workitem_status": "/pgd/6.0/reference/catalogs-visible#bdrtaskmgr_local_workitem_status", + "bdrtrigger": "/pgd/6.0/reference/catalogs-visible#bdrtrigger", + "bdrtriggers": "/pgd/6.0/reference/catalogs-visible#bdrtriggers", + "bdrworkers": "/pgd/6.0/reference/catalogs-visible#bdrworkers", + "bdrwriters": "/pgd/6.0/reference/catalogs-visible#bdrwriters", + "bdrworker_tasks": "/pgd/6.0/reference/catalogs-visible#bdrworker_tasks", + "bdrbdr_version": "/pgd/6.0/reference/functions#bdrbdr_version", + "bdrbdr_version_num": "/pgd/6.0/reference/functions#bdrbdr_version_num", + "bdrget_relation_stats": "/pgd/6.0/reference/functions#bdrget_relation_stats", + "bdrget_subscription_stats": "/pgd/6.0/reference/functions#bdrget_subscription_stats", + "bdrlocal_node_id": "/pgd/6.0/reference/functions#bdrlocal_node_id", + "bdrlast_committed_lsn": "/pgd/6.0/reference/functions#bdrlast_committed_lsn", + "transaction_id": "/pgd/6.0/reference/functions#transaction_id", + "bdris_node_connected": "/pgd/6.0/reference/functions#bdris_node_connected", + "bdris_node_ready": "/pgd/6.0/reference/functions#bdris_node_ready", + "bdrconsensus_disable": "/pgd/6.0/reference/functions#bdrconsensus_disable", + "bdrconsensus_enable": "/pgd/6.0/reference/functions#bdrconsensus_enable", + "bdrconsensus_proto_version": "/pgd/6.0/reference/functions#bdrconsensus_proto_version", + "bdrconsensus_snapshot_export": "/pgd/6.0/reference/functions#bdrconsensus_snapshot_export", + "bdrconsensus_snapshot_import": "/pgd/6.0/reference/functions#bdrconsensus_snapshot_import", + "bdrconsensus_snapshot_verify": "/pgd/6.0/reference/functions#bdrconsensus_snapshot_verify", + "bdrget_consensus_status": "/pgd/6.0/reference/functions#bdrget_consensus_status", + "bdrget_raft_status": "/pgd/6.0/reference/functions#bdrget_raft_status", + "bdrraft_leadership_transfer": "/pgd/6.0/reference/functions#bdrraft_leadership_transfer", + "bdrwait_slot_confirm_lsn": "/pgd/6.0/reference/functions#bdrwait_slot_confirm_lsn", + "bdrwait_node_confirm_lsn": "/pgd/6.0/reference/functions#bdrwait_node_confirm_lsn", + "bdrwait_for_apply_queue": "/pgd/6.0/reference/functions#bdrwait_for_apply_queue", + "bdrget_node_sub_receive_lsn": "/pgd/6.0/reference/functions#bdrget_node_sub_receive_lsn", + "bdrget_node_sub_apply_lsn": "/pgd/6.0/reference/functions#bdrget_node_sub_apply_lsn", + "bdrreplicate_ddl_command": "/pgd/6.0/reference/functions#bdrreplicate_ddl_command", + "bdrrun_on_all_nodes": "/pgd/6.0/reference/functions#bdrrun_on_all_nodes", + "bdrrun_on_nodes": "/pgd/6.0/reference/functions#bdrrun_on_nodes", + "bdrrun_on_group": "/pgd/6.0/reference/functions#bdrrun_on_group", + "bdrglobal_lock_table": "/pgd/6.0/reference/functions#bdrglobal_lock_table", + "bdrwait_for_xid_progress": "/pgd/6.0/reference/functions#bdrwait_for_xid_progress", + "bdrlocal_group_slot_name": "/pgd/6.0/reference/functions#bdrlocal_group_slot_name", + "bdrnode_group_type": "/pgd/6.0/reference/functions#bdrnode_group_type", + "bdralter_node_kind": "/pgd/6.0/reference/functions#bdralter_node_kind", + "bdralter_subscription_skip_changes_upto": "/pgd/6.0/reference/functions#bdralter_subscription_skip_changes_upto", + "bdrglobal_advisory_lock": "/pgd/6.0/reference/functions#bdrglobal_advisory_lock", + "bdrglobal_advisory_unlock": "/pgd/6.0/reference/functions#bdrglobal_advisory_unlock", + "bdrmonitor_group_versions": "/pgd/6.0/reference/functions#bdrmonitor_group_versions", + "bdrmonitor_group_raft": "/pgd/6.0/reference/functions#bdrmonitor_group_raft", + "bdrmonitor_local_replslots": "/pgd/6.0/reference/functions#bdrmonitor_local_replslots", + "bdrwal_sender_stats": "/pgd/6.0/reference/functions#bdrwal_sender_stats", + "bdrget_decoding_worker_stat": "/pgd/6.0/reference/functions#bdrget_decoding_worker_stat", + "bdrlag_control": "/pgd/6.0/reference/functions#bdrlag_control", + "bdris_camo_partner_connected": "/pgd/6.0/reference/functions#bdris_camo_partner_connected", + "bdris_camo_partner_ready": "/pgd/6.0/reference/functions#bdris_camo_partner_ready", + "bdrget_configured_camo_partner": "/pgd/6.0/reference/functions#bdrget_configured_camo_partner", + "bdrwait_for_camo_partner_queue": "/pgd/6.0/reference/functions#bdrwait_for_camo_partner_queue", + "bdrcamo_transactions_resolved": "/pgd/6.0/reference/functions#bdrcamo_transactions_resolved", + "bdrlogical_transaction_status": "/pgd/6.0/reference/functions#bdrlogical_transaction_status", + "bdradd_commit_scope": "/pgd/6.0/reference/functions#bdradd_commit_scope", + "bdrcreate_commit_scope": "/pgd/6.0/reference/functions#bdrcreate_commit_scope", + "bdralter_commit_scope": "/pgd/6.0/reference/functions#bdralter_commit_scope", + "bdrdrop_commit_scope": "/pgd/6.0/reference/functions#bdrdrop_commit_scope", + "bdrremove_commit_scope": "/pgd/6.0/reference/functions#bdrremove_commit_scope", + "bdrdefault_conflict_detection": "/pgd/6.0/reference/pgd-settings#bdrdefault_conflict_detection", + "bdrdefault_sequence_kind": "/pgd/6.0/reference/pgd-settings#bdrdefault_sequence_kind", + "bdrdefault_replica_identity": "/pgd/6.0/reference/pgd-settings#bdrdefault_replica_identity", + "bdrrole_replication": "/pgd/6.0/reference/pgd-settings#bdrrole_replication", + "bdrddl_locking": "/pgd/6.0/reference/pgd-settings#bdrddl_locking", + "bdrtruncate_locking": "/pgd/6.0/reference/pgd-settings#bdrtruncate_locking", + "bdrglobal_lock_max_locks": "/pgd/6.0/reference/pgd-settings#bdrglobal_lock_max_locks", + "bdrglobal_lock_timeout": "/pgd/6.0/reference/pgd-settings#bdrglobal_lock_timeout", + "bdrglobal_lock_statement_timeout": "/pgd/6.0/reference/pgd-settings#bdrglobal_lock_statement_timeout", + "bdrglobal_lock_idle_timeout": "/pgd/6.0/reference/pgd-settings#bdrglobal_lock_idle_timeout", + "bdrlock_table_locking": "/pgd/6.0/reference/pgd-settings#bdrlock_table_locking", + "bdrpredictive_checks": "/pgd/6.0/reference/pgd-settings#bdrpredictive_checks", + "bdrreplay_progress_frequency": "/pgd/6.0/reference/pgd-settings#bdrreplay_progress_frequency", + "bdrstandby_slot_names": "/pgd/6.0/reference/pgd-settings#bdrstandby_slot_names", + "bdrwriters_per_subscription": "/pgd/6.0/reference/pgd-settings#bdrwriters_per_subscription", + "bdrmax_writers_per_subscription": "/pgd/6.0/reference/pgd-settings#bdrmax_writers_per_subscription", + "bdrxact_replication": "/pgd/6.0/reference/pgd-settings#bdrxact_replication", + "bdrpermit_unsafe_commands": "/pgd/6.0/reference/pgd-settings#bdrpermit_unsafe_commands", + "bdrbatch_inserts": "/pgd/6.0/reference/pgd-settings#bdrbatch_inserts", + "bdrmaximum_clock_skew": "/pgd/6.0/reference/pgd-settings#bdrmaximum_clock_skew", + "bdrmaximum_clock_skew_action": "/pgd/6.0/reference/pgd-settings#bdrmaximum_clock_skew_action", + "bdraccept_connections": "/pgd/6.0/reference/pgd-settings#bdraccept_connections", + "bdrstandby_slots_min_confirmed": "/pgd/6.0/reference/pgd-settings#bdrstandby_slots_min_confirmed", + "bdrwriter_input_queue_size": "/pgd/6.0/reference/pgd-settings#bdrwriter_input_queue_size", + "bdrwriter_output_queue_size": "/pgd/6.0/reference/pgd-settings#bdrwriter_output_queue_size", + "bdrmin_worker_backoff_delay": "/pgd/6.0/reference/pgd-settings#bdrmin_worker_backoff_delay", + "bdrcrdt_raw_value": "/pgd/6.0/reference/pgd-settings#bdrcrdt_raw_value", + "bdrcommit_scope": "/pgd/6.0/reference/pgd-settings#bdrcommit_scope", + "bdrcamo_local_mode_delay": "/pgd/6.0/reference/pgd-settings#bdrcamo_local_mode_delay", + "bdrcamo_enable_client_warnings": "/pgd/6.0/reference/pgd-settings#bdrcamo_enable_client_warnings", + "bdrdefault_streaming_mode": "/pgd/6.0/reference/pgd-settings#bdrdefault_streaming_mode", + "bdrlag_control_max_commit_delay": "/pgd/6.0/reference/pgd-settings#bdrlag_control_max_commit_delay", + "bdrlag_control_max_lag_size": "/pgd/6.0/reference/pgd-settings#bdrlag_control_max_lag_size", + "bdrlag_control_max_lag_time": "/pgd/6.0/reference/pgd-settings#bdrlag_control_max_lag_time", + "bdrlag_control_min_conforming_nodes": "/pgd/6.0/reference/pgd-settings#bdrlag_control_min_conforming_nodes", + "bdrlag_control_commit_delay_adjust": "/pgd/6.0/reference/pgd-settings#bdrlag_control_commit_delay_adjust", + "bdrlag_control_sample_interval": "/pgd/6.0/reference/pgd-settings#bdrlag_control_sample_interval", + "bdrlag_control_commit_delay_start": "/pgd/6.0/reference/pgd-settings#bdrlag_control_commit_delay_start", + "bdrtimestamp_snapshot_keep": "/pgd/6.0/reference/pgd-settings#bdrtimestamp_snapshot_keep", + "bdrdebug_level": "/pgd/6.0/reference/pgd-settings#bdrdebug_level", + "bdrtrace_level": "/pgd/6.0/reference/pgd-settings#bdrtrace_level", + "bdrtrack_subscription_apply": "/pgd/6.0/reference/pgd-settings#bdrtrack_subscription_apply", + "bdrtrack_relation_apply": "/pgd/6.0/reference/pgd-settings#bdrtrack_relation_apply", + "bdrtrack_apply_lock_timing": "/pgd/6.0/reference/pgd-settings#bdrtrack_apply_lock_timing", + "bdrenable_wal_decoder": "/pgd/6.0/reference/pgd-settings#bdrenable_wal_decoder", + "bdrreceive_lcr": "/pgd/6.0/reference/pgd-settings#bdrreceive_lcr", + "bdrlcr_cleanup_interval": "/pgd/6.0/reference/pgd-settings#bdrlcr_cleanup_interval", + "bdrglobal_connection_timeout": "/pgd/6.0/reference/pgd-settings#bdrglobal_connection_timeout", + "bdrglobal_keepalives": "/pgd/6.0/reference/pgd-settings#bdrglobal_keepalives", + "bdrglobal_keepalives_idle": "/pgd/6.0/reference/pgd-settings#bdrglobal_keepalives_idle", + "bdrglobal_keepalives_interval": "/pgd/6.0/reference/pgd-settings#bdrglobal_keepalives_interval", + "bdrglobal_keepalives_count": "/pgd/6.0/reference/pgd-settings#bdrglobal_keepalives_count", + "bdrglobal_tcp_user_timeout": "/pgd/6.0/reference/pgd-settings#bdrglobal_tcp_user_timeout", + "bdrforce_full_mesh": "/pgd/6.0/reference/pgd-settings#bdrforce_full_mesh", + "bdrraft_global_election_timeout": "/pgd/6.0/reference/pgd-settings#bdrraft_global_election_timeout", + "bdrraft_group_election_timeout": "/pgd/6.0/reference/pgd-settings#bdrraft_group_election_timeout", + "bdrraft_response_timeout": "/pgd/6.0/reference/pgd-settings#bdrraft_response_timeout", + "bdrraft_keep_min_entries": "/pgd/6.0/reference/pgd-settings#bdrraft_keep_min_entries", + "bdrraft_log_min_apply_duration": "/pgd/6.0/reference/pgd-settings#bdrraft_log_min_apply_duration", + "bdrraft_log_min_message_duration": "/pgd/6.0/reference/pgd-settings#bdrraft_log_min_message_duration", + "bdrraft_group_max_connections": "/pgd/6.0/reference/pgd-settings#bdrraft_group_max_connections", + "bdrbackwards_compatibility": "/pgd/6.0/reference/pgd-settings#bdrbackwards_compatibility", + "bdrtrack_replication_estimates": "/pgd/6.0/reference/pgd-settings#bdrtrack_replication_estimates", + "bdrlag_tracker_apply_rate_weight": "/pgd/6.0/reference/pgd-settings#bdrlag_tracker_apply_rate_weight", + "bdrenable_auto_sync_reconcile": "/pgd/6.0/reference/pgd-settings#bdrenable_auto_sync_reconcile", + "list-of-node-states": "/pgd/6.0/reference/nodes#list-of-node-states", + "node-management-commands": "/pgd/6.0/reference/nodes#node-management-commands", + "bdr_init_physical": "/pgd/6.0/reference/nodes#bdr_init_physical", + "bdr_config": "/pgd/6.0/reference/nodes#bdr_config", + "bdralter_node_group_option": "/pgd/6.0/reference/nodes-management-interfaces#bdralter_node_group_option", + "bdralter_node_interface": "/pgd/6.0/reference/nodes-management-interfaces#bdralter_node_interface", + "bdralter_node_option": "/pgd/6.0/reference/nodes-management-interfaces#bdralter_node_option", + "bdralter_subscription_enable": "/pgd/6.0/reference/nodes-management-interfaces#bdralter_subscription_enable", + "bdralter_subscription_disable": "/pgd/6.0/reference/nodes-management-interfaces#bdralter_subscription_disable", + "bdrcreate_node": "/pgd/6.0/reference/nodes-management-interfaces#bdrcreate_node", + "bdrcreate_node_group": "/pgd/6.0/reference/nodes-management-interfaces#bdrcreate_node_group", + "bdrdrop_node_group": "/pgd/6.0/reference/nodes-management-interfaces#bdrdrop_node_group", + "bdrjoin_node_group": "/pgd/6.0/reference/nodes-management-interfaces#bdrjoin_node_group", + "bdrpart_node": "/pgd/6.0/reference/nodes-management-interfaces#bdrpart_node", + "bdrpromote_node": "/pgd/6.0/reference/nodes-management-interfaces#bdrpromote_node", + "bdrswitch_node_group": "/pgd/6.0/reference/nodes-management-interfaces#bdrswitch_node_group", + "bdrwait_for_join_completion": "/pgd/6.0/reference/nodes-management-interfaces#bdrwait_for_join_completion", + "bdralter_node_group_config": "/pgd/6.0/reference/nodes-management-interfaces#bdralter_node_group_config", + "bdrcreate_proxy": "/pgd/6.0/reference/routing#bdrcreate_proxy", + "bdralter_proxy_option": "/pgd/6.0/reference/routing#bdralter_proxy_option", + "bdrdrop_proxy": "/pgd/6.0/reference/routing#bdrdrop_proxy", + "bdrrouting_leadership_transfer": "/pgd/6.0/reference/routing#bdrrouting_leadership_transfer", + "cs.commit-scope-syntax": "/pgd/6.0/reference/commit-scopes#commit-scope-syntax", + "cs.commit_scope_degrade_operation": "/pgd/6.0/reference/commit-scopes#commit_scope_degrade_operation", + "cs.commit-scope-targets": "/pgd/6.0/reference/commit-scopes#commit-scope-targets", + "cs.origin_group": "/pgd/6.0/reference/commit-scopes#origin_group", + "cs.commit-scope-groups": "/pgd/6.0/reference/commit-scopes#commit-scope-groups", + "cs.any": "/pgd/6.0/reference/commit-scopes#any", + "cs.any-not": "/pgd/6.0/reference/commit-scopes#any-not", + "cs.majority": "/pgd/6.0/reference/commit-scopes#majority", + "cs.majority-not": "/pgd/6.0/reference/commit-scopes#majority-not", + "cs.all": "/pgd/6.0/reference/commit-scopes#all", + "cs.all-not": "/pgd/6.0/reference/commit-scopes#all-not", + "cs.confirmation-level": "/pgd/6.0/reference/commit-scopes#confirmation-level", + "cs.on-received": "/pgd/6.0/reference/commit-scopes#on-received", + "cs.on-replicated": "/pgd/6.0/reference/commit-scopes#on-replicated", + "cs.on-durable": "/pgd/6.0/reference/commit-scopes#on-durable", + "cs.on-visible": "/pgd/6.0/reference/commit-scopes#on-visible", + "cs.commit-scope-kinds": "/pgd/6.0/reference/commit-scopes#commit-scope-kinds", + "cs.synchronous-commit": "/pgd/6.0/reference/commit-scopes#synchronous-commit", + "cs.degrade-on-parameters": "/pgd/6.0/reference/commit-scopes#degrade-on-parameters", + "cs.group-commit": "/pgd/6.0/reference/commit-scopes#group-commit", + "cs.group-commit-parameters": "/pgd/6.0/reference/commit-scopes#group-commit-parameters", + "cs.abort-on-parameters": "/pgd/6.0/reference/commit-scopes#abort-on-parameters", + "cs.transaction_tracking-settings": "/pgd/6.0/reference/commit-scopes#transaction_tracking-settings", + "cs.conflict_resolution-settings": "/pgd/6.0/reference/commit-scopes#conflict_resolution-settings", + "cs.commit_decision-settings": "/pgd/6.0/reference/commit-scopes#commit_decision-settings", + "cs.commit_scope_degrade_operation-settings": "/pgd/6.0/reference/commit-scopes#commit_scope_degrade_operation-settings", + "cs.camo": "/pgd/6.0/reference/commit-scopes#camo", + "cs.lag-control": "/pgd/6.0/reference/commit-scopes#lag-control", + "cs.lag-control-parameters": "/pgd/6.0/reference/commit-scopes#lag-control-parameters", + "conflict-detection": "/pgd/6.0/reference/conflicts#conflict-detection", + "list-of-conflict-types": "/pgd/6.0/reference/conflicts#list-of-conflict-types", + "conflict-resolution": "/pgd/6.0/reference/conflicts#conflict-resolution", + "list-of-conflict-resolvers": "/pgd/6.0/reference/conflicts#list-of-conflict-resolvers", + "default-conflict-resolvers": "/pgd/6.0/reference/conflicts#default-conflict-resolvers", + "list-of-conflict-resolutions": "/pgd/6.0/reference/conflicts#list-of-conflict-resolutions", + "conflict-logging": "/pgd/6.0/reference/conflicts#conflict-logging", + "bdralter_table_conflict_detection": "/pgd/6.0/reference/conflict_functions#bdralter_table_conflict_detection", + "bdralter_node_set_conflict_resolver": "/pgd/6.0/reference/conflict_functions#bdralter_node_set_conflict_resolver", + "bdralter_node_set_log_config": "/pgd/6.0/reference/conflict_functions#bdralter_node_set_log_config", + "bdrcreate_replication_set": "/pgd/6.0/reference/repsets-management#bdrcreate_replication_set", + "bdralter_replication_set": "/pgd/6.0/reference/repsets-management#bdralter_replication_set", + "bdrdrop_replication_set": "/pgd/6.0/reference/repsets-management#bdrdrop_replication_set", + "bdralter_node_replication_sets": "/pgd/6.0/reference/repsets-management#bdralter_node_replication_sets", + "bdrreplication_set_add_table": "/pgd/6.0/reference/repsets-membership#bdrreplication_set_add_table", + "bdrreplication_set_remove_table": "/pgd/6.0/reference/repsets-membership#bdrreplication_set_remove_table", + "bdrreplication_set_add_ddl_filter": "/pgd/6.0/reference/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter", + "bdrreplication_set_remove_ddl_filter": "/pgd/6.0/reference/repsets-ddl-filtering#bdrreplication_set_remove_ddl_filter", + "pgd_bench": "/pgd/6.0/reference/testingandtuning#pgd_bench", + "bdralter_sequence_set_kind": "/pgd/6.0/reference/sequences#bdralter_sequence_set_kind", + "bdrextract_timestamp_from_snowflakeid": "/pgd/6.0/reference/sequences#bdrextract_timestamp_from_snowflakeid", + "bdrextract_nodeid_from_snowflakeid": "/pgd/6.0/reference/sequences#bdrextract_nodeid_from_snowflakeid", + "bdrextract_localseqid_from_snowflakeid": "/pgd/6.0/reference/sequences#bdrextract_localseqid_from_snowflakeid", + "bdrtimestamp_to_snowflakeid": "/pgd/6.0/reference/sequences#bdrtimestamp_to_snowflakeid", + "bdrextract_timestamp_from_timeshard": "/pgd/6.0/reference/sequences#bdrextract_timestamp_from_timeshard", + "bdrextract_nodeid_from_timeshard": "/pgd/6.0/reference/sequences#bdrextract_nodeid_from_timeshard", + "bdrextract_localseqid_from_timeshard": "/pgd/6.0/reference/sequences#bdrextract_localseqid_from_timeshard", + "bdrtimestamp_to_timeshard": "/pgd/6.0/reference/sequences#bdrtimestamp_to_timeshard", + "bdrgen_ksuuid_v2": "/pgd/6.0/reference/sequences#bdrgen_ksuuid_v2", + "bdrksuuid_v2_cmp": "/pgd/6.0/reference/sequences#bdrksuuid_v2_cmp", + "bdrextract_timestamp_from_ksuuid_v2": "/pgd/6.0/reference/sequences#bdrextract_timestamp_from_ksuuid_v2", + "bdrgen_ksuuid": "/pgd/6.0/reference/sequences#bdrgen_ksuuid", + "bdruuid_v1_cmp": "/pgd/6.0/reference/sequences#bdruuid_v1_cmp", + "bdrextract_timestamp_from_ksuuid": "/pgd/6.0/reference/sequences#bdrextract_timestamp_from_ksuuid", + "bdrautopartition": "/pgd/6.0/reference/autopartition#bdrautopartition", + "bdrdrop_autopartition": "/pgd/6.0/reference/autopartition#bdrdrop_autopartition", + "bdrautopartition_wait_for_partitions": "/pgd/6.0/reference/autopartition#bdrautopartition_wait_for_partitions", + "bdrautopartition_wait_for_partitions_on_all_nodes": "/pgd/6.0/reference/autopartition#bdrautopartition_wait_for_partitions_on_all_nodes", + "bdrautopartition_find_partition": "/pgd/6.0/reference/autopartition#bdrautopartition_find_partition", + "bdrautopartition_enable": "/pgd/6.0/reference/autopartition#bdrautopartition_enable", + "bdrautopartition_disable": "/pgd/6.0/reference/autopartition#bdrautopartition_disable", + "internal-functions": "/pgd/6.0/reference/autopartition#internal-functions", + "bdrautopartition_create_partition": "/pgd/6.0/reference/autopartition#bdrautopartition_create_partition", + "bdrautopartition_drop_partition": "/pgd/6.0/reference/autopartition#bdrautopartition_drop_partition", + "bdrcreate_conflict_trigger": "/pgd/6.0/reference/streamtriggers/interfaces#bdrcreate_conflict_trigger", + "bdrcreate_transform_trigger": "/pgd/6.0/reference/streamtriggers/interfaces#bdrcreate_transform_trigger", + "bdrdrop_trigger": "/pgd/6.0/reference/streamtriggers/interfaces#bdrdrop_trigger", + "bdrtrigger_get_row": "/pgd/6.0/reference/streamtriggers/rowfunctions#bdrtrigger_get_row", + "bdrtrigger_get_committs": "/pgd/6.0/reference/streamtriggers/rowfunctions#bdrtrigger_get_committs", + "bdrtrigger_get_xid": "/pgd/6.0/reference/streamtriggers/rowfunctions#bdrtrigger_get_xid", + "bdrtrigger_get_type": "/pgd/6.0/reference/streamtriggers/rowfunctions#bdrtrigger_get_type", + "bdrtrigger_get_conflict_type": "/pgd/6.0/reference/streamtriggers/rowfunctions#bdrtrigger_get_conflict_type", + "bdrtrigger_get_origin_node_id": "/pgd/6.0/reference/streamtriggers/rowfunctions#bdrtrigger_get_origin_node_id", + "bdrri_fkey_on_del_trigger": "/pgd/6.0/reference/streamtriggers/rowfunctions#bdrri_fkey_on_del_trigger", + "tg_name": "/pgd/6.0/reference/streamtriggers/rowvariables#tg_name", + "tg_when": "/pgd/6.0/reference/streamtriggers/rowvariables#tg_when", + "tg_level": "/pgd/6.0/reference/streamtriggers/rowvariables#tg_level", + "tg_op": "/pgd/6.0/reference/streamtriggers/rowvariables#tg_op", + "tg_relid": "/pgd/6.0/reference/streamtriggers/rowvariables#tg_relid", + "tg_table_name": "/pgd/6.0/reference/streamtriggers/rowvariables#tg_table_name", + "tg_table_schema": "/pgd/6.0/reference/streamtriggers/rowvariables#tg_table_schema", + "tg_nargs": "/pgd/6.0/reference/streamtriggers/rowvariables#tg_nargs", + "tg_argv": "/pgd/6.0/reference/streamtriggers/rowvariables#tg_argv", + "bdrautopartition_partitions": "/pgd/6.0/reference/catalogs-internal#bdrautopartition_partitions", + "bdrautopartition_rules": "/pgd/6.0/reference/catalogs-internal#bdrautopartition_rules", + "bdrddl_epoch": "/pgd/6.0/reference/catalogs-internal#bdrddl_epoch", + "bdrevent_history": "/pgd/6.0/reference/catalogs-internal#bdrevent_history", + "bdrevent_summary": "/pgd/6.0/reference/catalogs-internal#bdrevent_summary", + "bdrlocal_leader_change": "/pgd/6.0/reference/catalogs-internal#bdrlocal_leader_change", + "bdrnode_config": "/pgd/6.0/reference/catalogs-internal#bdrnode_config", + "bdrnode_config_summary": "/pgd/6.0/reference/catalogs-internal#bdrnode_config_summary", + "bdrnode_group_config": "/pgd/6.0/reference/catalogs-internal#bdrnode_group_config", + "bdrnode_group_routing_config_summary": "/pgd/6.0/reference/catalogs-internal#bdrnode_group_routing_config_summary", + "bdrnode_group_routing_info": "/pgd/6.0/reference/catalogs-internal#bdrnode_group_routing_info", + "bdrnode_group_routing_summary": "/pgd/6.0/reference/catalogs-internal#bdrnode_group_routing_summary", + "bdrnode_routing_config_summary": "/pgd/6.0/reference/catalogs-internal#bdrnode_routing_config_summary", + "bdrproxy_config": "/pgd/6.0/reference/catalogs-internal#bdrproxy_config", + "bdrproxy_config_summary": "/pgd/6.0/reference/catalogs-internal#bdrproxy_config_summary", + "bdrsequence_kind": "/pgd/6.0/reference/catalogs-internal#bdrsequence_kind", + "bdrsync_node_requests": "/pgd/6.0/reference/catalogs-internal#bdrsync_node_requests", + "bdrsync_node_requests_summary": "/pgd/6.0/reference/catalogs-internal#bdrsync_node_requests_summary", + "bdrbdr_get_commit_decisions": "/pgd/6.0/reference/functions-internal#bdrbdr_get_commit_decisions", + "bdrbdr_track_commit_decision": "/pgd/6.0/reference/functions-internal#bdrbdr_track_commit_decision", + "bdrconsensus_kv_fetch": "/pgd/6.0/reference/functions-internal#bdrconsensus_kv_fetch", + "bdrconsensus_kv_store": "/pgd/6.0/reference/functions-internal#bdrconsensus_kv_store", + "bdrdecode_message_payload": "/pgd/6.0/reference/functions-internal#bdrdecode_message_payload", + "bdrdecode_message_response_payload": "/pgd/6.0/reference/functions-internal#bdrdecode_message_response_payload", + "bdrdifference_fix_origin_create": "/pgd/6.0/reference/functions-internal#bdrdifference_fix_origin_create", + "bdrdifference_fix_session_reset": "/pgd/6.0/reference/functions-internal#bdrdifference_fix_session_reset", + "bdrdifference_fix_session_setup": "/pgd/6.0/reference/functions-internal#bdrdifference_fix_session_setup", + "bdrdifference_fix_xact_set_avoid_conflict": "/pgd/6.0/reference/functions-internal#bdrdifference_fix_xact_set_avoid_conflict", + "bdrdrop_node": "/pgd/6.0/reference/functions-internal#bdrdrop_node", + "bdrget_global_locks": "/pgd/6.0/reference/functions-internal#bdrget_global_locks", + "bdrget_node_conflict_resolvers": "/pgd/6.0/reference/functions-internal#bdrget_node_conflict_resolvers", + "bdrget_slot_flush_timestamp": "/pgd/6.0/reference/functions-internal#bdrget_slot_flush_timestamp", + "bdrinternal_alter_sequence_set_kind": "/pgd/6.0/reference/functions-internal#bdrinternal_alter_sequence_set_kind", + "bdrinternal_replication_set_add_table": "/pgd/6.0/reference/functions-internal#bdrinternal_replication_set_add_table", + "bdrinternal_replication_set_remove_table": "/pgd/6.0/reference/functions-internal#bdrinternal_replication_set_remove_table", + "bdrinternal_submit_join_request": "/pgd/6.0/reference/functions-internal#bdrinternal_submit_join_request", + "bdrisolation_test_session_is_blocked": "/pgd/6.0/reference/functions-internal#bdrisolation_test_session_is_blocked", + "bdrlocal_node_info": "/pgd/6.0/reference/functions-internal#bdrlocal_node_info", + "bdrmsgb_connect": "/pgd/6.0/reference/functions-internal#bdrmsgb_connect", + "bdrmsgb_deliver_message": "/pgd/6.0/reference/functions-internal#bdrmsgb_deliver_message", + "bdrnode_catchup_state_name": "/pgd/6.0/reference/functions-internal#bdrnode_catchup_state_name", + "bdrnode_kind_name": "/pgd/6.0/reference/functions-internal#bdrnode_kind_name", + "bdrpeer_state_name": "/pgd/6.0/reference/functions-internal#bdrpeer_state_name", + "bdrpg_xact_origin": "/pgd/6.0/reference/functions-internal#bdrpg_xact_origin", + "bdrrequest_replay_progress_update": "/pgd/6.0/reference/functions-internal#bdrrequest_replay_progress_update", + "bdrreset_relation_stats": "/pgd/6.0/reference/functions-internal#bdrreset_relation_stats", + "bdrreset_subscription_stats": "/pgd/6.0/reference/functions-internal#bdrreset_subscription_stats", + "bdrresynchronize_table_from_node": "/pgd/6.0/reference/functions-internal#bdrresynchronize_table_from_node", + "bdrseq_currval": "/pgd/6.0/reference/functions-internal#bdrseq_currval", + "bdrseq_lastval": "/pgd/6.0/reference/functions-internal#bdrseq_lastval", + "bdrseq_nextval": "/pgd/6.0/reference/functions-internal#bdrseq_nextval", + "bdrshow_subscription_status": "/pgd/6.0/reference/functions-internal#bdrshow_subscription_status", + "bdrshow_workers": "/pgd/6.0/reference/functions-internal#bdrshow_workers", + "bdrshow_writers": "/pgd/6.0/reference/functions-internal#bdrshow_writers", + "bdrsync_status_name": "/pgd/6.0/reference/functions-internal#bdrsync_status_name", + "bdrtaskmgr_set_leader": "/pgd/6.0/reference/functions-internal#bdrtaskmgr_set_leader", + "bdrtaskmgr_get_last_completed_workitem": "/pgd/6.0/reference/functions-internal#bdrtaskmgr_get_last_completed_workitem", + "bdrtaskmgr_work_queue_check_status": "/pgd/6.0/reference/functions-internal#bdrtaskmgr_work_queue_check_status", + "bdrpglogical_proto_version_ranges": "/pgd/6.0/reference/functions-internal#bdrpglogical_proto_version_ranges", + "bdrget_min_required_replication_slots": "/pgd/6.0/reference/functions-internal#bdrget_min_required_replication_slots", + "bdrget_min_required_worker_processes": "/pgd/6.0/reference/functions-internal#bdrget_min_required_worker_processes", + "bdrstat_get_activity": "/pgd/6.0/reference/functions-internal#bdrstat_get_activity", + "bdrworker_role_id_name": "/pgd/6.0/reference/functions-internal#bdrworker_role_id_name", + "bdrlag_history": "/pgd/6.0/reference/functions-internal#bdrlag_history", + "bdrget_raft_instance_by_nodegroup": "/pgd/6.0/reference/functions-internal#bdrget_raft_instance_by_nodegroup", + "bdrmonitor_camo_on_all_nodes": "/pgd/6.0/reference/functions-internal#bdrmonitor_camo_on_all_nodes", + "bdrmonitor_raft_details_on_all_nodes": "/pgd/6.0/reference/functions-internal#bdrmonitor_raft_details_on_all_nodes", + "bdrmonitor_replslots_details_on_all_nodes": "/pgd/6.0/reference/functions-internal#bdrmonitor_replslots_details_on_all_nodes", + "bdrmonitor_subscription_details_on_all_nodes": "/pgd/6.0/reference/functions-internal#bdrmonitor_subscription_details_on_all_nodes", + "bdrmonitor_version_details_on_all_nodes": "/pgd/6.0/reference/functions-internal#bdrmonitor_version_details_on_all_nodes", + "bdrnode_group_member_info": "/pgd/6.0/reference/functions-internal#bdrnode_group_member_info", + "bdrcolumn_timestamps_create": "/pgd/6.0/reference/clcd#bdrcolumn_timestamps_create" } \ No newline at end of file diff --git a/product_docs/docs/pgd/6/reference/index.mdx b/product_docs/docs/pgd/6/reference/index.mdx index 45e17f7d1d8..5d5bd097810 100644 --- a/product_docs/docs/pgd/6/reference/index.mdx +++ b/product_docs/docs/pgd/6/reference/index.mdx @@ -81,8 +81,13 @@ The reference section is a definitive listing of all functions, views, and comma * [`bdr.sequence_alloc`](catalogs-visible#bdrsequence_alloc) * [`bdr.sequences`](catalogs-visible#bdrsequences) * [`bdr.stat_activity`](catalogs-visible#bdrstat_activity) + * [`bdr.stat_activity` additional columns](catalogs-visible#bdrstat_activity-additional-columns) * [`bdr.stat_commit_scope`](catalogs-visible#bdrstat_commit_scope) * [`bdr.stat_commit_scope_state`](catalogs-visible#bdrstat_commit_scope_state) + * [`bdr.stat_connection_manager`](catalogs-visible#bdrstat_connection_manager) + * [`bdr.stat_connection_manager_connections`](catalogs-visible#bdrstat_connection_manager_connections) + * [`bdr.stat_connection_manager_node_stats`](catalogs-visible#bdrstat_connection_manager_node_stats) + * [`bdr.stat_connection_manager_hba_file_rules`](catalogs-visible#bdrstat_connection_manager_hba_file_rules) * [`bdr.stat_raft_followers_state`](catalogs-visible#bdrstat_raft_followers_state) * [`bdr.stat_raft_state`](catalogs-visible#bdrstat_raft_state) * [`bdr.stat_receiver`](catalogs-visible#bdrstat_receiver) From 833d0c46b9da83c7e88ca053d4ee11f6b6935b65 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Tue, 22 Apr 2025 10:52:47 +0100 Subject: [PATCH 015/145] First pass changes to support CM Signed-off-by: Dj Walker-Morgan --- .../6/cli/command_ref/group/set-option.mdx | 2 +- .../deploying/04-installing-software.mdx | 277 +++--------------- .../deploying/07-configure-proxies.mdx | 256 ---------------- ...using-pgd-cli.mdx => 07-using-pgd-cli.mdx} | 0 .../deploy-manual/deploying/index.mdx | 3 +- .../pgd/6/reference/catalogs-internal.mdx | 60 +--- .../pgd/6/reference/functions-internal.mdx | 4 - product_docs/docs/pgd/6/reference/index.json | 8 - product_docs/docs/pgd/6/reference/index.mdx | 11 - .../reference/nodes-management-interfaces.mdx | 59 +--- product_docs/docs/pgd/6/reference/routing.mdx | 104 ------- .../pgd/6/security/pgd-predefined-roles.mdx | 1 - .../docs/pgd/6/transaction-streaming.mdx | 6 +- .../docs/pgd/6/upgrades/compatibility.mdx | 6 +- 14 files changed, 49 insertions(+), 748 deletions(-) delete mode 100644 product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx rename product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/{08-using-pgd-cli.mdx => 07-using-pgd-cli.mdx} (100%) delete mode 100644 product_docs/docs/pgd/6/reference/routing.mdx diff --git a/product_docs/docs/pgd/6/cli/command_ref/group/set-option.mdx b/product_docs/docs/pgd/6/cli/command_ref/group/set-option.mdx index d09c7c41925..d07b3351fa2 100644 --- a/product_docs/docs/pgd/6/cli/command_ref/group/set-option.mdx +++ b/product_docs/docs/pgd/6/cli/command_ref/group/set-option.mdx @@ -27,7 +27,7 @@ The following options are available: | apply_delay | The delay in applying changes to the group. | | check_constraints | Whether to check constraints in the group. | | default_commit_scope | The default commit scope of the group. | -| enable_proxy_routing | Whether to enable proxy routing in the group. | +| enable_routing | Whether to enable routing in the group. | | enable_raft | Whether to enable Raft in the group. | | enable_wal_decoder | Whether to enable the WAL decoder in the group. | | location | The location of the group. | diff --git a/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/04-installing-software.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/04-installing-software.mdx index 1384438cf71..ba26fcd2fcd 100644 --- a/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/04-installing-software.mdx +++ b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/04-installing-software.mdx @@ -13,277 +13,76 @@ With the repositories configured, you can now install the Postgres Distributed s You must perform these steps on each host before proceeding to the next step. * **Install the packages.** - * Install the PGD packages, which include a server-specific BDR package and generic PGD Proxy and CLI packages. (`edb-bdr5-`, `edb-pgd5-proxy`, and `edb-pgd5-cli`) - - -* **Ensure the Postgres database server has been initialized and started.** - * Use `systemctl status` to check that the service is running. - * If the service isn't running, initialize the database and start the service. - - -* **Configure the BDR extension.** - * Add the BDR extension (`$libdir/bdr`) at the start of the `shared_preload_libraries` setting in `postgresql.conf`. - * Set the `wal_level` GUC variable to `logical` in `postgresql.conf`. - * Turn on commit timestamp tracking by setting `track_commit_timestamp` to `'on'` in `postgresql.conf`. - * Increase the maximum worker processes to 16 or higher by setting `max_worker_processes` to `'16'` in `postgresql.conf`.

- !!! Note The `max_worker_processes` value - The `max_worker_processes` value is derived from the topology of the cluster, the number of peers, number of databases, and other factors. - To calculate the needed value, see [Postgres configuration/settings](../../../postgres-configuration/#postgres-settings). - The value of 16 was calculated for the size of cluster being deployed in this example. It must be increased for larger clusters. - !!! - * Set a password on the EnterprisedDB/Postgres user. - * Add rules to `pg_hba.conf` to allow nodes to connect to each other. - * Ensure that these lines are present in `pg_hba.conf`: - ``` - host all all all md5 - host replication all all md5 - ``` - * Add a `.pgpass` file to allow nodes to authenticate each other. - * Configure a user with sufficient privileges to log in to the other nodes. - * See [The Password File](https://www.postgresql.org/docs/current/libpq-pgpass.html) in the Postgres documentation for more on the `.pgpass` file. - - -* **Restart the server.** - * Verify the restarted server is running with the modified settings and the BDR extension is available. - - -* **Create the replicated database.** - * Log in to the server's default database (`edb` for EDB Postgres Advanced Server, `postgres` for PGE and community Postgres). - * Use `CREATE DATABASE bdrdb` to create the default PGD replicated database. - * Log out and then log back in to `bdrdb`. - * Use `CREATE EXTENSION bdr` to enable the BDR extension and PGD to run on that database. - - -The worked example that follows shows the steps for EDB Postgres Advanced Server in detail. - -If you're installing PGD with EDB Postgres Extended Server or community Postgres, the steps are similar, but details such as package names and paths are different. These differences are summarized in [Installing PGD for EDB Postgres Extended Server](#installing-pgd-for-edb-postgres-extended-server) and [Installing PGD for Postgresql](#installing-pgd-for-postgresql). + * Install the PGD package which include a server-specific PGD package. (`edb-pgd6-`) that includes the PGD CLI. +* **Switch to the Postgres user.** + * The Postgres user is the system user that runs the database server. + * For EDB Postgres Advanced Server, this is `enterprisedb`. For PostgreSQL, it's `postgres`. +* **Run the PGD CLI command to create a PGD node** + * This command creates a node in the cluster. + * Then it joins the node to the existing cluster (or makes the first node in the cluster). ## Worked example ### Install the packages -The first step is to install the packages. Each Postgres package has an `edb-bdr5-` package to go with it. -For example, if you're installing EDB Postgres Advanced Server (epas) version 16, you'd install `edb-bdr5-epas16`. - -There are two other packages to also install: - -- `edb-pgd5-proxy` for PGD Proxy -- `edb-pgd5-cli` for the PGD command line tool - -To install all of these packages on a RHEL or RHEL compatible Linux, run: - -``` -sudo dnf -y install edb-bdr5-epas16 edb-pgd5-proxy edb-pgd5-cli -``` - -### Ensure the database is initialized and started - -If the server wasn't initialized and started by the database's package initialization (or you're repeating the process), you need to initialize and start the server. - -To see if the server is running, you can check the service. The service name for EDB Advanced Server is `edb-as-16`, so run: - -``` -sudo systemctl status edb-as-16 -``` - -If the server isn't running, the response is: - -``` -○ edb-as-16.service - EDB Postgres Advanced Server 16 - Loaded: loaded (/usr/lib/systemd/system/edb-as-16.service; disabled; preset: disabled) - Active: inactive (dead) -``` - -`Active: inactive (dead)` tells you that you need to initialize and start the server. - -You need to know the path to the setup script for your particular Postgres flavor. - -For EDB Postgres Advanced Server, you can find this script in `/usr/edb/as16/bin` as `edb-as-16-setup`. -Run this command with the `initdb` parameter and pass an option to set the database to use UTF-8: - -``` -sudo PGSETUP_INITDB_OPTIONS="-E UTF-8" /usr/edb/as16/bin/edb-as-16-setup initdb -``` - -Once the database is initialized, start it so that you can continue configuring the BDR extension: - -``` -sudo systemctl start edb-as-16 -``` - -### Configure the BDR extension - -Installing EDB Postgres Advanced Server creates a system user enterprisedb with admin capabilities when connected to the database. You'll use this user to configure the BDR extension. - -#### Preload the BDR library - -You need to preload the BDR library with other libraries. -EDB Postgres Advanced Server has a number of libraries already preloaded, so you have to prefix the existing list with the BDR library. - -``` -echo -e "shared_preload_libraries = '\$libdir/bdr,\$libdir/dbms_pipe,\$libdir/edb_gen,\$libdir/dbms_aq'" | sudo -u enterprisedb tee -a /var/lib/edb/as16/data/postgresql.conf >/dev/null -``` - -!!!tip -This command format (`echo ... | sudo ... tee -a ...`) appends the echoed string to the end of the `postgresql.conf` file, which is owned by another user. -!!! - -#### Set the `wal_level` - -The BDR extension needs to set the server to perform logical replication. Do this by setting `wal_level` to `logical`: - -``` -echo -e "wal_level = 'logical'" | sudo -u enterprisedb tee -a /var/lib/edb/as16/data/postgresql.conf >/dev/null - -``` - -#### Enable commit timestamp tracking +The first step is to install the packages. Each Postgres package has an `edb-pgd17--` package to go with it. +For example, if you're installing EDB Postgres Advanced Server (epas) version 17, you'd install `edb-pgd6-epas17`. -The BDR extension also needs the commit timestamp tracking enabled: + -``` -echo -e "track_commit_timestamp = 'on'" | sudo -u enterprisedb tee -a /var/lib/edb/as16/data/postgresql.conf >/dev/null - -``` - -#### Increase `max_worker_processes` - -To communicate between multiple nodes, Postgres Distributed nodes run more worker processes than usual. -The default limit (8) is too low even for a small cluster. - -The `max_worker_processes` value is derived from the topology of the cluster, the number of peers, number of databases, and other factors. -To calculate the needed value, see [Postgres configuration/settings](../../../postgres-configuration/#postgres-settings). - -This example, with a 3-node cluster, uses the value of 16. + -Increase the maximum number of worker processes to 16: +To install the packages on a RHEL or RHEL compatible Linux, run: +```bash +sudo dnf -y install edb-as17-server +sudo dnf -y install edb-pgd6-epas17 ``` -echo -e "max_worker_processes = '16'" | sudo -u enterprisedb tee -a /var/lib/edb/as16/data/postgresql.conf >/dev/null - -``` - -This value must be increased for larger clusters. + -#### Add a password to the Postgres enterprisedb user + -To allow connections between nodes, a password needs to be set on the Postgres enterprisedb user. -This example uses the password `secret`. -Select a different password for your deployments. -You will need this password to [Enable authentication between nodes](#enable-authentication-between-nodes). +To install the packages on a Debian or Ubuntu Linux, run: +```bash +sudo dnf -y install edb-as17-server +sudo apt-get -y install edb-pgd6-epas17 ``` -sudo -u enterprisedb psql edb -c "ALTER USER enterprisedb WITH PASSWORD 'secret'" -``` + -#### Enable inter-node authentication in pg_hba.conf + -Out of the box, Postgres allows local authentication and connections with the database but not external network connections. -To enable this, edit `pg_hba.conf` and add appropriate rules, including rules for the replication users. -To simplify the process, use this command: +### Switch to the Postgres user -``` -echo -e "host all all all md5\nhost replication all all md5" | sudo tee -a /var/lib/edb/as16/data/pg_hba.conf + -``` - -The command appends the following to `pg_hba.conf`: - -``` -host all all all md5 -host replication all all md5 - -``` - -These commands enable the nodes to replicate. + -#### Enable authentication between nodes - -As part of the process of connecting nodes for replication, PGD logs into other nodes. -It performs that login as the user that Postgres is running under. -For EDB Postgres Advanced server, this is the enterprisedb user. -That user needs credentials to log into the other nodes. -Supply these credentials using the `.pgpass` file, which needs to reside in the user's home directory. -The home directory for `enterprisedb` is `/var/lib/edb`. - -Run this command to create the file: - -``` -echo -e "*:*:*:enterprisedb:secret" | sudo -u enterprisedb tee /var/lib/edb/.pgpass; sudo chmod 0600 /var/lib/edb/.pgpass +To install the packages on a RHEL or RHEL compatible Linux, run: +```bash +sudo dnf -y install edb-as17-server +sudo dnf -y install edb-pgd6-epas17 ``` -You can read more about the `.pgpass` file in [The Password File](https://www.postgresql.org/docs/current/libpq-pgpass.html) in the PostgreSQL documentation. + -### Restart the server + -After all these configuration changes, we recommend that you restart the server with: - -``` -sudo systemctl restart edb-as-16 +To install the packages on a Debian or Ubuntu Linux, run: +```bash +sudo dnf -y install edb-as17-server +sudo apt-get -y install edb-pgd6-epas17 ``` -#### Check the extension has been installed + -At this point, it's worth checking whether the extension is actually available and the configuration was correctly loaded. You can query the `pg_available_extensions` table for the BDR extension like this: + -``` -sudo -u enterprisedb psql edb -c "select * from pg_available_extensions where name like 'bdr'" - -``` - -This command returns an entry for the extension and its version: - -``` - name | default_version | installed_version | comment -------+-----------------+-------------------+------------------------------------------- - bdr | 5.3.0 | | Bi-Directional Replication for PostgreSQL - ``` - -You can also confirm the other server settings using this command: - -``` -sudo -u enterprisedb psql edb -c "show all" | grep -e wal_level -e track_commit_timestamp -e max_worker_processes - -``` - -### Create the replicated database - -The server is now prepared for PGD. -You need to next create a database named `bdrdb` and install the BDR extension when logged into it: - -``` -sudo -u enterprisedb psql edb -c "CREATE DATABASE bdrdb" -sudo -u enterprisedb psql bdrdb -c "CREATE EXTENSION bdr" - -``` - -Finally, test the connection by logging in to the server. - -``` -sudo -u enterprisedb psql bdrdb -``` - -You're connected to the server. -Execute the command "\\dx" to list extensions installed: - -``` -bdrdb=# \dx - List of installed extensions - Name | Version | Schema | Description -------------------+---------+------------+-------------------------------------------------- - bdr | 5.3.0 | pg_catalog | Bi-Directional Replication for PostgreSQL - edb_dblink_libpq | 1.0 | pg_catalog | EnterpriseDB Foreign Data Wrapper for PostgreSQL - edb_dblink_oci | 1.0 | pg_catalog | EnterpriseDB Foreign Data Wrapper for Oracle - edbspl | 1.0 | pg_catalog | EDB-SPL procedural language - plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language -(5 rows) -``` -Notice that the BDR extension is listed in the table, showing that it's installed. ## Summaries diff --git a/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx b/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx deleted file mode 100644 index b9176256e26..00000000000 --- a/product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx +++ /dev/null @@ -1,256 +0,0 @@ ---- -title: Step 7 - Configure proxies -navTitle: Configure proxies -deepToC: true -redirects: - - /pgd/latest/install-admin/admin-manual/installing/07-configure-proxies/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-manual/installing/07-configure-proxies/ #generated for pgd deploy-config-planning reorg ---- - -## Configure proxies - -PGD can use proxies to direct traffic to one of the cluster's nodes, selected automatically by the cluster. -There are performance and availability reasons for using a proxy: - -* Performance: By directing all traffic (in particular, write traffic) to one node, the node can resolve write conflicts locally and more efficiently. -* Availability: When a node is taken down for maintenance or goes offline for other reasons, the proxy can direct new traffic to a new write leader that it selects. - -It's best practice to configure PGD Proxy for clusters to enable this behavior. - -### Configure the cluster for proxies - -To set up a proxy, you need to first prepare the cluster and subgroup the proxies will be working with by: - -* Log in and create as many uniquely named proxies as you plan to deploy using [`bdr.create_proxy`](/pgd/latest/reference/routing#bdrcreate_proxy) and passing the new proxy name and the subgroup to attach it to. The [`bdr.create_proxy`](/pgd/latest/reference/routing#bdrcreate_proxy) does not create a proxy, but creates a space for a proxy to register itself with the cluster. The space contains configuration values which can be modified later. Initially it is configured with default proxy options such as setting the `listen_address` to `0.0.0.0`. -* Configure proxy routes to each node by setting route_dsn for each node in the subgroup. The route_dsn is the connection string that the proxy should use to connect to that node. Use [`bdr.alter_node_option`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_option) to set the route_dsn for each node in the subgroup. -* Create a pgdproxy user on the cluster with a password or other authentication. - -### Configure each host as a proxy - -Once the cluster is ready, you need to configure each host to run pgd-proxy: - -* Create a pgdproxy local user. -* Create a `.pgpass` file for that user that allows the user to log into the cluster as pgdproxy. -* Modify the systemd service file for pgdproxy to use the pgdproxy user. -* Create a proxy config file for the host that lists the connection strings for all the nodes in the subgroup, specifies the name for the proxy to use when fetching proxy options like `listen_address` and `listen_port`. -* Install that file as `/etc/edb/pgd-proxy/pgd-proxy-config.yml`. -* Restart the systemd service and check its status. -* Log in to the proxy and verify its operation. - -Further detail on all these steps is included in the worked example. - -## Worked example - -## Preparing for proxies - -Create a PGD proxy within the cluster using the `bdr.create_proxy` function. -This function takes two parameters: the proxy's unique name and the group you want it to be a proxy for. - -In this example, you want a proxy on each host in the `dc1` subgroup: - -``` -SELECT bdr.create_proxy('pgd-proxy-one','dc1'); -SELECT bdr.create_proxy('pgd-proxy-two','dc1'); -SELECT bdr.create_proxy('pgd-proxy-three','dc1'); -``` - -You can use the [`bdr.proxy_config_summary`](/pgd/latest/reference/catalogs-internal#bdrproxy_config_summary) view to check that the proxies were created: - -```sql -SELECT proxy_name, node_group_name - FROM bdr.proxy_config_summary; -__OUTPUT__ - proxy_name | node_group_name ------------------+----------------- - pgd-proxy-one | dc1 - pgd-proxy-two | dc1 - pgd-proxy-three | dc1 - - bdrdb=# - ``` - -## Create a pgdproxy user on the database - -Create a user named pgdproxy and give it a password. This example uses `proxysecret`. - -On any node, log into the `bdrdb` database as enterprisedb/postgres. - -``` -CREATE USER pgdproxy PASSWORD 'proxysecret'; -GRANT bdr_superuser TO pgdproxy; -``` - -## Configure proxy routes to each node - -Once a proxy has connected, it gets its dsn values (connection strings) from the cluster. The cluster needs to know the connection details that a proxy should use for each node in the subgroup. This is done by setting the `route_dsn` option for each node to a connection string that the proxy can use to connect to that node. - -Please note that when a proxy starts, it gets the initial dsn from the proxy's config file. The route_dsn value set in this step and in config file should match. - -On any node, log into the bdrdb database as enterprisedb/postgres. - -```sql -SELECT bdr.alter_node_option('node-one', 'route_dsn', 'host=host-one dbname=bdrdb port=5444 user=pgdproxy'); -SELECT bdr.alter_node_option('node-two', 'route_dsn', 'host=host-two dbname=bdrdb port=5444 user=pgdproxy'); -SELECT bdr.alter_node_option('node-three', 'route_dsn', 'host=host-three dbname=bdrdb port=5444 user=pgdproxy'); -``` - -Note that the endpoints in this example specify `port=5444`. -This is necessary for EDB Postgres Advanced Server instances. -For EDB Postgres Extended and community PostgreSQL, you can omit this. - -## Create a pgdproxy user on each host - -```shell -sudo adduser pgdproxy -``` - -This user needs credentials to connect to the server. -Create a `.pgpass` file with the `proxysecret` password in it. -Then lock down the `.pgpass` file so it's accessible only by its owner. - -```shell -echo -e "*:*:*:pgdproxy:proxysecret" | sudo tee /home/pgdproxy/.pgpass -sudo chown pgdproxy /home/pgdproxy/.pgpass -sudo chmod 0600 /home/pgdproxy/.pgpass -``` - -## Configure the systemd service on each host - -Switch the service file from using root to using the pgdproxy user. - -```shell -sudo sed -i s/root/pgdproxy/ /usr/lib/systemd/system/pgd-proxy.service -``` - -Reload the systemd daemon. - -```shell -sudo systemctl daemon-reload -``` - -## Create a proxy config file for each host - -The proxy configuration file is slightly different for each host. -It's a YAML file that contains a cluster object. The cluster object has three -properties: - -* The name of the PGD cluster's top-level group (as `name`) -* An array of endpoints of databases (as `endpoints`) -* The proxy definition object with a name and endpoint (as `proxy`) - -The first two properties are the same for all hosts: - -``` -cluster: - name: pgd - endpoints: - - "host=host-one dbname=bdrdb port=5444 user=pgdproxy" - - "host=host-two dbname=bdrdb port=5444 user=pgdproxy" - - "host=host-three dbname=bdrdb port=5444 user=pgdproxy" -``` - -Remember that host-one, host-two, and host-three are the systems on which the cluster nodes (node-one, node-two, node-three) are running. -You use the name of the host, not the node, for the endpoint connection. - -Again, note that the endpoints in this example specify `port=5444`. -This is necessary for EDB Postgres Advanced Server instances. -For EDB Postgres Extended and community PostgreSQL, you can set this to `port=5432`. - -The third property, `proxy`, has a `name` property. -The `name` property is a name created with `bdr.create_proxy` earlier, and it's different on each host. -A proxy can't be on the same port as the Postgres server and, ideally, should be on a commonly used port different from direct connections, even when no Postgres server is running on the host. -Typically, you use port 6432 for PGD proxies. - -``` - proxy: - name: pgd-proxy-one -``` - -In this case, using `localhost` in the endpoint specifies that this proxy will listen on the host where the proxy is running. - -## Install a PGD proxy configuration on each host - -For each host, create the `/etc/edb/pgd-proxy` directory: - -``` -sudo mkdir -p /etc/edb/pgd-proxy -``` - -Then, on each host, write the appropriate configuration to the `pgd-proxy-config.yml` file in the `/etc/edb/pgd-proxy` directory. - -For this example, you can run this on host-one to create the file: - -``` -cat <
For more details, see [Transaction streaming](../transaction-streaming). Applies to top-level group only.| -| `default_commit_scope` | The commit scope to use by default, initially the `local` commit scope. This parameter applies only to the top-level node group. You can use individual rules for different origin groups of the same commit scope. See [Origin groups](../commit-scopes/origin_groups) for more details. | - -### Notes - -This function passes a request to the group consensus mechanism to change -the defaults. The changes made are replicated globally using the consensus -mechanism. - -The function isn't transactional. The request is processed in the background -so you can't roll back the function call. Also, the changes might not be -immediately visible to the current transaction. - -This function doesn't hold any locks. - diff --git a/product_docs/docs/pgd/6/reference/routing.mdx b/product_docs/docs/pgd/6/reference/routing.mdx deleted file mode 100644 index 600be7e26fd..00000000000 --- a/product_docs/docs/pgd/6/reference/routing.mdx +++ /dev/null @@ -1,104 +0,0 @@ ---- -navTitle: Routing functions -title: Routing functions -indexdepth: 3 -rootisheading: false ---- - -### `bdr.create_proxy` - -Create a proxy configuration. - -#### Synopsis - -```sql -bdr.create_proxy(proxy_name text, node_group text, proxy_mode text); -``` - -#### Parameters - -| Name | Type | Default | Description | -|--------------|------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `proxy_name` | text | | Name of the new proxy. | -| `node_group` | text | | Name of the group to be used by the proxy. | -| `proxy_mode` | text | `'default'` | Mode of the proxy. It can be `'default'` (listen_port connections follow write leader, no read_listen_port), `'read-only'` (no listen_port, read_listen_port connections follow read-only nodes), or `'any'` (listen_port connections follow write_leader, read_listen_port connections follow read-only nodes). Default is `'default'`. | - -When proxy_mode is set to `'default'`, all read options in the proxy config are set to NULL. When it's set to `'read-only'`, all write options in the proxy config are set to NULL. When set to `'any'` all options are set to their defaults. - - -### `bdr.alter_proxy_option` - -Change a proxy configuration. - -#### Synopsis - -```sql -bdr.alter_proxy_option(proxy_name text, config_key text, config_value text); -``` - -#### Parameters - -| Name | Type | Default | Description | -|----------------|------|---------|-----------------------------------------------| -| `proxy_name` | text | | Name of the proxy to change. | -| `config_key` | text | | Key of the option in the proxy to change. | -| `config_value` | text | | New value to set for the given key. | - -The table shows the proxy options (`config_key`) that can be changed using this function. - -| Option | Description | -|-------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `listen_address` | Address for the proxy to listen on. Default is '{0.0.0.0}'. | -| `listen_port` | Port for the proxy to listen on. Default is '6432' in 'default' or 'any' mode and '0' in 'read-only' mode, which disables the write leader following port. | -| `max_client_conn` | Maximum number of connections for the proxy to accept. Default is '32767'. | -| `max_server_conn` | Maximum number of connections the proxy can make to the Postgres node. Default is '32767'. | -| `server_conn_timeout` | Connection timeout for server connections. Default is '2' (seconds). | -| `server_conn_keepalive` | Keepalive interval for server connections. Default is '10' (seconds). | -| `consensus_grace_period` | Duration for which proxy continues to route even upon loss of a Raft leader. If set to 0s, proxy stops routing immediately. Default is generally '6' (seconds) for local proxies and '12' (seconds) for global proxies. These values will be overridden if `raft_response_timeout`, `raft_global_election_timeout`, or `raft_group_election_timeout` are changed from their defaults. | -| `read_listen_address` | Address for the read-only proxy to listen on. Default is '{0.0.0.0}'. | -| `read_listen_port` | Port for the read-only proxy to listen on. Default is '6433' in 'read-only' or 'any' mode and '0' in 'default' mode, which disables the read-only port. | -| `read_max_client_conn` | Maximum number of connections for the read-only proxy to accept. Default is '32767'. | -| `read_max_server_conn` | Maximum number of connections the read-only proxy can make to the Postgres node. Default is '32767'. | -| `read_server_conn_keepalive` | Keepalive interval for read-only server connections. Default is '10' (seconds). | -| `read_server_conn_timeout` | Connection timeout for read-only server connections. Default is '2' (seconds). | -| `read_consensus_grace_period` | Duration for which read-only proxy continues to route even upon loss of a Raft leader. Default is 1 hour. | - -Changing any of these values requires a restart of the proxy. - -### `bdr.drop_proxy` - -Drop a proxy configuration. - -#### Synopsis - -```sql -bdr.drop_proxy(proxy_name text); -``` - -#### Parameters - -| Name | Type | Default | Description | -|--------------|------|---------|-----------------------------------------------| -| `proxy_name` | text | | Name of the proxy to drop. | - -### `bdr.routing_leadership_transfer` - -Changing the routing leader transfers the leadership of the node group to another node. - -#### Synopsis - -```sql -bdr.routing_leadership_transfer(node_group_name text, - leader_name text, - transfer_method text DEFAULT 'strict', - transfer_timeout interval DEFAULT '10s'); -``` - -#### Parameters - -| Name | Type | Default | Description | -|--------------------|----------|----------|---------------------------------------------------------------------------------------------| -| `node_group_name` | text | | Name of group where the leadership transfer is requested. | -| `leader_name` | text | | Name of node that will become write leader. | -| `transfer_method` | text | `'strict'` | Type of the transfer. It can be `'fast'` or the default, `'strict'`, which checks the maximum lag. | -| `transfer_timeout` | interval | '10s' | Timeout of the leadership transfer. Default is 10 seconds. | diff --git a/product_docs/docs/pgd/6/security/pgd-predefined-roles.mdx b/product_docs/docs/pgd/6/security/pgd-predefined-roles.mdx index 97e74fae2a0..43cebb6392a 100644 --- a/product_docs/docs/pgd/6/security/pgd-predefined-roles.mdx +++ b/product_docs/docs/pgd/6/security/pgd-predefined-roles.mdx @@ -83,7 +83,6 @@ EXECUTE privilege on: - [`bdr.node_catchup_state_name`](/pgd/latest/reference/functions-internal#bdrnode_catchup_state_name) - [`bdr.node_kind_name`](/pgd/latest/reference/functions-internal#bdrnode_kind_name) - [`bdr.peer_state_name`](/pgd/latest/reference/functions-internal#bdrpeer_state_name) -- [`bdr.pglogical_proto_version_ranges`](/pgd/latest/reference/functions-internal#bdrpglogical_proto_version_ranges) - [`bdr.show_subscription_status`](/pgd/latest/reference/functions-internal#bdrshow_subscription_status) - [`bdr.show_workers`](/pgd/latest/reference/functions-internal#bdrshow_workers) - [`bdr.show_writers`](/pgd/latest/reference/functions-internal#bdrshow_writers) diff --git a/product_docs/docs/pgd/6/transaction-streaming.mdx b/product_docs/docs/pgd/6/transaction-streaming.mdx index 8e6e53288fa..a024e2e8257 100644 --- a/product_docs/docs/pgd/6/transaction-streaming.mdx +++ b/product_docs/docs/pgd/6/transaction-streaming.mdx @@ -70,9 +70,9 @@ Permitted values are: Default value is `auto`. -Changing this setting requires a restart of the -pglogical receiver process for each subscription for the setting to take effect. You can achieve this with a server -restart. +Changing this setting requires a restart of the pglogical receiver process for each subscription for the setting to take effect. + +You can achieve this with a server restart. If `bdr.default_streaming_mode` is set to any value other than `off`, the subscriber requests transaction streaming from the publisher. How this is diff --git a/product_docs/docs/pgd/6/upgrades/compatibility.mdx b/product_docs/docs/pgd/6/upgrades/compatibility.mdx index ae938f4467f..50effc2ef67 100644 --- a/product_docs/docs/pgd/6/upgrades/compatibility.mdx +++ b/product_docs/docs/pgd/6/upgrades/compatibility.mdx @@ -17,7 +17,8 @@ management configuration. CAMO configuration is now done through [commit scopes](../commit-scopes/commit-scopes). The `bdr.camo_pairs` catalog and any related manipulation functions don't exist -anymore. The `bdr.enable_camo` GUC was removed. +anymore. + The `synchronous_replication_availability` GUC doesn't affect CAMO anymore. Use the `DEGRADE ON ... TO ASYNC` clause of a commit scope. @@ -36,9 +37,6 @@ SELECT bdr.create_commit_scope( ); ``` -The `bdr.global_commit_timeout` GUC was removed. Use the `ABORT ON` clause for the -commit scope. - ## Lag Control Similarly to CAMO and Eager, Lag Control configuration was also moved to From 6ecd6c3a0f05a461c6a6c976ed6c7def4d370504 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Tue, 22 Apr 2025 11:20:28 +0100 Subject: [PATCH 016/145] Configuration changes Signed-off-by: Dj Walker-Morgan --- .../6/cli/command_ref/group/get-option.mdx | 2 +- .../docs/pgd/6/cli/installing/linux.mdx | 4 +-- .../docs/pgd/6/commit-scopes/camo.mdx | 2 +- .../docs/pgd/6/commit-scopes/group-commit.mdx | 3 -- product_docs/docs/pgd/6/ddl/ddl-locking.mdx | 2 ++ .../docs/pgd/6/reference/autopartition.mdx | 2 -- .../pgd/6/reference/catalogs-internal.mdx | 1 - .../docs/pgd/6/reference/catalogs-visible.mdx | 36 +++++++++---------- .../reference/nodes-management-interfaces.mdx | 4 +-- .../docs/pgd/6/reference/pgd-settings.mdx | 12 ++++--- 10 files changed, 33 insertions(+), 35 deletions(-) diff --git a/product_docs/docs/pgd/6/cli/command_ref/group/get-option.mdx b/product_docs/docs/pgd/6/cli/command_ref/group/get-option.mdx index 0ba52568cf6..9b11f69502b 100644 --- a/product_docs/docs/pgd/6/cli/command_ref/group/get-option.mdx +++ b/product_docs/docs/pgd/6/cli/command_ref/group/get-option.mdx @@ -25,7 +25,7 @@ And `
Async
(default)
Parallel
Apply 		Transaction
Streaming 		Single
Decoding
Worker 		Parallel
Apply 		Transaction
Streaming 		Single
Decoding
Worker
Group Commit Group Commit ⛔︎ ❌ ❌❗️ ✅
CAMO CAMO ⛔︎ ✅ ❌ ❌
Lag Control Lag Control ✅ ✅ ✅ ✅
Synchronous Commit Synchronous Commit ⛔︎ ✅ ✅
- - - - + + + + - + - + - + - + @@ -110,5 +110,4 @@ Although you can't mix commit scopes, you can [combine rules](../commit-scopes/c #### Notes -Each commit scope implicitly works with itself. - +Each commit scope implicitly works with itself. diff --git a/product_docs/docs/pgd/6/concepts/appusage/index.mdx b/product_docs/docs/pgd/6/reference/appusage/index.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/appusage/index.mdx rename to product_docs/docs/pgd/6/reference/appusage/index.mdx diff --git a/product_docs/docs/pgd/6/concepts/appusage/nodes-with-differences.mdx b/product_docs/docs/pgd/6/reference/appusage/nodes-with-differences.mdx similarity index 95% rename from product_docs/docs/pgd/6/concepts/appusage/nodes-with-differences.mdx rename to product_docs/docs/pgd/6/reference/appusage/nodes-with-differences.mdx index 2cbfe9f6a12..695e102bb6d 100644 --- a/product_docs/docs/pgd/6/concepts/appusage/nodes-with-differences.mdx +++ b/product_docs/docs/pgd/6/reference/appusage/nodes-with-differences.mdx @@ -20,7 +20,7 @@ definitions, such as a source that's a normal table replicating to a partitioned table, including support for updates that change partitions on the target. It can be faster if the partitioning definition is the same on the source and target since dynamic partition routing doesn't need to execute at apply time. -For details, see [Replication sets](../repsets). +For details, see [Replication sets](/pgd/latest/reference/repsets). By default, all columns are replicated. @@ -69,11 +69,11 @@ value of a table's storage parameter `user_catalog_table` must be identical on all nodes. A table being replicated must be owned by the same user/role on each node. See -[Security and roles](../security) for details. +[Security and roles](/pgd/latest/reference/security) for details. Roles can have different passwords for connection on each node, although by default changes to roles are replicated to each node. See [DDL -replication](../ddl) to specify how to alter a role password on only a subset of +replication](/pgd/latest/reference/ddl) to specify how to alter a role password on only a subset of nodes or locally. ## Comparison between nodes with differences @@ -119,4 +119,4 @@ you can't add a node with a minor version if the cluster uses a newer protocol version. Doing so returns an error. Both of these features might be affected by specific restrictions. See [Release -notes](../rel_notes/) for any known incompatibilities. \ No newline at end of file +notes](/pgd/latest/rel_notes/) for any known incompatibilities. \ No newline at end of file diff --git a/product_docs/docs/pgd/6/concepts/appusage/rules.mdx b/product_docs/docs/pgd/6/reference/appusage/rules.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/appusage/rules.mdx rename to product_docs/docs/pgd/6/reference/appusage/rules.mdx diff --git a/product_docs/docs/pgd/6/concepts/appusage/table-access-methods.mdx b/product_docs/docs/pgd/6/reference/appusage/table-access-methods.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/appusage/table-access-methods.mdx rename to product_docs/docs/pgd/6/reference/appusage/table-access-methods.mdx diff --git a/product_docs/docs/pgd/6/concepts/appusage/timing.mdx b/product_docs/docs/pgd/6/reference/appusage/timing.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/appusage/timing.mdx rename to product_docs/docs/pgd/6/reference/appusage/timing.mdx diff --git a/product_docs/docs/pgd/6/reference/architectures/index.mdx b/product_docs/docs/pgd/6/reference/architectures/index.mdx new file mode 100644 index 00000000000..9d9ed8012ed --- /dev/null +++ b/product_docs/docs/pgd/6/reference/architectures/index.mdx @@ -0,0 +1,19 @@ +--- +title: PGD 6 Supported Architectures +navTitle: Supported Architectures +--- + +## Supported Essential Architectures + +### Standard + +### Near-Far + +## Supported Expanded Architectures + +### Standard + +### Near-Far + +### Multi-Region + diff --git a/product_docs/docs/pgd/6/reference/cdc-failover.mdx b/product_docs/docs/pgd/6/reference/cdc-failover.mdx index 32bf72ebb62..b83085b630e 100644 --- a/product_docs/docs/pgd/6/reference/cdc-failover.mdx +++ b/product_docs/docs/pgd/6/reference/cdc-failover.mdx @@ -39,7 +39,7 @@ Currently, there's no way to ensure exactly-once delivery, and we expect consumi ## Enabling CDC Failover support -To enable CDC Failover support run the SQL command and call the [`bdr.alter_node_group_option`](/pgd/latest/reference/tables-views-functions/tables-views-functions/nodes-management-interfaces#bdralter_node_group_option) function with the following parameters: +To enable CDC Failover support run the SQL command and call the [`bdr.alter_node_group_option`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdralter_node_group_option) function with the following parameters: ```sql select bdr.alter_node_group_option(, @@ -48,9 +48,9 @@ select bdr.alter_node_group_option(, ``` -Replace `` with the name of your cluster’s top-level group. If you don't know the name, it's the group with a node_group_parent_id equal to 0 in [`bdr.node_group`](/pgd/latest/reference/tables-views-functions/tables-views-functions/catalogs-visible#bdrnode_group). +Replace `` with the name of your cluster’s top-level group. If you don't know the name, it's the group with a node_group_parent_id equal to 0 in [`bdr.node_group`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrnode_group). -If you do not know the name, it is the group with a node_group_parent_id equal to 0 in [`bdr.node_group`](/pgd/latest/reference/tables-views-functions/tables-views-functions/catalogs-visible#bdrnode_group). You can also use: +If you do not know the name, it is the group with a node_group_parent_id equal to 0 in [`bdr.node_group`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrnode_group). You can also use: ```sql SELECT bdr.alter_node_group_option( @@ -74,7 +74,7 @@ Logical replication slots created before the option was set to `global` aren't r Failover slots can also be created with the `CREATE_REPLICATION_SLOT` command on a replication connection. -The status of failover slots is tracked in the [`bdr.failover_replication_slots`](/pgd/latest/reference/tables-views-functions/tables-views-functions/catalogs-visible#bdrfailover_replication_slots) table. +The status of failover slots is tracked in the [`bdr.failover_replication_slots`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrfailover_replication_slots) table. ## CDC Failover support with Postgres 17+ diff --git a/product_docs/docs/pgd/6/reference/commit-scopes/durabilityterminology.mdx b/product_docs/docs/pgd/6/reference/commit-scopes/durabilityterminology.mdx index 490bba31074..7ac60387d71 100644 --- a/product_docs/docs/pgd/6/reference/commit-scopes/durabilityterminology.mdx +++ b/product_docs/docs/pgd/6/reference/commit-scopes/durabilityterminology.mdx @@ -5,7 +5,7 @@ title: Durability terminology ## Durability terminology This page covers terms and definitions directly related to PGD's durability options. -For other terms, see [Terminology](../terminology). +For other terms, see [Terminology](/pgd/latest/terminology). ### Nodes diff --git a/product_docs/docs/pgd/6/reference/commit-scopes/group-commit.mdx b/product_docs/docs/pgd/6/reference/commit-scopes/group-commit.mdx index 0dc7a82b655..b5d8892da7d 100644 --- a/product_docs/docs/pgd/6/reference/commit-scopes/group-commit.mdx +++ b/product_docs/docs/pgd/6/reference/commit-scopes/group-commit.mdx @@ -47,13 +47,13 @@ it's parted from the cluster. This behavior is the same as with Postgres legacy built-in synchronous replication. Transactions committed with Group Commit use [two-phase -commit](../terminology/#two-phase-commit-2pc) underneath. Therefore, configure +commit](/pgd/latest/terminology/#two-phase-commit-2pc) underneath. Therefore, configure `max_prepared_transactions` high enough to handle all such transactions originating per node. ## Limitations -See the Group Commit section of [Limitations](limitations#group-commit). +See the Group Commit section of [Limitations](pgd/latest/known_issues#group-commit). ## Configuration @@ -104,7 +104,7 @@ Conflict resolution can be `async` or `eager`. Async means that PGD does optimistic conflict resolution during replication using the row-level resolution as configured for a given node. This happens regardless of whether the origin transaction committed or is still in progress. -See [Conflicts](../conflict-management/conflicts) for details about how the asynchronous +See [Conflicts](/pgd/latest/reference/conflict-management/conflicts) for details about how the asynchronous conflict resolution works. Eager means that conflicts are resolved eagerly (as part of agreement on diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/column-level-conflicts/01_overview_clcd.mdx b/product_docs/docs/pgd/6/reference/conflict-management/column-level-conflicts/01_overview_clcd.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/column-level-conflicts/01_overview_clcd.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/column-level-conflicts/01_overview_clcd.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/column-level-conflicts/02_enabling_disabling.mdx b/product_docs/docs/pgd/6/reference/conflict-management/column-level-conflicts/02_enabling_disabling.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/column-level-conflicts/02_enabling_disabling.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/column-level-conflicts/02_enabling_disabling.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/column-level-conflicts/03_timestamps.mdx b/product_docs/docs/pgd/6/reference/conflict-management/column-level-conflicts/03_timestamps.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/column-level-conflicts/03_timestamps.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/column-level-conflicts/03_timestamps.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/column-level-conflicts/index.mdx b/product_docs/docs/pgd/6/reference/conflict-management/column-level-conflicts/index.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/column-level-conflicts/index.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/column-level-conflicts/index.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/conflicts/00_conflicts_overview.mdx b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/00_conflicts_overview.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/conflicts/00_conflicts_overview.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/conflicts/00_conflicts_overview.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/conflicts/02_types_of_conflict.mdx b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/02_types_of_conflict.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/conflicts/02_types_of_conflict.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/conflicts/02_types_of_conflict.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/conflicts/03_conflict_detection.mdx b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/03_conflict_detection.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/conflicts/03_conflict_detection.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/conflicts/03_conflict_detection.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/conflicts/04_conflict_resolution.mdx b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/04_conflict_resolution.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/conflicts/04_conflict_resolution.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/conflicts/04_conflict_resolution.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/conflicts/05_conflict_logging.mdx b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/05_conflict_logging.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/conflicts/05_conflict_logging.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/conflicts/05_conflict_logging.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/conflicts/06_live_compare.mdx b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/06_live_compare.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/conflicts/06_live_compare.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/conflicts/06_live_compare.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/conflicts/index.mdx b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/index.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/conflicts/index.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/conflicts/index.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/00_crdt_overview.mdx b/product_docs/docs/pgd/6/reference/conflict-management/crdt/00_crdt_overview.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/00_crdt_overview.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/crdt/00_crdt_overview.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/01_crdt_usage.mdx b/product_docs/docs/pgd/6/reference/conflict-management/crdt/01_crdt_usage.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/01_crdt_usage.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/crdt/01_crdt_usage.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/02_state-op-crdts.mdx b/product_docs/docs/pgd/6/reference/conflict-management/crdt/02_state-op-crdts.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/02_state-op-crdts.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/crdt/02_state-op-crdts.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/03_crdt-disk-reqs.mdx b/product_docs/docs/pgd/6/reference/conflict-management/crdt/03_crdt-disk-reqs.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/03_crdt-disk-reqs.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/crdt/03_crdt-disk-reqs.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/04_crdt-vs-conflict.mdx b/product_docs/docs/pgd/6/reference/conflict-management/crdt/04_crdt-vs-conflict.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/04_crdt-vs-conflict.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/crdt/04_crdt-vs-conflict.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/05_crdt-reset.mdx b/product_docs/docs/pgd/6/reference/conflict-management/crdt/05_crdt-reset.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/05_crdt-reset.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/crdt/05_crdt-reset.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/06_crdt-implemented.mdx b/product_docs/docs/pgd/6/reference/conflict-management/crdt/06_crdt-implemented.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/06_crdt-implemented.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/crdt/06_crdt-implemented.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/index.mdx b/product_docs/docs/pgd/6/reference/conflict-management/crdt/index.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/crdt/index.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/crdt/index.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/index.mdx b/product_docs/docs/pgd/6/reference/conflict-management/index.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/advanced-concepts/conflict-management/index.mdx rename to product_docs/docs/pgd/6/reference/conflict-management/index.mdx diff --git a/product_docs/docs/pgd/6/reference/connection-manager/configuring.mdx b/product_docs/docs/pgd/6/reference/connection-manager/configuring.mdx index 53f87b4022d..4d216ee1790 100644 --- a/product_docs/docs/pgd/6/reference/connection-manager/configuring.mdx +++ b/product_docs/docs/pgd/6/reference/connection-manager/configuring.mdx @@ -7,7 +7,7 @@ description: How to configure Connection Manager Connection Manager takes its configuration from the PGD Group options for the group the node is a member of. -These can be configured using the [`bdr.alter_node_group_option`](/pgd/6.0/reference/nodes-management-interfaces#bdralter_node_group_option) command, or using the [`pgd group set-option`](../../../cli/command_ref/group/set-option/) command. +These can be configured using the [`bdr.alter_node_group_option`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdralter_node_group_option) command, or using the [`pgd group set-option`](/pgd/latest/reference/cli/command_ref/group/set-option/) command. The following options are available for configuring Connection Manager: diff --git a/product_docs/docs/pgd/6/reference/connection-manager/monitoring.mdx b/product_docs/docs/pgd/6/reference/connection-manager/monitoring.mdx index d4646f3bae9..3c8b05b3c88 100644 --- a/product_docs/docs/pgd/6/reference/connection-manager/monitoring.mdx +++ b/product_docs/docs/pgd/6/reference/connection-manager/monitoring.mdx @@ -9,11 +9,11 @@ deepToC: true The Connection Manager provides a number of tables and views that can be used to monitor the status of the Connection Manager and its connections. These include: -- [`bdr.stat_activity`](/pgd/6.0/reference/catalogs-visible#bdrstat_activity) — which is information from `pg_stat_activity` enhanced with addition columns regarding the `connection_manager_client_addr` and `connection_manager_client_port` is the connection has come through the connection manager, and `session_read_only` if it has connected through the read-only port. -- [`bdr.stat_connection_manager`](/pgd/6.0/reference/catalogs-visible#bdrstat_connection_manager) — which is a view that provides statistics about the Connection Manager's status. -- [`bdr.stat_connection_manager_connections`](/pgd/6.0/reference/catalogs-visible#bdrstat_connection_manager_connections) — which is a view that provides statistics about the Connection Manager's connections. -- [`bdr.stat_connection_manager_nodes_stats`](/pgd/6.0/reference/catalogs-visible#bdrstat_connection_manager_nodes) — which is a view that provides statistics about the Connection Manager on each of the data nodes. -- [`bdr.stat_connection_manager_hba_file_rules`](/pgd/6.0/reference/catalogs-visible#bdrstat_connection_manager_hba_file_rules) — which is a view that shows which HBA file rules for the connection manager are being used on this node. +- [`bdr.stat_activity`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_activity) — which is information from `pg_stat_activity` enhanced with addition columns regarding the `connection_manager_client_addr` and `connection_manager_client_port` is the connection has come through the connection manager, and `session_read_only` if it has connected through the read-only port. +- [`bdr.stat_connection_manager`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_connection_manager) — which is a view that provides statistics about the Connection Manager's status. +- [`bdr.stat_connection_manager_connections`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_connection_manager_connections) — which is a view that provides statistics about the Connection Manager's connections. +- [`bdr.stat_connection_manager_nodes_stats`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_connection_manager_nodes) — which is a view that provides statistics about the Connection Manager on each of the data nodes. +- [`bdr.stat_connection_manager_hba_file_rules`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_connection_manager_hba_file_rules) — which is a view that shows which HBA file rules for the connection manager are being used on this node. ## Monitoring the Connection Manager diff --git a/product_docs/docs/pgd/6/reference/connection-manager/overview.mdx b/product_docs/docs/pgd/6/reference/connection-manager/overview.mdx index 4a07d2d8d53..70197368970 100644 --- a/product_docs/docs/pgd/6/reference/connection-manager/overview.mdx +++ b/product_docs/docs/pgd/6/reference/connection-manager/overview.mdx @@ -28,5 +28,5 @@ Connecting a client to the read-only port provided by connection manager restric ## TLS and Authentication -The Connection Manager performs TLS termination and pre-authentication. The configuration for these is taken directly from Postgres - pg_hba.conf and server key configuration are used transparently. See [authentication](../authentication/) for more information. +The Connection Manager performs TLS termination and pre-authentication. The configuration for these is taken directly from Postgres - pg_hba.conf and server key configuration are used transparently. See [authentication](authentication/) for more information. diff --git a/product_docs/docs/pgd/6/concepts/ddl/ddl-locking.mdx b/product_docs/docs/pgd/6/reference/ddl/ddl-locking.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/ddl/ddl-locking.mdx rename to product_docs/docs/pgd/6/reference/ddl/ddl-locking.mdx diff --git a/product_docs/docs/pgd/6/concepts/ddl/ddl-managing-with-pgd-replication.mdx b/product_docs/docs/pgd/6/reference/ddl/ddl-managing-with-pgd-replication.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/ddl/ddl-managing-with-pgd-replication.mdx rename to product_docs/docs/pgd/6/reference/ddl/ddl-managing-with-pgd-replication.mdx diff --git a/product_docs/docs/pgd/6/concepts/ddl/ddl-overview.mdx b/product_docs/docs/pgd/6/reference/ddl/ddl-overview.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/ddl/ddl-overview.mdx rename to product_docs/docs/pgd/6/reference/ddl/ddl-overview.mdx diff --git a/product_docs/docs/pgd/6/concepts/ddl/ddl-pgd-functions-like-ddl.mdx b/product_docs/docs/pgd/6/reference/ddl/ddl-pgd-functions-like-ddl.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/ddl/ddl-pgd-functions-like-ddl.mdx rename to product_docs/docs/pgd/6/reference/ddl/ddl-pgd-functions-like-ddl.mdx diff --git a/product_docs/docs/pgd/6/concepts/ddl/ddl-role-manipulation.mdx b/product_docs/docs/pgd/6/reference/ddl/ddl-role-manipulation.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/ddl/ddl-role-manipulation.mdx rename to product_docs/docs/pgd/6/reference/ddl/ddl-role-manipulation.mdx diff --git a/product_docs/docs/pgd/6/concepts/ddl/ddl-workarounds.mdx b/product_docs/docs/pgd/6/reference/ddl/ddl-workarounds.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/ddl/ddl-workarounds.mdx rename to product_docs/docs/pgd/6/reference/ddl/ddl-workarounds.mdx diff --git a/product_docs/docs/pgd/6/reference/ddl/index.mdx b/product_docs/docs/pgd/6/reference/ddl/index.mdx index 2dce729456b..4ff76b4b9dc 100644 --- a/product_docs/docs/pgd/6/reference/ddl/index.mdx +++ b/product_docs/docs/pgd/6/reference/ddl/index.mdx @@ -1,9 +1,37 @@ --- -title: DDL Reference -navTitle: DDL Reference +title: DDL replication +redirects: + - ../bdr/ddl +description: How DDL is replicated in PGD and when it isn't +navigation: + - ddl-overview + - ddl-replication-options + - ddl-locking + - ddl-managing-with-pgd-replication + - ddl-command-handling + - ddl-role-manipulation + - ddl-workarounds + - ddl-pgd-functions-like-ddl --- -* [DDL Command Handling](ddl-command-handling) +DDL stands for data definition language, the subset of the SQL +language that creates, alters, and drops database objects. -* [DDL Replication Options](ddl-replication-options) +PGD provides automatic DDL replication, which makes certain DDL changes easier. With automatic replication, you don't have to manually distribute the DDL change to all nodes and ensure that they're consistent. + +This section looks at how DDL replication is handled in PGD. + +* [Overview](ddl-overview) provides a general outline of what PGD's DDL replication is capable of. + +* [Locking](ddl-locking) examines how DDL replication uses locks to safely replicate DDL. + +* [Managing DDL with PGD replication](ddl-managing-with-pgd-replication) gives best practice advice on why and how to limit the impact of DDL changes so they don't overly affect the smooth running of the cluster. +* [DDL role manipulation](ddl-role-manipulation) notes issues around manipulating roles over multiple databases in a cluster. + +* [Workarounds](ddl-workarounds) gives a range of options for handling situations where DDL replication may present restrictions, such as altering columns, constraints, and types. + +* [DDL-like PGD functions](ddl-pgd-functions-like-ddl) details the PGD functions that behave like DDL and therefore behave in a similar way and are subject to similar restrictions. + + +Further information on DDL replication can be found in the [PGD Reference](../reference/ddl). diff --git a/product_docs/docs/pgd/6/reference/decoding_worker.mdx b/product_docs/docs/pgd/6/reference/decoding_worker.mdx index 72688d9f043..0f2fcbca628 100644 --- a/product_docs/docs/pgd/6/reference/decoding_worker.mdx +++ b/product_docs/docs/pgd/6/reference/decoding_worker.mdx @@ -16,7 +16,7 @@ since the WAL sender process now spends more time on communication. ## Enabling `enable_wal_decoder` is an option for each PGD group, which is currently -disabled by default. You can use [`bdr.alter_node_group_option()`](reference/nodes-management-interfaces/#bdralter_node_group_option) to enable or +disabled by default. You can use [`bdr.alter_node_group_option()`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces/#bdralter_node_group_option) to enable or disable the decoding worker for a PGD group. When the decoding worker is enabled, PGD stores logical change record (LCR) diff --git a/product_docs/docs/pgd/6/reference/index.mdx b/product_docs/docs/pgd/6/reference/index.mdx index bd03bc8ff6b..9e6f0cce767 100644 --- a/product_docs/docs/pgd/6/reference/index.mdx +++ b/product_docs/docs/pgd/6/reference/index.mdx @@ -2,15 +2,22 @@ title: PGD Reference navTitle: Reference navigation: -- cli -- table-views-functions +- tables-views-functions +- appusage +- architectures - cdc-failover +- cli +- commit-scopes +- conflict-management - connection-manager - ddl - decoding-worker +- nodes +- node-management - parallelapply - postgres-configuration - repsets +- security - striggers - testing-tuning - transaction-streaming diff --git a/product_docs/docs/pgd/6/reference/monitoring/sql.mdx b/product_docs/docs/pgd/6/reference/monitoring/sql.mdx index eebfc30610b..45a43ba6eb3 100644 --- a/product_docs/docs/pgd/6/reference/monitoring/sql.mdx +++ b/product_docs/docs/pgd/6/reference/monitoring/sql.mdx @@ -122,7 +122,7 @@ and Each node has one PGD group slot that must never have a connection to it and is very rarely be marked as active. This is normal and doesn't imply -something is down or disconnected. See [Replication slots](../node_management/replication_slots) in Node Management. +something is down or disconnected. See [Replication slots](/pgd/latest/reference/node_management/replication_slots) in Node Management. ### Monitoring outgoing replication @@ -303,7 +303,7 @@ postgres=# SELECT * FROM bdr.wal_sender_stats(); If `is_using_lcr` is `FALSE`, `decoder_slot_name`/`lcr_file_name` is `NULL`. This is the case if the decoding worker isn't enabled or the WAL sender is -serving a [logical standby](../nodes/logical_standby_nodes/). +serving a [logical standby](/pgd/latest/reference/nodes/logical_standby_nodes/). Also, you can monitor information about the decoding worker using the function [`bdr.get_decoding_worker_stat()`](/pgd/latest/reference/tables-views-functions/functions/#bdrget_decoding_worker_stat). For example: @@ -411,7 +411,7 @@ timing information. ## Monitoring conflicts -Replication [conflicts](../conflict-management/conflicts) can arise when multiple nodes make +Replication [conflicts](/pgd/latest/reference/conflict-management/conflicts) can arise when multiple nodes make changes that affect the same rows in ways that can interact with each other. Monitor the PGD system to identify conflicts and, where possible, make application changes to eliminate the conflicts or make them less frequent. @@ -699,7 +699,7 @@ consumed the corresponding transactions. Consequently, it's not necessary to monitor the status of the group slot. The function [`bdr.monitor_local_replslots()`](/pgd/latest/reference/tables-views-functions/functions#bdrmonitor_local_replslots) provides a summary of whether all -PGD node replication slots are working as expected. This summary is also available on subscriber-only nodes that are operating as subscriber-only group leaders in a PGD cluster when [optimized topology](../nodes/subscriber_only/optimizing-so) is enabled. For example: +PGD node replication slots are working as expected. This summary is also available on subscriber-only nodes that are operating as subscriber-only group leaders in a PGD cluster when [optimized topology](/pgd/latest/reference/nodes/subscriber_only/optimizing-so) is enabled. For example: ```sql bdrdb=# SELECT * FROM bdr.monitor_local_replslots(); diff --git a/product_docs/docs/pgd/6/concepts/node_management/automatic_sync.mdx b/product_docs/docs/pgd/6/reference/node_management/automatic_sync.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/node_management/automatic_sync.mdx rename to product_docs/docs/pgd/6/reference/node_management/automatic_sync.mdx diff --git a/product_docs/docs/pgd/6/concepts/node_management/connections_dsns_and_ssl.mdx b/product_docs/docs/pgd/6/reference/node_management/connections_dsns_and_ssl.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/node_management/connections_dsns_and_ssl.mdx rename to product_docs/docs/pgd/6/reference/node_management/connections_dsns_and_ssl.mdx diff --git a/product_docs/docs/pgd/6/concepts/node_management/creating_and_joining.mdx b/product_docs/docs/pgd/6/reference/node_management/creating_and_joining.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/node_management/creating_and_joining.mdx rename to product_docs/docs/pgd/6/reference/node_management/creating_and_joining.mdx diff --git a/product_docs/docs/pgd/6/concepts/node_management/creating_nodes.mdx b/product_docs/docs/pgd/6/reference/node_management/creating_nodes.mdx similarity index 71% rename from product_docs/docs/pgd/6/concepts/node_management/creating_nodes.mdx rename to product_docs/docs/pgd/6/reference/node_management/creating_nodes.mdx index e2fbbee1bc3..243d410f982 100644 --- a/product_docs/docs/pgd/6/concepts/node_management/creating_nodes.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/creating_nodes.mdx @@ -3,7 +3,6 @@ title: Creating PGD nodes navTitle: Creating PGD nodes --- -Depending on your [selected deployment method](../deploy-config), you may or may not have to create PGD nodes manually. For example, if you are using [TPA](../deploy-config/deploy-tpa/deploying/) or the [EDB Postgres Distributed for Kubernetes](../deploy-config/deploy-kubernetes/), the nodes are created automatically. But if you are [manually deploying PGD](../deploy-config/deploy-manual/deploying/) or creating your own deployment method, you need to know how to create and configure a PGD node. ## It's just Postgres @@ -23,31 +22,31 @@ You must install your selected Postgres distribution on each node you are config The BDR extension is the key to PGD's distributed architecture. You need to install the BDR extension on each node in your PGD cluster. The BDR extension is available from the EDB Postgres Distributed repository. You need to add the `postgres_distributed` repository to your package management system on Linux and then install the `edb-bdr` package. You can find the repository configuration instructions in the [PGD manual installation guide](../deploy-config/deploy-manual/deploying/03-configuring-repositories). -Once the repository is configured, you can install the BDR package with your package manager. The package name is `edb-bdr5-` where `` is the version of Postgres you are using. For example, if you are using Postgres 13, the package name is `edb-bdr5-13`. +Once the repository is configured, you can install the BDR package with your package manager. The package name is `edb-pgd6-` where `` is the version of Postgres you are using. For example, if you are using Postgres 14, the package name is `edb-pgd6-14`. ### Configuring the database for PGD This process is specific to PGD and involves configuring the Postgres instance to work with the BDR extension and adjusting various settings to work with the PGD cluster. This process is also detailed in the [PGD manual installation guide](../deploy-config/deploy-manual/deploying/04-installing-software) The steps are as follows: - * Add the BDR extension `$libdir/bdr` at the start of the `shared_preload_libraries` setting in `postgresql.conf`. - * Set the `wal_level` GUC variable to `logical` in `postgresql.conf`. - * Turn on commit timestamp tracking by setting `track_commit_timestamp` to `'on'` in `postgresql.conf`. - * Increase the maximum worker processes to 16 or higher by setting `max_worker_processes` to `'16'` in `postgresql.conf`.

+* Add the BDR extension `$libdir/bdr` at the start of the `shared_preload_libraries` setting in `postgresql.conf`. +* Set the `wal_level` GUC variable to `logical` in `postgresql.conf`. +* Turn on commit timestamp tracking by setting `track_commit_timestamp` to `'on'` in `postgresql.conf`. +* Increase the maximum worker processes to 16 or higher by setting `max_worker_processes` to `'16'` in `postgresql.conf`.

!!! Note The `max_worker_processes` value The `max_worker_processes` value is derived from the topology of the cluster, the number of peers, number of databases, and other factors. To calculate the needed value, see [Postgres configuration/settings](/pgd/latest/postgres-configuration/#postgres-settings). The value of 16 was calculated for the size of cluster being deployed in this example. It must be increased for larger clusters. !!! - * Set a password on the EnterprisedDB/Postgres user. - * Add rules to `pg_hba.conf` to allow nodes to connect to each other. - * Ensure that these lines are present in `pg_hba.conf`: - ``` - host all all all md5 - host replication all all md5 - ``` - * Add a `.pgpass` file to allow nodes to authenticate each other. - * Configure a user with sufficient privileges to log in to the other nodes. - * See [The Password File](https://www.postgresql.org/docs/current/libpq-pgpass.html) in the Postgres documentation for more on the `.pgpass` file. +* Set a password on the EnterprisedDB/Postgres user. +* Add rules to `pg_hba.conf` to allow nodes to connect to each other. + * Ensure that these lines are present in `pg_hba.conf`: + ``` + host all all all md5 + host replication all all md5 + ``` +* Add a `.pgpass` file to allow nodes to authenticate each other. + * Configure a user with sufficient privileges to log in to the other nodes. + * See [The Password File](https://www.postgresql.org/docs/current/libpq-pgpass.html) in the Postgres documentation for more on the `.pgpass` file. Once these steps are complete, restart the Postgres instance to apply the changes. @@ -64,5 +63,5 @@ The created database should be the name of the database that other nodes in the ## Next steps The node is now configured and ready to be join a group, or start a group, in the PGD cluster. - +You can find instructions for joining a node to a group in the [Joining a node to a group](/creating_and_joining) section. diff --git a/product_docs/docs/pgd/6/concepts/node_management/groups_and_subgroups.mdx b/product_docs/docs/pgd/6/reference/node_management/groups_and_subgroups.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/node_management/groups_and_subgroups.mdx rename to product_docs/docs/pgd/6/reference/node_management/groups_and_subgroups.mdx diff --git a/product_docs/docs/pgd/6/concepts/node_management/heterogeneous_clusters.mdx b/product_docs/docs/pgd/6/reference/node_management/heterogeneous_clusters.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/node_management/heterogeneous_clusters.mdx rename to product_docs/docs/pgd/6/reference/node_management/heterogeneous_clusters.mdx diff --git a/product_docs/docs/pgd/6/concepts/node_management/index.mdx b/product_docs/docs/pgd/6/reference/node_management/index.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/node_management/index.mdx rename to product_docs/docs/pgd/6/reference/node_management/index.mdx diff --git a/product_docs/docs/pgd/6/concepts/node_management/maintainance_with_proxies.mdx b/product_docs/docs/pgd/6/reference/node_management/maintainance_with_proxies.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/node_management/maintainance_with_proxies.mdx rename to product_docs/docs/pgd/6/reference/node_management/maintainance_with_proxies.mdx diff --git a/product_docs/docs/pgd/6/concepts/node_management/node_recovery.mdx b/product_docs/docs/pgd/6/reference/node_management/node_recovery.mdx similarity index 95% rename from product_docs/docs/pgd/6/concepts/node_management/node_recovery.mdx rename to product_docs/docs/pgd/6/reference/node_management/node_recovery.mdx index f425944184f..a343a7a40f6 100644 --- a/product_docs/docs/pgd/6/concepts/node_management/node_recovery.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/node_recovery.mdx @@ -40,9 +40,9 @@ vacuuming of catalog tables. On EDB Postgres Extended Server and EDB Postgres Advanced Server, offline nodes also hold back freezing of data to prevent losing conflict-resolution data -(see [Origin conflict detection](../conflict-management/conflicts)). +(see [Origin conflict detection](/pgd/latest/reference/conflict-management/conflicts)). -Administrators must monitor for node outages (see [Monitoring](../monitoring/)) +Administrators must monitor for node outages (see [Monitoring](/pgd/latest/reference/monitoring/)) and make sure nodes have enough free disk space. If the workload is predictable, you might be able to calculate how much space is used over time, allowing a prediction of the maximum time a node can be down before critical diff --git a/product_docs/docs/pgd/6/concepts/node_management/removing_nodes_and_groups.mdx b/product_docs/docs/pgd/6/reference/node_management/removing_nodes_and_groups.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/node_management/removing_nodes_and_groups.mdx rename to product_docs/docs/pgd/6/reference/node_management/removing_nodes_and_groups.mdx diff --git a/product_docs/docs/pgd/6/concepts/node_management/replication_slots.mdx b/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/node_management/replication_slots.mdx rename to product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx diff --git a/product_docs/docs/pgd/6/concepts/node_management/viewing_topology.mdx b/product_docs/docs/pgd/6/reference/node_management/viewing_topology.mdx similarity index 93% rename from product_docs/docs/pgd/6/concepts/node_management/viewing_topology.mdx rename to product_docs/docs/pgd/6/reference/node_management/viewing_topology.mdx index d8920d7f26f..8661ed2204e 100644 --- a/product_docs/docs/pgd/6/concepts/node_management/viewing_topology.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/viewing_topology.mdx @@ -5,9 +5,9 @@ title: Viewing PGD topology ## Listing PGD groups -### Using [pgd-cli](../cli) +### Using [pgd-cli](/pgd/latest/reference/cli/) -Use the [pgd-cli](../cli) `groups list` command to list all groups in the PGD cluster: +Use the [pgd-cli](/pgd/latest/reference/cli/) `groups list` command to list all groups in the PGD cluster: ```shell pgd groups list @@ -48,7 +48,7 @@ JOIN bdr.node_group g USING (node_group_name); ## Listing nodes in a PGD group -### Using [pgd-cli](../cli) +### Using [pgd-cli](/pgd/latest/reference/cli/) Use the `nodes list` command to list all nodes in the PGD cluster: diff --git a/product_docs/docs/pgd/6/concepts/nodes/index.mdx b/product_docs/docs/pgd/6/reference/nodes/index.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/nodes/index.mdx rename to product_docs/docs/pgd/6/reference/nodes/index.mdx diff --git a/product_docs/docs/pgd/6/concepts/nodes/logical_standby_nodes.mdx b/product_docs/docs/pgd/6/reference/nodes/logical_standby_nodes.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/nodes/logical_standby_nodes.mdx rename to product_docs/docs/pgd/6/reference/nodes/logical_standby_nodes.mdx diff --git a/product_docs/docs/pgd/6/concepts/nodes/overview.mdx b/product_docs/docs/pgd/6/reference/nodes/overview.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/nodes/overview.mdx rename to product_docs/docs/pgd/6/reference/nodes/overview.mdx diff --git a/product_docs/docs/pgd/6/concepts/nodes/subscriber_only/creating-so.mdx b/product_docs/docs/pgd/6/reference/nodes/subscriber_only/creating-so.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/nodes/subscriber_only/creating-so.mdx rename to product_docs/docs/pgd/6/reference/nodes/subscriber_only/creating-so.mdx diff --git a/product_docs/docs/pgd/6/concepts/nodes/subscriber_only/index.mdx b/product_docs/docs/pgd/6/reference/nodes/subscriber_only/index.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/nodes/subscriber_only/index.mdx rename to product_docs/docs/pgd/6/reference/nodes/subscriber_only/index.mdx diff --git a/product_docs/docs/pgd/6/concepts/nodes/subscriber_only/joining-so.mdx b/product_docs/docs/pgd/6/reference/nodes/subscriber_only/joining-so.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/nodes/subscriber_only/joining-so.mdx rename to product_docs/docs/pgd/6/reference/nodes/subscriber_only/joining-so.mdx diff --git a/product_docs/docs/pgd/6/concepts/nodes/subscriber_only/optimizing-so.mdx b/product_docs/docs/pgd/6/reference/nodes/subscriber_only/optimizing-so.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/nodes/subscriber_only/optimizing-so.mdx rename to product_docs/docs/pgd/6/reference/nodes/subscriber_only/optimizing-so.mdx diff --git a/product_docs/docs/pgd/6/concepts/nodes/subscriber_only/overview.mdx b/product_docs/docs/pgd/6/reference/nodes/subscriber_only/overview.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/nodes/subscriber_only/overview.mdx rename to product_docs/docs/pgd/6/reference/nodes/subscriber_only/overview.mdx diff --git a/product_docs/docs/pgd/6/concepts/nodes/witness_nodes.mdx b/product_docs/docs/pgd/6/reference/nodes/witness_nodes.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/nodes/witness_nodes.mdx rename to product_docs/docs/pgd/6/reference/nodes/witness_nodes.mdx diff --git a/product_docs/docs/pgd/6/concepts/overview/architecture-and-performance.mdx b/product_docs/docs/pgd/6/reference/overview/architecture-and-performance.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/overview/architecture-and-performance.mdx rename to product_docs/docs/pgd/6/reference/overview/architecture-and-performance.mdx diff --git a/product_docs/docs/pgd/6/concepts/overview/basic-architecture.mdx b/product_docs/docs/pgd/6/reference/overview/basic-architecture.mdx similarity index 70% rename from product_docs/docs/pgd/6/concepts/overview/basic-architecture.mdx rename to product_docs/docs/pgd/6/reference/overview/basic-architecture.mdx index 6e0e50b2671..623ff888963 100644 --- a/product_docs/docs/pgd/6/concepts/overview/basic-architecture.mdx +++ b/product_docs/docs/pgd/6/reference/overview/basic-architecture.mdx @@ -39,10 +39,10 @@ PGD comprises several key architectural elements that work together to provide i - **Replication mechanisms**: PGD's replication mechanisms include 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 use its [built-in command-line interface](../cli) (CLI), which offers several useful commands. For example: - - The [`pgd nodes list`](/pgd/latest/cli/command_ref/nodes/list/) command provides a summary of all nodes in the cluster, including their state and status. - - The [`pgd cluster show --health`](/pgd/latest/cli/command_ref/cluster/show/#options) command checks the health of the cluster, reporting on node accessibility, replication slot health, and other critical metrics. - - The [`pgd events show`](/pgd/latest/cli/command_ref/events/show/) command lists significant events like background worker errors and node membership changes, which helps in tracking the operational status and issues within the cluster. + - **Monitoring tools**: To monitor performance, health, and usage with PGD, you can use its [built-in command-line interface](/pgd/latest/reference/cli) (CLI), which offers several useful commands. For example: + - The [`pgd nodes list`](/pgd/latest/reference/cli/command_ref/nodes/list/) command provides a summary of all nodes in the cluster, including their state and status. + - The [`pgd cluster show --health`](/pgd/latest/reference/cli/command_ref/cluster/show/#options) command checks the health of the cluster, reporting on node accessibility, replication slot health, and other critical metrics. + - The [`pgd events show`](/pgd/latest/reference/cli/command_ref/events/show/) 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. @@ -50,15 +50,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](../nodes/overview#data-nodes)**: Store and manage data, handle read and write operations, and participate in replication. + - **[Data nodes](/pgd/latest/reference/nodes/overview#data-nodes)**: Store and manage data, handle read and write operations, and participate in replication. There are then three types of nodes which, although built like a data node, have a specific purpose. These are: - - **[Subscriber-only nodes](../nodes/subscriber_only/)**: Subscribe to changes from data nodes for read-only purposes. Used in reporting or analytics. + - **[Subscriber-only nodes](/pgd/latest/reference/nodes/subscriber_only/)**: Subscribe to changes from data nodes for read-only purposes. Used in reporting or analytics. - - **[Witness nodes](../nodes/witness_nodes/)**: Participate in the consensus process without storing data, aiding in achieving quorum and maintaining high availability. + - **[Witness nodes](/pgd/latest/reference/nodes/witness_nodes/)**: Participate in the consensus process without storing data, aiding in achieving quorum and maintaining high availability. - - **[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. + - **[Logical standby nodes](/pgd/latest/reference/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 @@ -68,7 +68,7 @@ These roles can include: - **Raft leader**: Arbitrates and manages consensus between a group's nodes. - - **[Write leader](../terminology/#write-leader)**: Receives all write operations from PGD Proxy. + - **[Write leader](/pgd/latest/terminology/#write-leader)**: Receives all write operations from PGD Proxy. ## Architectural flexibility @@ -82,10 +82,10 @@ PGD allows for selective replication, enabling users to replicate only a subset With commit scopes, PGD also provides configurable durability. Accordingly, durability can be increased from the default asynchronous behavior and tuned using various configurable commit scopes: -- **[Synchronous Commit](../commit-scopes/synchronous_commit.mdx)**: Works a lot like PostgreSQL’s synchronous_commit option in its underlying operation. Requires writing to at least one other node at COMMIT time but can be tuned to require all nodes. +- **[Synchronous Commit](/pgd/latest/reference/commit-scopes/synchronous_commit.mdx)**: Works a lot like PostgreSQL’s synchronous_commit option in its underlying operation. Requires writing to at least one other node at COMMIT time but can be tuned to require all nodes. -- **[CAMO](../commit-scopes/camo.mdx)** (Commit At Most Once): Works by tracking each transaction with a unique ID and using a pair of nodes to confirm the transaction's outcome, ensuring the application knows whether to retry the transaction or not. +- **[CAMO](/pgd/latest/reference/commit-scopes/camo.mdx)** (Commit At Most Once): Works by tracking each transaction with a unique ID and using a pair of nodes to confirm the transaction's outcome, ensuring the application knows whether to retry the transaction or not. -- **[Group Commit](../commit-scopes/group-commit.mdx)**: An experimental commit scope, the goal of which is to protect against data loss in case of single-node failures of temporary outages by requiring more than one PGD node to successfully confirm a transaction at COMMIT time. +- **[Group Commit](/pgd/latest/reference/commit-scopes/group-commit.mdx)**: An experimental commit scope, the goal of which is to protect against data loss in case of single-node failures of temporary outages by requiring more than one PGD node to successfully confirm a transaction at COMMIT time. -- **[Lag Control](../commit-scopes/lag-control.mdx)**: If replication is running outside of set limits (taking too long for another node to be replicated to), a delay is injected into the node that originally received the transaction, slowing things down until other nodes have caught up. +- **[Lag Control](/pgd/latest/reference/commit-scopes/lag-control.mdx)**: If replication is running outside of set limits (taking too long for another node to be replicated to), a delay is injected into the node that originally received the transaction, slowing things down until other nodes have caught up. diff --git a/product_docs/docs/pgd/6/concepts/overview/compared.mdx b/product_docs/docs/pgd/6/reference/overview/compared.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/overview/compared.mdx rename to product_docs/docs/pgd/6/reference/overview/compared.mdx diff --git a/product_docs/docs/pgd/6/concepts/overview/images/always_on_1x3_updated.png b/product_docs/docs/pgd/6/reference/overview/images/always_on_1x3_updated.png similarity index 100% rename from product_docs/docs/pgd/6/concepts/overview/images/always_on_1x3_updated.png rename to product_docs/docs/pgd/6/reference/overview/images/always_on_1x3_updated.png diff --git a/product_docs/docs/pgd/6/concepts/overview/index.mdx b/product_docs/docs/pgd/6/reference/overview/index.mdx similarity index 100% rename from product_docs/docs/pgd/6/concepts/overview/index.mdx rename to product_docs/docs/pgd/6/reference/overview/index.mdx diff --git a/product_docs/docs/pgd/6/reference/postgres-configuration.mdx b/product_docs/docs/pgd/6/reference/postgres-configuration.mdx index 26805c2b7a3..1d9a473f327 100644 --- a/product_docs/docs/pgd/6/reference/postgres-configuration.mdx +++ b/product_docs/docs/pgd/6/reference/postgres-configuration.mdx @@ -9,19 +9,19 @@ redirects: Several Postgres configuration parameters affect PGD nodes. You can set these parameters differently on each node, although we don't generally recommend it. -For PGD's own settings, see the [PGD settings reference](reference/pgd-settings). +For PGD's own settings, see the [PGD settings reference](/pgd/latest/reference/pgd-settings). ## Postgres settings To run correctly, PGD requires these Postgres settings: -- `wal_level` — Must be set to `logical`, since PGD relies on logical decoding. -- `shared_preload_libraries` — Must include `bdr` to enable the extension. Most other - extensions can appear before or after the `bdr` entry in the comma-separated list. One exception - to that is `pgaudit`, which must appear in the list before `bdr`. Also, don't include - `pglogical` in this list. -- `track_commit_timestamp` — Must be set to `on` for conflict resolution to - retrieve the timestamp for each conflicting row. +- `wal_level` — Must be set to `logical`, since PGD relies on logical decoding. +- `shared_preload_libraries` — Must include `bdr` to enable the extension. Most other + extensions can appear before or after the `bdr` entry in the comma-separated list. One exception + to that is `pgaudit`, which must appear in the list before `bdr`. Also, don't include + `pglogical` in this list. +- `track_commit_timestamp` — Must be set to `on` for conflict resolution to + retrieve the timestamp for each conflicting row. PGD requires these PostgreSQL settings to be set to appropriate values, which vary according to the size and scale of the cluster: diff --git a/product_docs/docs/pgd/6/reference/repsets.mdx b/product_docs/docs/pgd/6/reference/repsets.mdx index 4156f72a854..cb93c933274 100644 --- a/product_docs/docs/pgd/6/reference/repsets.mdx +++ b/product_docs/docs/pgd/6/reference/repsets.mdx @@ -259,12 +259,6 @@ This example assumes you have a cluster of six data nodes, `data-a1` to `data-a3 There's also, as we recommend, a witness node named `witness` in `region-c` that isn't mentioned in this example. The cluster is called `sere`. -This configuration looks like this: - -![Multi-Region 3 Nodes Configuration](./planning/images/always-on-2x3-aa-updated.png) - -This is the standard Always-on Multi-region configuration discussed in [Choosing your architecture](planning/architectures). - ### Application requirements This example works with an application that records the opinions of people who attended performances of musical works. There's a table for attendees, a table for the works, and an opinion table. The opinion table records each work each attendee saw, where and when they saw it, and how they scored the work. Because of data regulation, the example assumes that opinion data must stay only in the region where the opinion was recorded. diff --git a/product_docs/docs/pgd/6/reference/sequences.mdx b/product_docs/docs/pgd/6/reference/sequences.mdx index e98f86b3183..2687424fa30 100644 --- a/product_docs/docs/pgd/6/reference/sequences.mdx +++ b/product_docs/docs/pgd/6/reference/sequences.mdx @@ -61,7 +61,7 @@ Globally allocated sequences allocate a local range of values that can be replenished as needed by inter-node consensus, making them suitable for either BIGINT or INTEGER sequences. -You can create a global sequence using the [`bdr.alter_sequence_set_kind()`](reference/sequences/#bdralter_sequence_set_kind) +You can create a global sequence using the [`bdr.alter_sequence_set_kind()`](/pgd/latest/reference/tables-views-functions/sequences/#bdralter_sequence_set_kind) function. This function takes a standard PostgreSQL sequence and marks it as a PGD global sequence. It can also convert the sequence back to the standard PostgreSQL sequence. @@ -80,7 +80,7 @@ command is executed or when a `serial`, `bigserial`, or - `timeshard` — The older version of SnowflakeId sequence. Provided for backward compatibility only. The SnowflakeId is preferred. - `distributed` (default) — A special value that you can use only for - [`bdr.default_sequence_kind`](reference/pgd-settings/#global-sequence-parameters). It selects `snowflakeid` for `int8` + [`bdr.default_sequence_kind`](/pgd/latest/reference/tables-views-functions/pgd-settings/#global-sequence-parameters). It selects `snowflakeid` for `int8` sequences (that is, `bigserial`) and `galloc` sequence for `int4` (that is, `serial`) and `int2` sequences. @@ -296,7 +296,7 @@ When the sequence kind is altered to `galloc`, it's rewritten and restarts from the defined start value of the local sequence. If this happens on an existing sequence in a production database, you need to query the current value and then set the start value appropriately. To help with this use case, PGD -lets you pass a starting value with the function [`bdr.alter_sequence_set_kind()`](reference/sequences/#bdralter_sequence_set_kind). +lets you pass a starting value with the function [`bdr.alter_sequence_set_kind()`](/pgd/latest/reference/tables-views-functions/sequences/#bdralter_sequence_set_kind). If you're already using offset and you have writes from multiple nodes, you need to check what's the greatest used value and restart the sequence to at least the next value: @@ -316,7 +316,7 @@ SELECT bdr.alter_sequence_set_kind('public.sequence'::regclass, 'galloc', $MAX + Since users can't lock a sequence, you must leave a `$MARGIN` value to allow operations to continue while the `max()` value is queried. -The [`bdr.sequence_alloc`](reference/catalogs-visible/#bdrsequence_alloc) table gives information on the chunk size and the +The [`bdr.sequence_alloc`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrsequence_alloc) table gives information on the chunk size and the ranges allocated around the whole cluster. In this example, the sequence starts at `333`, and the cluster has two nodes. @@ -464,7 +464,7 @@ The internal contents of v1 and v2 aren't compatible. As such, the functions to manipulate them also aren't compatible. The v2 of `KSUUID` also no longer stores the `UUID` version number. -See [KSUUID v2 functions](reference/sequences/#ksuuid-v2-functions) and [KSUUID v1 functions](reference/sequences/#ksuuid-v1-functions) in the PGD reference. +See [KSUUID v2 functions](/pgd/latest/reference/tables-views-functions/sequences/#ksuuid-v2-functions) and [KSUUID v1 functions](/pgd/latest/reference/tables-views-functions/sequences/#ksuuid-v1-functions) in the PGD reference. ### Step and offset sequences @@ -526,6 +526,6 @@ a one-row table that isn't part of a replication set to store a different value in each node. ## See also -* [Global Sequence management interfaces](reference/sequences/) -* [KSUUID v2 functions](reference/sequences/#ksuuid-v2-functions) -* [KSUUID v1 functions](reference/sequences/#ksuuid-v1-functions) +* [Global Sequence management interfaces](/pgd/latest/reference/tables-views-functions/sequences/) +* [KSUUID v2 functions](/pgd/latest/reference/tables-views-functions/sequences/#ksuuid-v2-functions) +* [KSUUID v1 functions](/pgd/latest/reference/tables-views-functions/sequences/#ksuuid-v1-functions) diff --git a/product_docs/docs/pgd/6/reference/striggers.mdx b/product_docs/docs/pgd/6/reference/striggers.mdx index 377e0a44d2e..7511d82d971 100644 --- a/product_docs/docs/pgd/6/reference/striggers.mdx +++ b/product_docs/docs/pgd/6/reference/striggers.mdx @@ -30,7 +30,7 @@ A trigger function is a program defined in this form: `CREATE FUNCTION ... RETURNS TRIGGER`. Creating the trigger doesn't require use of the `CREATE TRIGGER` command. Instead, create stream triggers using the special PGD functions -[`bdr.create_conflict_trigger()`](reference/streamtriggers/interfaces/#bdrcreate_conflict_trigger) and [`bdr.create_transform_trigger()`](reference/streamtriggers/interfaces/#bdrcreate_transform_trigger). +[`bdr.create_conflict_trigger()`](/pgd/latest/reference/tables-views-functions/streamtriggers/interfaces/#bdrcreate_conflict_trigger) and [`bdr.create_transform_trigger()`](/pgd/latest/reference/tables-views-functions/streamtriggers/interfaces/#bdrcreate_transform_trigger). Once created, the trigger is visible in the catalog table `pg_trigger`. The stream triggers are marked as `tgisinternal = true` and diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx index c1d0e0d5763..ce6d993770f 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx @@ -49,7 +49,7 @@ The default data retention period is 30 days. Access to this table is possible by any table owner, who can see all conflicts for the tables they own, restricted by row-level security. -For details, see [Logging conflicts to a table](../conflict-management/conflicts). +For details, see [Logging conflicts to a table](/pgd/latest/reference/conflict-management/conflicts). #### `bdr.conflict_history` columns diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/conflict_functions.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/conflict_functions.mdx index 26d01bdde5d..79899c6571e 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/conflict_functions.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/conflict_functions.mdx @@ -23,10 +23,10 @@ bdr.alter_table_conflict_detection(relation regclass, The recognized methods for conflict detection are: -- `row_origin` — Origin of the previous change made on the tuple (see [Origin conflict detection](../conflict-management/conflicts/03_conflict_detection/#origin-conflict-detection)). This is the only method supported that doesn't require an extra column in the table. -- `row_version` — Row version column (see [Row version conflict detection](../conflict-management/conflicts/03_conflict_detection/#row-version-conflict-detection)). -- `column_commit_timestamp` — Per-column commit timestamps (described in [CLCD](../conflict-management/column-level-conflicts)). -- `column_modify_timestamp` — Per-column modification timestamp (described in [CLCD](../conflict-management/column-level-conflicts)). +- `row_origin` — Origin of the previous change made on the tuple (see [Origin conflict detection](/pgd/latest/reference/conflict-management/conflicts/03_conflict_detection/#origin-conflict-detection)). This is the only method supported that doesn't require an extra column in the table. +- `row_version` — Row version column (see [Row version conflict detection](/pgd/latest/reference/conflict-management/conflicts/03_conflict_detection/#row-version-conflict-detection)). +- `column_commit_timestamp` — Per-column commit timestamps (described in [CLCD](/pgd/latest/reference/conflict-management/column-level-conflicts)). +- `column_modify_timestamp` — Per-column modification timestamp (described in [CLCD](/pgd/latest/reference/conflict-management/column-level-conflicts)). ### Notes diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/conflicts.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/conflicts.mdx index 1f7abd45414..238db9fa88f 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/conflicts.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/conflicts.mdx @@ -19,7 +19,7 @@ PGD recognizes the following conflict types, which can be used as the `conflict_ | `update_recently_deleted` | An incoming update is trying to modify a row that was recently deleted. | | `update_pkey_exists` | An incoming update has modified the `PRIMARY KEY` to a value that already exists on the node that's applying the change. | | `multiple_unique_conflicts`| An incoming row conflicts with multiple rows per UNIQUE/EXCLUDE indexes of the target table. | -| `delete_recently_updated` | An incoming delete with an older commit timestamp than the most recent update of the row on the current node or when using [row version conflict detection](../conflict-management/conflicts/03_conflict_detection/#row-version-conflict-detection). | +| `delete_recently_updated` | An incoming delete with an older commit timestamp than the most recent update of the row on the current node or when using [row version conflict detection](/pgd/latest/reference/conflict-management/conflicts/03_conflict_detection/#row-version-conflict-detection). | | `delete_missing` | An incoming delete is trying to remove a row that doesn't exist. | | `target_column_missing` | The target table is missing one or more columns present in the incoming row. | | `source_column_missing` | The incoming row is missing one or more columns that are present in the target table. | diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx index 3e5b07425f8..affc011c80d 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx @@ -281,7 +281,7 @@ If a slot is dropped concurrently, the wait ends for that slot. If a node is currently down and isn't updating its slot, then the wait continues. You might want to set `statement_timeout` to complete earlier in that case. -If you are using [Optimized Topology](../nodes/subscriber_only/optimizing-so), we recommend using [`bdr.wait_node_confirm_lsn`](/pgd/latest/reference/tables-views-functions/functions#bdrwait_node_confirm_lsn) instead. +If you are using [Optimized Topology](/pgd/latest/reference/nodes/subscriber_only/optimizing-so), we recommend using [`bdr.wait_node_confirm_lsn`](/pgd/latest/reference/tables-views-functions/functions#bdrwait_node_confirm_lsn) instead. ) #### Synopsis @@ -619,7 +619,7 @@ either transparent DDL replication or `bdr.replicate_ddl_command()`. ### `bdr.global_lock_table` This function acquires a global DML locks on a given table. -See [DDL locking details](../ddl/ddl-locking.mdx) for information +See [DDL locking details](/pgd/latest/reference/ddl/ddl-locking.mdx) for information about global DML lock. #### Synopsis @@ -968,7 +968,7 @@ view `pg_replication_slots` (slot active or inactive) to provide a local check considering all replication slots except the PGD group slots. -This function also provides status information on subscriber-only nodes that are operating as subscriber-only group leaders in a PGD cluster when [optimized topology](../nodes/subscriber_only/optimizing-so) is enabled. +This function also provides status information on subscriber-only nodes that are operating as subscriber-only group leaders in a PGD cluster when [optimized topology](/pgd/latest/reference/nodes/subscriber_only/optimizing-so) is enabled. #### Synopsis @@ -1067,6 +1067,31 @@ bdr.lag_control() | `maximum_lag_time` | Configured maximum lag time, in milliseconds. | | `sample_interval` | Configured minimum time between lag samples and possible commit delay adjustments, in milliseconds. | +## Routing functions + + +### `bdr.routing_leadership_transfer` + +Changing the routing leader transfers the leadership of the node group to another node. + +#### Synopsis + +```sql +bdr.routing_leadership_transfer(node_group_name text, + leader_name text, + transfer_method text DEFAULT 'strict', + transfer_timeout interval DEFAULT '10s'); +``` + +#### Parameters + +| Name | Type | Default | Description | +|--------------------|----------|----------|---------------------------------------------------------------------------------------------| +| `node_group_name` | text | | Name of group where the leadership transfer is requested. | +| `leader_name` | text | | Name of node that will become write leader. | +| `transfer_method` | text | `'strict'` | Type of the transfer. It can be `'fast'` or the default, `'strict'`, which checks the maximum lag. | +| `transfer_timeout` | interval | '10s' | Timeout of the leadership transfer. Default is 10 seconds. | + ## CAMO functions diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/index.json b/product_docs/docs/pgd/6/reference/tables-views-functions/index.json index 4ee46e03b8a..38e37103ca3 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/index.json +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/index.json @@ -115,6 +115,7 @@ "bdrwal_sender_stats": "/pgd/6/reference/tables-views-functions/functions#bdrwal_sender_stats", "bdrget_decoding_worker_stat": "/pgd/6/reference/tables-views-functions/functions#bdrget_decoding_worker_stat", "bdrlag_control": "/pgd/6/reference/tables-views-functions/functions#bdrlag_control", + "bdrrouting_leadership_transfer": "/pgd/6/reference/tables-views-functions/functions#bdrrouting_leadership_transfer", "bdris_camo_partner_connected": "/pgd/6/reference/tables-views-functions/functions#bdris_camo_partner_connected", "bdris_camo_partner_ready": "/pgd/6/reference/tables-views-functions/functions#bdris_camo_partner_ready", "bdrget_configured_camo_partner": "/pgd/6/reference/tables-views-functions/functions#bdrget_configured_camo_partner", diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx index 9e8be2cead5..7daee58fa9b 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx @@ -1,9 +1,9 @@ --- # edit index.mdx.src DO NOT edit index.mdx or index.json -title: "Table, view and function reference" -navTitle: "Table, view and function reference" +title: "Tables, views and functions reference" +navTitle: "Tables, views and functions" description: > - The complete reference to all functions, views, and commands available in EDB Postgres Distributed. + The complete reference to all tables, views, functions, views, and commands available in EDB Postgres Distributed. indexCards: none navigation: - catalogs-visible @@ -160,6 +160,8 @@ The reference section is a definitive listing of all functions, views, and comma * [`bdr.wal_sender_stats`](functions#bdrwal_sender_stats) * [`bdr.get_decoding_worker_stat`](functions#bdrget_decoding_worker_stat) * [`bdr.lag_control`](functions#bdrlag_control) +### [Routing functions](functions#routing-functions) + * [`bdr.routing_leadership_transfer`](functions#bdrrouting_leadership_transfer) ### [CAMO functions](functions#camo-functions) * [`bdr.is_camo_partner_connected`](functions#bdris_camo_partner_connected) * [`bdr.is_camo_partner_ready`](functions#bdris_camo_partner_ready) @@ -288,6 +290,9 @@ The reference section is a definitive listing of all functions, views, and comma * [`bdr.wait_for_join_completion`](nodes-management-interfaces#bdrwait_for_join_completion) +## [Routing functions](routing) + + ## [Commit scopes](commit-scopes) * [Commit scope syntax](commit-scopes#commit-scope-syntax) * [commit_scope_degrade_operation](commit-scopes#commit_scope_degrade_operation) diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx.src b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx.src index eba43e560d7..9755338d0a9 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx.src +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx.src @@ -1,9 +1,9 @@ --- # edit index.mdx.src DO NOT edit index.mdx or index.json -title: "Table, view and function reference" -navTitle: "Table, view and function reference" +title: "Tables, views and functions reference" +navTitle: "Tables, views and functions" description: > - The complete reference to all functions, views, and commands available in EDB Postgres Distributed. + The complete reference to all tables, views, functions, views, and commands available in EDB Postgres Distributed. indexCards: none navigation: - catalogs-visible diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/nodes-management-interfaces.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/nodes-management-interfaces.mdx index 94cb3e5d475..626a9d02184 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/nodes-management-interfaces.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/nodes-management-interfaces.mdx @@ -35,7 +35,7 @@ The table shows the group options that can be changed using this function. | `apply_delay` | `interval` | How long nodes wait to apply incoming changes. This option is useful mainly to set up a special subgroup with delayed subscriber-only nodes. Don't set this on groups that contain data nodes or on the top-level group. Default is `0s`. | | `check_constraints` | `boolean` | Whether the apply process checks the constraints when writing replicated data. We recommend keeping the default value or you risk data loss. Valid values are `on` or `off`. Default is `on`. | | `default_commit_scope` | `text` | The commit scope to use by default, initially the `local` commit scope. This option applies only to the top-level node group. You can use individual rules for different origin groups of the same commit scope. See [Origin groups](../commit-scopes/origin_groups) for more details. | -| `enable_routing` | `boolean` | Where [`Connection Manager`](../routing/) through the group write leader is enabled for given group. Valid values are `on` or `off`. Default is `on` for subgroups and off for the cluster group. | +| `enable_routing` | `boolean` | Where [`Connection Manager`](/pgd/latest/reference/connection-manager/) through the group write leader is enabled for given group. Valid values are `on` or `off`. Default is `on` for subgroups and off for the cluster group. | | `enable_raft` | `boolean` | Whether group has its own Raft consensus. This option is necessary for setting `enable_routing` to `on`. This option is always `on` for the top-level group. Valid values are `on` or `off`. Default is `on` for subgroups. | | `enable_wal_decoder` | `boolean` | Enables/disables the decoding worker process. You can't enable the decoding worker process if `streaming_mode` is already enabled. Valid values are `on` or `off`. Default is `off`. | | `location` | `text` | Information about group location. This option is purely metadata for monitoring. Default is `''` (empty string). | @@ -44,7 +44,7 @@ The table shows the group options that can be changed using this function. | `route_writer_max_lag` | `integer` | Maximum lag in bytes of the new write candidate to be selected as write leader. If no candidate passes this, no writer is selected. Default is `-1`. | | `route_writer_wait_flush` | `boolean` | Whether to switch if PGD needs to wait for the flush. Currently reserved for future use. | | `streaming_mode` | `text` | Enables/disables streaming of large transactions. When set to `off`, streaming is disabled. When set to any other value, large transactions are decoded while they're still in progress, and the changes are sent to the downstream. If the value is set to `file`, then the incoming changes of streaming transactions are stored in a file and applied only after the transaction is committed on upstream. If the value is set to `writer`, then the incoming changes are directly sent to one of the writers, if available.
If [parallel apply](../parallelapply) is disabled or no writer is free to handle streaming transactions, then the changes are written to a file and applied after the transaction is committed. If the value is set to `auto`, PGD tries to intelligently pick between `file` and `writer`, depending on the transaction property and available resources. You can't enable `streaming_mode` if the WAL decoder is already enabled. Default is `auto`.

For more details, see [Transaction streaming](../transaction-streaming). | -| `failover_slot_scope` | `text` | PGD 5.7 and later only. Sets the scope for Logical Slot Failover support. Valid values are `global` or `local`. Default is `local`. For more information, see [CDC Failover support](/pgd/latest/cdc-failover). | +| `failover_slot_scope` | `text` | PGD 5.7 and later only. Sets the scope for Logical Slot Failover support. Valid values are `global` or `local`. Default is `local`. For more information, see [CDC Failover support](/pgd/latest/reference/cdc-failover). | ### Return value @@ -249,7 +249,7 @@ bdr.create_node_group(node_group_name text, | `node_group_name` | Name of the new PGD group. As with the node name, valid group names consist of only lowercase letters, numbers, and underscores. | | `parent_group_name` | If a node subgroup is being created, this must be the name of the parent group. Provide `NULL` (the default) when creating the main node group for the cluster. | | `join_node_group` | Determines whether the node joins the group being created. The default value is `true`. Providing `false` when creating a subgroup means the local node won't join the new group, for example, when creating an independent remote group. In this case, you must specify `parent_group_name`. | -| `node_group_type` | The valid values are `NULL` or `subscriber-only`. `NULL` (the default) is for creating a normal, general-purpose node group. `subscriber-only` is for creating [subscriber-only groups](../nodes/subscriber_only/) whose members receive changes only from the fully joined nodes in the cluster but that never send changes to other nodes. | +| `node_group_type` | The valid values are `NULL` or `subscriber-only`. `NULL` (the default) is for creating a normal, general-purpose node group. `subscriber-only` is for creating [subscriber-only groups](/pgd/latest/reference/nodes/subscriber_only/) whose members receive changes only from the fully joined nodes in the cluster but that never send changes to other nodes. | ### Notes diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/pgd-settings.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/pgd-settings.mdx index cb611a4ab4f..b3cdfa95fe0 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/pgd-settings.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/pgd-settings.mdx @@ -92,7 +92,7 @@ Turning this parameter off without using external methods to ensure roles are in across all nodes might cause replicated DDL to interrupt replication until the administrator intervenes. -See [Role manipulation statements](../ddl/ddl-role-manipulation.mdx) +See [Role manipulation statements](/pgd/latest/reference/ddl/ddl-role-manipulation.mdx) for details. ### `bdr.ddl_locking` @@ -382,7 +382,7 @@ receivers don't have a writer ID. ### `bdr.crdt_raw_value` -Sets the output format of [CRDT data types](../conflict-management/crdt). +Sets the output format of [CRDT data types](/pgd/latest/reference/conflict-management/crdt). The default output (when this setting is `off`) is to return only the current value of the base CRDT type, for example, a bigint for `crdt_pncounter`. @@ -393,7 +393,7 @@ the CRDT value, which can, for example, include the state from multiple nodes. ### `bdr.commit_scope` -Sets the current (or default) [commit scope](../commit-scopes/commit-scopes) (default +Sets the current (or default) [commit scope](/pgd/latest/reference/commit-scopes/commit-scopes) (default is an empty string). ## Commit At Most Once diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/routing.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/routing.mdx new file mode 100644 index 00000000000..b911e1b9e9e --- /dev/null +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/routing.mdx @@ -0,0 +1,7 @@ +--- +navTitle: Routing functions +title: Routing functions +indexdepth: 3 +rootisheading: false +--- + diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/streamtriggers/index.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/streamtriggers/index.mdx index 95311f688cc..304689b5811 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/streamtriggers/index.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/streamtriggers/index.mdx @@ -8,10 +8,10 @@ navigation: --- !!! SeeAlso -[Stream Triggers](../../striggers) for an introduction to Stream Triggers. +[Stream Triggers](/pgd/latest/reference/striggers) for an introduction to Stream Triggers. !!! -Both [conflict triggers](../../striggers/#conflict-triggers) and [transform triggers](../../striggers/#transform-triggers) have access to information about +Both [conflict triggers](/pgd/latest/reference/striggers/#conflict-triggers) and [transform triggers](/pgd/latest/reference/striggers/#transform-triggers) have access to information about rows and metadata by way of the predefined variables provided by the trigger API and additional information functions provided by PGD. diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/streamtriggers/rowfunctions.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/streamtriggers/rowfunctions.mdx index 82ddd20b556..28b023a527f 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/streamtriggers/rowfunctions.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/streamtriggers/rowfunctions.mdx @@ -77,7 +77,7 @@ bdr.trigger_get_type() This function returns the current conflict type if called inside a conflict trigger. Otherwise, returns `NULL`. -See [Conflict types](../../conflict-management/conflicts/02_types_of_conflict/) +See [Conflict types](/pgd/latest/reference/conflict-management/conflicts/02_types_of_conflict/) for possible return values of this function. #### Synopsis diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/testingandtuning.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/testingandtuning.mdx index 1e43b60b817..0f8d9638d59 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/testingandtuning.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/testingandtuning.mdx @@ -4,7 +4,7 @@ navTitle: Testing and tuning indexdepth: 2 --- -EDB Postgres Distributed has tools that help with testing and tuning your PGD clusters. For background, see [Testing and tuning](../testingandtuning). +EDB Postgres Distributed has tools that help with testing and tuning your PGD clusters. For background, see [Testing and tuning](/pgd/latest/reference/testing-tuning). ## `pgd_bench` @@ -20,7 +20,7 @@ pgd_bench [OPTION]... [DBNAME] [DBNAME2] `DBNAME` can be a conninfo string of the format: `"host=10.1.1.2 user=postgres dbname=master"` -See [pgd_bench in Testing and tuning](../testingandtuning#pgd_bench) for examples +See [pgd_bench in Testing and tuning](/pgd/latest/reference/testing-tuning#pgd_bench) for examples of pgd_bench options and usage. ### Options @@ -48,7 +48,7 @@ option is automatically enabled when `-m camo` is used. `-o` or `--set-option` This option is followed by `NAME=VALUE` entries, which are applied using the -Postgres [`SET`](https://www.postgresql.org/docs/current/sql-set.html) command on each server that pgd_bench connects to, and only those servers. +Postgres [`SET`](https://www.postgresql.org/docs/current/sql-set.html) command on each server that pgd_bench connects to, and only those servers. The other options are identical to the Postgres pgbench command. For details, see the PostgreSQL diff --git a/product_docs/docs/pgd/6/terminology.mdx b/product_docs/docs/pgd/6/terminology.mdx index 7b795a8e46f..4f7fdc5fc74 100644 --- a/product_docs/docs/pgd/6/terminology.mdx +++ b/product_docs/docs/pgd/6/terminology.mdx @@ -90,7 +90,7 @@ Traditionally, in PostgreSQL, a number of databases running on a single server i #### Quorum A quorum is the minimum number of voting nodes needed to participate in a distributed vote. It ensures that the decision made has validity. For example, -when a [Raft](#replicated-available-fault-tolerance-raft) [consensus](#consensus) is needed by a PGD cluster, a minimum number of voting nodes participating in the vote are needed. With a 5-node cluster, the quorum is 3 nodes in the cluster voting. A consensus is 5/2+1 nodes, 3 nodes voting the same way. If there are only 2 voting nodes, then a consensus is never established. Quorums are required in PGD for [global locks](ddl/ddl-locking/) and Raft decisions. +when a [Raft](#replicated-available-fault-tolerance-raft) [consensus](#consensus) is needed by a PGD cluster, a minimum number of voting nodes participating in the vote are needed. With a 5-node cluster, the quorum is 3 nodes in the cluster voting. A consensus is 5/2+1 nodes, 3 nodes voting the same way. If there are only 2 voting nodes, then a consensus is never established. Quorums are required in PGD for [global locks](/pgd/latest/reference/ddl/ddl-locking/) and Raft decisions. #### Replicated available fault tolerance (Raft) From 97f4cea2bd91ddf9b78e21b5d1b02f7436780015 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 1 May 2025 09:35:10 +0100 Subject: [PATCH 032/145] small fixes Signed-off-by: Dj Walker-Morgan --- .../pgd_cli_ba.mdx | 12 +-- .../reference/cli/command_ref/node/setup.mdx | 78 +++++++++++++++++++ .../docs/pgd/6/reference/cli/index.mdx | 4 +- .../pgd/6/reference/cli/installing/linux.mdx | 34 +++++++- .../cli/installing/postgres-configuration.mdx | 66 ---------------- 5 files changed, 116 insertions(+), 78 deletions(-) create mode 100644 product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx delete mode 100644 product_docs/docs/pgd/6/reference/cli/installing/postgres-configuration.mdx diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/pgd_cli_ba.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/pgd_cli_ba.mdx index 5aa4bbbcb22..c5a8731d763 100644 --- a/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/pgd_cli_ba.mdx +++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/pgd_cli_ba.mdx @@ -6,7 +6,7 @@ redirects: - /biganimal/latest/using_cluster/pgd_cli_ba/ #generated for BigAnimal URL path removal branch --- -When running a distributed high-availability cluster on Cloud Service, you can use the [PGD CLI](/pgd/latest/cli/) to manage cluster operations. +When running a distributed high-availability cluster on Cloud Service, you can use the [PGD CLI](/pgd/latest/reference/cli/) to manage cluster operations. Examples of these operations include switching over write leaders, performing cluster health checks, and viewing various details about nodes, groups, or other aspects of the cluster. ## Installing the PGD CLI @@ -31,11 +31,11 @@ sudo yum install edb-pgd5-cli To connect to your distributed high-availability Cloud Service cluster using the PGD CLI, you need to [discover the database connection string](/pgd/latest/cli/discover_connections/). From your Console: -1. Log in to the [Cloud Service clusters](https://portal.biganimal.com/clusters) view. -2. To show only clusters that work with PGD CLI, in the filter, set **Cluster Type** to **Distributed High Availability**. -3. Select your cluster. -4. In the view of your cluster, select the **Connect** tab. -5. Copy the read/write URI from the connection info. This is your connection string. +1. Log in to the [Cloud Service clusters](https://portal.biganimal.com/clusters) view. +2. To show only clusters that work with PGD CLI, in the filter, set **Cluster Type** to **Distributed High Availability**. +3. Select your cluster. +4. In the view of your cluster, select the **Connect** tab. +5. Copy the read/write URI from the connection info. This is your connection string. ### Using the PGD CLI with your database connection string diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx new file mode 100644 index 00000000000..936cc3dbfe6 --- /dev/null +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx @@ -0,0 +1,78 @@ +--- +title: pgd node setup +navTitle: setup +deepToC: true +--- + +## Synopsis + +The `pgd node setup` command is used to configure PGD data nodes in a cluster. It can be used to set up a new node, join an existing node to a cluster, or perform a logical join of a node to the cluster. + +The behavior of the command depends on the state of the local node and the remote node specified in the command. + +If this is the first node in the cluster, `pgd node setup` will perform initdb and setup PGD node. + +If this is not the first node, but the local node is not up and running, `pgd node setup` will perform a physical join of the node to the cluster. This will copy the data from the remote node to the local node as part of the initialization process, then join the local node to the cluster. This is the fastest way to load data into a new node. + +If the local node is up and running and remote node also is reachable, `pgd node setup` will perform a logical join of the node to the cluster. This will create a new node in the cluster and start streaming replication from the remote node. This is the recommended way to add a new node to an existing cluster. + +If the local node is up and running and remote node dsn is not provided, `pgd node setup` will do a node group switch if node not part of the given group. + +## Syntax + +```plaintext +pgd node setup [OPTIONS] --pgdata ``` +``` + +## Arguments + +### + +DSN of the local node. This is the connection string to the local node. It is used to connect to the local node and perform the setup operation. +This is a mandatory argument and should be in the format `host=localhost port=5432 user=postgres dbname=bdrdb`. + +## Options + +| Option | Description | +|------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------| +| -D, --pgdata | Data directory of the node. | +| --dbname | DB name. Default is bdrdb. | +| --node-kind | Node kind. Default is data. Applicable for first node only. [possible values: data, witness, subscriber-only] | +| --group-name | Node group name. If not provided, the node will be added to the group of the active node. It becomes a mandatory argument for the first node. | +| --create-group | Set this to create the given group if not already present. This will be true by default for the first node. | +| --cluster-name | Name of the cluster to join the node to. This is a mandatory argument and is used as global group name for the first node of the cluster. | +| --cluster-dsn | A DSN to connect to active PGD cluster. | +| --postgresql-conf | Path of the postgresql.conf file to be used for the node. | +| --postgresql-auto-conf | Path of the postgresql.auto.conf file to be used for the node. | +| --hba-conf | Path of the pg_hba.conf file to be used for the node. | +| --debug | Print debug messages, useful while troubleshooting. | +| -f, --config-file | Sets the configuration file path. | + +See also [Global Options](/pgd/latest/cli/command_ref/#global-options). + +## Examples + +### Configuring a new node + +```shell +pgd node kaboom setup --pgdata /var/lib/edb/pgd/data --group-name dc1 --cluster-name dc1-cluster --cluster-dsn "host=localhost port=5444 user=postgres dbname=bdrdb" +``` + +This command will create a new node named `kaboom` in the cluster `dc1-cluster` with the group name `dc1`. The data directory for the node is set to `/var/lib/edb/pgd/data`. + +### Configuring a new node with a custom postgresql.conf file + +```shell +pgd node kaboom setup --pgdata /var/lib/edb/pgd/data --group-name dc1 --cluster-name dc1-cluster --cluster-dsn "host=localhost port=5444 user=postgres dbname=bdrdb" --postgresql-conf /path/to/postgresql.conf +``` + +This command will create a new node named `kaboom` in the cluster `dc1-cluster` with the group name `dc1`. The data directory for the node is set to `/var/lib/edb/pgd/data`, and the postgresql.conf file is set to `/path/to/postgresql.conf`. + +### Configuring a new node with a custom pg_hba.conf file + +```shell +pgd node kaboom setup --pgdata /var/lib/edb/pgd/data --group-name dc1 --cluster-name dc1-cluster --cluster-dsn "host=localhost port=5444 user=postgres dbname=bdrdb" --hba-conf /path/to/pg_hba.conf +``` + +This command will create a new node named `kaboom` in the cluster `dc1-cluster` with the group name `dc1`. The data directory for the node is set to `/var/lib/edb/pgd/data`, and the pg_hba.conf file is set to `/path/to/pg_hba.conf`. + diff --git a/product_docs/docs/pgd/6/reference/cli/index.mdx b/product_docs/docs/pgd/6/reference/cli/index.mdx index 7667152b677..5b304494230 100644 --- a/product_docs/docs/pgd/6/reference/cli/index.mdx +++ b/product_docs/docs/pgd/6/reference/cli/index.mdx @@ -27,8 +27,8 @@ PGD CLI is installed automatically on systems in a TPA-deployed PGD cluster. You can also install it manually on Linux and macOS systems that can connect to a PGD cluster, including: -* EDB Cloud Service distributed high-availability clusters. -* PGD clusters deployed using the EDB PGD for Kubernetes operator. +* HCP advanced and distributed high-availability clusters. +* PGD clusters deployed using the CloudNative Postgres Global Clusters operator. * Manually deployed PGD clusters. * TPA-deployed PGD clusters. diff --git a/product_docs/docs/pgd/6/reference/cli/installing/linux.mdx b/product_docs/docs/pgd/6/reference/cli/installing/linux.mdx index a9c6b8d07e5..9ed8cb97c3c 100644 --- a/product_docs/docs/pgd/6/reference/cli/installing/linux.mdx +++ b/product_docs/docs/pgd/6/reference/cli/installing/linux.mdx @@ -21,7 +21,13 @@ export EDB_SUBSCRIPTION_TOKEN= Then run the appropriate commands for your operating system. -## Install on Debian or Ubuntu + + + + +### Debian or Ubuntu + +On Debian or Ubuntu, you can install PGD CLI using the `apt` package manager. ```bash curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/postgres_distributed/setup.deb.sh" | sudo -E bash @@ -41,8 +47,14 @@ You can now install the PGD CLI package using the command: ```shell sudo apt-get install edb-pgd6-cli ``` + + + -## Install on RHEL, Rocky, AlmaLinux, or Oracle Linux +### RHEL, Rocky, AlmaLinux, or Oracle Linux + +On RHEL, Rocky, AlmaLinux, or Oracle Linux, you can install PGD CLI using the `yum` package manager. +You can also use the `dnf` package manager, which is the default package manager for RHEL 8 and later. ```bash curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/postgres_distributed/setup.rpm.sh" | sudo -E bash @@ -59,8 +71,22 @@ Executing the setup script for the 'enterprisedb/postgres_distributed' reposito You can now install the PGD CLI package using the command: -```shell + + + +```bash +sudo dnf install edb-pgd6-cli +``` + + + +```bash sudo yum install edb-pgd6-cli ``` -[Next: Using PGD CLI](../using_cli) + + + + + + diff --git a/product_docs/docs/pgd/6/reference/cli/installing/postgres-configuration.mdx b/product_docs/docs/pgd/6/reference/cli/installing/postgres-configuration.mdx deleted file mode 100644 index a9c6b8d07e5..00000000000 --- a/product_docs/docs/pgd/6/reference/cli/installing/postgres-configuration.mdx +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: Installing PGD CLI on Linux -navTitle: Linux -description: Installing PGD CLI on Linux ---- - - PGD CLI is available for most Linux distributions. You can install it from the EDB repositories, which you can access with your EDB account. PGD users and EDB Cloud Service users, including those on a free trial, have an EDB account and access to PGD CLI. - -## Obtain your EDB subscription token - -These repositories require a token to enable downloads from them. To obtain your token, log in to [EDB Repos 2.0](https://www.enterprisedb.com/repos-downloads). If this is your first time visiting the EDB Repos 2.0 page, you must select **Request Access** to generate your token. Once a generated token is available, select the **Copy** icon to copy it to your clipboard, or select the eye icon to view it. - -## Set the EDB_SUBSCRIPTION_TOKEN environment variable - -Once you have the token, execute the command shown for your operating system, substituting -your token for ``. - -```shell -export EDB_SUBSCRIPTION_TOKEN= -``` - -Then run the appropriate commands for your operating system. - -## Install on Debian or Ubuntu - -```bash -curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/postgres_distributed/setup.deb.sh" | sudo -E bash -``` - -If this command returns an error like `curl: (22) The requested URL returned error: 404`, check that you entered the correct token. - -When the command is successful, you'll see output like this: - -```console -Executing the setup script for the 'enterprisedb/postgres_distributed' repository ... -... -``` - -You can now install the PGD CLI package using the command: - -```shell -sudo apt-get install edb-pgd6-cli -``` - -## Install on RHEL, Rocky, AlmaLinux, or Oracle Linux - -```bash -curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/postgres_distributed/setup.rpm.sh" | sudo -E bash -``` - -If this command returns an error like `curl: (22) The requested URL returned error: 404`, check that you entered the correct token. - -When the command is successful, you'll see output like this: - -```console -Executing the setup script for the 'enterprisedb/postgres_distributed' repository ... -... -``` - -You can now install the PGD CLI package using the command: - -```shell -sudo yum install edb-pgd6-cli -``` - -[Next: Using PGD CLI](../using_cli) From a2be78febf51537963989cb400e7742c0a8449a2 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 1 May 2025 10:37:12 +0100 Subject: [PATCH 033/145] Overwrite with original 5.6 files Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/5.6/appusage/timing.mdx | 2 +- product_docs/docs/pgd/5.6/backup.mdx | 2 +- .../docs/pgd/5.6/commit-scopes/camo.mdx | 22 +- .../5.6/commit-scopes/commit-scope-rules.mdx | 2 +- .../docs/pgd/5.6/commit-scopes/degrading.mdx | 2 +- .../pgd/5.6/commit-scopes/group-commit.mdx | 2 +- .../5.6/commit-scopes/synchronous_commit.mdx | 2 +- .../01_overview_clcd.mdx | 2 +- .../02_enabling_disabling.mdx | 4 +- .../column-level-conflicts/03_timestamps.mdx | 2 +- .../conflicts/00_conflicts_overview.mdx | 2 +- product_docs/docs/pgd/5.6/ddl/ddl-locking.mdx | 2 +- .../ddl/ddl-managing-with-pgd-replication.mdx | 12 +- .../docs/pgd/5.6/ddl/ddl-overview.mdx | 4 +- .../5.6/ddl/ddl-pgd-functions-like-ddl.mdx | 22 +- .../pgd/5.6/ddl/ddl-replication-options.mdx | 6 +- .../pgd/5.6/ddl/ddl-role-manipulation.mdx | 2 +- .../docs/pgd/5.6/ddl/ddl-workarounds.mdx | 2 +- product_docs/docs/pgd/5.6/decoding_worker.mdx | 10 +- .../deploying/05-creating-cluster.mdx | 14 +- .../deploying/07-configure-proxies.mdx | 10 +- product_docs/docs/pgd/5.6/known_issues.mdx | 4 +- product_docs/docs/pgd/5.6/monitoring/sql.mdx | 72 +++---- .../node_management/creating_and_joining.mdx | 12 +- .../heterogeneous_clusters.mdx | 2 +- .../maintainance_with_proxies.mdx | 4 +- .../pgd/5.6/node_management/node_recovery.mdx | 2 +- .../removing_nodes_and_groups.mdx | 6 +- .../5.6/node_management/replication_slots.mdx | 2 +- .../5.6/node_management/viewing_topology.mdx | 4 +- .../pgd/5.6/nodes/logical_standby_nodes.mdx | 6 +- .../nodes/subscriber_only/optimizing-so.mdx | 2 +- product_docs/docs/pgd/5.6/parallelapply.mdx | 16 +- .../pgd/5.6/reference/catalogs-internal.mdx | 4 +- .../pgd/5.6/reference/catalogs-visible.mdx | 2 +- .../docs/pgd/5.6/reference/commit-scopes.mdx | 6 +- .../pgd/5.6/reference/functions-internal.mdx | 22 +- .../docs/pgd/5.6/reference/functions.mdx | 14 +- .../reference/nodes-management-interfaces.mdx | 2 +- .../docs/pgd/5.6/reference/pgd-settings.mdx | 6 +- product_docs/docs/pgd/5.6/repsets.mdx | 10 +- .../docs/pgd/5.6/routing/administering.mdx | 2 +- .../docs/pgd/5.6/routing/configuration.mdx | 8 +- .../docs/pgd/5.6/routing/monitoring.mdx | 6 +- product_docs/docs/pgd/5.6/routing/proxy.mdx | 2 +- product_docs/docs/pgd/5.6/scaling.mdx | 16 +- .../pgd/5.6/security/pgd-predefined-roles.mdx | 190 +++++++++--------- .../docs/pgd/5.6/security/role-management.mdx | 6 +- product_docs/docs/pgd/5.6/security/roles.mdx | 6 +- product_docs/docs/pgd/5.6/sequences.mdx | 6 +- .../docs/pgd/5.6/testingandtuning.mdx | 2 +- .../docs/pgd/5.6/transaction-streaming.mdx | 10 +- .../docs/pgd/5.6/upgrades/compatibility.mdx | 2 +- 53 files changed, 291 insertions(+), 291 deletions(-) diff --git a/product_docs/docs/pgd/5.6/appusage/timing.mdx b/product_docs/docs/pgd/5.6/appusage/timing.mdx index eb84cb10354..62300ef3c8f 100644 --- a/product_docs/docs/pgd/5.6/appusage/timing.mdx +++ b/product_docs/docs/pgd/5.6/appusage/timing.mdx @@ -8,7 +8,7 @@ possible for a client connected to multiple PGD nodes or switching between them to read stale data. A [queue wait -function](/pgd/latest/reference/tables-views-functions/functions/#bdrwait_for_apply_queue) is provided +function](/pgd/latest/reference/functions/#bdrwait_for_apply_queue) is provided for clients or proxies to prevent such stale reads. The synchronous replication features of Postgres are available to PGD as well. diff --git a/product_docs/docs/pgd/5.6/backup.mdx b/product_docs/docs/pgd/5.6/backup.mdx index 2cad123fe56..60af885fca3 100644 --- a/product_docs/docs/pgd/5.6/backup.mdx +++ b/product_docs/docs/pgd/5.6/backup.mdx @@ -233,7 +233,7 @@ of a single PGD node, optionally plus WAL archives: To clean up leftover PGD metadata: -1. Drop the PGD node using [`bdr.drop_node`](/pgd/latest/reference/tables-views-functions/functions-internal#bdrdrop_node). +1. Drop the PGD node using [`bdr.drop_node`](/pgd/latest/reference/functions-internal#bdrdrop_node). 2. Fully stop and restart PostgreSQL (important!). #### Cleanup of replication origins diff --git a/product_docs/docs/pgd/5.6/commit-scopes/camo.mdx b/product_docs/docs/pgd/5.6/commit-scopes/camo.mdx index b4d76f38a1f..63db329783b 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/camo.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/camo.mdx @@ -43,7 +43,7 @@ To use CAMO, an application must issue an explicit `COMMIT` message as a separat ## Configuration -See the[`CAMO`](/pgd/latest/reference/tables-views-functions/commit-scopes/#camo) commit scope reference for configuration parameters. +See the[`CAMO`](/pgd/latest/reference/commit-scopes/#camo) commit scope reference for configuration parameters. ## Confirmation @@ -76,7 +76,7 @@ When the `DEGRADE ON ... TO ASYNC` clause is used in the commit scope, a node de This doesn't allow COMMIT status to be retrieved, but it does let you choose availability over consistency. This mode can tolerate a single-node failure. In case both nodes of a CAMO pair fail, they might choose incongruent commit decisions to maintain availability, leading to data inconsistencies. -For a CAMO partner to switch to ready, it needs to be connected, and the estimated catchup interval needs to drop below the `timeout` value of `TO ASYNC`. You can check the current readiness status of a CAMO partner with [`bdr.is_camo_partner_ready()`](/pgd/latest/reference/tables-views-functions/functions#bdris_camo_partner_ready), while [`bdr.node_replication_rates`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrnode_replication_rates) provides the current estimate of the catchup time. +For a CAMO partner to switch to ready, it needs to be connected, and the estimated catchup interval needs to drop below the `timeout` value of `TO ASYNC`. You can check the current readiness status of a CAMO partner with [`bdr.is_camo_partner_ready()`](/pgd/latest/reference/functions#bdris_camo_partner_ready), while [`bdr.node_replication_rates`](/pgd/latest/reference/catalogs-visible#bdrnode_replication_rates) provides the current estimate of the catchup time. The switch from CAMO-protected to asynchronous mode is only ever triggered by an actual CAMO transaction. This is true either because the commit exceeds the `timeout` value of `TO ASYNC` or, in case the CAMO partner is already known, disconnected at the time of commit. This switch is independent of the estimated catchup interval. If the CAMO pair is configured to require the current node to be the write lead of a group as configured through the `enable_proxy_routing` node group option. See [Commit scopes](commit-scopes) for syntax. This can prevent a split brain situation due to an isolated node from switching to asynchronous mode. If `enable_proxy_routing` isn't set for the CAMO group, the origin node switches to asynchronous mode immediately. @@ -85,7 +85,7 @@ The switch from asynchronous mode to CAMO mode depends on the CAMO partner node, the CAMO partner further delays the switch back to CAMO protected mode. Unlike during normal CAMO operation, in asynchronous mode there's no added commit overhead. This can be problematic, as it allows the node to continuously process more transactions than the CAMO pair can normally process. Even if the CAMO partner eventually reconnects and applies transactions, its lag only ever increases -in such a situation, preventing reestablishing the CAMO protection. To artificially throttle transactional throughput, PGD provides the [`bdr.camo_local_mode_delay`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrcamo_local_mode_delay) setting, which allows you to delay a `COMMIT` in local mode by an arbitrary amount of time. We recommend measuring commit times in normal CAMO mode during expected workloads and configuring this delay accordingly. The default is 5 ms, which reflects a asynchronous network and a relatively quick CAMO partner response. +in such a situation, preventing reestablishing the CAMO protection. To artificially throttle transactional throughput, PGD provides the [`bdr.camo_local_mode_delay`](/pgd/latest/reference/pgd-settings#bdrcamo_local_mode_delay) setting, which allows you to delay a `COMMIT` in local mode by an arbitrary amount of time. We recommend measuring commit times in normal CAMO mode during expected workloads and configuring this delay accordingly. The default is 5 ms, which reflects a asynchronous network and a relatively quick CAMO partner response. Consider the choice of whether to allow asynchronous mode in view of the architecture and the availability requirements. The following examples provide some detail. @@ -184,7 +184,7 @@ If it was a bad connection, then you can check on the CAMO partner node to see i If you can't connect to the partner node, there's not a lot you can do. In this case, panic, or take similar actions. -But if you can connect, you can use [`bdr.logical_transaction_status()`](/pgd/latest/reference/tables-views-functions/functions#bdrlogical_transaction_status) to find out how the transaction did. The code recorded the required values, node_id and xid (the transaction id), just before committing the transaction. +But if you can connect, you can use [`bdr.logical_transaction_status()`](/pgd/latest/reference/functions#bdrlogical_transaction_status) to find out how the transaction did. The code recorded the required values, node_id and xid (the transaction id), just before committing the transaction. ``` sql = "SELECT bdr.logical_transaction_status($node_id, $xid)"; @@ -224,24 +224,24 @@ must have at least the [bdr_application](../security/pgd-predefined-roles/#bdr_a role assigned to them. !!! -The function [`bdr.is_camo_partner_connected()`](/pgd/latest/reference/tables-views-functions/functions#bdris_camo_partner_connected) allows checking the connection status of a CAMO partner node configured in pair mode. There currently is no equivalent for CAMO used with Eager Replication. +The function [`bdr.is_camo_partner_connected()`](/pgd/latest/reference/functions#bdris_camo_partner_connected) allows checking the connection status of a CAMO partner node configured in pair mode. There currently is no equivalent for CAMO used with Eager Replication. -To check that the CAMO partner is ready, use the function [`bdr.is_camo_partner_ready`](/pgd/latest/reference/tables-views-functions/functions#bdris_camo_partner_ready). Underneath, this triggers the switch to and from local mode. +To check that the CAMO partner is ready, use the function [`bdr.is_camo_partner_ready`](/pgd/latest/reference/functions#bdris_camo_partner_ready). Underneath, this triggers the switch to and from local mode. -To find out more about the configured CAMO partner, use [`bdr.get_configured_camo_partner()`](/pgd/latest/reference/tables-views-functions/functions#bdrget_configured_camo_partner). This function returns the local node's CAMO partner. +To find out more about the configured CAMO partner, use [`bdr.get_configured_camo_partner()`](/pgd/latest/reference/functions#bdrget_configured_camo_partner). This function returns the local node's CAMO partner. You can wait on the CAMO partner to process the queue with the function -[`bdr.wait_for_camo_partner_queue()`](/pgd/latest/reference/tables-views-functions/functions#bdrwait_for_camo_partner_queue). +[`bdr.wait_for_camo_partner_queue()`](/pgd/latest/reference/functions#bdrwait_for_camo_partner_queue). This function is a wrapper of -[`bdr.wait_for_apply_queue`](/pgd/latest/reference/tables-views-functions/functions#bdrwait_for_apply_queue). +[`bdr.wait_for_apply_queue`](/pgd/latest/reference/functions#bdrwait_for_apply_queue). The difference is that -[`bdr.wait_for_camo_partner_queue()`](/pgd/latest/reference/tables-views-functions/functions#bdrwait_for_camo_partner_queue) +[`bdr.wait_for_camo_partner_queue()`](/pgd/latest/reference/functions#bdrwait_for_camo_partner_queue) defaults to querying the CAMO partner node. It returns an error if the local node isn't part of a CAMO pair. To check the status of a transaction that was being committed when the node failed, the application must use the function -[`bdr.logical_transaction_status()`](/pgd/latest/reference/tables-views-functions/functions#bdrlogical_transaction_status). +[`bdr.logical_transaction_status()`](/pgd/latest/reference/functions#bdrlogical_transaction_status). You pass this function the the node_id and transaction_id of the transaction you want to check on. With CAMO used in pair mode, you can use this function only on a node that's part of a CAMO pair. Along with Eager Replication, you can use it on all nodes. diff --git a/product_docs/docs/pgd/5.6/commit-scopes/commit-scope-rules.mdx b/product_docs/docs/pgd/5.6/commit-scopes/commit-scope-rules.mdx index 893541f5c21..e636ae25fbd 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/commit-scope-rules.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/commit-scope-rules.mdx @@ -12,7 +12,7 @@ Each operation is made up of two or three parts: the commit scope group, an opti commit_scope_group [ confirmation_level ] commit_scope_kind ``` -A full formal syntax diagram is available in the [Commit scopes](/pgd/latest/reference/tables-views-functions/commit-scopes/#commit-scope-syntax) reference. +A full formal syntax diagram is available in the [Commit scopes](/pgd/latest/reference/commit-scopes/#commit-scope-syntax) reference. A typical commit scope rule, such as `ANY 2 (group) GROUP COMMIT`, can be broken down into its components. `ANY 2 (group)` is the commit scope group specifying, for the rule, which nodes need to respond and confirm they processed the transaction. In this example, any two nodes from the named group must confirm. diff --git a/product_docs/docs/pgd/5.6/commit-scopes/degrading.mdx b/product_docs/docs/pgd/5.6/commit-scopes/degrading.mdx index ad22be774b1..0c3980b09fc 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/degrading.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/degrading.mdx @@ -22,7 +22,7 @@ Once during the commit, while the commit being processed is waiting for response This mechanism alone is insufficient for the intended behavior, as this alone would mean that every transaction—even those that were certain to degrade due to connectivity issues—must wait for the timeout to expire before degraded mode kicks in, which would severely affect performance in such degrading-cluster scenarios. -To avoid this, the PGD manager process also periodically (every 5s) checks the connectivity and apply rate (the one in [bdr.node_replication_rates](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrnode_replication_rates)) and if there are commit scopes that would degrade at that point based on the current state of replication, they will be automatically degraded—such that any transaction using that commit scope when processing after that uses the degraded rule instead of waiting for timeout—until the manager process detects that replication is moving swiftly enough again. +To avoid this, the PGD manager process also periodically (every 5s) checks the connectivity and apply rate (the one in [bdr.node_replication_rates](/pgd/latest/reference/catalogs-visible/#bdrnode_replication_rates)) and if there are commit scopes that would degrade at that point based on the current state of replication, they will be automatically degraded—such that any transaction using that commit scope when processing after that uses the degraded rule instead of waiting for timeout—until the manager process detects that replication is moving swiftly enough again. ## SYNCHRONOUS COMMIT and GROUP COMMIT diff --git a/product_docs/docs/pgd/5.6/commit-scopes/group-commit.mdx b/product_docs/docs/pgd/5.6/commit-scopes/group-commit.mdx index 83d551a9769..470ba63294e 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/group-commit.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/group-commit.mdx @@ -58,7 +58,7 @@ See the Group Commit section of [Limitations](limitations#group-commit). ## Configuration -`GROUP_COMMIT` supports optional `GROUP COMMIT` parameters, as well as `ABORT ON` and `DEGRADE ON` clauses. For a full description of configuration parameters, see the [GROUP_COMMIT](/pgd/latest/reference/tables-views-functions/commit-scopes/#group-commit) commit scope reference or for more regarding `DEGRADE ON` options in general, see the [Degrade options](degrading) section. +`GROUP_COMMIT` supports optional `GROUP COMMIT` parameters, as well as `ABORT ON` and `DEGRADE ON` clauses. For a full description of configuration parameters, see the [GROUP_COMMIT](/pgd/latest/reference/commit-scopes/#group-commit) commit scope reference or for more regarding `DEGRADE ON` options in general, see the [Degrade options](degrading) section. ## Confirmation diff --git a/product_docs/docs/pgd/5.6/commit-scopes/synchronous_commit.mdx b/product_docs/docs/pgd/5.6/commit-scopes/synchronous_commit.mdx index 8f90cda01f7..668c0a13808 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/synchronous_commit.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/synchronous_commit.mdx @@ -26,7 +26,7 @@ SELECT bdr.create_commit_scope( ## Configuration -`SYNCHRONOUS COMMIT` supports the optional `DEGRADE ON` clause. See the [`SYNCHRONOUS COMMIT`](/pgd/latest/reference/tables-views-functions/commit-scopes/#synchronous-commit) commit scope reference for specific configuration parameters or see [this section](degrading) regarding Degrade on options. +`SYNCHRONOUS COMMIT` supports the optional `DEGRADE ON` clause. See the [`SYNCHRONOUS COMMIT`](/pgd/latest/reference/commit-scopes/#synchronous-commit) commit scope reference for specific configuration parameters or see [this section](degrading) regarding Degrade on options. ## Confirmation diff --git a/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/01_overview_clcd.mdx b/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/01_overview_clcd.mdx index 0e3b3810a57..0c810550011 100644 --- a/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/01_overview_clcd.mdx +++ b/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/01_overview_clcd.mdx @@ -35,7 +35,7 @@ Applied to the previous example, the result is `(100,100)` on both nodes, despit When thinking about column-level conflict resolution, it can be useful to see tables as vertically partitioned, so that each update affects data in only one slice. This approach eliminates conflicts between changes to different subsets of columns. In fact, vertical partitioning can even be a practical alternative to column-level conflict resolution. -Column-level conflict resolution requires the table to have `REPLICA IDENTITY FULL`. The [bdr.alter_table_conflict_detection()](https://www.enterprisedb.com/docs/pgd/latest/reference/tables-views-functions/conflict_functions#bdralter_table_conflict_detection) function checks that and fails with an error if this setting is missing. +Column-level conflict resolution requires the table to have `REPLICA IDENTITY FULL`. The [bdr.alter_table_conflict_detection()](https://www.enterprisedb.com/docs/pgd/latest/reference/conflict_functions#bdralter_table_conflict_detection) function checks that and fails with an error if this setting is missing. ## Special problems for column-level conflict resolution diff --git a/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/02_enabling_disabling.mdx b/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/02_enabling_disabling.mdx index d52287da419..a145d1d67a7 100644 --- a/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/02_enabling_disabling.mdx +++ b/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/02_enabling_disabling.mdx @@ -8,11 +8,11 @@ deepToC: true Column-level conflict detection uses the `column_timestamps` type. This type requires any user needing to detect column-level conflicts to have at least the [bdr_application](../../security/pgd-predefined-roles/#bdr_application) role assigned. !!! -The [bdr.alter_table_conflict_detection()](https://www.enterprisedb.com/docs/pgd/latest/reference/tables-views-functions/conflict_functions/#bdralter_table_conflict_detection) function manages column-level conflict resolution. +The [bdr.alter_table_conflict_detection()](https://www.enterprisedb.com/docs/pgd/latest/reference/conflict_functions/#bdralter_table_conflict_detection) function manages column-level conflict resolution. ## Using bdr.alter_table_conflict_detection to enable column-level conflict resolution -The [bdr.alter_table_conflict_detection](https://www.enterprisedb.com/docs/pgd/latest/reference/tables-views-functions/conflict_functions/#bdralter_table_conflict_detection) function takes a table name and column name as its arguments. The column is added to the table as a `column_modify_timestamp` column. The function also adds two triggers (BEFORE INSERT and BEFORE UPDATE) that are responsible for maintaining timestamps in the new column before each change. +The [bdr.alter_table_conflict_detection](https://www.enterprisedb.com/docs/pgd/latest/reference/conflict_functions/#bdralter_table_conflict_detection) function takes a table name and column name as its arguments. The column is added to the table as a `column_modify_timestamp` column. The function also adds two triggers (BEFORE INSERT and BEFORE UPDATE) that are responsible for maintaining timestamps in the new column before each change. ```sql db=# CREATE TABLE my_app.test_table (id SERIAL PRIMARY KEY, val INT); diff --git a/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/03_timestamps.mdx b/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/03_timestamps.mdx index 07fea6bf4cb..1e20d619aad 100644 --- a/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/03_timestamps.mdx +++ b/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/03_timestamps.mdx @@ -21,7 +21,7 @@ This approach is simple and, for many cases, it's correct, for example, when the For example, if an `UPDATE` affects multiple rows, the clock continues ticking while the `UPDATE` runs. So each row gets a slightly different timestamp, even if they're being modified concurrently by the one `UPDATE`. This behavior, in turn, means that the effects of concurrent changes might get "mixed" in various ways, depending on how the changes performed on different nodes interleaves. -Another possible issue is clock skew. When the clocks on different nodes drift, the timestamps generated by those nodes also drift. This clock skew can induce unexpected behavior such as newer changes being discarded because the timestamps are apparently switched around. However, you can manage clock skew between nodes using the parameters [bdr.maximum_clock_skew](/pgd/latest/reference/tables-views-functions/pgd-settings/#bdrmaximum_clock_skew) and [bdr.maximum_clock_skew_action](/pgd/latest/reference/tables-views-functions/pgd-settings/#bdrmaximum_clock_skew_action). +Another possible issue is clock skew. When the clocks on different nodes drift, the timestamps generated by those nodes also drift. This clock skew can induce unexpected behavior such as newer changes being discarded because the timestamps are apparently switched around. However, you can manage clock skew between nodes using the parameters [bdr.maximum_clock_skew](/pgd/latest/reference/pgd-settings/#bdrmaximum_clock_skew) and [bdr.maximum_clock_skew_action](/pgd/latest/reference/pgd-settings/#bdrmaximum_clock_skew_action). As the current timestamp is unrelated to the commit timestamp, using it to resolve conflicts means that the result isn't equivalent to the commit order, which means it probably can't be serialized. diff --git a/product_docs/docs/pgd/5.6/conflict-management/conflicts/00_conflicts_overview.mdx b/product_docs/docs/pgd/5.6/conflict-management/conflicts/00_conflicts_overview.mdx index 5af82599291..da19837bec6 100644 --- a/product_docs/docs/pgd/5.6/conflict-management/conflicts/00_conflicts_overview.mdx +++ b/product_docs/docs/pgd/5.6/conflict-management/conflicts/00_conflicts_overview.mdx @@ -15,7 +15,7 @@ Conflict handling is configurable, as described in [Conflict resolution](04_conf Column-level conflict detection and resolution is available with PGD, as described in [CLCD](../column-level-conflicts). -By default, all conflicts are logged to [`bdr.conflict_history`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrconflict_history). If conflicts are possible, then table owners must monitor for them and analyze how to avoid them or make plans to handle them regularly as an application task. The [LiveCompare](/livecompare/latest) tool is also available to scan regularly for divergence. +By default, all conflicts are logged to [`bdr.conflict_history`](/pgd/latest/reference/catalogs-visible/#bdrconflict_history). If conflicts are possible, then table owners must monitor for them and analyze how to avoid them or make plans to handle them regularly as an application task. The [LiveCompare](/livecompare/latest) tool is also available to scan regularly for divergence. Some clustering systems use distributed lock mechanisms to prevent concurrent access to data. These can perform reasonably when servers are very close to each other but can't support geographically distributed applications where very low latency is critical for acceptable performance. diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-locking.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-locking.mdx index e292d89c33a..d44fc6b9985 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-locking.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-locking.mdx @@ -73,7 +73,7 @@ Witness and subscriber-only nodes aren't eligible to participate. If a DDL statement isn't replicated, no global locks are acquired. -Specify locking behavior with the [`bdr.ddl_locking`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrddl_locking) parameter, as +Specify locking behavior with the [`bdr.ddl_locking`](/pgd/latest/reference/pgd-settings#bdrddl_locking) parameter, as explained in [Executing DDL on PGD systems](ddl-overview#executing-ddl-on-pgd-systems): - `ddl_locking = all` takes global DDL lock and, if needed, takes relation DML lock. diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-managing-with-pgd-replication.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-managing-with-pgd-replication.mdx index 99bd43cd439..c1fe779c19e 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-managing-with-pgd-replication.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-managing-with-pgd-replication.mdx @@ -32,7 +32,7 @@ SELECT bdr.run_on_all_nodes($ddl$ $ddl$); ``` -We recommend using the [`bdr.run_on_all_nodes()`](/pgd/latest/reference/tables-views-functions/functions#bdrrun_on_all_nodes) technique with `CREATE +We recommend using the [`bdr.run_on_all_nodes()`](/pgd/latest/reference/functions#bdrrun_on_all_nodes) technique with `CREATE INDEX CONCURRENTLY`, noting that DDL replication must be disabled for the whole session because `CREATE INDEX CONCURRENTLY` is a multi-transaction command. Avoid `CREATE INDEX` on production systems @@ -60,10 +60,10 @@ cancel the DDL on the originating node with **Control-C** in psql or with `pg_ca You can't cancel a DDL lock from any other node. You can control how long the global lock takes with optional global locking -timeout settings. [`bdr.global_lock_timeout`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrglobal_lock_timeout) limits how long the wait for +timeout settings. [`bdr.global_lock_timeout`](/pgd/latest/reference/pgd-settings#bdrglobal_lock_timeout) limits how long the wait for acquiring the global lock can take before it's canceled. -[`bdr.global_lock_statement_timeout`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrglobal_lock_statement_timeout) limits the runtime length of any statement -in transaction that holds global locks, and [`bdr.global_lock_idle_timeout`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrglobal_lock_idle_timeout) sets +[`bdr.global_lock_statement_timeout`](/pgd/latest/reference/pgd-settings#bdrglobal_lock_statement_timeout) limits the runtime length of any statement +in transaction that holds global locks, and [`bdr.global_lock_idle_timeout`](/pgd/latest/reference/pgd-settings#bdrglobal_lock_idle_timeout) sets the maximum allowed idle time (time between statements) for a transaction holding any global locks. You can disable all of these timeouts by setting their values to zero. @@ -84,7 +84,7 @@ locks that it holds. If it stays down for a long time or indefinitely, remove the node from the PGD group to release the global locks. This is one reason for executing emergency DDL using the `SET` command as -the bdr_superuser to update the [`bdr.ddl_locking`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrddl_locking) value. +the bdr_superuser to update the [`bdr.ddl_locking`](/pgd/latest/reference/pgd-settings#bdrddl_locking) value. If one of the other nodes goes down after it confirmed the global lock but before the command acquiring it executed, the execution of @@ -102,7 +102,7 @@ command continues normally, and the lock is released. Not all commands can be replicated automatically. Such commands are generally disallowed, unless DDL replication is turned off -by turning [`bdr.ddl_replication`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrddl_replication) off. +by turning [`bdr.ddl_replication`](/pgd/latest/reference/pgd-settings#bdrddl_replication) off. PGD prevents some DDL statements from running when it's active on a database. This protects the consistency of the system by disallowing diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-overview.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-overview.mdx index ec874c8fcd2..aec5291d0ed 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-overview.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-overview.mdx @@ -71,7 +71,7 @@ it a useful option when creating a new and empty database schema. These options can be set only by the bdr_superuser, by the superuser, or in the `postgres.conf` configuration file. -When using the [`bdr.replicate_ddl_command`](/pgd/latest/reference/tables-views-functions/functions#bdrreplicate_ddl_command), you can set this +When using the [`bdr.replicate_ddl_command`](/pgd/latest/reference/functions#bdrreplicate_ddl_command), you can set this parameter directly with the third argument, using the specified -[`bdr.ddl_locking`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrddl_locking) setting only for the DDL commands passed to that +[`bdr.ddl_locking`](/pgd/latest/reference/pgd-settings#bdrddl_locking) setting only for the DDL commands passed to that function. diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-pgd-functions-like-ddl.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-pgd-functions-like-ddl.mdx index 7a9d6bb3066..0f9aa5d00e3 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-pgd-functions-like-ddl.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-pgd-functions-like-ddl.mdx @@ -10,13 +10,13 @@ information, see the documentation for the individual functions. Replication set management: -- [`bdr.create_replication_set`](/pgd/latest/reference/tables-views-functions/repsets-management#bdrcreate_replication_set) -- [`bdr.alter_replication_set`](/pgd/latest/reference/tables-views-functions/repsets-management#bdralter_replication_set) -- [`bdr.drop_replication_set`](/pgd/latest/reference/tables-views-functions/repsets-management#bdrdrop_replication_set) -- [`bdr.replication_set_add_table`](/pgd/latest/reference/tables-views-functions/repsets-membership#bdrreplication_set_add_table) -- [`bdr.replication_set_remove_table`](/pgd/latest/reference/tables-views-functions/repsets-membership#bdrreplication_set_remove_table) -- [`bdr.replication_set_add_ddl_filter`](/pgd/latest/reference/tables-views-functions/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter) -- [`bdr.replication_set_remove_ddl_filter`](/pgd/latest/reference/tables-views-functions/repsets-ddl-filtering#bdrreplication_set_remove_ddl_filter) +- [`bdr.create_replication_set`](/pgd/latest/reference/repsets-management#bdrcreate_replication_set) +- [`bdr.alter_replication_set`](/pgd/latest/reference/repsets-management#bdralter_replication_set) +- [`bdr.drop_replication_set`](/pgd/latest/reference/repsets-management#bdrdrop_replication_set) +- [`bdr.replication_set_add_table`](/pgd/latest/reference/repsets-membership#bdrreplication_set_add_table) +- [`bdr.replication_set_remove_table`](/pgd/latest/reference/repsets-membership#bdrreplication_set_remove_table) +- [`bdr.replication_set_add_ddl_filter`](/pgd/latest/reference/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter) +- [`bdr.replication_set_remove_ddl_filter`](/pgd/latest/reference/repsets-ddl-filtering#bdrreplication_set_remove_ddl_filter) Conflict management: @@ -26,10 +26,10 @@ Conflict management: Sequence management: -- [`bdr.alter_sequence_set_kind`](/pgd/latest/reference/tables-views-functions/sequences#bdralter_sequence_set_kind) +- [`bdr.alter_sequence_set_kind`](/pgd/latest/reference/sequences#bdralter_sequence_set_kind) Stream triggers: -- [`bdr.create_conflict_trigger`](/pgd/latest/reference/tables-views-functions/streamtriggers/interfaces#bdrcreate_conflict_trigger) -- [`bdr.create_transform_trigger`](/pgd/latest/reference/tables-views-functions/streamtriggers/interfaces#bdrcreate_transform_trigger) -- [`bdr.drop_trigger`](/pgd/latest/reference/tables-views-functions/streamtriggers/interfaces#bdrdrop_trigger) +- [`bdr.create_conflict_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrcreate_conflict_trigger) +- [`bdr.create_transform_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrcreate_transform_trigger) +- [`bdr.drop_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrdrop_trigger) diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-replication-options.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-replication-options.mdx index 311fc09b9ae..cd37f8f04ef 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-replication-options.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-replication-options.mdx @@ -3,7 +3,7 @@ title: DDL replication options navTitle: Options --- -The [`bdr.ddl_replication`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrddl_replication) parameter specifies replication behavior. +The [`bdr.ddl_replication`](/pgd/latest/reference/pgd-settings#bdrddl_replication) parameter specifies replication behavior. `bdr.ddl_replication = on` is the default. This setting replicates DDL to the default replication set, which by default means all nodes. Non-default @@ -12,7 +12,7 @@ replication sets don't replicate DDL unless they have a defined for them. You can also replicate DDL to specific replication sets using the -function [`bdr.replicate_ddl_command()`](/pgd/latest/reference/tables-views-functions/functions#bdrreplicate_ddl_command). This function can be helpful if you +function [`bdr.replicate_ddl_command()`](/pgd/latest/reference/functions#bdrreplicate_ddl_command). This function can be helpful if you want to run DDL commands when a node is down. It's also helpful if you want to have indexes or partitions that exist on a subset of nodes or rep sets, for example, all nodes at site1. @@ -26,7 +26,7 @@ SELECT bdr.replicate_ddl_command( ``` While we don't recommend it, you can skip automatic DDL replication and -execute it manually on each node using the [`bdr.ddl_replication`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrddl_replication) configuration +execute it manually on each node using the [`bdr.ddl_replication`](/pgd/latest/reference/pgd-settings#bdrddl_replication) configuration parameter. ``` diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-role-manipulation.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-role-manipulation.mdx index 15b2c9a7f8a..37cff6150aa 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-role-manipulation.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-role-manipulation.mdx @@ -11,7 +11,7 @@ PGD requires that any roles that are referenced by any replicated DDL must exist on all nodes. The roles don't have to have the same grants, password, and so on, but they must exist. -PGD replicates role manipulation statements if [`bdr.role_replication`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrrole_replication) is +PGD replicates role manipulation statements if [`bdr.role_replication`](/pgd/latest/reference/pgd-settings#bdrrole_replication) is enabled (default) and role manipulation statements are run in a PGD-enabled database. diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-workarounds.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-workarounds.mdx index a84628c2918..921110deb78 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-workarounds.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-workarounds.mdx @@ -130,7 +130,7 @@ The `ALTER TYPE` statement is replicated, but affected tables aren't locked. When you use this DDL, ensure that the statement has successfully executed on all nodes before using the new type. You can achieve this using -the [`bdr.wait_slot_confirm_lsn()`](/pgd/latest/reference/tables-views-functions/functions#bdrwait_slot_confirm_lsn) function. +the [`bdr.wait_slot_confirm_lsn()`](/pgd/latest/reference/functions#bdrwait_slot_confirm_lsn) function. This example ensures that the DDL is written to all nodes before using the new value in DML statements: diff --git a/product_docs/docs/pgd/5.6/decoding_worker.mdx b/product_docs/docs/pgd/5.6/decoding_worker.mdx index 3e58dc68d6a..d73a8c6c171 100644 --- a/product_docs/docs/pgd/5.6/decoding_worker.mdx +++ b/product_docs/docs/pgd/5.6/decoding_worker.mdx @@ -24,8 +24,8 @@ subscribing nodes received data. LCR files are stored under the size of the LCR files varies as replication lag increases, so this process also needs monitoring. The LCRs that aren't required by any of the PGD nodes are cleaned periodically. The interval between two consecutive cleanups is controlled by -[`bdr.lcr_cleanup_interval`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrlcr_cleanup_interval), which defaults to 3 minutes. The cleanup is -disabled when [`bdr.lcr_cleanup_interval`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrlcr_cleanup_interval) is 0. +[`bdr.lcr_cleanup_interval`](/pgd/latest/reference/pgd-settings#bdrlcr_cleanup_interval), which defaults to 3 minutes. The cleanup is +disabled when [`bdr.lcr_cleanup_interval`](/pgd/latest/reference/pgd-settings#bdrlcr_cleanup_interval) is 0. ## Disabling @@ -37,11 +37,11 @@ GUCs control the production and use of LCR per node. By default these are `false`. For production and use of LCRs, enable the decoding worker for the PGD group and set these GUCs to `true` on each of the nodes in the PGD group. -- [`bdr.enable_wal_decoder`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrenable_wal_decoder) — When `false`, all WAL +- [`bdr.enable_wal_decoder`](/pgd/latest/reference/pgd-settings#bdrenable_wal_decoder) — When `false`, all WAL senders using LCRs restart to use WAL directly. When `true` along with the PGD group config, a decoding worker process is started to produce LCR and WAL senders that use LCR. -- [`bdr.receive_lcr`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrreceive_lcr) — When `true` on the subscribing node, it requests WAL +- [`bdr.receive_lcr`](/pgd/latest/reference/pgd-settings#bdrreceive_lcr) — When `true` on the subscribing node, it requests WAL sender on the publisher node to use LCRs if available. @@ -82,7 +82,7 @@ The WAL decoder always streams the transactions to LCRs but based on downstream To support this feature, the system creates additional streaming files. These files have names in that begin with `STR_TXN_` and `CAS_TXN_` and each streamed transaction creates their own pair. -To enable transaction streaming with the WAL decoder, set the PGD group's `bdr.streaming_mode` set to ‘default’ using [`bdr.alter_node_group_option`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdralter_node_group_option). +To enable transaction streaming with the WAL decoder, set the PGD group's `bdr.streaming_mode` set to ‘default’ using [`bdr.alter_node_group_option`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_group_option). diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/05-creating-cluster.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/05-creating-cluster.mdx index 2efbf299368..009e2486ecf 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/05-creating-cluster.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/05-creating-cluster.mdx @@ -81,7 +81,7 @@ sudo -iu enterprisedb psql bdrdb ### Create the first node -Call the [`bdr.create_node`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrcreate_node) function to create a node, passing it the node name and a connection string that other nodes can use to connect to it. +Call the [`bdr.create_node`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node) function to create a node, passing it the node name and a connection string that other nodes can use to connect to it. ``` select bdr.create_node('node-one','host=host-one dbname=bdrdb port=5444'); @@ -89,7 +89,7 @@ select bdr.create_node('node-one','host=host-one dbname=bdrdb port=5444'); #### Create the top-level group -Call the [`bdr.create_node_group`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrcreate_node_group) function to create a top-level group for your PGD cluster. Passing a single string parameter creates the top-level group with that name. This example creates a top-level group named `pgd`. +Call the [`bdr.create_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node_group) function to create a top-level group for your PGD cluster. Passing a single string parameter creates the top-level group with that name. This example creates a top-level group named `pgd`. ``` select bdr.create_node_group('pgd'); @@ -101,7 +101,7 @@ Using subgroups to organize your nodes is preferred, as it allows services like In a larger PGD installation, multiple subgroups can exist. These subgroups provide organizational grouping that enables geographical mapping of clusters and localized resilience. For that reason, this example creates a subgroup for the first nodes to enable simpler expansion and the use of PGD Proxy. -Call the [`bdr.create_node_group`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrcreate_node_group) function again to create a subgroup of the top-level group. +Call the [`bdr.create_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node_group) function again to create a subgroup of the top-level group. The subgroup name is the first parameter, and the parent group is the second parameter. This example creates a subgroup `dc1` as a child of `pgd`. @@ -121,7 +121,7 @@ sudo -iu enterprisedb psql bdrdb #### Create the second node -Call the [`bdr.create_node`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrcreate_node) function to create this node, passing it the node name and a connection string that other nodes can use to connect to it. +Call the [`bdr.create_node`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node) function to create this node, passing it the node name and a connection string that other nodes can use to connect to it. ``` select bdr.create_node('node-two','host=host-two dbname=bdrdb port=5444'); @@ -129,7 +129,7 @@ select bdr.create_node('node-two','host=host-two dbname=bdrdb port=5444'); #### Join the second node to the cluster -Using [`bdr.join_node_group`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrjoin_node_group), you can ask node-two to join node-one's `dc1` group. The function takes as a first parameter the connection string of a node already in the group and the group name as a second parameter. +Using [`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group), you can ask node-two to join node-one's `dc1` group. The function takes as a first parameter the connection string of a node already in the group and the group name as a second parameter. ``` select bdr.join_node_group('host=host-one dbname=bdrdb port=5444','dc1'); @@ -146,7 +146,7 @@ sudo -iu enterprisedb psql bdrdb #### Create the third node -Call the [`bdr.create_node`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrcreate_node) function to create this node, passing it the node name and a connection string that other nodes can use to connect to it. +Call the [`bdr.create_node`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node) function to create this node, passing it the node name and a connection string that other nodes can use to connect to it. ``` select bdr.create_node('node-three','host=host-three dbname=bdrdb port=5444'); @@ -154,7 +154,7 @@ select bdr.create_node('node-three','host=host-three dbname=bdrdb port=5444'); #### Join the third node to the cluster -Using [`bdr.join_node_group`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrjoin_node_group), you can ask node-three to join node-one's `dc1` group. The function takes as a first parameter the connection string of a node already in the group and the group name as a second parameter. +Using [`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group), you can ask node-three to join node-one's `dc1` group. The function takes as a first parameter the connection string of a node already in the group and the group name as a second parameter. ``` select bdr.join_node_group('host=host-one dbname=bdrdb port=5444','dc1'); diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx index 743c96cd8fb..0bee3e06b9a 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx @@ -21,9 +21,9 @@ It's best practice to configure PGD Proxy for clusters to enable this behavior. To set up a proxy, you need to first prepare the cluster and subgroup the proxies will be working with by: -* Logging in and setting the `enable_raft` and `enable_proxy_routing` node group options to `true` for the subgroup. Use [`bdr.alter_node_group_option`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdralter_node_group_option), passing the subgroup name, option name, and new value as parameters. -* Create as many uniquely named proxies as you plan to deploy using [`bdr.create_proxy`](/pgd/latest/reference/tables-views-functions/routing#bdrcreate_proxy) and passing the new proxy name and the subgroup to attach it to. The [`bdr.create_proxy`](/pgd/latest/reference/tables-views-functions/routing#bdrcreate_proxy) does not create a proxy, but creates a space for a proxy to register itself with the cluster. The space contains configuration values which can be modified later. Initially it is configured with default proxy options such as setting the `listen_address` to `0.0.0.0`. -* Configure proxy routes to each node by setting route_dsn for each node in the subgroup. The route_dsn is the connection string that the proxy should use to connect to that node. Use [`bdr.alter_node_option`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdralter_node_option) to set the route_dsn for each node in the subgroup. +* Logging in and setting the `enable_raft` and `enable_proxy_routing` node group options to `true` for the subgroup. Use [`bdr.alter_node_group_option`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_group_option), passing the subgroup name, option name, and new value as parameters. +* Create as many uniquely named proxies as you plan to deploy using [`bdr.create_proxy`](/pgd/latest/reference/routing#bdrcreate_proxy) and passing the new proxy name and the subgroup to attach it to. The [`bdr.create_proxy`](/pgd/latest/reference/routing#bdrcreate_proxy) does not create a proxy, but creates a space for a proxy to register itself with the cluster. The space contains configuration values which can be modified later. Initially it is configured with default proxy options such as setting the `listen_address` to `0.0.0.0`. +* Configure proxy routes to each node by setting route_dsn for each node in the subgroup. The route_dsn is the connection string that the proxy should use to connect to that node. Use [`bdr.alter_node_option`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_option) to set the route_dsn for each node in the subgroup. * Create a pgdproxy user on the cluster with a password or other authentication. ### Configure each host as a proxy @@ -53,7 +53,7 @@ SELECT bdr.alter_node_group_option('dc1', 'enable_raft', 'true'); SELECT bdr.alter_node_group_option('dc1', 'enable_proxy_routing', 'true'); ``` -You can use the [`bdr.node_group_summary`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrnode_group_summary) view to check the status of options previously set with `bdr.alter_node_group_option()`: +You can use the [`bdr.node_group_summary`](/pgd/latest/reference/catalogs-visible#bdrnode_group_summary) view to check the status of options previously set with `bdr.alter_node_group_option()`: ```sql SELECT node_group_name, enable_proxy_routing, enable_raft @@ -80,7 +80,7 @@ SELECT bdr.create_proxy('pgd-proxy-two','dc1'); SELECT bdr.create_proxy('pgd-proxy-three','dc1'); ``` -You can use the [`bdr.proxy_config_summary`](/pgd/latest/reference/tables-views-functions/catalogs-internal#bdrproxy_config_summary) view to check that the proxies were created: +You can use the [`bdr.proxy_config_summary`](/pgd/latest/reference/catalogs-internal#bdrproxy_config_summary) view to check that the proxies were created: ```sql SELECT proxy_name, node_group_name diff --git a/product_docs/docs/pgd/5.6/known_issues.mdx b/product_docs/docs/pgd/5.6/known_issues.mdx index 58329aada07..92f945eac79 100644 --- a/product_docs/docs/pgd/5.6/known_issues.mdx +++ b/product_docs/docs/pgd/5.6/known_issues.mdx @@ -38,7 +38,7 @@ Adding or removing a pair doesn't require a restart of Postgres or even a reload - Transactions using Eager Replication can't yet execute DDL. The TRUNCATE command is allowed. -- Parallel Apply isn't currently supported in combination with Group Commit. Make sure to disable it when using Group Commit by either (a) Setting `num_writers` to 1 for the node group using [`bdr.alter_node_group_option`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces/#bdralter_node_group_option) or (b) using the GUC [`bdr.writers_per_subscription`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrwriters_per_subscription). See [Configuration of generic replication](/pgd/latest/reference/tables-views-functions/pgd-settings#generic-replication). +- Parallel Apply isn't currently supported in combination with Group Commit. Make sure to disable it when using Group Commit by either (a) Setting `num_writers` to 1 for the node group using [`bdr.alter_node_group_option`](/pgd/latest/reference/nodes-management-interfaces/#bdralter_node_group_option) or (b) using the GUC [`bdr.writers_per_subscription`](/pgd/latest/reference/pgd-settings#bdrwriters_per_subscription). See [Configuration of generic replication](/pgd/latest/reference/pgd-settings#generic-replication). - There currently is no protection against altering or removing a commit scope. Running transactions in a commit scope that's concurrently being altered or removed can lead to the transaction blocking or replication stalling completely due to an error on the downstream node attempting to apply the transaction. @@ -47,7 +47,7 @@ Make sure that any transactions using a specific commit scope have finished befo - The [PGD CLI](cli) can return stale data on the state of the cluster if it's still connecting to nodes that were previously parted from the cluster. Edit the [`pgd-cli-config.yml`](cli/configuring_cli/#using-a-configuration-file) file, or change your [`--dsn`](cli/configuring_cli/#using-database-connection-strings-in-the-command-line) settings to ensure only active nodes in the cluster are listed for connection. -To modify a commit scope safely, use [`bdr.alter_commit_scope`](/pgd/latest/reference/tables-views-functions/functions#bdralter_commit_scope). +To modify a commit scope safely, use [`bdr.alter_commit_scope`](/pgd/latest/reference/functions#bdralter_commit_scope). - DDL run in serializable transactions can face the error: `ERROR: could not serialize access due to read/write dependencies among transactions`. A workaround is to run the DDL outside serializable transactions. diff --git a/product_docs/docs/pgd/5.6/monitoring/sql.mdx b/product_docs/docs/pgd/5.6/monitoring/sql.mdx index c357fbbbfac..4f5d18f198f 100644 --- a/product_docs/docs/pgd/5.6/monitoring/sql.mdx +++ b/product_docs/docs/pgd/5.6/monitoring/sql.mdx @@ -74,7 +74,7 @@ node_seq_id | 3 node_local_dbname | postgres ``` -Also, the table [`bdr.node_catchup_info`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrnode_catchup_info) gives information +Also, the table [`bdr.node_catchup_info`](/pgd/latest/reference/catalogs-visible/#bdrnode_catchup_info) gives information on the catch-up state, which can be relevant to joining nodes or parting nodes. When a node is parted, some nodes in the cluster might not receive @@ -94,7 +94,7 @@ The `catchup_state` can be one of the following: The manager worker is responsible for many background tasks, including the managing of all the other workers. As such it is important to know what it's doing, especially in cases where it might seem stuck. -Accordingly, the [`bdr.stat_worker`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrstat_worker) view provides per worker statistics for PGD workers, including manager workers. With respect to ensuring manager workers do not get stuck, the current task they are executing would be reported in their `query` field prefixed by "pgd manager:". +Accordingly, the [`bdr.stat_worker`](/pgd/latest/reference/catalogs-visible/#bdrstat_worker) view provides per worker statistics for PGD workers, including manager workers. With respect to ensuring manager workers do not get stuck, the current task they are executing would be reported in their `query` field prefixed by "pgd manager:". The `worker_backend_state` field for manager workers also reports whether the manager is idle or busy. @@ -104,15 +104,15 @@ Routing is a critical part of PGD for ensuring a seemless application experience Monitoring all of these is important for noticing issues, debugging issues, as well as informing more optimal configurations. Accoringly, there are two main views for monitoring statistics to do with routing: -- [`bdr.stat_routing_state`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrstat_routing_state) for monitoring the state of the connection routing with PGD Proxy uses to route the connections. -- [`bdr.stat_routing_candidate_state`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrstat_routing_candidate_state) for information about routing candidate nodes from the point of view of the Raft leader (the view is empty on other nodes). +- [`bdr.stat_routing_state`](/pgd/latest/reference/catalogs-visible/#bdrstat_routing_state) for monitoring the state of the connection routing with PGD Proxy uses to route the connections. +- [`bdr.stat_routing_candidate_state`](/pgd/latest/reference/catalogs-visible/#bdrstat_routing_candidate_state) for information about routing candidate nodes from the point of view of the Raft leader (the view is empty on other nodes). ## Monitoring Replication Peers You use two main views for monitoring of replication activity: -- [`bdr.node_slots`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrnode_slots) for monitoring outgoing replication -- [`bdr.subscription_summary`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrsubscription_summary) for monitoring incoming replication +- [`bdr.node_slots`](/pgd/latest/reference/catalogs-visible/#bdrnode_slots) for monitoring outgoing replication +- [`bdr.subscription_summary`](/pgd/latest/reference/catalogs-visible/#bdrsubscription_summary) for monitoring incoming replication You can also obtain most of the information provided by `bdr.node_slots` by querying the standard PostgreSQL replication monitoring views @@ -128,9 +128,9 @@ something is down or disconnected. See [Replication slots](../node_management/re You can use another view for monitoring of outgoing replication activity: -- [`bdr.node_replication_rates`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrnode_replication_rates) for monitoring outgoing replication +- [`bdr.node_replication_rates`](/pgd/latest/reference/catalogs-visible/#bdrnode_replication_rates) for monitoring outgoing replication -The [`bdr.node_replication_rates`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrnode_replication_rates) view gives an overall picture of the outgoing +The [`bdr.node_replication_rates`](/pgd/latest/reference/catalogs-visible/#bdrnode_replication_rates) view gives an overall picture of the outgoing replication activity along with the catchup estimates for peer nodes, specifically. @@ -163,10 +163,10 @@ at which the peer is consuming data from the local node. The `replay_lag` when a node reconnects to the cluster is immediately set to zero. This information will be fixed in a future release. As a workaround, we recommend using the `catchup_interval` column that refers to the time required for the peer node to catch up to the -local node data. The other fields are also available from the [`bdr.node_slots`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrnode_slots) +local node data. The other fields are also available from the [`bdr.node_slots`](/pgd/latest/reference/catalogs-visible/#bdrnode_slots) view. -Administrators can query [`bdr.node_slots`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrnode_slots) for outgoing replication from the +Administrators can query [`bdr.node_slots`](/pgd/latest/reference/catalogs-visible/#bdrnode_slots) for outgoing replication from the local node. It shows information about replication status of all other nodes in the group that are known to the current node as well as any additional replication slots created by PGD on the current node. @@ -283,13 +283,13 @@ sub_slot_name | bdr_postgres_bdrgroup_node1 subscription_status | replicating ``` -You can further monitor subscriptions by monitoring subscription summary statistics through [`bdr.stat_subscription`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrstat_subscription), and by monitoring the subscription replication receivers and subscription replication writers, using [`bdr.stat_receiver`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrstat_receiver) and [`bdr.stat_writer`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrstat_writer), respectively. +You can further monitor subscriptions by monitoring subscription summary statistics through [`bdr.stat_subscription`](/pgd/latest/reference/catalogs-visible/#bdrstat_subscription), and by monitoring the subscription replication receivers and subscription replication writers, using [`bdr.stat_receiver`](/pgd/latest/reference/catalogs-visible/#bdrstat_receiver) and [`bdr.stat_writer`](/pgd/latest/reference/catalogs-visible/#bdrstat_writer), respectively. ### Monitoring WAL senders using LCR If the [decoding worker](../decoding_worker/) is enabled, you can monitor information about the current logical change record (LCR) file for each WAL sender -using the function [`bdr.wal_sender_stats()`](/pgd/latest/reference/tables-views-functions/functions/#bdrwal_sender_stats). For example: +using the function [`bdr.wal_sender_stats()`](/pgd/latest/reference/functions/#bdrwal_sender_stats). For example: ``` postgres=# SELECT * FROM bdr.wal_sender_stats(); @@ -306,7 +306,7 @@ This is the case if the decoding worker isn't enabled or the WAL sender is serving a [logical standby](../nodes/logical_standby_nodes/). Also, you can monitor information about the decoding worker using the function -[`bdr.get_decoding_worker_stat()`](/pgd/latest/reference/tables-views-functions/functions/#bdrget_decoding_worker_stat). For example: +[`bdr.get_decoding_worker_stat()`](/pgd/latest/reference/functions/#bdrget_decoding_worker_stat). For example: ``` postgres=# SELECT * FROM bdr.get_decoding_worker_stat(); @@ -365,9 +365,9 @@ Commit scopes are our durability and consistency configuration framework. As suc Accordingly, these two views show relevant statistics about commit scopes: -- [bdr.stat_commit_scope](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrstat_commit_scope) for cumulative statistics for each commit scope. +- [bdr.stat_commit_scope](/pgd/latest/reference/catalogs-visible/#bdrstat_commit_scope) for cumulative statistics for each commit scope. -- [bdr.stat_commit_scope_state](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrstat_commit_scope_state) for information about the current use of commit scopes by backend processes. +- [bdr.stat_commit_scope_state](/pgd/latest/reference/catalogs-visible/#bdrstat_commit_scope_state) for information about the current use of commit scopes by backend processes. ## Monitoring global locks @@ -384,7 +384,7 @@ There are currently two types of global locks: You can create either or both entry types for the same transaction, depending on the type of DDL operation and the value of the `bdr.ddl_locking` setting. -Global locks held on the local node are visible in the [`bdr.global_locks`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrglobal_locks) view. +Global locks held on the local node are visible in the [`bdr.global_locks`](/pgd/latest/reference/catalogs-visible/#bdrglobal_locks) view. This view shows the type of the lock. For relation locks, it shows the relation that's being locked, the PID holding the lock (if local), and whether the lock was globally granted. In case @@ -406,7 +406,7 @@ relation | someschema.sometable pid | 15534 ``` -See [Catalogs](/pgd/latest/reference/tables-views-functions/catalogs-visible/) for details on all fields, including lock +See [Catalogs](/pgd/latest/reference/catalogs-visible/) for details on all fields, including lock timing information. ## Monitoring conflicts @@ -421,7 +421,7 @@ row-level security to ensure they're visible only by owners of replicated tables. Owners should expect conflicts and analyze them to see which, if any, might be considered as problems to resolve. -For monitoring purposes, use [`bdr.conflict_history_summary`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrconflict_history_summary), which doesn't +For monitoring purposes, use [`bdr.conflict_history_summary`](/pgd/latest/reference/catalogs-visible#bdrconflict_history_summary), which doesn't contain user data. This example shows a query to count the number of conflicts seen in the current day using an efficient query plan: @@ -437,8 +437,8 @@ WHERE local_time > date_trunc('day', current_timestamp) PGD collects statistics about replication apply, both for each subscription and for each table. -Two monitoring views exist: [`bdr.stat_subscription`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_subscription) for subscription statistics -and [`bdr.stat_relation`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_relation) for relation statistics. These views both provide: +Two monitoring views exist: [`bdr.stat_subscription`](/pgd/latest/reference/catalogs-visible#bdrstat_subscription) for subscription statistics +and [`bdr.stat_relation`](/pgd/latest/reference/catalogs-visible#bdrstat_relation) for relation statistics. These views both provide: - Number of INSERTs/UPDATEs/DELETEs/TRUNCATEs replicated - Block accesses and cache hit ratio @@ -447,18 +447,18 @@ and [`bdr.stat_relation`](/pgd/latest/reference/tables-views-functions/catalogs- - Number of in-progress transactions streamed to writers - Number of in-progress streamed transactions committed/aborted -For relations only, [`bdr.stat_relation`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_relation) also includes: +For relations only, [`bdr.stat_relation`](/pgd/latest/reference/catalogs-visible#bdrstat_relation) also includes: - Total time spent processing replication for the relation - Total lock wait time to acquire lock (if any) for the relation (only) -For subscriptions only, [`bdr.stat_subscription`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_subscription) includes: +For subscriptions only, [`bdr.stat_subscription`](/pgd/latest/reference/catalogs-visible#bdrstat_subscription) includes: - Number of COMMITs/DDL replicated for the subscription - Number of times this subscription has connected upstream Tracking of these statistics is controlled by the PGD GUCs -[`bdr.track_subscription_apply`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrtrack_subscription_apply) and [`bdr.track_relation_apply`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrtrack_relation_apply), +[`bdr.track_subscription_apply`](/pgd/latest/reference/pgd-settings#bdrtrack_subscription_apply) and [`bdr.track_relation_apply`](/pgd/latest/reference/pgd-settings#bdrtrack_relation_apply), respectively. The following shows the example output from these: @@ -480,9 +480,9 @@ nddl | 2 In this case, the subscription connected three times to the upstream, inserted 10 rows, and performed two DDL commands inside five transactions. -You can reset the stats counters for these views to zero using the functions [`bdr.reset_subscription_stats`](/pgd/latest/reference/tables-views-functions/functions-internal#bdrreset_subscription_stats) and [`bdr.reset_relation_stats`](/pgd/latest/reference/tables-views-functions/functions-internal#bdrreset_relation_stats). +You can reset the stats counters for these views to zero using the functions [`bdr.reset_subscription_stats`](/pgd/latest/reference/functions-internal#bdrreset_subscription_stats) and [`bdr.reset_relation_stats`](/pgd/latest/reference/functions-internal#bdrreset_relation_stats). -PGD also monitors statistics regarding subscription replication receivers and subscription replication writers for each subscription, using [`bdr.stat_receiver`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrstat_receiver) and [`bdr.stat_writer`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrstat_writer), respectively. +PGD also monitors statistics regarding subscription replication receivers and subscription replication writers for each subscription, using [`bdr.stat_receiver`](/pgd/latest/reference/catalogs-visible/#bdrstat_receiver) and [`bdr.stat_writer`](/pgd/latest/reference/catalogs-visible/#bdrstat_writer), respectively. ## Standard PostgreSQL statistics views @@ -524,8 +524,8 @@ PGD allows running different Postgres versions as well as different BDR extension versions across the nodes in the same cluster. This capability is useful for upgrading. -The view [`bdr.group_versions_details`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrgroup_versions_details) uses the function -[`bdr.run_on_all_nodes()`](/pgd/latest/reference/tables-views-functions/functions#bdrrun_on_all_nodes) to retrieve Postgres and BDR extension versions from all +The view [`bdr.group_versions_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_versions_details) uses the function +[`bdr.run_on_all_nodes()`](/pgd/latest/reference/functions#bdrrun_on_all_nodes) to retrieve Postgres and BDR extension versions from all nodes at the same time. For example: ```sql @@ -550,7 +550,7 @@ For monitoring purposes, we recommend the following alert levels: when compared to other nodes The described behavior is implemented in the function -[`bdr.monitor_group_versions()`](/pgd/latest/reference/tables-views-functions/functions#bdrmonitor_group_versions), which uses PGD version +[`bdr.monitor_group_versions()`](/pgd/latest/reference/functions#bdrmonitor_group_versions), which uses PGD version information returned from the view `bdr.group_version_details` to provide a cluster-wide version check. For example: @@ -577,8 +577,8 @@ follows: - PGD group replication slot doesn't advance LSN and thus keeps WAL files on disk. -The view [`bdr.group_raft_details`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrgroup_raft_details) uses the functions -[`bdr.run_on_all_nodes()`](/pgd/latest/reference/tables-views-functions/functions#bdrrun_on_all_nodes) and [`bdr.get_raft_status()`](/pgd/latest/reference/tables-views-functions/functions#bdrget_raft_status) to retrieve Raft +The view [`bdr.group_raft_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_raft_details) uses the functions +[`bdr.run_on_all_nodes()`](/pgd/latest/reference/functions#bdrrun_on_all_nodes) and [`bdr.get_raft_status()`](/pgd/latest/reference/functions#bdrget_raft_status) to retrieve Raft consensus status from all nodes at the same time. For example: ```sql @@ -645,8 +645,8 @@ monitoring alert levels are defined as follows: than the node set as RAFT_LEADER The described behavior is implemented in the function -[`bdr.monitor_group_raft()`](/pgd/latest/reference/tables-views-functions/functions#bdrmonitor_group_raft), which uses Raft consensus status -information returned from the view [`bdr.group_raft_details`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrgroup_raft_details) +[`bdr.monitor_group_raft()`](/pgd/latest/reference/functions#bdrmonitor_group_raft), which uses Raft consensus status +information returned from the view [`bdr.group_raft_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_raft_details) to provide a cluster-wide Raft check. For example: ```sql @@ -656,7 +656,7 @@ node_group_name | status | message mygroup | OK | Raft Consensus is working correctly ``` -Two further views that can give a finer-grained look at the state of Raft consensus are [`bdr.stat_raft_state`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrstat_raft_state), which provides the state of the Raft consensus on the local node, and [`bdr.stat_raft_followers_state`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrstat_raft_followers_state), which provides a view when on the Raft leader (it is empty on other nodes) regarding the state of the followers of that Raft leader. +Two further views that can give a finer-grained look at the state of Raft consensus are [`bdr.stat_raft_state`](/pgd/latest/reference/catalogs-visible/#bdrstat_raft_state), which provides the state of the Raft consensus on the local node, and [`bdr.stat_raft_followers_state`](/pgd/latest/reference/catalogs-visible/#bdrstat_raft_followers_state), which provides a view when on the Raft leader (it is empty on other nodes) regarding the state of the followers of that Raft leader. ## Monitoring replication slots @@ -681,7 +681,7 @@ FROM pg_replication_slots ORDER BY slot_name; Peer slot names follow the convention `bdr___`, while the PGD group slot name follows the convention `bdr__`. You can access the group slot using the function -[`bdr.local_group_slot_name()`](/pgd/latest/reference/tables-views-functions/functions#bdrlocal_group_slot_name). +[`bdr.local_group_slot_name()`](/pgd/latest/reference/functions#bdrlocal_group_slot_name). Peer replication slots must be active on all nodes at all times. If a peer replication slot isn't active, then it might mean either: @@ -698,7 +698,7 @@ maintains this slot and advances its LSN when all other peers already consumed the corresponding transactions. Consequently, it's not necessary to monitor the status of the group slot. -The function [`bdr.monitor_local_replslots()`](/pgd/latest/reference/tables-views-functions/functions#bdrmonitor_local_replslots) provides a summary of whether all +The function [`bdr.monitor_local_replslots()`](/pgd/latest/reference/functions#bdrmonitor_local_replslots) provides a summary of whether all PGD node replication slots are working as expected. This summary is also available on subscriber-only nodes that are operating as subscriber-only group leaders in a PGD cluster when [optimized topology](../nodes/subscriber_only/optimizing-so) is enabled. For example: ```sql @@ -724,6 +724,6 @@ One of the following status summaries is returned: By default, PGD transactions are committed only to the local node. In that case, a transaction's `COMMIT` is processed quickly. PGD's [Commit Scopes](../commit-scopes/commit-scopes) feature offers a range of synchronous transaction commit scopes that allow you to balance durability, consistency, and performance for your particular queries. -You can monitor these transactions by examining the [`bdr.stat_activity`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_activity) catalog. The processes report different `wait_event` states as a transaction is committed. This monitoring only covers transactions in progress and doesn't provide historical timing information. +You can monitor these transactions by examining the [`bdr.stat_activity`](/pgd/latest/reference/catalogs-visible#bdrstat_activity) catalog. The processes report different `wait_event` states as a transaction is committed. This monitoring only covers transactions in progress and doesn't provide historical timing information. diff --git a/product_docs/docs/pgd/5.6/node_management/creating_and_joining.mdx b/product_docs/docs/pgd/5.6/node_management/creating_and_joining.mdx index fc265ee45c8..91d36338d36 100644 --- a/product_docs/docs/pgd/5.6/node_management/creating_and_joining.mdx +++ b/product_docs/docs/pgd/5.6/node_management/creating_and_joining.mdx @@ -18,7 +18,7 @@ format, like `host=myhost port=5432 dbname=mydb`, or URI format, like `postgresql://myhost:5432/mydb`. The SQL function -[`bdr.create_node_group()`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrcreate_node_group) +[`bdr.create_node_group()`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node_group) creates the PGD group from the local node. Doing so activates PGD on that node and allows other nodes to join the PGD group, which consists of only one node at that point. At the time of creation, you must specify the connection string for @@ -26,11 +26,11 @@ other nodes to use to connect to this node. Once the node group is created, every further node can join the PGD group using the -[`bdr.join_node_group()`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrjoin_node_group) +[`bdr.join_node_group()`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) function. Alternatively, use the command line utility -[bdr_init_physical](/pgd/latest/reference/tables-views-functions/nodes/#bdr_init_physical) to create a +[bdr_init_physical](/pgd/latest/reference/nodes/#bdr_init_physical) to create a new node, using `pg_basebackup`. If using `pg_basebackup`, the bdr_init_physical utility can optionally specify the base backup of only the target database. The earlier behavior was to back up the entire database cluster. With this utility, @@ -62,7 +62,7 @@ more details, see [Connections and roles](../security/role-management#connection Optionally, you can skip the schema synchronization using the `synchronize_structure` parameter of the -[`bdr.join_node_group`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrjoin_node_group) +[`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) function. In this case, the schema must already exist on the newly joining node. We recommend that you select the source node that has the best connection (logically close, ideally with low latency and high bandwidth) @@ -73,7 +73,7 @@ Coordinate the join procedure using the Raft consensus algorithm, which requires most existing nodes to be online and reachable. The logical join procedure (which uses the -[`bdr.join_node_group`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrjoin_node_group) +[`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) function) performs data sync doing `COPY` operations and uses multiple writers (parallel apply) if those are enabled. @@ -99,6 +99,6 @@ If this is necessary, run LiveCompare on the newly joined node to correct any data divergence once all nodes are available and caught up. `pg_dump` can fail when there's concurrent DDL activity on the source node -because of cache-lookup failures. Since [`bdr.join_node_group`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrjoin_node_group) uses pg_dump +because of cache-lookup failures. Since [`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) uses pg_dump internally, it might fail if there's concurrent DDL activity on the source node. Retrying the join works in that case. diff --git a/product_docs/docs/pgd/5.6/node_management/heterogeneous_clusters.mdx b/product_docs/docs/pgd/5.6/node_management/heterogeneous_clusters.mdx index 98247d9b4e2..62a3feed9c2 100644 --- a/product_docs/docs/pgd/5.6/node_management/heterogeneous_clusters.mdx +++ b/product_docs/docs/pgd/5.6/node_management/heterogeneous_clusters.mdx @@ -22,7 +22,7 @@ join the cluster. Don't run any DDLs that might not be available on the older versions and vice versa. A node joining with a different major PostgreSQL release can't use -physical backup taken with [`bdr_init_physical`](/pgd/latest/reference/tables-views-functions/nodes#bdr_init_physical), and the node must join +physical backup taken with [`bdr_init_physical`](/pgd/latest/reference/nodes#bdr_init_physical), and the node must join using the logical join method. Using this method is necessary because the major PostgreSQL releases aren't on-disk compatible with each other. diff --git a/product_docs/docs/pgd/5.6/node_management/maintainance_with_proxies.mdx b/product_docs/docs/pgd/5.6/node_management/maintainance_with_proxies.mdx index c26457bf3cf..242d1436ab6 100644 --- a/product_docs/docs/pgd/5.6/node_management/maintainance_with_proxies.mdx +++ b/product_docs/docs/pgd/5.6/node_management/maintainance_with_proxies.mdx @@ -39,7 +39,7 @@ select node_name from bdr.node; ``` !!! Tip -For more details, see the [`bdr.node`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrnode) table. +For more details, see the [`bdr.node`](/pgd/latest/reference/catalogs-visible#bdrnode) table. !!! This command lists just the node names. If you need to know the group they are a member of, use: @@ -49,7 +49,7 @@ select node_name, node_group_name from bdr.node_summary; ``` !!! Tip -For more details, see the [`bdr.node_summary`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrnode_summary) table. +For more details, see the [`bdr.node_summary`](/pgd/latest/reference/catalogs-visible#bdrnode_summary) table. !!! ## Finding the write leader diff --git a/product_docs/docs/pgd/5.6/node_management/node_recovery.mdx b/product_docs/docs/pgd/5.6/node_management/node_recovery.mdx index 2348b73711a..b05ac8daaea 100644 --- a/product_docs/docs/pgd/5.6/node_management/node_recovery.mdx +++ b/product_docs/docs/pgd/5.6/node_management/node_recovery.mdx @@ -7,7 +7,7 @@ PGD is designed to recover from node restart or node disconnection. The disconnected node rejoins the group by reconnecting to each peer node and then replicating any missing data from that node. -When a node starts up, each connection begins showing up in [`bdr.node_slots`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrnode_slots) with +When a node starts up, each connection begins showing up in [`bdr.node_slots`](/pgd/latest/reference/catalogs-visible#bdrnode_slots) with `bdr.node_slots.state = catchup` and begins replicating missing data. Catching up continues for a period of time that depends on the amount of missing data from each peer node and will likely increase diff --git a/product_docs/docs/pgd/5.6/node_management/removing_nodes_and_groups.mdx b/product_docs/docs/pgd/5.6/node_management/removing_nodes_and_groups.mdx index e6216ef311b..1ba218e14c8 100644 --- a/product_docs/docs/pgd/5.6/node_management/removing_nodes_and_groups.mdx +++ b/product_docs/docs/pgd/5.6/node_management/removing_nodes_and_groups.mdx @@ -10,9 +10,9 @@ permanently. If you permanently shut down a node and don't tell the other nodes, then performance suffers and eventually the whole system stops working. -Node removal, also called *parting*, is done using the [`bdr.part_node()`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrpart_node) +Node removal, also called *parting*, is done using the [`bdr.part_node()`](/pgd/latest/reference/nodes-management-interfaces#bdrpart_node) function. You must specify the node name (as passed during node creation) -to remove a node. You can call the [`bdr.part_node()`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrpart_node) function from any active +to remove a node. You can call the [`bdr.part_node()`](/pgd/latest/reference/nodes-management-interfaces#bdrpart_node) function from any active node in the PGD group, including the node that you're removing. Just like the join procedure, parting is done using Raft consensus and requires a @@ -26,7 +26,7 @@ most recent node to allow them to catch up any missing data. A parted node still is known to PGD but doesn't consume resources. A node might be added again under the same name as a parted node. In rare cases, you might want to clear all metadata of a parted -node by using the function [`bdr.drop_node()`](/pgd/latest/reference/tables-views-functions/functions-internal#bdrdrop_node). +node by using the function [`bdr.drop_node()`](/pgd/latest/reference/functions-internal#bdrdrop_node). ## Removing a whole PGD group diff --git a/product_docs/docs/pgd/5.6/node_management/replication_slots.mdx b/product_docs/docs/pgd/5.6/node_management/replication_slots.mdx index d371c7059a8..8fbe149f7ff 100644 --- a/product_docs/docs/pgd/5.6/node_management/replication_slots.mdx +++ b/product_docs/docs/pgd/5.6/node_management/replication_slots.mdx @@ -42,7 +42,7 @@ The group slot is an internal slot used by PGD primarily to track the oldest safe position that any node in the PGD group (including all logical standbys) has caught up to, for any outbound replication from this node. -The group slot name is given by the function [`bdr.local_group_slot_name()`](/pgd/latest/reference/tables-views-functions/functions#bdrlocal_group_slot_name). +The group slot name is given by the function [`bdr.local_group_slot_name()`](/pgd/latest/reference/functions#bdrlocal_group_slot_name). The group slot can: diff --git a/product_docs/docs/pgd/5.6/node_management/viewing_topology.mdx b/product_docs/docs/pgd/5.6/node_management/viewing_topology.mdx index 40853dd3f84..e9732a872ff 100644 --- a/product_docs/docs/pgd/5.6/node_management/viewing_topology.mdx +++ b/product_docs/docs/pgd/5.6/node_management/viewing_topology.mdx @@ -26,7 +26,7 @@ pgd show-groups The following simple query lists all the PGD node groups of which the current node is a member. It currently returns only one row from -[`bdr.local_node_summary`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrlocal_node_summary). +[`bdr.local_node_summary`](/pgd/latest/reference/catalogs-visible#bdrlocal_node_summary). ```sql SELECT node_group_name @@ -85,7 +85,7 @@ pgd show-nodes | grep group_b ### Using SQL You can extract the list of all nodes in a given node group (such as `mygroup`) -from the [`bdr.node_summary`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrnode_summary)` view. For example: +from the [`bdr.node_summary`](/pgd/latest/reference/catalogs-visible#bdrnode_summary)` view. For example: ```sql SELECT node_name AS name diff --git a/product_docs/docs/pgd/5.6/nodes/logical_standby_nodes.mdx b/product_docs/docs/pgd/5.6/nodes/logical_standby_nodes.mdx index 5eb9ad3ef47..a18d28fe430 100644 --- a/product_docs/docs/pgd/5.6/nodes/logical_standby_nodes.mdx +++ b/product_docs/docs/pgd/5.6/nodes/logical_standby_nodes.mdx @@ -14,17 +14,17 @@ A master node can have zero, one, or more logical standby nodes. location is always preferred. Logical standby nodes are nodes that are held in a state of continual recovery, -constantly updating until they're required. This behavior is similar to how Postgres physical standbys operate while using logical replication for better performance. [`bdr.join_node_group`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrjoin_node_group) has the `pause_in_standby` +constantly updating until they're required. This behavior is similar to how Postgres physical standbys operate while using logical replication for better performance. [`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) has the `pause_in_standby` option to make the node stay in halfway-joined as a logical standby node. Logical standby nodes receive changes but don't send changes made locally to other nodes. Later, if you want, use -[`bdr.promote_node`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrpromote_node) +[`bdr.promote_node`](/pgd/latest/reference/nodes-management-interfaces#bdrpromote_node) to move the logical standby into a full, normal send/receive node. A logical standby is sent data by one source node, defined by the DSN in -[`bdr.join_node_group`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrjoin_node_group). +[`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group). Changes from all other nodes are received from this one source node, minimizing bandwidth between multiple sites. diff --git a/product_docs/docs/pgd/5.6/nodes/subscriber_only/optimizing-so.mdx b/product_docs/docs/pgd/5.6/nodes/subscriber_only/optimizing-so.mdx index c6bcc166d5b..fbe4bd5416f 100644 --- a/product_docs/docs/pgd/5.6/nodes/subscriber_only/optimizing-so.mdx +++ b/product_docs/docs/pgd/5.6/nodes/subscriber_only/optimizing-so.mdx @@ -56,7 +56,7 @@ The subscriber-only node and group form the building block for PGD tree topologi By default, PGD 5.6 forces the full mesh topology. This means the optimization described here is off. To enable the optimized topology, you must have your data nodes in subgroups, with proxy routing enabled on the subgroups. -You can then set the GUC [`bdr.force_full_mesh`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrforce_full_mesh) to `off` to allow the optimization to be activated. +You can then set the GUC [`bdr.force_full_mesh`](/pgd/latest/reference/pgd-settings#bdrforce_full_mesh) to `off` to allow the optimization to be activated. !!! Note This GUC needs to be set in the `postgresql.conf` file on each data node and each node restarted for the change to take effect. diff --git a/product_docs/docs/pgd/5.6/parallelapply.mdx b/product_docs/docs/pgd/5.6/parallelapply.mdx index 6be548715c9..726f0b79f61 100644 --- a/product_docs/docs/pgd/5.6/parallelapply.mdx +++ b/product_docs/docs/pgd/5.6/parallelapply.mdx @@ -13,9 +13,9 @@ subscription and improves replication performance. ### Configuring Parallel Apply Two variables control Parallel Apply in PGD 5: -[`bdr.max_writers_per_subscription`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrmax_writers_per_subscription) +[`bdr.max_writers_per_subscription`](/pgd/latest/reference/pgd-settings#bdrmax_writers_per_subscription) (defaults to 8) and -[`bdr.writers_per_subscription`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrwriters_per_subscription) +[`bdr.writers_per_subscription`](/pgd/latest/reference/pgd-settings#bdrwriters_per_subscription) (defaults to 2). ```plain @@ -26,18 +26,18 @@ bdr.writers_per_subscription = 2 This configuration gives each subscription two writers. However, in some circumstances, the system might allocate up to eight writers for a subscription. -Changing [`bdr.max_writers_per_subscription`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrmax_writers_per_subscription) +Changing [`bdr.max_writers_per_subscription`](/pgd/latest/reference/pgd-settings#bdrmax_writers_per_subscription) requires a server restart to take effect. You can change -[`bdr.writers_per_subscription`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrwriters_per_subscription) +[`bdr.writers_per_subscription`](/pgd/latest/reference/pgd-settings#bdrwriters_per_subscription) for a specific subscription without a restart by: 1. Halting the subscription using - [`bdr.alter_subscription_disable`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdralter_subscription_disable). + [`bdr.alter_subscription_disable`](/pgd/latest/reference/nodes-management-interfaces#bdralter_subscription_disable). 1. Setting the new value. 1. Resuming the subscription using - [`bdr.alter_subscription_enable`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdralter_subscription_enable). + [`bdr.alter_subscription_enable`](/pgd/latest/reference/nodes-management-interfaces#bdralter_subscription_enable). First though, establish the name of the subscription using `select * from @@ -61,7 +61,7 @@ Parallel Apply is always on by default and, for most operations, we recommend le ### Monitoring Parallel Apply To support Parallel Apply's deadlock mitigation, PGD 5.2 adds columns to -[`bdr.stat_subscription`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_subscription). +[`bdr.stat_subscription`](/pgd/latest/reference/catalogs-visible#bdrstat_subscription). The new columns are `nprovisional_waits`, `ntuple_waits`, and `ncommmit_waits`. These are metrics that indicate how well Parallel Apply is managing what previously would have been deadlocks. They don't reflect overall system @@ -77,7 +77,7 @@ are counted in `ncommit_waits`. ### Disabling Parallel Apply -To disable Parallel Apply, set [`bdr.writers_per_subscription`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrwriters_per_subscription) to `1`. +To disable Parallel Apply, set [`bdr.writers_per_subscription`](/pgd/latest/reference/pgd-settings#bdrwriters_per_subscription) to `1`. ### Deadlock mitigation diff --git a/product_docs/docs/pgd/5.6/reference/catalogs-internal.mdx b/product_docs/docs/pgd/5.6/reference/catalogs-internal.mdx index c29045fe114..df6820f9b89 100644 --- a/product_docs/docs/pgd/5.6/reference/catalogs-internal.mdx +++ b/product_docs/docs/pgd/5.6/reference/catalogs-internal.mdx @@ -71,7 +71,7 @@ node. Specifically, it tracks: * Node joins (to the cluster) * Raft state changes (that is, whenever the node changes its role in the consensus protocol - leader, follower, or candidate to leader); see [Monitoring Raft consensus](../monitoring/sql#monitoring-raft-consensus) -* Whenever a worker has errored out (see [bdr.workers](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrworkers) +* Whenever a worker has errored out (see [bdr.workers](/pgd/latest/reference/catalogs-visible/#bdrworkers) and [Monitoring PGD replication workers](../monitoring/sql#monitoring-pgd-replication-workers)) #### `bdr.event_history` columns @@ -94,7 +94,7 @@ as textual representations rather than integers. ### `bdr.local_leader_change` -This is a local cache of the recent portion of leader change history. It has the same fields as [`bdr.leader`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrleader), except that it is an ordered set of (node_group_id, leader_kind, generation) instead of a map tracking merely the current version. +This is a local cache of the recent portion of leader change history. It has the same fields as [`bdr.leader`](/pgd/latest/reference/catalogs-visible#bdrleader), except that it is an ordered set of (node_group_id, leader_kind, generation) instead of a map tracking merely the current version. diff --git a/product_docs/docs/pgd/5.6/reference/catalogs-visible.mdx b/product_docs/docs/pgd/5.6/reference/catalogs-visible.mdx index 967acfe21bd..44355815073 100644 --- a/product_docs/docs/pgd/5.6/reference/catalogs-visible.mdx +++ b/product_docs/docs/pgd/5.6/reference/catalogs-visible.mdx @@ -969,7 +969,7 @@ A view containing all the necessary info about the replication subscription rece | sub_slot_name | name | Replication slot name used by the receiver | source_name | name | Source node for this receiver (the one it connects to), this is normally the same as the origin node, but is different for forward mode subscriptions | origin_name | name | The origin node for this receiver (the one it receives forwarded changes from), this is normally the same as the source node, but is different for forward mode subscriptions -| subscription_mode | char | Mode of the subscription, see [`bdr.subscription_summary`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrsubscription_summary) for more details +| subscription_mode | char | Mode of the subscription, see [`bdr.subscription_summary`](/pgd/latest/reference/catalogs-visible/#bdrsubscription_summary) for more details | sub_replication_sets| text[] | Replication sets this receiver is subscribed to | sub_apply_delay | interval | Apply delay interval | receive_lsn | pg_lsn | LSN of the last change received so far diff --git a/product_docs/docs/pgd/5.6/reference/commit-scopes.mdx b/product_docs/docs/pgd/5.6/reference/commit-scopes.mdx index 4cf9db4a447..1dfcedd54a9 100644 --- a/product_docs/docs/pgd/5.6/reference/commit-scopes.mdx +++ b/product_docs/docs/pgd/5.6/reference/commit-scopes.mdx @@ -11,9 +11,9 @@ Commit scopes are rules that determine how transaction commits and conflicts are You can manipulate commit scopes using the following functions: -- [`bdr.create_commit_scope`](/pgd/latest/reference/tables-views-functions/functions#bdrcreate_commit_scope) -- [`bdr.alter_commit_scope`](/pgd/latest/reference/tables-views-functions/functions#bdralter_commit_scope) -- [`bdr.drop_commit_scope`](/pgd/latest/reference/tables-views-functions/functions#bdrdrop_commit_scope) +- [`bdr.create_commit_scope`](/pgd/latest/reference/functions#bdrcreate_commit_scope) +- [`bdr.alter_commit_scope`](/pgd/latest/reference/functions#bdralter_commit_scope) +- [`bdr.drop_commit_scope`](/pgd/latest/reference/functions#bdrdrop_commit_scope) ## Commit scope syntax diff --git a/product_docs/docs/pgd/5.6/reference/functions-internal.mdx b/product_docs/docs/pgd/5.6/reference/functions-internal.mdx index 4d4766fefe1..b275c29e62c 100644 --- a/product_docs/docs/pgd/5.6/reference/functions-internal.mdx +++ b/product_docs/docs/pgd/5.6/reference/functions-internal.mdx @@ -177,7 +177,7 @@ Use of this internal function is limited to: * When you're instructed to by EDB Technical Support. * Where you're specifically instructed to in the documentation. -Use [`bdr.part_node`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrpart_node) to remove a node from a PGD group. That function sets the node to `PARTED` state and enables reuse of the node name. +Use [`bdr.part_node`](/pgd/latest/reference/nodes-management-interfaces#bdrpart_node) to remove a node from a PGD group. That function sets the node to `PARTED` state and enables reuse of the node name. !!! @@ -492,40 +492,40 @@ Internal function intended for use by PGD-CLI. ### `bdr.stat_get_activity` -Internal function underlying view `bdr.stat_activity`. Do not use directly. Use the [`bdr.stat_activity`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_activity) view instead. +Internal function underlying view `bdr.stat_activity`. Do not use directly. Use the [`bdr.stat_activity`](/pgd/latest/reference/catalogs-visible#bdrstat_activity) view instead. ### `bdr.worker_role_id_name` -Internal helper function used when generating view `bdr.worker_tasks`. Do not use directly. Use the [`bdr.worker_tasks`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrworker_tasks) view instead. +Internal helper function used when generating view `bdr.worker_tasks`. Do not use directly. Use the [`bdr.worker_tasks`](/pgd/latest/reference/catalogs-visible#bdrworker_tasks) view instead. ### `bdr.lag_history` -Internal function used when generating view `bdr.node_replication_rates`. Do not use directly. Use the [`bdr.node_replication_rates`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrnode_replication_rates) view instead. +Internal function used when generating view `bdr.node_replication_rates`. Do not use directly. Use the [`bdr.node_replication_rates`](/pgd/latest/reference/catalogs-visible#bdrnode_replication_rates) view instead. ### `bdr.get_raft_instance_by_nodegroup` -Internal function used when generating view `bdr.group_raft_details`. Do not use directly. Use the [`bdr.group_raft_details`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrgroup_raft_details) view instead. +Internal function used when generating view `bdr.group_raft_details`. Do not use directly. Use the [`bdr.group_raft_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_raft_details) view instead. ### `bdr.monitor_camo_on_all_nodes` -Internal function used when generating view `bdr.group_camo_details`. Do not use directly. Use the [`bdr.group_camo_details`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrgroup_camo_details) view instead. +Internal function used when generating view `bdr.group_camo_details`. Do not use directly. Use the [`bdr.group_camo_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_camo_details) view instead. ### `bdr.monitor_raft_details_on_all_nodes` -Internal function used when generating view `bdr.group_raft_details`. Do not use directly. Use the [`bdr.group_raft_details`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrgroup_raft_details) view instead. +Internal function used when generating view `bdr.group_raft_details`. Do not use directly. Use the [`bdr.group_raft_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_raft_details) view instead. ### `bdr.monitor_replslots_details_on_all_nodes` -Internal function used when generating view `bdr.group_replslots_details`. Do not use directly. Use the [`bdr.group_replslots_details`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrgroup_replslots_details) view instead. +Internal function used when generating view `bdr.group_replslots_details`. Do not use directly. Use the [`bdr.group_replslots_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_replslots_details) view instead. ### `bdr.monitor_subscription_details_on_all_nodes` -Internal function used when generating view `bdr.group_subscription_summary`. Do not use directly. Use the [`bdr.group_subscription_summary`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrgroup_subscription_summary) view instead. +Internal function used when generating view `bdr.group_subscription_summary`. Do not use directly. Use the [`bdr.group_subscription_summary`](/pgd/latest/reference/catalogs-visible#bdrgroup_subscription_summary) view instead. ### `bdr.monitor_version_details_on_all_nodes` -Internal function used when generating view `bdr.group_versions_details`. Do not use directly. Use the [`bdr.group_versions_details`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrgroup_versions_details) view instead. +Internal function used when generating view `bdr.group_versions_details`. Do not use directly. Use the [`bdr.group_versions_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_versions_details) view instead. ### `bdr.node_group_member_info` -Internal function used when generating view `bdr.group_raft_details`. Do not use directly. Use the [`bdr.group_raft_details`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrgroup_raft_details) view instead. \ No newline at end of file +Internal function used when generating view `bdr.group_raft_details`. Do not use directly. Use the [`bdr.group_raft_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_raft_details) view instead. \ No newline at end of file diff --git a/product_docs/docs/pgd/5.6/reference/functions.mdx b/product_docs/docs/pgd/5.6/reference/functions.mdx index 3e5b07425f8..20308f1d296 100644 --- a/product_docs/docs/pgd/5.6/reference/functions.mdx +++ b/product_docs/docs/pgd/5.6/reference/functions.mdx @@ -281,7 +281,7 @@ If a slot is dropped concurrently, the wait ends for that slot. If a node is currently down and isn't updating its slot, then the wait continues. You might want to set `statement_timeout` to complete earlier in that case. -If you are using [Optimized Topology](../nodes/subscriber_only/optimizing-so), we recommend using [`bdr.wait_node_confirm_lsn`](/pgd/latest/reference/tables-views-functions/functions#bdrwait_node_confirm_lsn) instead. +If you are using [Optimized Topology](../nodes/subscriber_only/optimizing-so), we recommend using [`bdr.wait_node_confirm_lsn`](/pgd/latest/reference/functions#bdrwait_node_confirm_lsn) instead. ) #### Synopsis @@ -312,7 +312,7 @@ If no LSN is supplied, the current wal_flush_lsn (using the `pg_current_wal_flus Supplying a node name parameter tells the function to wait for that node to pass the LSN. If no node name is supplied (by passing NULL), the function waits until all the nodes pass the LSN. -We recommend using this function if you are using [Optimized Topology](../nodes/subscriber_only/optimizing-so) instead of [`bdr.wait_slot_confirm_lsn`](/pgd/latest/reference/tables-views-functions/functions#bdrwait_slot_confirm_lsn). +We recommend using this function if you are using [Optimized Topology](../nodes/subscriber_only/optimizing-so) instead of [`bdr.wait_slot_confirm_lsn`](/pgd/latest/reference/functions#bdrwait_slot_confirm_lsn). This is because in an Optimized Topology, not all nodes have replication slots, so the function `bdr.wait_slot_confirm_lsn` might not work as expected. `bdr.wait_node_confirm_lsn` is designed to work with nodes that don't have replication slots, using alternative strategies to determine the progress of a node. @@ -433,7 +433,7 @@ bdr.replicate_ddl_command(ddl_cmd text, | --------- | ----------- | | `ddl_cmd` | DDL command to execute. | | `replication_sets` | An array of replication set names to apply the `ddlcommand` to. If NULL (or the function is passed only the `ddlcommand`), this parameter is set to the active PGD groups's default replication set. | -| `ddl_locking` | A string that sets the [`bdr.ddl_locking`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrddl_locking) value while replicating. Defaults to the GUC value for `bdr.ddl_locking` on the local system that's running `replicate_ddl_command`. | +| `ddl_locking` | A string that sets the [`bdr.ddl_locking`](/pgd/latest/reference/pgd-settings#bdrddl_locking) value while replicating. Defaults to the GUC value for `bdr.ddl_locking` on the local system that's running `replicate_ddl_command`. | | `execute_locally` | A Boolean that determines whether the DDL command executes locally. Defaults to true. | #### Notes @@ -1054,7 +1054,7 @@ bdr.lag_control() | Column name | Description | |----------------------------|---------------------------------------------------------------------------------------------------------------------------| -| `commit_scope_id` | OID of the commit scope (see [`bdr.commit_scopes`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrcommit_scopes)). | +| `commit_scope_id` | OID of the commit scope (see [`bdr.commit_scopes`](/pgd/latest/reference/catalogs-visible#bdrcommit_scopes)). | | `sessions` | Number of sessions referencing the lag control entry. | | `current_commit_delay` | Current runtime commit delay, in fractional milliseconds. | | `maximum_commit_delay` | Configured maximum commit delay, in fractional milliseconds. | @@ -1174,7 +1174,7 @@ The client must be prepared to retry the function call on error. ### `bdr.add_commit_scope` -**Deprecated**. Use [`bdr.create_commit_scope`](/pgd/latest/reference/tables-views-functions/functions#bdrcreate_commit_scope) instead. Previously, this function was used to add a commit scope to a node group. It's now deprecated and will emit a warning until it is removed in a future release, at which point it will raise an error. +**Deprecated**. Use [`bdr.create_commit_scope`](/pgd/latest/reference/functions#bdrcreate_commit_scope) instead. Previously, this function was used to add a commit scope to a node group. It's now deprecated and will emit a warning until it is removed in a future release, at which point it will raise an error. ### `bdr.create_commit_scope` @@ -1194,7 +1194,7 @@ bdr.create_commit_scope( #### Note -`bdr.create_commit_scope` replaces the deprecated [`bdr.add_commit_scope`](/pgd/latest/reference/tables-views-functions/functions#bdradd_commit_scope) function. Unlike `add_commit_scope`, it does not silently overwrite existing commit scopes when the same name is used. Instead, an error is reported. +`bdr.create_commit_scope` replaces the deprecated [`bdr.add_commit_scope`](/pgd/latest/reference/functions#bdradd_commit_scope) function. Unlike `add_commit_scope`, it does not silently overwrite existing commit scopes when the same name is used. Instead, an error is reported. ### `bdr.alter_commit_scope` @@ -1226,4 +1226,4 @@ bdr.drop_commit_scope( ### `bdr.remove_commit_scope` -**Deprecated**. Use [`bdr.drop_commit_scope`](/pgd/latest/reference/tables-views-functions/functions#bdrdrop_commit_scope) instead. Previously, this function was used to remove a commit scope from a node group. It's now deprecated and will emit a warning until it is removed in a future release, at which point it will raise an error. +**Deprecated**. Use [`bdr.drop_commit_scope`](/pgd/latest/reference/functions#bdrdrop_commit_scope) instead. Previously, this function was used to remove a commit scope from a node group. It's now deprecated and will emit a warning until it is removed in a future release, at which point it will raise an error. diff --git a/product_docs/docs/pgd/5.6/reference/nodes-management-interfaces.mdx b/product_docs/docs/pgd/5.6/reference/nodes-management-interfaces.mdx index e0a21b5520c..669df80c07e 100644 --- a/product_docs/docs/pgd/5.6/reference/nodes-management-interfaces.mdx +++ b/product_docs/docs/pgd/5.6/reference/nodes-management-interfaces.mdx @@ -317,7 +317,7 @@ bdr.join_node_group ( If `wait_for_completion` is specified as `false`, the function call returns as soon as the joining procedure starts. You can see the progress of the join in -the log files and the [`bdr.event_summary`](/pgd/latest/reference/tables-views-functions/catalogs-internal#bdrevent_summary) +the log files and the [`bdr.event_summary`](/pgd/latest/reference/catalogs-internal#bdrevent_summary) information view. You can call the function [`bdr.wait_for_join_completion()`](#bdrwait_for_join_completion) after `bdr.join_node_group()` to wait for the join operation to complete. It can emit progress information if called with `verbose_progress` set to `true`. diff --git a/product_docs/docs/pgd/5.6/reference/pgd-settings.mdx b/product_docs/docs/pgd/5.6/reference/pgd-settings.mdx index a062cbcbe14..4c2bf954370 100644 --- a/product_docs/docs/pgd/5.6/reference/pgd-settings.mdx +++ b/product_docs/docs/pgd/5.6/reference/pgd-settings.mdx @@ -489,15 +489,15 @@ archival, and rotation to prevent disk space exhaustion. ### `bdr.track_subscription_apply` -Tracks apply statistics for each subscription with [`bdr.stat_subscription`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_subscription) (default is `on`). +Tracks apply statistics for each subscription with [`bdr.stat_subscription`](/pgd/latest/reference/catalogs-visible#bdrstat_subscription) (default is `on`). ### `bdr.track_relation_apply` -Tracks apply statistics for each relation with [`bdr.stat_relation`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_relation) (default is `off`). +Tracks apply statistics for each relation with [`bdr.stat_relation`](/pgd/latest/reference/catalogs-visible#bdrstat_relation) (default is `off`). ### `bdr.track_apply_lock_timing` -Tracks lock timing when tracking statistics for relations with [`bdr.stat_relation`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_relation) (default is `off`). +Tracks lock timing when tracking statistics for relations with [`bdr.stat_relation`](/pgd/latest/reference/catalogs-visible#bdrstat_relation) (default is `off`). ## Decoding worker diff --git a/product_docs/docs/pgd/5.6/repsets.mdx b/product_docs/docs/pgd/5.6/repsets.mdx index 4156f72a854..afcf3cf7bab 100644 --- a/product_docs/docs/pgd/5.6/repsets.mdx +++ b/product_docs/docs/pgd/5.6/repsets.mdx @@ -17,7 +17,7 @@ In other words, by default, all user tables are replicated between all nodes. ## Using replication sets -You can create replication sets using [`bdr.create_replication_set`](/pgd/latest/reference/tables-views-functions/repsets-management#bdrcreate_replication_set), +You can create replication sets using [`bdr.create_replication_set`](/pgd/latest/reference/repsets-management#bdrcreate_replication_set), specifying whether to include insert, update, delete, or truncate actions. One option lets you add existing tables to the set, and a second option defines whether to add tables when they're @@ -33,12 +33,12 @@ Once the node is joined, you can still remove tables from the replication set, but you must add new tables using a resync operation. By default, a newly defined replication set doesn't replicate DDL or PGD -administration function calls. Use [`bdr.replication_set_add_ddl_filter`](/pgd/latest/reference/tables-views-functions/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter) +administration function calls. Use [`bdr.replication_set_add_ddl_filter`](/pgd/latest/reference/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter) to define the commands to replicate. PGD creates replication set definitions on all nodes. Each node can then be defined to publish or subscribe to each replication set using -[`bdr.alter_node_replication_sets`](/pgd/latest/reference/tables-views-functions/repsets-management#bdralter_node_replication_sets). +[`bdr.alter_node_replication_sets`](/pgd/latest/reference/repsets-management#bdralter_node_replication_sets). You can use functions to alter these definitions later or to drop the replication set. @@ -146,7 +146,7 @@ of replication set A that replicates only INSERT actions and replication set B t replicates only UPDATE actions. Both INSERT and UPDATE actions are replicated if the target node is also subscribed to both replication set A and B. -You can control membership using [`bdr.replication_set_add_table`](/pgd/latest/reference/tables-views-functions/repsets-membership#bdrreplication_set_add_table) and [`bdr.replication_set_remove_table`](/pgd/latest/reference/tables-views-functions/repsets-membership#bdrreplication_set_remove_table). +You can control membership using [`bdr.replication_set_add_table`](/pgd/latest/reference/repsets-membership#bdrreplication_set_add_table) and [`bdr.replication_set_remove_table`](/pgd/latest/reference/repsets-membership#bdrreplication_set_remove_table). ## Listing replication sets @@ -245,7 +245,7 @@ filter, the regular expression applied to the command tag and to the role name: SELECT * FROM bdr.ddl_replication; ``` -You can use [`bdr.replication_set_add_ddl_filter`](/pgd/latest/reference/tables-views-functions/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter) and [`bdr.replication_set_remove_ddl_filter`](/pgd/latest/reference/tables-views-functions/repsets-ddl-filtering#bdrreplication_set_remove_ddl_filter) to manipulate DDL filters. +You can use [`bdr.replication_set_add_ddl_filter`](/pgd/latest/reference/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter) and [`bdr.replication_set_remove_ddl_filter`](/pgd/latest/reference/repsets-ddl-filtering#bdrreplication_set_remove_ddl_filter) to manipulate DDL filters. They're considered to be `DDL` and are therefore subject to DDL replication and global locking. diff --git a/product_docs/docs/pgd/5.6/routing/administering.mdx b/product_docs/docs/pgd/5.6/routing/administering.mdx index 7610765d870..fe989098721 100644 --- a/product_docs/docs/pgd/5.6/routing/administering.mdx +++ b/product_docs/docs/pgd/5.6/routing/administering.mdx @@ -22,7 +22,7 @@ The switchover operation is not a guaranteed operation. If, due to a timeout or You can perform a switchover operation that explicitly changes the node that's the write leader to another node. -Use the [`bdr.routing_leadership_transfer()`](/pgd/5.6/reference/routing#bdrrouting_leadership_transfer) function. +Use the [`bdr.routing_leadership_transfer()`](/pgd/latest/reference/routing#bdrrouting_leadership_transfer) function. For example, to switch the write leader to node `node1` in group `group1`, use the following SQL command: diff --git a/product_docs/docs/pgd/5.6/routing/configuration.mdx b/product_docs/docs/pgd/5.6/routing/configuration.mdx index af5d62e11bb..3e11ee0964c 100644 --- a/product_docs/docs/pgd/5.6/routing/configuration.mdx +++ b/product_docs/docs/pgd/5.6/routing/configuration.mdx @@ -8,7 +8,7 @@ navTitle: "Configuration" Configuring the routing is done either through SQL interfaces or through PGD CLI. -You can enable routing decisions by calling the [`bdr.alter_node_group_option()`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdralter_node_group_option) function. +You can enable routing decisions by calling the [`bdr.alter_node_group_option()`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_group_option) function. For example: ```text @@ -27,7 +27,7 @@ Additional group-level options affect the routing decisions: ## Node-level configuration -Set per-node configuration of routing using [`bdr.alter_node_option()`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdralter_node_option). The +Set per-node configuration of routing using [`bdr.alter_node_option()`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_option). The available options that affect routing are: - `route_dsn` — The dsn used by proxy to connect to this node. @@ -45,7 +45,7 @@ You can configure the proxies using SQL interfaces. ### Creating and dropping proxy configurations -You can add a proxy configuration using [`bdr.create_proxy`](/pgd/5.6/reference/routing#bdrcreate_proxy). +You can add a proxy configuration using [`bdr.create_proxy`](/pgd/latest/reference/routing#bdrcreate_proxy). For example, `SELECT bdr.create_proxy('region1-proxy1', 'region1-group');` creates the default configuration for a proxy named `region1-proxy1` in the PGD group `region1-group`. @@ -56,7 +56,7 @@ Dropping a proxy deactivates it. ### Altering proxy configurations -You can configure options for each proxy using the [`bdr.alter_proxy_option()`](/pgd/5.6/reference/routing#bdralter_proxy_option) function. +You can configure options for each proxy using the [`bdr.alter_proxy_option()`](/pgd/latest/reference/routing#bdralter_proxy_option) function. The available options are: diff --git a/product_docs/docs/pgd/5.6/routing/monitoring.mdx b/product_docs/docs/pgd/5.6/routing/monitoring.mdx index d92962a6cbf..d8383e276be 100644 --- a/product_docs/docs/pgd/5.6/routing/monitoring.mdx +++ b/product_docs/docs/pgd/5.6/routing/monitoring.mdx @@ -9,11 +9,11 @@ You cam monitor proxies at the cluster and group level or at the process level. ### Using SQL -The current configuration of every group is visible in the [`bdr.node_group_routing_config_summary`](/pgd/5.6/reference/catalogs-internal#bdrnode_group_routing_config_summary) view. +The current configuration of every group is visible in the [`bdr.node_group_routing_config_summary`](/pgd/latest/reference/catalogs-internal#bdrnode_group_routing_config_summary) view. -The [`bdr.node_routing_config_summary`](/pgd/5.6/reference/catalogs-internal#bdrnode_routing_config_summary) view shows current per-node routing configuration. +The [`bdr.node_routing_config_summary`](/pgd/latest/reference/catalogs-internal#bdrnode_routing_config_summary) view shows current per-node routing configuration. -[`bdr.proxy_config_summary`](/pgd/5.6/reference/catalogs-internal#bdrproxy_config_summary) shows per-proxy configuration. +[`bdr.proxy_config_summary`](/pgd/latest/reference/catalogs-internal#bdrproxy_config_summary) shows per-proxy configuration. ## Monitoring at the process level diff --git a/product_docs/docs/pgd/5.6/routing/proxy.mdx b/product_docs/docs/pgd/5.6/routing/proxy.mdx index 283fb0343f8..3ea91560070 100644 --- a/product_docs/docs/pgd/5.6/routing/proxy.mdx +++ b/product_docs/docs/pgd/5.6/routing/proxy.mdx @@ -69,7 +69,7 @@ Upon starting, PGD Proxy connects to one of the endpoints given in the local con - Proxy options like listen address, listen port. - Routing details including the current write leader in default mode, read nodes in read-only mode, or both in any mode. -The endpoints given in the config file are used only at startup. After that, actual endpoints are taken from the PGD catalog's `route_dsn` field in [`bdr.node_routing_config_summary`](/pgd/latest/reference/tables-views-functions/catalogs-internal#bdrnode_routing_config_summary). +The endpoints given in the config file are used only at startup. After that, actual endpoints are taken from the PGD catalog's `route_dsn` field in [`bdr.node_routing_config_summary`](/pgd/latest/reference/catalogs-internal#bdrnode_routing_config_summary). PGD manages write leader election. PGD Proxy interacts with PGD to get write leader change events notifications on Postgres notify/listen channels and routes client traffic to the current write leader. PGD Proxy disconnects all existing client connections on write leader change or when write leader is unavailable. Write leader election is a Raft-backed activity and is subject to Raft leader availability. PGD Proxy closes the new client connections if the write leader is unavailable. diff --git a/product_docs/docs/pgd/5.6/scaling.mdx b/product_docs/docs/pgd/5.6/scaling.mdx index 219e2fe03e6..49bb625b580 100644 --- a/product_docs/docs/pgd/5.6/scaling.mdx +++ b/product_docs/docs/pgd/5.6/scaling.mdx @@ -19,7 +19,7 @@ your search_path, you need to schema qualify the name of each function. ## Auto creation of partitions -PGD AutoPartition uses the [`bdr.autopartition()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition) +PGD AutoPartition uses the [`bdr.autopartition()`](/pgd/latest/reference/autopartition#bdrautopartition) function to create or alter the definition of automatic range partitioning for a table. If no definition exists, it's created. Otherwise, later executions will alter the definition. @@ -42,7 +42,7 @@ case, all partitions are managed locally on each node. Managing partitions locally is useful when the partitioned table isn't a replicated table. In that case, you might not need or want to have all partitions on all nodes. For example, the built-in -[`bdr.conflict_history`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrconflict_history) +[`bdr.conflict_history`](/pgd/latest/reference/catalogs-visible#bdrconflict_history) table isn't a replicated table. It's managed by AutoPartition locally. Each node creates partitions for this table locally and drops them once they're old enough. @@ -145,7 +145,7 @@ upper bound. ## Stopping automatic creation of partitions Use -[`bdr.drop_autopartition()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrdrop_autopartition) +[`bdr.drop_autopartition()`](/pgd/latest/reference/autopartition#bdrdrop_autopartition) to drop the autopartitioning rule for the given relation. All pending work items for the relation are deleted, and no new work items are created. @@ -155,7 +155,7 @@ Partition creation is an asynchronous process. AutoPartition provides a set of functions to wait for the partition to be created, locally or on all nodes. Use -[`bdr.autopartition_wait_for_partitions()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_wait_for_partitions) +[`bdr.autopartition_wait_for_partitions()`](/pgd/latest/reference/autopartition#bdrautopartition_wait_for_partitions) to wait for the creation of partitions on the local node. The function takes the partitioned table name and a partition key column value and waits until the partition that holds that value is created. @@ -164,14 +164,14 @@ The function waits only for the partitions to be created locally. It doesn't guarantee that the partitions also exist on the remote nodes. To wait for the partition to be created on all PGD nodes, use the -[`bdr.autopartition_wait_for_partitions_on_all_nodes()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_wait_for_partitions_on_all_nodes) +[`bdr.autopartition_wait_for_partitions_on_all_nodes()`](/pgd/latest/reference/autopartition#bdrautopartition_wait_for_partitions_on_all_nodes) function. This function internally checks local as well as all remote nodes and waits until the partition is created everywhere. ## Finding a partition Use the -[`bdr.autopartition_find_partition()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_find_partition) +[`bdr.autopartition_find_partition()`](/pgd/latest/reference/autopartition#bdrautopartition_find_partition) function to find the partition for the given partition key value. If a partition to hold that value doesn't exist, then the function returns NULL. Otherwise it returns the Oid of the partition. @@ -179,10 +179,10 @@ of the partition. ## Enabling or disabling autopartitioning Use -[`bdr.autopartition_enable()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_enable) +[`bdr.autopartition_enable()`](/pgd/latest/reference/autopartition#bdrautopartition_enable) to enable autopartitioning on the given table. If autopartitioning is already enabled, then no action occurs. Similarly, use -[`bdr.autopartition_disable()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_disable) +[`bdr.autopartition_disable()`](/pgd/latest/reference/autopartition#bdrautopartition_disable) to disable autopartitioning on the given table. ## Restrictions on EDB Postgres Advanced Server-native automatic partitioning diff --git a/product_docs/docs/pgd/5.6/security/pgd-predefined-roles.mdx b/product_docs/docs/pgd/5.6/security/pgd-predefined-roles.mdx index e358af4d02b..97e74fae2a0 100644 --- a/product_docs/docs/pgd/5.6/security/pgd-predefined-roles.mdx +++ b/product_docs/docs/pgd/5.6/security/pgd-predefined-roles.mdx @@ -25,71 +25,71 @@ This role provides read access to most of the tables, views, and functions that `SELECT` privilege on: -- [`bdr.autopartition_partitions`](/pgd/5.6/reference/catalogs-internal#bdrautopartition_partitions) -- [`bdr.autopartition_rules`](/pgd/5.6/reference/catalogs-internal#bdrautopartition_rules) -- [`bdr.ddl_epoch`](/pgd/5.6/reference/catalogs-internal#bdrddl_epoch) -- [`bdr.ddl_replication`](/pgd/5.6/reference/pgd-settings#bdrddl_replication) -- [`bdr.global_consensus_journal_details`](/pgd/5.6/reference/catalogs-visible#bdrglobal_consensus_journal_details) -- [`bdr.global_lock`](/pgd/5.6/reference/catalogs-visible#bdrglobal_lock) -- [`bdr.global_locks`](/pgd/5.6/reference/catalogs-visible#bdrglobal_locks) -- [`bdr.group_camo_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_camo_details) -- [`bdr.local_consensus_state`](/pgd/5.6/reference/catalogs-visible#bdrlocal_consensus_state) -- [`bdr.local_node_summary`](/pgd/5.6/reference/catalogs-visible#bdrlocal_node_summary) -- [`bdr.node`](/pgd/5.6/reference/catalogs-visible#bdrnode) -- [`bdr.node_catchup_info`](/pgd/5.6/reference/catalogs-visible#bdrnode_catchup_info) -- [`bdr.node_catchup_info_details`](/pgd/5.6/reference/catalogs-visible#bdrnode_catchup_info_details) -- [`bdr.node_conflict_resolvers`](/pgd/5.6/reference/catalogs-visible#bdrnode_conflict_resolvers) -- [`bdr.node_group`](/pgd/5.6/reference/catalogs-visible#bdrnode_group) -- [`bdr.node_local_info`](/pgd/5.6/reference/catalogs-visible#bdrnode_local_info) -- [`bdr.node_peer_progress`](/pgd/5.6/reference/catalogs-visible#bdrnode_peer_progress) -- [`bdr.node_replication_rates`](/pgd/5.6/reference/catalogs-visible#bdrnode_replication_rates) -- [`bdr.node_slots`](/pgd/5.6/reference/catalogs-visible#bdrnode_slots) -- [`bdr.node_summary`](/pgd/5.6/reference/catalogs-visible#bdrnode_summary) -- [`bdr.replication_sets`](/pgd/5.6/reference/catalogs-visible#bdrreplication_sets) +- [`bdr.autopartition_partitions`](/pgd/latest/reference/catalogs-internal#bdrautopartition_partitions) +- [`bdr.autopartition_rules`](/pgd/latest/reference/catalogs-internal#bdrautopartition_rules) +- [`bdr.ddl_epoch`](/pgd/latest/reference/catalogs-internal#bdrddl_epoch) +- [`bdr.ddl_replication`](/pgd/latest/reference/pgd-settings#bdrddl_replication) +- [`bdr.global_consensus_journal_details`](/pgd/latest/reference/catalogs-visible#bdrglobal_consensus_journal_details) +- [`bdr.global_lock`](/pgd/latest/reference/catalogs-visible#bdrglobal_lock) +- [`bdr.global_locks`](/pgd/latest/reference/catalogs-visible#bdrglobal_locks) +- [`bdr.group_camo_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_camo_details) +- [`bdr.local_consensus_state`](/pgd/latest/reference/catalogs-visible#bdrlocal_consensus_state) +- [`bdr.local_node_summary`](/pgd/latest/reference/catalogs-visible#bdrlocal_node_summary) +- [`bdr.node`](/pgd/latest/reference/catalogs-visible#bdrnode) +- [`bdr.node_catchup_info`](/pgd/latest/reference/catalogs-visible#bdrnode_catchup_info) +- [`bdr.node_catchup_info_details`](/pgd/latest/reference/catalogs-visible#bdrnode_catchup_info_details) +- [`bdr.node_conflict_resolvers`](/pgd/latest/reference/catalogs-visible#bdrnode_conflict_resolvers) +- [`bdr.node_group`](/pgd/latest/reference/catalogs-visible#bdrnode_group) +- [`bdr.node_local_info`](/pgd/latest/reference/catalogs-visible#bdrnode_local_info) +- [`bdr.node_peer_progress`](/pgd/latest/reference/catalogs-visible#bdrnode_peer_progress) +- [`bdr.node_replication_rates`](/pgd/latest/reference/catalogs-visible#bdrnode_replication_rates) +- [`bdr.node_slots`](/pgd/latest/reference/catalogs-visible#bdrnode_slots) +- [`bdr.node_summary`](/pgd/latest/reference/catalogs-visible#bdrnode_summary) +- [`bdr.replication_sets`](/pgd/latest/reference/catalogs-visible#bdrreplication_sets) - `bdr.replication_status` -- [`bdr.sequences`](/pgd/5.6/reference/catalogs-visible#bdrsequences) -- [`bdr.stat_activity`](/pgd/5.6/reference/catalogs-visible#bdrstat_activity) -- [`bdr.stat_relation`](/pgd/5.6/reference/catalogs-visible#bdrstat_relation) -- [`bdr.stat_subscription`](/pgd/5.6/reference/catalogs-visible#bdrstat_subscription) _deprecated_ -- [`bdr.state_journal_details`](/pgd/5.6/reference/catalogs-visible#) -- [`bdr.subscription`](/pgd/5.6/reference/catalogs-visible#bdrsubscription) -- [`bdr.subscription_summary`](/pgd/5.6/reference/catalogs-visible#bdrsubscription_summary) -- [`bdr.tables`](/pgd/5.6/reference/catalogs-visible#bdrtables) -- [`bdr.taskmgr_local_work_queue`](/pgd/5.6/reference/catalogs-visible#bdrtaskmgr_local_work_queue) -- [`bdr.taskmgr_work_queue`](/pgd/5.6/reference/catalogs-visible#bdrtaskmgr_work_queue) -- [`bdr.worker_errors`](/pgd/5.6/reference/catalogs-visible#) _deprecated_ -- [`bdr.workers`](/pgd/5.6/reference/catalogs-visible#bdrworkers) -- [`bdr.writers`](/pgd/5.6/reference/catalogs-visible#bdrwriters) +- [`bdr.sequences`](/pgd/latest/reference/catalogs-visible#bdrsequences) +- [`bdr.stat_activity`](/pgd/latest/reference/catalogs-visible#bdrstat_activity) +- [`bdr.stat_relation`](/pgd/latest/reference/catalogs-visible#bdrstat_relation) +- [`bdr.stat_subscription`](/pgd/latest/reference/catalogs-visible#bdrstat_subscription) _deprecated_ +- [`bdr.state_journal_details`](/pgd/latest/reference/catalogs-visible#) +- [`bdr.subscription`](/pgd/latest/reference/catalogs-visible#bdrsubscription) +- [`bdr.subscription_summary`](/pgd/latest/reference/catalogs-visible#bdrsubscription_summary) +- [`bdr.tables`](/pgd/latest/reference/catalogs-visible#bdrtables) +- [`bdr.taskmgr_local_work_queue`](/pgd/latest/reference/catalogs-visible#bdrtaskmgr_local_work_queue) +- [`bdr.taskmgr_work_queue`](/pgd/latest/reference/catalogs-visible#bdrtaskmgr_work_queue) +- [`bdr.worker_errors`](/pgd/latest/reference/catalogs-visible#) _deprecated_ +- [`bdr.workers`](/pgd/latest/reference/catalogs-visible#bdrworkers) +- [`bdr.writers`](/pgd/latest/reference/catalogs-visible#bdrwriters) - `bdr.xid_peer_progress` EXECUTE privilege on: - `bdr.bdr_edition` _deprecated_ -- [`bdr.bdr_version`](/pgd/5.6/reference/functions#bdrbdr_version) -- [`bdr.bdr_version_num`](/pgd/5.6/reference/functions#bdrbdr_version_num) -- [`bdr.decode_message_payload`](/pgd/5.6/reference/functions-internal#bdrdecode_message_payload) -- [`bdr.get_consensus_status`](/pgd/5.6/reference/functions#bdrget_consensus_status) -- [`bdr.get_decoding_worker_stat`](/pgd/5.6/reference/functions#bdrget_decoding_worker_stat) -- [`bdr.get_global_locks`](/pgd/5.6/reference/functions-internal#bdrget_global_locks) -- [`bdr.get_min_required_replication_slots`](/pgd/5.6/reference/functions-internal#bdrget_min_required_replication_slots) -- [`bdr.get_min_required_worker_processes`](/pgd/5.6/reference/functions-internal#bdrget_min_required_worker_processes) -- [`bdr.get_raft_status`](/pgd/5.6/reference/functions#bdrget_raft_status) -- [`bdr.get_relation_stats`](/pgd/5.6/reference/functions#bdrget_relation_stats) -- [`bdr.get_slot_flush_timestamp`](/pgd/5.6/reference/functions-internal#bdrget_slot_flush_timestamp) +- [`bdr.bdr_version`](/pgd/latest/reference/functions#bdrbdr_version) +- [`bdr.bdr_version_num`](/pgd/latest/reference/functions#bdrbdr_version_num) +- [`bdr.decode_message_payload`](/pgd/latest/reference/functions-internal#bdrdecode_message_payload) +- [`bdr.get_consensus_status`](/pgd/latest/reference/functions#bdrget_consensus_status) +- [`bdr.get_decoding_worker_stat`](/pgd/latest/reference/functions#bdrget_decoding_worker_stat) +- [`bdr.get_global_locks`](/pgd/latest/reference/functions-internal#bdrget_global_locks) +- [`bdr.get_min_required_replication_slots`](/pgd/latest/reference/functions-internal#bdrget_min_required_replication_slots) +- [`bdr.get_min_required_worker_processes`](/pgd/latest/reference/functions-internal#bdrget_min_required_worker_processes) +- [`bdr.get_raft_status`](/pgd/latest/reference/functions#bdrget_raft_status) +- [`bdr.get_relation_stats`](/pgd/latest/reference/functions#bdrget_relation_stats) +- [`bdr.get_slot_flush_timestamp`](/pgd/latest/reference/functions-internal#bdrget_slot_flush_timestamp) - `bdr.get_sub_progress_timestamp` -- [`bdr.get_subscription_stats`](/pgd/5.6/reference/functions#bdrget_subscription_stats) -- [`bdr.lag_control`](/pgd/5.6/reference/functions#bdrlag_control) -- [`bdr.lag_history`](/pgd/5.6/reference/functions-internal#bdrlag_history) -- [`bdr.node_catchup_state_name`](/pgd/5.6/reference/functions-internal#bdrnode_catchup_state_name) -- [`bdr.node_kind_name`](/pgd/5.6/reference/functions-internal#bdrnode_kind_name) -- [`bdr.peer_state_name`](/pgd/5.6/reference/functions-internal#bdrpeer_state_name) -- [`bdr.pglogical_proto_version_ranges`](/pgd/5.6/reference/functions-internal#bdrpglogical_proto_version_ranges) -- [`bdr.show_subscription_status`](/pgd/5.6/reference/functions-internal#bdrshow_subscription_status) -- [`bdr.show_workers`](/pgd/5.6/reference/functions-internal#bdrshow_workers) -- [`bdr.show_writers`](/pgd/5.6/reference/functions-internal#bdrshow_writers) -- [`bdr.stat_get_activity`](/pgd/5.6/reference/functions-internal#bdrstat_get_activity) -- [`bdr.wal_sender_stats`](/pgd/5.6/reference/functions#bdrwal_sender_stats) -- [`bdr.worker_role_id_name`](/pgd/5.6/reference/functions-internal#bdrworker_role_id_name) +- [`bdr.get_subscription_stats`](/pgd/latest/reference/functions#bdrget_subscription_stats) +- [`bdr.lag_control`](/pgd/latest/reference/functions#bdrlag_control) +- [`bdr.lag_history`](/pgd/latest/reference/functions-internal#bdrlag_history) +- [`bdr.node_catchup_state_name`](/pgd/latest/reference/functions-internal#bdrnode_catchup_state_name) +- [`bdr.node_kind_name`](/pgd/latest/reference/functions-internal#bdrnode_kind_name) +- [`bdr.peer_state_name`](/pgd/latest/reference/functions-internal#bdrpeer_state_name) +- [`bdr.pglogical_proto_version_ranges`](/pgd/latest/reference/functions-internal#bdrpglogical_proto_version_ranges) +- [`bdr.show_subscription_status`](/pgd/latest/reference/functions-internal#bdrshow_subscription_status) +- [`bdr.show_workers`](/pgd/latest/reference/functions-internal#bdrshow_workers) +- [`bdr.show_writers`](/pgd/latest/reference/functions-internal#bdrshow_writers) +- [`bdr.stat_get_activity`](/pgd/latest/reference/functions-internal#bdrstat_get_activity) +- [`bdr.wal_sender_stats`](/pgd/latest/reference/functions#bdrwal_sender_stats) +- [`bdr.worker_role_id_name`](/pgd/latest/reference/functions-internal#bdrworker_role_id_name) ### bdr_monitor @@ -101,24 +101,24 @@ All privileges from [`bdr_read_all_stats`](#bdr_read_all_stats) plus the followi `SELECT` privilege on: -- [`bdr.group_raft_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_raft_details) -- [`bdr.group_replslots_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_replslots_details) -- [`bdr.group_subscription_summary`](/pgd/5.6/reference/catalogs-visible#bdrgroup_subscription_summary) -- [`bdr.group_versions_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_versions_details) +- [`bdr.group_raft_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_raft_details) +- [`bdr.group_replslots_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_replslots_details) +- [`bdr.group_subscription_summary`](/pgd/latest/reference/catalogs-visible#bdrgroup_subscription_summary) +- [`bdr.group_versions_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_versions_details) - `bdr.raft_instances` `EXECUTE` privilege on: -- [`bdr.get_raft_instance_by_nodegroup`](/pgd/5.6/reference/functions-internal#bdrget_raft_instance_by_nodegroup) -- [`bdr.monitor_camo_on_all_nodes`](/pgd/5.6/reference/functions-internal#bdrmonitor_camo_on_all_nodes) -- [`bdr.monitor_group_raft`](/pgd/5.6/reference/functions#bdrmonitor_group_raft) -- [`bdr.monitor_group_versions`](/pgd/5.6/reference/functions#bdrmonitor_group_versions) -- [`bdr.monitor_local_replslots`](/pgd/5.6/reference/functions#bdrmonitor_local_replslots) -- [`bdr.monitor_raft_details_on_all_nodes`](/pgd/5.6/reference/functions-internal#bdrmonitor_raft_details_on_all_nodes) -- [`bdr.monitor_replslots_details_on_all_nodes`](/pgd/5.6/reference/functions-internal#bdrmonitor_replslots_details_on_all_nodes) -- [`bdr.monitor_subscription_details_on_all_nodes`](/pgd/5.6/reference/functions-internal#bdrmonitor_subscription_details_on_all_nodes) -- [`bdr.monitor_version_details_on_all_nodes`](/pgd/5.6/reference/functions-internal#bdrmonitor_version_details_on_all_nodes) -- [`bdr.node_group_member_info`](/pgd/5.6/reference/functions-internal#bdrnode_group_member_info) +- [`bdr.get_raft_instance_by_nodegroup`](/pgd/latest/reference/functions-internal#bdrget_raft_instance_by_nodegroup) +- [`bdr.monitor_camo_on_all_nodes`](/pgd/latest/reference/functions-internal#bdrmonitor_camo_on_all_nodes) +- [`bdr.monitor_group_raft`](/pgd/latest/reference/functions#bdrmonitor_group_raft) +- [`bdr.monitor_group_versions`](/pgd/latest/reference/functions#bdrmonitor_group_versions) +- [`bdr.monitor_local_replslots`](/pgd/latest/reference/functions#bdrmonitor_local_replslots) +- [`bdr.monitor_raft_details_on_all_nodes`](/pgd/latest/reference/functions-internal#bdrmonitor_raft_details_on_all_nodes) +- [`bdr.monitor_replslots_details_on_all_nodes`](/pgd/latest/reference/functions-internal#bdrmonitor_replslots_details_on_all_nodes) +- [`bdr.monitor_subscription_details_on_all_nodes`](/pgd/latest/reference/functions-internal#bdrmonitor_subscription_details_on_all_nodes) +- [`bdr.monitor_version_details_on_all_nodes`](/pgd/latest/reference/functions-internal#bdrmonitor_version_details_on_all_nodes) +- [`bdr.node_group_member_info`](/pgd/latest/reference/functions-internal#bdrnode_group_member_info) ### bdr_application @@ -130,28 +130,28 @@ This role is designed for applications that require access to PGD features, obje - All functions for column_timestamps datatypes - All functions for CRDT datatypes -- [`bdr.alter_sequence_set_kind`](/pgd/5.6/reference/sequences#bdralter_sequence_set_kind) -- [`bdr.create_conflict_trigger`](/pgd/5.6/reference/streamtriggers/interfaces#bdrcreate_conflict_trigger) -- [`bdr.create_transform_trigger`](/pgd/5.6/reference/streamtriggers/interfaces#bdrcreate_transform_trigger) -- [`bdr.drop_trigger`](/pgd/5.6/reference/streamtriggers/interfaces#bdrdrop_trigger) -- [`bdr.get_configured_camo_partner`](/pgd/5.6/reference/functions#bdrget_configured_camo_partner) -- [`bdr.global_lock_table`](/pgd/5.6/reference/functions#bdrglobal_lock_table) -- [`bdr.is_camo_partner_connected`](/pgd/5.6/reference/functions#bdris_camo_partner_connected) -- [`bdr.is_camo_partner_ready`](/pgd/5.6/reference/functions#bdris_camo_partner_ready) -- [`bdr.logical_transaction_status`](/pgd/5.6/reference/functions#bdrlogical_transaction_status) +- [`bdr.alter_sequence_set_kind`](/pgd/latest/reference/sequences#bdralter_sequence_set_kind) +- [`bdr.create_conflict_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrcreate_conflict_trigger) +- [`bdr.create_transform_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrcreate_transform_trigger) +- [`bdr.drop_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrdrop_trigger) +- [`bdr.get_configured_camo_partner`](/pgd/latest/reference/functions#bdrget_configured_camo_partner) +- [`bdr.global_lock_table`](/pgd/latest/reference/functions#bdrglobal_lock_table) +- [`bdr.is_camo_partner_connected`](/pgd/latest/reference/functions#bdris_camo_partner_connected) +- [`bdr.is_camo_partner_ready`](/pgd/latest/reference/functions#bdris_camo_partner_ready) +- [`bdr.logical_transaction_status`](/pgd/latest/reference/functions#bdrlogical_transaction_status) - `bdr.ri_fkey_trigger` -- [`bdr.seq_nextval`](/pgd/5.6/reference/functions-internal#bdrseq_nextval) -- [`bdr.seq_currval`](/pgd/5.6/reference/functions-internal#bdrseq_currval) -- [`bdr.seq_lastval`](/pgd/5.6/reference/functions-internal#bdrseq_lastval) -- [`bdr.trigger_get_committs`](/pgd/5.6/reference/streamtriggers/rowfunctions#bdrtrigger_get_committs) -- [`bdr.trigger_get_conflict_type`](/pgd/5.6/reference/streamtriggers/rowfunctions#bdrtrigger_get_conflict_type) -- [`bdr.trigger_get_origin_node_id`](/pgd/5.6/reference/streamtriggers/rowfunctions#bdrtrigger_get_origin_node_id) -- [`bdr.trigger_get_row`](/pgd/5.6/reference/streamtriggers/rowfunctions#bdrtrigger_get_row) -- [`bdr.trigger_get_type`](/pgd/5.6/reference/streamtriggers/rowfunctions#bdrtrigger_get_type) -- [`bdr.trigger_get_xid`](/pgd/5.6/reference/streamtriggers/rowfunctions#bdrtrigger_get_xid) -- [`bdr.wait_for_camo_partner_queue`](/pgd/5.6/reference/functions#bdrwait_for_camo_partner_queue) -- [`bdr.wait_slot_confirm_lsn`](/pgd/5.6/reference/functions#bdrwait_slot_confirm_lsn) -- [`bdr.wait_node_confirm_lsn`](/pgd/5.6/reference/functions#bdrwait_node_confirm_lsn) +- [`bdr.seq_nextval`](/pgd/latest/reference/functions-internal#bdrseq_nextval) +- [`bdr.seq_currval`](/pgd/latest/reference/functions-internal#bdrseq_currval) +- [`bdr.seq_lastval`](/pgd/latest/reference/functions-internal#bdrseq_lastval) +- [`bdr.trigger_get_committs`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_committs) +- [`bdr.trigger_get_conflict_type`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_conflict_type) +- [`bdr.trigger_get_origin_node_id`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_origin_node_id) +- [`bdr.trigger_get_row`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_row) +- [`bdr.trigger_get_type`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_type) +- [`bdr.trigger_get_xid`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_xid) +- [`bdr.wait_for_camo_partner_queue`](/pgd/latest/reference/functions#bdrwait_for_camo_partner_queue) +- [`bdr.wait_slot_confirm_lsn`](/pgd/latest/reference/functions#bdrwait_slot_confirm_lsn) +- [`bdr.wait_node_confirm_lsn`](/pgd/latest/reference/functions#bdrwait_node_confirm_lsn) Many of these functions require additional privileges before you can use them. For example, you must be the table owner to successfully execute @@ -161,7 +161,7 @@ specific function. ### bdr_read_all_conflicts PGD logs conflicts into the -[`bdr.conflict_history`](/pgd/5.6/reference/catalogs-visible#bdrconflict_history) +[`bdr.conflict_history`](/pgd/latest/reference/catalogs-visible#bdrconflict_history) table. Conflicts are visible only to table owners, so no extra privileges are required for the owners to read the conflict history. @@ -170,4 +170,4 @@ you can optionally grant the role `bdr_read_all_conflicts` to that user. #### Privileges -An explicit policy is set on [`bdr.conflict_history`](/pgd/5.6/reference/catalogs-visible#bdrconflict_history) that allows this role to read the `bdr.conflict_history` table. +An explicit policy is set on [`bdr.conflict_history`](/pgd/latest/reference/catalogs-visible#bdrconflict_history) that allows this role to read the `bdr.conflict_history` table. diff --git a/product_docs/docs/pgd/5.6/security/role-management.mdx b/product_docs/docs/pgd/5.6/security/role-management.mdx index 21f3e519df0..cc32a697155 100644 --- a/product_docs/docs/pgd/5.6/security/role-management.mdx +++ b/product_docs/docs/pgd/5.6/security/role-management.mdx @@ -12,12 +12,12 @@ Remember that a user in Postgres terms is simply a role with login privileges. If you do create a role or user in a non-PGD, unreplicated database, it's especially important that you do not make an object in the PGD-replicated database rely on that role. It will break the replication process, as PGD cannot replicate a role that is not in the PGD-replicated database. -You can disable this automatic replication behavior by turning off the [`bdr.role_replication`](https://www.enterprisedb.com/docs/pgd/latest/reference/tables-views-functions/pgd-settings/#bdrrole_replication) setting, but we don't recommend that. +You can disable this automatic replication behavior by turning off the [`bdr.role_replication`](https://www.enterprisedb.com/docs/pgd/latest/reference/pgd-settings/#bdrrole_replication) setting, but we don't recommend that. ## Roles for new nodes -New PGD nodes that are added using [`bdr_init_physical`](https://www.enterprisedb.com/docs/pgd/latest/reference/tables-views-functions/nodes/#bdr_init_physical) will automatically replicate the roles from other nodes of the PGD cluster. +New PGD nodes that are added using [`bdr_init_physical`](https://www.enterprisedb.com/docs/pgd/latest/reference/nodes/#bdr_init_physical) will automatically replicate the roles from other nodes of the PGD cluster. If a PGD node is joined to a PGD group manually, without using `bdr_init_physical`, existing roles aren't copied to the newly joined node. This is intentional behavior to ensure that access isn't accidentally granted. @@ -37,7 +37,7 @@ When joining a new node, the “No unreplicated roles” rule also applies. If a ## Connections and roles When allocating a new PGD node, the user supplied in the DSN for the `local_dsn` -argument of [`bdr.create_node`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrcreate_node) and the `join_target_dsn` of [`bdr.join_node_group`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrjoin_node_group) +argument of [`bdr.create_node`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node) and the `join_target_dsn` of [`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) are used frequently to refer to, create, and manage database objects. PGD is carefully written to prevent privilege escalation attacks even when using diff --git a/product_docs/docs/pgd/5.6/security/roles.mdx b/product_docs/docs/pgd/5.6/security/roles.mdx index cc1e7724f35..f058d2567bb 100644 --- a/product_docs/docs/pgd/5.6/security/roles.mdx +++ b/product_docs/docs/pgd/5.6/security/roles.mdx @@ -12,7 +12,7 @@ PGD are split across the following predefined roles. | [**bdr_read_all_stats**](pgd-predefined-roles/#bdr_read_all_stats) | The role having read-only access to the tables, views, and functions, sufficient to understand the state of PGD. | | [**bdr_monitor**](pgd-predefined-roles/#bdr_monitor) | Includes the privileges of bdr_read_all_stats, with some extra privileges for monitoring. | | [**bdr_application**](pgd-predefined-roles/#bdr_application) | The minimal privileges required by applications running PGD. | - | [**bdr_read_all_conflicts**](pgd-predefined-roles/#bdr_read_all_conflicts) | Can view all conflicts in [`bdr.conflict_history`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrconflict_history). | + | [**bdr_read_all_conflicts**](pgd-predefined-roles/#bdr_read_all_conflicts) | Can view all conflicts in [`bdr.conflict_history`](/pgd/latest/reference/catalogs-visible#bdrconflict_history). | These roles are named to be analogous to PostgreSQL's `pg_` [predefined @@ -25,9 +25,9 @@ role has. Managing PGD doesn't require that administrators have access to user data. Arrangements for securing information about conflicts are discussed in -[Logging conflicts to a table](/pgd/latest/reference/tables-views-functions/conflict_functions#logging-conflicts-to-a-table). +[Logging conflicts to a table](/pgd/latest/reference/conflict_functions#logging-conflicts-to-a-table). -You can monitor conflicts using the [`bdr.conflict_history_summary`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrconflict_history_summary) view. +You can monitor conflicts using the [`bdr.conflict_history_summary`](/pgd/latest/reference/catalogs-visible#bdrconflict_history_summary) view. !!! Note The BDR extension and superuser access The one exception to the rule of not needing superuser access is in the diff --git a/product_docs/docs/pgd/5.6/sequences.mdx b/product_docs/docs/pgd/5.6/sequences.mdx index bce02abcd42..78e9dfd457d 100644 --- a/product_docs/docs/pgd/5.6/sequences.mdx +++ b/product_docs/docs/pgd/5.6/sequences.mdx @@ -66,7 +66,7 @@ function. This function takes a standard PostgreSQL sequence and marks it as a PGD global sequence. It can also convert the sequence back to the standard PostgreSQL sequence. -PGD also provides the configuration variable [`bdr.default_sequence_kind`](/pgd/latest/reference/tables-views-functions/pgd-settings/#bdrdefault_sequence_kind). This variable +PGD also provides the configuration variable [`bdr.default_sequence_kind`](/pgd/latest/reference/pgd-settings/#bdrdefault_sequence_kind). This variable determines the kind of sequence to create when the `CREATE SEQUENCE` command is executed or when a `serial`, `bigserial`, or `GENERATED BY DEFAULT AS IDENTITY` column is created. Valid settings are: @@ -84,7 +84,7 @@ command is executed or when a `serial`, `bigserial`, or sequences (that is, `bigserial`) and `galloc` sequence for `int4` (that is, `serial`) and `int2` sequences. -The [`bdr.sequences`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrsequences) view shows information about individual sequence kinds. +The [`bdr.sequences`](/pgd/latest/reference/catalogs-visible/#bdrsequences) view shows information about individual sequence kinds. `currval()` and `lastval()` work correctly for all types of global sequence. @@ -220,7 +220,7 @@ to or more than the above ranges assigned for each sequence datatype. `setval()` doesn't reset the global state for `galloc` sequences. Don't use it. A few limitations apply to `galloc` sequences. PGD tracks `galloc` sequences in a -special PGD catalog [bdr.sequence_alloc](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrsequence_alloc). This +special PGD catalog [bdr.sequence_alloc](/pgd/latest/reference/catalogs-visible/#bdrsequence_alloc). This catalog is required to track the currently allocated chunks for the `galloc` sequences. The sequence name and namespace is stored in this catalog. The sequence chunk allocation is managed by Raft, whereas any changes to the diff --git a/product_docs/docs/pgd/5.6/testingandtuning.mdx b/product_docs/docs/pgd/5.6/testingandtuning.mdx index bd3e6283969..e1965318d0d 100644 --- a/product_docs/docs/pgd/5.6/testingandtuning.mdx +++ b/product_docs/docs/pgd/5.6/testingandtuning.mdx @@ -33,7 +33,7 @@ The Postgres benchmarking application [`pgbench`](https://www.postgresql.org/docs/current/pgbench.html) was extended in PGD 5.0 in the form of a new application: pgd_bench. -[pgd_bench](/pgd/latest/reference/tables-views-functions/testingandtuning#pgd_bench) is a regular command-line utility that's added to the PostgreSQL bin +[pgd_bench](/pgd/latest/reference/testingandtuning#pgd_bench) is a regular command-line utility that's added to the PostgreSQL bin directory. The utility is based on the PostgreSQL pgbench tool but supports benchmarking CAMO transactions and PGD-specific workloads. diff --git a/product_docs/docs/pgd/5.6/transaction-streaming.mdx b/product_docs/docs/pgd/5.6/transaction-streaming.mdx index 6f202501e02..8e6e53288fa 100644 --- a/product_docs/docs/pgd/5.6/transaction-streaming.mdx +++ b/product_docs/docs/pgd/5.6/transaction-streaming.mdx @@ -56,8 +56,8 @@ processes on each subscriber. This capability is leveraged to provide the follow Configure transaction streaming in two locations: -- At node level, using the GUC [`bdr.default_streaming_mode`](/pgd/latest/reference/tables-views-functions/pgd-settings/#transaction-streaming) -- At group level, using the function [`bdr.alter_node_group_option()`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces/#bdralter_node_group_option) +- At node level, using the GUC [`bdr.default_streaming_mode`](/pgd/latest/reference/pgd-settings/#transaction-streaming) +- At group level, using the function [`bdr.alter_node_group_option()`](/pgd/latest/reference/nodes-management-interfaces/#bdralter_node_group_option) ### Node configuration using bdr.default_streaming_mode @@ -81,7 +81,7 @@ provided can also depend on the group configuration setting. See ### Group configuration using bdr.alter_node_group_option() -You can use the parameter `streaming_mode` in the function [`bdr.alter_node_group_option()`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces/#bdralter_node_group_option) +You can use the parameter `streaming_mode` in the function [`bdr.alter_node_group_option()`](/pgd/latest/reference/nodes-management-interfaces/#bdralter_node_group_option) to set the group transaction streaming configuration. Permitted values are: @@ -95,7 +95,7 @@ Permitted values are: The default value is `default`. The value of the current setting is contained in the column `node_group_streaming_mode` -from the view [`bdr.node_group`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrnode_group). The value returned is +from the view [`bdr.node_group`](/pgd/latest/reference/catalogs-visible/#bdrnode_group). The value returned is a single char type, and the possible values are `D` (`default`), `W` (`writer`), `F` (`file`), `A` (`auto`), and `O` (`off`). @@ -151,7 +151,7 @@ and can be safely handled by the writer. ## Monitoring -You can monitor the use of transaction streaming using the [`bdr.stat_subscription`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrstat_subscription) +You can monitor the use of transaction streaming using the [`bdr.stat_subscription`](/pgd/latest/reference/catalogs-visible/#bdrstat_subscription) function on the subscriber node. - `nstream_writer` — Number of transactions streamed to a writer. diff --git a/product_docs/docs/pgd/5.6/upgrades/compatibility.mdx b/product_docs/docs/pgd/5.6/upgrades/compatibility.mdx index bdb637b57bc..ac30086652a 100644 --- a/product_docs/docs/pgd/5.6/upgrades/compatibility.mdx +++ b/product_docs/docs/pgd/5.6/upgrades/compatibility.mdx @@ -66,6 +66,6 @@ Similarly to CAMO and Eager, Lag Control configuration was also moved to - `bdr.network_monitoring` view was removed along with underlying tables and functions. - Many catalogs were added and some have new columns, as described in - [Catalogs](/pgd/latest/reference/tables-views-functions/catalogs-visible/). These + [Catalogs](/pgd/latest/reference/catalogs-visible/). These aren't breaking changes strictly speaking, but we recommend reviewing them when upgrading. From 13b80b3b5ba492d13a8d54d619cb1c6c999e4b20 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 1 May 2025 11:09:23 +0100 Subject: [PATCH 034/145] Fix multiline in reference index Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/reference/tables-views-functions/index.mdx | 3 +-- .../docs/pgd/6/reference/tables-views-functions/index.mdx.src | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx index 7daee58fa9b..4267094f2c6 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx @@ -2,8 +2,7 @@ # edit index.mdx.src DO NOT edit index.mdx or index.json title: "Tables, views and functions reference" navTitle: "Tables, views and functions" -description: > - The complete reference to all tables, views, functions, views, and commands available in EDB Postgres Distributed. +description: "The complete reference to all tables, views, functions, views, and commands available in EDB Postgres Distributed." indexCards: none navigation: - catalogs-visible diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx.src b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx.src index 9755338d0a9..fb5cbaa416b 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx.src +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx.src @@ -2,8 +2,7 @@ # edit index.mdx.src DO NOT edit index.mdx or index.json title: "Tables, views and functions reference" navTitle: "Tables, views and functions" -description: > - The complete reference to all tables, views, functions, views, and commands available in EDB Postgres Distributed. +description: "The complete reference to all tables, views, functions, views, and commands available in EDB Postgres Distributed." indexCards: none navigation: - catalogs-visible From 9f07ae350dd5b703057a0186f62f7b910cd46b03 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 1 May 2025 11:27:59 +0100 Subject: [PATCH 035/145] Fix 5.6 tree /pgd/latest/ to /pgd/5.6/ Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/5.6/appusage/timing.mdx | 2 +- product_docs/docs/pgd/5.6/backup.mdx | 2 +- .../docs/pgd/5.6/cli/installing/index.mdx | 2 +- .../docs/pgd/5.6/commit-scopes/camo.mdx | 24 +-- .../5.6/commit-scopes/commit-scope-rules.mdx | 2 +- .../docs/pgd/5.6/commit-scopes/degrading.mdx | 2 +- .../pgd/5.6/commit-scopes/group-commit.mdx | 4 +- .../docs/pgd/5.6/commit-scopes/index.mdx | 6 +- .../pgd/5.6/commit-scopes/lag-control.mdx | 2 +- .../pgd/5.6/commit-scopes/limitations.mdx | 2 +- .../5.6/commit-scopes/synchronous_commit.mdx | 2 +- product_docs/docs/pgd/5.6/compatibility.mdx | 12 +- .../01_overview_clcd.mdx | 2 +- .../02_enabling_disabling.mdx | 4 +- .../column-level-conflicts/03_timestamps.mdx | 2 +- .../column-level-conflicts/index.mdx | 2 +- .../conflicts/00_conflicts_overview.mdx | 2 +- .../conflicts/02_types_of_conflict.mdx | 2 +- .../conflict-management/conflicts/index.mdx | 2 +- .../5.6/conflict-management/crdt/index.mdx | 2 +- .../pgd/5.6/conflict-management/index.mdx | 2 +- product_docs/docs/pgd/5.6/ddl/ddl-locking.mdx | 2 +- .../ddl/ddl-managing-with-pgd-replication.mdx | 12 +- .../docs/pgd/5.6/ddl/ddl-overview.mdx | 4 +- .../5.6/ddl/ddl-pgd-functions-like-ddl.mdx | 22 +- .../pgd/5.6/ddl/ddl-replication-options.mdx | 6 +- .../pgd/5.6/ddl/ddl-role-manipulation.mdx | 2 +- .../docs/pgd/5.6/ddl/ddl-workarounds.mdx | 2 +- product_docs/docs/pgd/5.6/decoding_worker.mdx | 10 +- .../deploy-cloudservice/index.mdx | 6 +- .../deploy-config/deploy-kubernetes/index.mdx | 4 +- .../deploying/01-provisioning-hosts.mdx | 4 +- .../deploying/02-install-postgres.mdx | 4 +- .../deploying/03-configuring-repositories.mdx | 6 +- .../deploying/04-installing-software.mdx | 4 +- .../deploying/05-creating-cluster.mdx | 18 +- .../deploying/06-check-cluster.mdx | 4 +- .../deploying/07-configure-proxies.mdx | 14 +- .../deploying/08-using-pgd-cli.mdx | 4 +- .../deploy-manual/deploying/index.mdx | 4 +- .../deploy-tpa/deploying/01-configuring.mdx | 4 +- .../deploy-tpa/deploying/02-deploying.mdx | 4 +- .../deploy-tpa/deploying/index.mdx | 16 +- .../5.6/deploy-config/deploy-tpa/index.mdx | 4 +- product_docs/docs/pgd/5.6/index.mdx | 4 +- product_docs/docs/pgd/5.6/known_issues.mdx | 4 +- product_docs/docs/pgd/5.6/monitoring/sql.mdx | 72 +++---- .../node_management/creating_and_joining.mdx | 12 +- .../5.6/node_management/creating_nodes.mdx | 4 +- .../heterogeneous_clusters.mdx | 2 +- .../maintainance_with_proxies.mdx | 4 +- .../pgd/5.6/node_management/node_recovery.mdx | 2 +- .../removing_nodes_and_groups.mdx | 6 +- .../5.6/node_management/replication_slots.mdx | 2 +- .../5.6/node_management/viewing_topology.mdx | 4 +- .../pgd/5.6/nodes/logical_standby_nodes.mdx | 6 +- .../5.6/nodes/subscriber_only/creating-so.mdx | 2 +- .../nodes/subscriber_only/optimizing-so.mdx | 2 +- product_docs/docs/pgd/5.6/parallelapply.mdx | 16 +- .../docs/pgd/5.6/planning/architectures.mdx | 10 +- .../docs/pgd/5.6/planning/choosing_server.mdx | 46 ++--- .../docs/pgd/5.6/planning/deployments.mdx | 2 +- .../docs/pgd/5.6/planning/limitations.mdx | 33 +-- .../pgd/5.6/planning/other_considerations.mdx | 6 +- .../pgd/5.6/quickstart/quick_start_aws.mdx | 6 +- .../pgd/5.6/quickstart/quick_start_cloud.mdx | 2 +- .../pgd/5.6/quickstart/quick_start_docker.mdx | 2 +- .../pgd/5.6/quickstart/quick_start_linux.mdx | 2 +- .../pgd/5.6/reference/catalogs-internal.mdx | 4 +- .../pgd/5.6/reference/catalogs-visible.mdx | 2 +- .../docs/pgd/5.6/reference/commit-scopes.mdx | 10 +- .../pgd/5.6/reference/functions-internal.mdx | 22 +- .../docs/pgd/5.6/reference/functions.mdx | 14 +- .../reference/nodes-management-interfaces.mdx | 2 +- .../docs/pgd/5.6/reference/pgd-settings.mdx | 6 +- .../pgd/5.6/rel_notes/pgd_5.4.0_rel_notes.mdx | 2 +- product_docs/docs/pgd/5.6/repsets.mdx | 10 +- .../docs/pgd/5.6/routing/administering.mdx | 2 +- .../docs/pgd/5.6/routing/configuration.mdx | 8 +- product_docs/docs/pgd/5.6/routing/index.mdx | 14 +- .../docs/pgd/5.6/routing/monitoring.mdx | 6 +- product_docs/docs/pgd/5.6/routing/proxy.mdx | 2 +- product_docs/docs/pgd/5.6/scaling.mdx | 16 +- .../pgd/5.6/security/pgd-predefined-roles.mdx | 190 +++++++++--------- .../docs/pgd/5.6/security/role-management.mdx | 6 +- product_docs/docs/pgd/5.6/security/roles.mdx | 6 +- product_docs/docs/pgd/5.6/sequences.mdx | 6 +- .../docs/pgd/5.6/testingandtuning.mdx | 2 +- .../docs/pgd/5.6/transaction-streaming.mdx | 10 +- .../docs/pgd/5.6/upgrades/compatibility.mdx | 2 +- .../5.6/upgrades/upgrading_major_rolling.mdx | 6 +- product_docs/docs/pgd/6/known_issues.mdx | 4 +- 92 files changed, 410 insertions(+), 435 deletions(-) diff --git a/product_docs/docs/pgd/5.6/appusage/timing.mdx b/product_docs/docs/pgd/5.6/appusage/timing.mdx index 62300ef3c8f..6515d73a0df 100644 --- a/product_docs/docs/pgd/5.6/appusage/timing.mdx +++ b/product_docs/docs/pgd/5.6/appusage/timing.mdx @@ -8,7 +8,7 @@ possible for a client connected to multiple PGD nodes or switching between them to read stale data. A [queue wait -function](/pgd/latest/reference/functions/#bdrwait_for_apply_queue) is provided +function](/pgd/5.6/reference/functions/#bdrwait_for_apply_queue) is provided for clients or proxies to prevent such stale reads. The synchronous replication features of Postgres are available to PGD as well. diff --git a/product_docs/docs/pgd/5.6/backup.mdx b/product_docs/docs/pgd/5.6/backup.mdx index 60af885fca3..3c20928da55 100644 --- a/product_docs/docs/pgd/5.6/backup.mdx +++ b/product_docs/docs/pgd/5.6/backup.mdx @@ -233,7 +233,7 @@ of a single PGD node, optionally plus WAL archives: To clean up leftover PGD metadata: -1. Drop the PGD node using [`bdr.drop_node`](/pgd/latest/reference/functions-internal#bdrdrop_node). +1. Drop the PGD node using [`bdr.drop_node`](/pgd/5.6/reference/functions-internal#bdrdrop_node). 2. Fully stop and restart PostgreSQL (important!). #### Cleanup of replication origins diff --git a/product_docs/docs/pgd/5.6/cli/installing/index.mdx b/product_docs/docs/pgd/5.6/cli/installing/index.mdx index af78ef30dde..9fa0b2fd3db 100644 --- a/product_docs/docs/pgd/5.6/cli/installing/index.mdx +++ b/product_docs/docs/pgd/5.6/cli/installing/index.mdx @@ -2,7 +2,7 @@ title: "Installing PGD CLI" navTitle: "Installing PGD CLI" redirects: - - /pgd/latest/cli/installing_cli + - /pgd/5.6/cli/installing_cli deepToC: true indexCards: simple description: Installing the PGD CLI on various systems. diff --git a/product_docs/docs/pgd/5.6/commit-scopes/camo.mdx b/product_docs/docs/pgd/5.6/commit-scopes/camo.mdx index 63db329783b..346d39e6870 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/camo.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/camo.mdx @@ -2,7 +2,7 @@ title: Commit At Most Once navTitle: Commit At Most Once redirects: - - /pgd/latest/bdr/camo/ + - /pgd/5.6/bdr/camo/ --- Commit scope kind: `CAMO` @@ -43,7 +43,7 @@ To use CAMO, an application must issue an explicit `COMMIT` message as a separat ## Configuration -See the[`CAMO`](/pgd/latest/reference/commit-scopes/#camo) commit scope reference for configuration parameters. +See the[`CAMO`](/pgd/5.6/reference/commit-scopes/#camo) commit scope reference for configuration parameters. ## Confirmation @@ -76,7 +76,7 @@ When the `DEGRADE ON ... TO ASYNC` clause is used in the commit scope, a node de This doesn't allow COMMIT status to be retrieved, but it does let you choose availability over consistency. This mode can tolerate a single-node failure. In case both nodes of a CAMO pair fail, they might choose incongruent commit decisions to maintain availability, leading to data inconsistencies. -For a CAMO partner to switch to ready, it needs to be connected, and the estimated catchup interval needs to drop below the `timeout` value of `TO ASYNC`. You can check the current readiness status of a CAMO partner with [`bdr.is_camo_partner_ready()`](/pgd/latest/reference/functions#bdris_camo_partner_ready), while [`bdr.node_replication_rates`](/pgd/latest/reference/catalogs-visible#bdrnode_replication_rates) provides the current estimate of the catchup time. +For a CAMO partner to switch to ready, it needs to be connected, and the estimated catchup interval needs to drop below the `timeout` value of `TO ASYNC`. You can check the current readiness status of a CAMO partner with [`bdr.is_camo_partner_ready()`](/pgd/5.6/reference/functions#bdris_camo_partner_ready), while [`bdr.node_replication_rates`](/pgd/5.6/reference/catalogs-visible#bdrnode_replication_rates) provides the current estimate of the catchup time. The switch from CAMO-protected to asynchronous mode is only ever triggered by an actual CAMO transaction. This is true either because the commit exceeds the `timeout` value of `TO ASYNC` or, in case the CAMO partner is already known, disconnected at the time of commit. This switch is independent of the estimated catchup interval. If the CAMO pair is configured to require the current node to be the write lead of a group as configured through the `enable_proxy_routing` node group option. See [Commit scopes](commit-scopes) for syntax. This can prevent a split brain situation due to an isolated node from switching to asynchronous mode. If `enable_proxy_routing` isn't set for the CAMO group, the origin node switches to asynchronous mode immediately. @@ -85,7 +85,7 @@ The switch from asynchronous mode to CAMO mode depends on the CAMO partner node, the CAMO partner further delays the switch back to CAMO protected mode. Unlike during normal CAMO operation, in asynchronous mode there's no added commit overhead. This can be problematic, as it allows the node to continuously process more transactions than the CAMO pair can normally process. Even if the CAMO partner eventually reconnects and applies transactions, its lag only ever increases -in such a situation, preventing reestablishing the CAMO protection. To artificially throttle transactional throughput, PGD provides the [`bdr.camo_local_mode_delay`](/pgd/latest/reference/pgd-settings#bdrcamo_local_mode_delay) setting, which allows you to delay a `COMMIT` in local mode by an arbitrary amount of time. We recommend measuring commit times in normal CAMO mode during expected workloads and configuring this delay accordingly. The default is 5 ms, which reflects a asynchronous network and a relatively quick CAMO partner response. +in such a situation, preventing reestablishing the CAMO protection. To artificially throttle transactional throughput, PGD provides the [`bdr.camo_local_mode_delay`](/pgd/5.6/reference/pgd-settings#bdrcamo_local_mode_delay) setting, which allows you to delay a `COMMIT` in local mode by an arbitrary amount of time. We recommend measuring commit times in normal CAMO mode during expected workloads and configuring this delay accordingly. The default is 5 ms, which reflects a asynchronous network and a relatively quick CAMO partner response. Consider the choice of whether to allow asynchronous mode in view of the architecture and the availability requirements. The following examples provide some detail. @@ -184,7 +184,7 @@ If it was a bad connection, then you can check on the CAMO partner node to see i If you can't connect to the partner node, there's not a lot you can do. In this case, panic, or take similar actions. -But if you can connect, you can use [`bdr.logical_transaction_status()`](/pgd/latest/reference/functions#bdrlogical_transaction_status) to find out how the transaction did. The code recorded the required values, node_id and xid (the transaction id), just before committing the transaction. +But if you can connect, you can use [`bdr.logical_transaction_status()`](/pgd/5.6/reference/functions#bdrlogical_transaction_status) to find out how the transaction did. The code recorded the required values, node_id and xid (the transaction id), just before committing the transaction. ``` sql = "SELECT bdr.logical_transaction_status($node_id, $xid)"; @@ -224,24 +224,24 @@ must have at least the [bdr_application](../security/pgd-predefined-roles/#bdr_a role assigned to them. !!! -The function [`bdr.is_camo_partner_connected()`](/pgd/latest/reference/functions#bdris_camo_partner_connected) allows checking the connection status of a CAMO partner node configured in pair mode. There currently is no equivalent for CAMO used with Eager Replication. +The function [`bdr.is_camo_partner_connected()`](/pgd/5.6/reference/functions#bdris_camo_partner_connected) allows checking the connection status of a CAMO partner node configured in pair mode. There currently is no equivalent for CAMO used with Eager Replication. -To check that the CAMO partner is ready, use the function [`bdr.is_camo_partner_ready`](/pgd/latest/reference/functions#bdris_camo_partner_ready). Underneath, this triggers the switch to and from local mode. +To check that the CAMO partner is ready, use the function [`bdr.is_camo_partner_ready`](/pgd/5.6/reference/functions#bdris_camo_partner_ready). Underneath, this triggers the switch to and from local mode. -To find out more about the configured CAMO partner, use [`bdr.get_configured_camo_partner()`](/pgd/latest/reference/functions#bdrget_configured_camo_partner). This function returns the local node's CAMO partner. +To find out more about the configured CAMO partner, use [`bdr.get_configured_camo_partner()`](/pgd/5.6/reference/functions#bdrget_configured_camo_partner). This function returns the local node's CAMO partner. You can wait on the CAMO partner to process the queue with the function -[`bdr.wait_for_camo_partner_queue()`](/pgd/latest/reference/functions#bdrwait_for_camo_partner_queue). +[`bdr.wait_for_camo_partner_queue()`](/pgd/5.6/reference/functions#bdrwait_for_camo_partner_queue). This function is a wrapper of -[`bdr.wait_for_apply_queue`](/pgd/latest/reference/functions#bdrwait_for_apply_queue). +[`bdr.wait_for_apply_queue`](/pgd/5.6/reference/functions#bdrwait_for_apply_queue). The difference is that -[`bdr.wait_for_camo_partner_queue()`](/pgd/latest/reference/functions#bdrwait_for_camo_partner_queue) +[`bdr.wait_for_camo_partner_queue()`](/pgd/5.6/reference/functions#bdrwait_for_camo_partner_queue) defaults to querying the CAMO partner node. It returns an error if the local node isn't part of a CAMO pair. To check the status of a transaction that was being committed when the node failed, the application must use the function -[`bdr.logical_transaction_status()`](/pgd/latest/reference/functions#bdrlogical_transaction_status). +[`bdr.logical_transaction_status()`](/pgd/5.6/reference/functions#bdrlogical_transaction_status). You pass this function the the node_id and transaction_id of the transaction you want to check on. With CAMO used in pair mode, you can use this function only on a node that's part of a CAMO pair. Along with Eager Replication, you can use it on all nodes. diff --git a/product_docs/docs/pgd/5.6/commit-scopes/commit-scope-rules.mdx b/product_docs/docs/pgd/5.6/commit-scopes/commit-scope-rules.mdx index e636ae25fbd..d3a88f7fd69 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/commit-scope-rules.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/commit-scope-rules.mdx @@ -12,7 +12,7 @@ Each operation is made up of two or three parts: the commit scope group, an opti commit_scope_group [ confirmation_level ] commit_scope_kind ``` -A full formal syntax diagram is available in the [Commit scopes](/pgd/latest/reference/commit-scopes/#commit-scope-syntax) reference. +A full formal syntax diagram is available in the [Commit scopes](/pgd/5.6/reference/commit-scopes/#commit-scope-syntax) reference. A typical commit scope rule, such as `ANY 2 (group) GROUP COMMIT`, can be broken down into its components. `ANY 2 (group)` is the commit scope group specifying, for the rule, which nodes need to respond and confirm they processed the transaction. In this example, any two nodes from the named group must confirm. diff --git a/product_docs/docs/pgd/5.6/commit-scopes/degrading.mdx b/product_docs/docs/pgd/5.6/commit-scopes/degrading.mdx index 0c3980b09fc..3bdd2812ba5 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/degrading.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/degrading.mdx @@ -22,7 +22,7 @@ Once during the commit, while the commit being processed is waiting for response This mechanism alone is insufficient for the intended behavior, as this alone would mean that every transaction—even those that were certain to degrade due to connectivity issues—must wait for the timeout to expire before degraded mode kicks in, which would severely affect performance in such degrading-cluster scenarios. -To avoid this, the PGD manager process also periodically (every 5s) checks the connectivity and apply rate (the one in [bdr.node_replication_rates](/pgd/latest/reference/catalogs-visible/#bdrnode_replication_rates)) and if there are commit scopes that would degrade at that point based on the current state of replication, they will be automatically degraded—such that any transaction using that commit scope when processing after that uses the degraded rule instead of waiting for timeout—until the manager process detects that replication is moving swiftly enough again. +To avoid this, the PGD manager process also periodically (every 5s) checks the connectivity and apply rate (the one in [bdr.node_replication_rates](/pgd/5.6/reference/catalogs-visible/#bdrnode_replication_rates)) and if there are commit scopes that would degrade at that point based on the current state of replication, they will be automatically degraded—such that any transaction using that commit scope when processing after that uses the degraded rule instead of waiting for timeout—until the manager process detects that replication is moving swiftly enough again. ## SYNCHRONOUS COMMIT and GROUP COMMIT diff --git a/product_docs/docs/pgd/5.6/commit-scopes/group-commit.mdx b/product_docs/docs/pgd/5.6/commit-scopes/group-commit.mdx index 470ba63294e..380c3fc083c 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/group-commit.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/group-commit.mdx @@ -1,7 +1,7 @@ --- title: Group Commit redirects: - - /pgd/latest/bdr/group-commit/ + - /pgd/5.6/bdr/group-commit/ deepToC: true --- @@ -58,7 +58,7 @@ See the Group Commit section of [Limitations](limitations#group-commit). ## Configuration -`GROUP_COMMIT` supports optional `GROUP COMMIT` parameters, as well as `ABORT ON` and `DEGRADE ON` clauses. For a full description of configuration parameters, see the [GROUP_COMMIT](/pgd/latest/reference/commit-scopes/#group-commit) commit scope reference or for more regarding `DEGRADE ON` options in general, see the [Degrade options](degrading) section. +`GROUP_COMMIT` supports optional `GROUP COMMIT` parameters, as well as `ABORT ON` and `DEGRADE ON` clauses. For a full description of configuration parameters, see the [GROUP_COMMIT](/pgd/5.6/reference/commit-scopes/#group-commit) commit scope reference or for more regarding `DEGRADE ON` options in general, see the [Degrade options](degrading) section. ## Confirmation diff --git a/product_docs/docs/pgd/5.6/commit-scopes/index.mdx b/product_docs/docs/pgd/5.6/commit-scopes/index.mdx index 7c7710869d0..680018df663 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/index.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/index.mdx @@ -20,9 +20,9 @@ navigation: - limitations description: Durability options, commit scopes, and lag control in PGD. redirects: - - /pgd/latest/bdr/durability/ - - /pgd/latest/choosing_durability/ - - /pgd/latest/durability/ + - /pgd/5.6/bdr/durability/ + - /pgd/5.6/choosing_durability/ + - /pgd/5.6/durability/ --- EDB Postgres Distributed (PGD) offers a range of synchronous modes to complement its diff --git a/product_docs/docs/pgd/5.6/commit-scopes/lag-control.mdx b/product_docs/docs/pgd/5.6/commit-scopes/lag-control.mdx index 8bfad64a166..8983b9a493b 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/lag-control.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/lag-control.mdx @@ -1,7 +1,7 @@ --- title: Lag Control redirects: - - /pgd/latest/bdr/lag-control/ + - /pgd/5.6/bdr/lag-control/ --- Commit scope kind: `LAG CONTROL` diff --git a/product_docs/docs/pgd/5.6/commit-scopes/limitations.mdx b/product_docs/docs/pgd/5.6/commit-scopes/limitations.mdx index a67b71db097..b52470f084b 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/limitations.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/limitations.mdx @@ -43,7 +43,7 @@ nodes in a group. If you use this feature, take the following limitations into a ## Eager -[Eager](/pgd/latest/commit-scopes/group-commit/#eager-conflict-resolution) is available through Group Commit. It avoids conflicts by eagerly aborting transactions that might clash. It's subject to the same limitations as Group Commit. +[Eager](/pgd/5.6/commit-scopes/group-commit/#eager-conflict-resolution) is available through Group Commit. It avoids conflicts by eagerly aborting transactions that might clash. It's subject to the same limitations as Group Commit. Eager doesn't allow the `NOTIFY` SQL command or the `pg_notify()` function. It also doesn't allow `LISTEN` or `UNLISTEN`. diff --git a/product_docs/docs/pgd/5.6/commit-scopes/synchronous_commit.mdx b/product_docs/docs/pgd/5.6/commit-scopes/synchronous_commit.mdx index 668c0a13808..70e8067cb34 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/synchronous_commit.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/synchronous_commit.mdx @@ -26,7 +26,7 @@ SELECT bdr.create_commit_scope( ## Configuration -`SYNCHRONOUS COMMIT` supports the optional `DEGRADE ON` clause. See the [`SYNCHRONOUS COMMIT`](/pgd/latest/reference/commit-scopes/#synchronous-commit) commit scope reference for specific configuration parameters or see [this section](degrading) regarding Degrade on options. +`SYNCHRONOUS COMMIT` supports the optional `DEGRADE ON` clause. See the [`SYNCHRONOUS COMMIT`](/pgd/5.6/reference/commit-scopes/#synchronous-commit) commit scope reference for specific configuration parameters or see [this section](degrading) regarding Degrade on options. ## Confirmation diff --git a/product_docs/docs/pgd/5.6/compatibility.mdx b/product_docs/docs/pgd/5.6/compatibility.mdx index 14cd8df9c61..e1d72fc538a 100644 --- a/product_docs/docs/pgd/5.6/compatibility.mdx +++ b/product_docs/docs/pgd/5.6/compatibility.mdx @@ -11,12 +11,12 @@ The following table shows the major versions of PostgreSQL and each version of E | Postgres Version | PGD 5 | PGD 4 | |----------------------|------------------------|--------------| -| 17 | [5.6.1+](/pgd/latest/) | | -| 16 | [5.3+](/pgd/latest/) | | -| 15 | [5](/pgd/latest/) | | -| 14 | [5](/pgd/latest/) | [4](/pgd/4/) | -| 13 | [5](/pgd/latest/) | [4](/pgd/4/) | -| 12 | [5](/pgd/latest/) | [4](/pgd/4/) | +| 17 | [5.6.1+](/pgd/5.6/) | | +| 16 | [5.3+](/pgd/5.6/) | | +| 15 | [5](/pgd/5.6/) | | +| 14 | [5](/pgd/5.6/) | [4](/pgd/4/) | +| 13 | [5](/pgd/5.6/) | [4](/pgd/4/) | +| 12 | [5](/pgd/5.6/) | [4](/pgd/4/) | diff --git a/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/01_overview_clcd.mdx b/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/01_overview_clcd.mdx index 0c810550011..63e91e284ca 100644 --- a/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/01_overview_clcd.mdx +++ b/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/01_overview_clcd.mdx @@ -35,7 +35,7 @@ Applied to the previous example, the result is `(100,100)` on both nodes, despit When thinking about column-level conflict resolution, it can be useful to see tables as vertically partitioned, so that each update affects data in only one slice. This approach eliminates conflicts between changes to different subsets of columns. In fact, vertical partitioning can even be a practical alternative to column-level conflict resolution. -Column-level conflict resolution requires the table to have `REPLICA IDENTITY FULL`. The [bdr.alter_table_conflict_detection()](https://www.enterprisedb.com/docs/pgd/latest/reference/conflict_functions#bdralter_table_conflict_detection) function checks that and fails with an error if this setting is missing. +Column-level conflict resolution requires the table to have `REPLICA IDENTITY FULL`. The [bdr.alter_table_conflict_detection()](https://www.enterprisedb.com/docs/pgd/5.6/reference/conflict_functions#bdralter_table_conflict_detection) function checks that and fails with an error if this setting is missing. ## Special problems for column-level conflict resolution diff --git a/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/02_enabling_disabling.mdx b/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/02_enabling_disabling.mdx index a145d1d67a7..6f5d5eeae27 100644 --- a/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/02_enabling_disabling.mdx +++ b/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/02_enabling_disabling.mdx @@ -8,11 +8,11 @@ deepToC: true Column-level conflict detection uses the `column_timestamps` type. This type requires any user needing to detect column-level conflicts to have at least the [bdr_application](../../security/pgd-predefined-roles/#bdr_application) role assigned. !!! -The [bdr.alter_table_conflict_detection()](https://www.enterprisedb.com/docs/pgd/latest/reference/conflict_functions/#bdralter_table_conflict_detection) function manages column-level conflict resolution. +The [bdr.alter_table_conflict_detection()](https://www.enterprisedb.com/docs/pgd/5.6/reference/conflict_functions/#bdralter_table_conflict_detection) function manages column-level conflict resolution. ## Using bdr.alter_table_conflict_detection to enable column-level conflict resolution -The [bdr.alter_table_conflict_detection](https://www.enterprisedb.com/docs/pgd/latest/reference/conflict_functions/#bdralter_table_conflict_detection) function takes a table name and column name as its arguments. The column is added to the table as a `column_modify_timestamp` column. The function also adds two triggers (BEFORE INSERT and BEFORE UPDATE) that are responsible for maintaining timestamps in the new column before each change. +The [bdr.alter_table_conflict_detection](https://www.enterprisedb.com/docs/pgd/5.6/reference/conflict_functions/#bdralter_table_conflict_detection) function takes a table name and column name as its arguments. The column is added to the table as a `column_modify_timestamp` column. The function also adds two triggers (BEFORE INSERT and BEFORE UPDATE) that are responsible for maintaining timestamps in the new column before each change. ```sql db=# CREATE TABLE my_app.test_table (id SERIAL PRIMARY KEY, val INT); diff --git a/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/03_timestamps.mdx b/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/03_timestamps.mdx index 1e20d619aad..30803a62804 100644 --- a/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/03_timestamps.mdx +++ b/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/03_timestamps.mdx @@ -21,7 +21,7 @@ This approach is simple and, for many cases, it's correct, for example, when the For example, if an `UPDATE` affects multiple rows, the clock continues ticking while the `UPDATE` runs. So each row gets a slightly different timestamp, even if they're being modified concurrently by the one `UPDATE`. This behavior, in turn, means that the effects of concurrent changes might get "mixed" in various ways, depending on how the changes performed on different nodes interleaves. -Another possible issue is clock skew. When the clocks on different nodes drift, the timestamps generated by those nodes also drift. This clock skew can induce unexpected behavior such as newer changes being discarded because the timestamps are apparently switched around. However, you can manage clock skew between nodes using the parameters [bdr.maximum_clock_skew](/pgd/latest/reference/pgd-settings/#bdrmaximum_clock_skew) and [bdr.maximum_clock_skew_action](/pgd/latest/reference/pgd-settings/#bdrmaximum_clock_skew_action). +Another possible issue is clock skew. When the clocks on different nodes drift, the timestamps generated by those nodes also drift. This clock skew can induce unexpected behavior such as newer changes being discarded because the timestamps are apparently switched around. However, you can manage clock skew between nodes using the parameters [bdr.maximum_clock_skew](/pgd/5.6/reference/pgd-settings/#bdrmaximum_clock_skew) and [bdr.maximum_clock_skew_action](/pgd/5.6/reference/pgd-settings/#bdrmaximum_clock_skew_action). As the current timestamp is unrelated to the commit timestamp, using it to resolve conflicts means that the result isn't equivalent to the commit order, which means it probably can't be serialized. diff --git a/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/index.mdx b/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/index.mdx index 5d379171bae..e178877bd1f 100644 --- a/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/index.mdx +++ b/product_docs/docs/pgd/5.6/conflict-management/column-level-conflicts/index.mdx @@ -2,7 +2,7 @@ navTitle: Column-level conflict resolution title: Column-level conflict detection redirects: - - /pgd/latest/bdr/column-level-conflicts/ + - /pgd/5.6/bdr/column-level-conflicts/ --- By default, conflicts are resolved at row level. When changes from two nodes conflict, either the local or remote tuple is selected and the other is discarded. For example, commit timestamps for the two conflicting changes might be compared and the newer one kept. This approach ensures that all nodes converge to the same result and establishes commit-order-like semantics on the whole cluster. diff --git a/product_docs/docs/pgd/5.6/conflict-management/conflicts/00_conflicts_overview.mdx b/product_docs/docs/pgd/5.6/conflict-management/conflicts/00_conflicts_overview.mdx index da19837bec6..167f2f5dcfb 100644 --- a/product_docs/docs/pgd/5.6/conflict-management/conflicts/00_conflicts_overview.mdx +++ b/product_docs/docs/pgd/5.6/conflict-management/conflicts/00_conflicts_overview.mdx @@ -15,7 +15,7 @@ Conflict handling is configurable, as described in [Conflict resolution](04_conf Column-level conflict detection and resolution is available with PGD, as described in [CLCD](../column-level-conflicts). -By default, all conflicts are logged to [`bdr.conflict_history`](/pgd/latest/reference/catalogs-visible/#bdrconflict_history). If conflicts are possible, then table owners must monitor for them and analyze how to avoid them or make plans to handle them regularly as an application task. The [LiveCompare](/livecompare/latest) tool is also available to scan regularly for divergence. +By default, all conflicts are logged to [`bdr.conflict_history`](/pgd/5.6/reference/catalogs-visible/#bdrconflict_history). If conflicts are possible, then table owners must monitor for them and analyze how to avoid them or make plans to handle them regularly as an application task. The [LiveCompare](/livecompare/latest) tool is also available to scan regularly for divergence. Some clustering systems use distributed lock mechanisms to prevent concurrent access to data. These can perform reasonably when servers are very close to each other but can't support geographically distributed applications where very low latency is critical for acceptable performance. diff --git a/product_docs/docs/pgd/5.6/conflict-management/conflicts/02_types_of_conflict.mdx b/product_docs/docs/pgd/5.6/conflict-management/conflicts/02_types_of_conflict.mdx index d9f1cca3255..cb6b2a10d3e 100644 --- a/product_docs/docs/pgd/5.6/conflict-management/conflicts/02_types_of_conflict.mdx +++ b/product_docs/docs/pgd/5.6/conflict-management/conflicts/02_types_of_conflict.mdx @@ -50,7 +50,7 @@ The deletion tries to preserve the row with the correct `PRIMARY KEY` and delete In case of multiple rows conflicting this way, if the result of conflict resolution is to proceed with the insert operation, some of the data is always deleted. !!! -You can also define a different behavior using a [conflict trigger](/pgd/latest/striggers/#conflict-triggers). +You can also define a different behavior using a [conflict trigger](/pgd/5.6/striggers/#conflict-triggers). ### UPDATE/UPDATE conflicts diff --git a/product_docs/docs/pgd/5.6/conflict-management/conflicts/index.mdx b/product_docs/docs/pgd/5.6/conflict-management/conflicts/index.mdx index 85a6b5ec93e..1df20df56b4 100644 --- a/product_docs/docs/pgd/5.6/conflict-management/conflicts/index.mdx +++ b/product_docs/docs/pgd/5.6/conflict-management/conflicts/index.mdx @@ -1,7 +1,7 @@ --- title: Conflicts redirects: - - /pgd/latest/bdr/conflicts/ + - /pgd/5.6/bdr/conflicts/ --- EDB Postgres Distributed is an active/active or multi-master DBMS. If used asynchronously, writes to the same or related rows from multiple different nodes can result in data conflicts when using standard data types. diff --git a/product_docs/docs/pgd/5.6/conflict-management/crdt/index.mdx b/product_docs/docs/pgd/5.6/conflict-management/crdt/index.mdx index 70292e7018c..157875552f0 100644 --- a/product_docs/docs/pgd/5.6/conflict-management/crdt/index.mdx +++ b/product_docs/docs/pgd/5.6/conflict-management/crdt/index.mdx @@ -2,7 +2,7 @@ navTitle: CRDTs title: Conflict-free replicated data types redirects: - - /pgd/latest/bdr/crdt/ + - /pgd/5.6/bdr/crdt/ --- Conflict-free replicated data types (CRDTs) support merging values from concurrently modified rows instead of discarding one of the rows as the traditional resolution does. diff --git a/product_docs/docs/pgd/5.6/conflict-management/index.mdx b/product_docs/docs/pgd/5.6/conflict-management/index.mdx index 3d337bf87a2..0c67162687b 100644 --- a/product_docs/docs/pgd/5.6/conflict-management/index.mdx +++ b/product_docs/docs/pgd/5.6/conflict-management/index.mdx @@ -18,4 +18,4 @@ By default, conflicts are resolved at the row level. When changes from two nodes Column-level conflict detection and resolution is available with PGD, described in [CLCD](column-level-conflicts). -If you want to avoid conflicts, you can use [Group Commit](/pgd/latest/commit-scopes/group-commit/) with [Eager conflict resolution](/pgd/latest/commit-scopes/group-commit/#eager-conflict-resolution) or conflict-free data types (CRDTs), described in [CRDT](crdt). You can also use PGD Proxy and route all writes to one write-leader, eliminating the chance for inter-nodal conflicts. +If you want to avoid conflicts, you can use [Group Commit](/pgd/5.6/commit-scopes/group-commit/) with [Eager conflict resolution](/pgd/5.6/commit-scopes/group-commit/#eager-conflict-resolution) or conflict-free data types (CRDTs), described in [CRDT](crdt). You can also use PGD Proxy and route all writes to one write-leader, eliminating the chance for inter-nodal conflicts. diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-locking.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-locking.mdx index d44fc6b9985..c3daeca5d39 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-locking.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-locking.mdx @@ -73,7 +73,7 @@ Witness and subscriber-only nodes aren't eligible to participate. If a DDL statement isn't replicated, no global locks are acquired. -Specify locking behavior with the [`bdr.ddl_locking`](/pgd/latest/reference/pgd-settings#bdrddl_locking) parameter, as +Specify locking behavior with the [`bdr.ddl_locking`](/pgd/5.6/reference/pgd-settings#bdrddl_locking) parameter, as explained in [Executing DDL on PGD systems](ddl-overview#executing-ddl-on-pgd-systems): - `ddl_locking = all` takes global DDL lock and, if needed, takes relation DML lock. diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-managing-with-pgd-replication.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-managing-with-pgd-replication.mdx index c1fe779c19e..0d66318dce8 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-managing-with-pgd-replication.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-managing-with-pgd-replication.mdx @@ -32,7 +32,7 @@ SELECT bdr.run_on_all_nodes($ddl$ $ddl$); ``` -We recommend using the [`bdr.run_on_all_nodes()`](/pgd/latest/reference/functions#bdrrun_on_all_nodes) technique with `CREATE +We recommend using the [`bdr.run_on_all_nodes()`](/pgd/5.6/reference/functions#bdrrun_on_all_nodes) technique with `CREATE INDEX CONCURRENTLY`, noting that DDL replication must be disabled for the whole session because `CREATE INDEX CONCURRENTLY` is a multi-transaction command. Avoid `CREATE INDEX` on production systems @@ -60,10 +60,10 @@ cancel the DDL on the originating node with **Control-C** in psql or with `pg_ca You can't cancel a DDL lock from any other node. You can control how long the global lock takes with optional global locking -timeout settings. [`bdr.global_lock_timeout`](/pgd/latest/reference/pgd-settings#bdrglobal_lock_timeout) limits how long the wait for +timeout settings. [`bdr.global_lock_timeout`](/pgd/5.6/reference/pgd-settings#bdrglobal_lock_timeout) limits how long the wait for acquiring the global lock can take before it's canceled. -[`bdr.global_lock_statement_timeout`](/pgd/latest/reference/pgd-settings#bdrglobal_lock_statement_timeout) limits the runtime length of any statement -in transaction that holds global locks, and [`bdr.global_lock_idle_timeout`](/pgd/latest/reference/pgd-settings#bdrglobal_lock_idle_timeout) sets +[`bdr.global_lock_statement_timeout`](/pgd/5.6/reference/pgd-settings#bdrglobal_lock_statement_timeout) limits the runtime length of any statement +in transaction that holds global locks, and [`bdr.global_lock_idle_timeout`](/pgd/5.6/reference/pgd-settings#bdrglobal_lock_idle_timeout) sets the maximum allowed idle time (time between statements) for a transaction holding any global locks. You can disable all of these timeouts by setting their values to zero. @@ -84,7 +84,7 @@ locks that it holds. If it stays down for a long time or indefinitely, remove the node from the PGD group to release the global locks. This is one reason for executing emergency DDL using the `SET` command as -the bdr_superuser to update the [`bdr.ddl_locking`](/pgd/latest/reference/pgd-settings#bdrddl_locking) value. +the bdr_superuser to update the [`bdr.ddl_locking`](/pgd/5.6/reference/pgd-settings#bdrddl_locking) value. If one of the other nodes goes down after it confirmed the global lock but before the command acquiring it executed, the execution of @@ -102,7 +102,7 @@ command continues normally, and the lock is released. Not all commands can be replicated automatically. Such commands are generally disallowed, unless DDL replication is turned off -by turning [`bdr.ddl_replication`](/pgd/latest/reference/pgd-settings#bdrddl_replication) off. +by turning [`bdr.ddl_replication`](/pgd/5.6/reference/pgd-settings#bdrddl_replication) off. PGD prevents some DDL statements from running when it's active on a database. This protects the consistency of the system by disallowing diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-overview.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-overview.mdx index aec5291d0ed..b51aa1dfb4e 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-overview.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-overview.mdx @@ -71,7 +71,7 @@ it a useful option when creating a new and empty database schema. These options can be set only by the bdr_superuser, by the superuser, or in the `postgres.conf` configuration file. -When using the [`bdr.replicate_ddl_command`](/pgd/latest/reference/functions#bdrreplicate_ddl_command), you can set this +When using the [`bdr.replicate_ddl_command`](/pgd/5.6/reference/functions#bdrreplicate_ddl_command), you can set this parameter directly with the third argument, using the specified -[`bdr.ddl_locking`](/pgd/latest/reference/pgd-settings#bdrddl_locking) setting only for the DDL commands passed to that +[`bdr.ddl_locking`](/pgd/5.6/reference/pgd-settings#bdrddl_locking) setting only for the DDL commands passed to that function. diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-pgd-functions-like-ddl.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-pgd-functions-like-ddl.mdx index 0f9aa5d00e3..d4f8aa46393 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-pgd-functions-like-ddl.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-pgd-functions-like-ddl.mdx @@ -10,13 +10,13 @@ information, see the documentation for the individual functions. Replication set management: -- [`bdr.create_replication_set`](/pgd/latest/reference/repsets-management#bdrcreate_replication_set) -- [`bdr.alter_replication_set`](/pgd/latest/reference/repsets-management#bdralter_replication_set) -- [`bdr.drop_replication_set`](/pgd/latest/reference/repsets-management#bdrdrop_replication_set) -- [`bdr.replication_set_add_table`](/pgd/latest/reference/repsets-membership#bdrreplication_set_add_table) -- [`bdr.replication_set_remove_table`](/pgd/latest/reference/repsets-membership#bdrreplication_set_remove_table) -- [`bdr.replication_set_add_ddl_filter`](/pgd/latest/reference/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter) -- [`bdr.replication_set_remove_ddl_filter`](/pgd/latest/reference/repsets-ddl-filtering#bdrreplication_set_remove_ddl_filter) +- [`bdr.create_replication_set`](/pgd/5.6/reference/repsets-management#bdrcreate_replication_set) +- [`bdr.alter_replication_set`](/pgd/5.6/reference/repsets-management#bdralter_replication_set) +- [`bdr.drop_replication_set`](/pgd/5.6/reference/repsets-management#bdrdrop_replication_set) +- [`bdr.replication_set_add_table`](/pgd/5.6/reference/repsets-membership#bdrreplication_set_add_table) +- [`bdr.replication_set_remove_table`](/pgd/5.6/reference/repsets-membership#bdrreplication_set_remove_table) +- [`bdr.replication_set_add_ddl_filter`](/pgd/5.6/reference/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter) +- [`bdr.replication_set_remove_ddl_filter`](/pgd/5.6/reference/repsets-ddl-filtering#bdrreplication_set_remove_ddl_filter) Conflict management: @@ -26,10 +26,10 @@ Conflict management: Sequence management: -- [`bdr.alter_sequence_set_kind`](/pgd/latest/reference/sequences#bdralter_sequence_set_kind) +- [`bdr.alter_sequence_set_kind`](/pgd/5.6/reference/sequences#bdralter_sequence_set_kind) Stream triggers: -- [`bdr.create_conflict_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrcreate_conflict_trigger) -- [`bdr.create_transform_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrcreate_transform_trigger) -- [`bdr.drop_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrdrop_trigger) +- [`bdr.create_conflict_trigger`](/pgd/5.6/reference/streamtriggers/interfaces#bdrcreate_conflict_trigger) +- [`bdr.create_transform_trigger`](/pgd/5.6/reference/streamtriggers/interfaces#bdrcreate_transform_trigger) +- [`bdr.drop_trigger`](/pgd/5.6/reference/streamtriggers/interfaces#bdrdrop_trigger) diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-replication-options.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-replication-options.mdx index cd37f8f04ef..14bc2ca8964 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-replication-options.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-replication-options.mdx @@ -3,7 +3,7 @@ title: DDL replication options navTitle: Options --- -The [`bdr.ddl_replication`](/pgd/latest/reference/pgd-settings#bdrddl_replication) parameter specifies replication behavior. +The [`bdr.ddl_replication`](/pgd/5.6/reference/pgd-settings#bdrddl_replication) parameter specifies replication behavior. `bdr.ddl_replication = on` is the default. This setting replicates DDL to the default replication set, which by default means all nodes. Non-default @@ -12,7 +12,7 @@ replication sets don't replicate DDL unless they have a defined for them. You can also replicate DDL to specific replication sets using the -function [`bdr.replicate_ddl_command()`](/pgd/latest/reference/functions#bdrreplicate_ddl_command). This function can be helpful if you +function [`bdr.replicate_ddl_command()`](/pgd/5.6/reference/functions#bdrreplicate_ddl_command). This function can be helpful if you want to run DDL commands when a node is down. It's also helpful if you want to have indexes or partitions that exist on a subset of nodes or rep sets, for example, all nodes at site1. @@ -26,7 +26,7 @@ SELECT bdr.replicate_ddl_command( ``` While we don't recommend it, you can skip automatic DDL replication and -execute it manually on each node using the [`bdr.ddl_replication`](/pgd/latest/reference/pgd-settings#bdrddl_replication) configuration +execute it manually on each node using the [`bdr.ddl_replication`](/pgd/5.6/reference/pgd-settings#bdrddl_replication) configuration parameter. ``` diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-role-manipulation.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-role-manipulation.mdx index 37cff6150aa..648e51b2184 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-role-manipulation.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-role-manipulation.mdx @@ -11,7 +11,7 @@ PGD requires that any roles that are referenced by any replicated DDL must exist on all nodes. The roles don't have to have the same grants, password, and so on, but they must exist. -PGD replicates role manipulation statements if [`bdr.role_replication`](/pgd/latest/reference/pgd-settings#bdrrole_replication) is +PGD replicates role manipulation statements if [`bdr.role_replication`](/pgd/5.6/reference/pgd-settings#bdrrole_replication) is enabled (default) and role manipulation statements are run in a PGD-enabled database. diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-workarounds.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-workarounds.mdx index 921110deb78..cd54c360b85 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-workarounds.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-workarounds.mdx @@ -130,7 +130,7 @@ The `ALTER TYPE` statement is replicated, but affected tables aren't locked. When you use this DDL, ensure that the statement has successfully executed on all nodes before using the new type. You can achieve this using -the [`bdr.wait_slot_confirm_lsn()`](/pgd/latest/reference/functions#bdrwait_slot_confirm_lsn) function. +the [`bdr.wait_slot_confirm_lsn()`](/pgd/5.6/reference/functions#bdrwait_slot_confirm_lsn) function. This example ensures that the DDL is written to all nodes before using the new value in DML statements: diff --git a/product_docs/docs/pgd/5.6/decoding_worker.mdx b/product_docs/docs/pgd/5.6/decoding_worker.mdx index d73a8c6c171..e3daa03bff5 100644 --- a/product_docs/docs/pgd/5.6/decoding_worker.mdx +++ b/product_docs/docs/pgd/5.6/decoding_worker.mdx @@ -24,8 +24,8 @@ subscribing nodes received data. LCR files are stored under the size of the LCR files varies as replication lag increases, so this process also needs monitoring. The LCRs that aren't required by any of the PGD nodes are cleaned periodically. The interval between two consecutive cleanups is controlled by -[`bdr.lcr_cleanup_interval`](/pgd/latest/reference/pgd-settings#bdrlcr_cleanup_interval), which defaults to 3 minutes. The cleanup is -disabled when [`bdr.lcr_cleanup_interval`](/pgd/latest/reference/pgd-settings#bdrlcr_cleanup_interval) is 0. +[`bdr.lcr_cleanup_interval`](/pgd/5.6/reference/pgd-settings#bdrlcr_cleanup_interval), which defaults to 3 minutes. The cleanup is +disabled when [`bdr.lcr_cleanup_interval`](/pgd/5.6/reference/pgd-settings#bdrlcr_cleanup_interval) is 0. ## Disabling @@ -37,11 +37,11 @@ GUCs control the production and use of LCR per node. By default these are `false`. For production and use of LCRs, enable the decoding worker for the PGD group and set these GUCs to `true` on each of the nodes in the PGD group. -- [`bdr.enable_wal_decoder`](/pgd/latest/reference/pgd-settings#bdrenable_wal_decoder) — When `false`, all WAL +- [`bdr.enable_wal_decoder`](/pgd/5.6/reference/pgd-settings#bdrenable_wal_decoder) — When `false`, all WAL senders using LCRs restart to use WAL directly. When `true` along with the PGD group config, a decoding worker process is started to produce LCR and WAL senders that use LCR. -- [`bdr.receive_lcr`](/pgd/latest/reference/pgd-settings#bdrreceive_lcr) — When `true` on the subscribing node, it requests WAL +- [`bdr.receive_lcr`](/pgd/5.6/reference/pgd-settings#bdrreceive_lcr) — When `true` on the subscribing node, it requests WAL sender on the publisher node to use LCRs if available. @@ -82,7 +82,7 @@ The WAL decoder always streams the transactions to LCRs but based on downstream To support this feature, the system creates additional streaming files. These files have names in that begin with `STR_TXN_` and `CAS_TXN_` and each streamed transaction creates their own pair. -To enable transaction streaming with the WAL decoder, set the PGD group's `bdr.streaming_mode` set to ‘default’ using [`bdr.alter_node_group_option`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_group_option). +To enable transaction streaming with the WAL decoder, set the PGD group's `bdr.streaming_mode` set to ‘default’ using [`bdr.alter_node_group_option`](/pgd/5.6/reference/nodes-management-interfaces#bdralter_node_group_option). diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-cloudservice/index.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-cloudservice/index.mdx index 9d17e513485..552384fc36a 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-cloudservice/index.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-cloudservice/index.mdx @@ -2,9 +2,9 @@ title: Deploying and configuring PGD on EDB Postgres AI Cloud Service navTitle: On EDB Cloud Service redirects: - - /pgd/latest/deploy-config/deploy-biganimal/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/install-admin/admin-biganimal/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-biganimal/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/deploy-config/deploy-biganimal/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-biganimal/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-biganimal/ #generated for pgd deploy-config-planning reorg --- EDB Postgres AI Cloud Service is a fully managed database-as-a-service with built-in Oracle compatibility. It runs in your cloud account where it's operated by our Postgres experts. EDB Postgres AI Cloud Service makes it easy to set up, manage, and scale your databases. The addition of distributed high-availability support powered by EDB Postgres Distributed (PGD) enables single and multi-region Always-on clusters. diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-kubernetes/index.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-kubernetes/index.mdx index f0a8813151a..9a1b070cd0e 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-kubernetes/index.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-kubernetes/index.mdx @@ -2,8 +2,8 @@ title: Deploying and configuring PGD on Kubernetes navTitle: With Kubernetes redirects: - - /pgd/latest/install-admin/admin-kubernetes/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-kubernetes/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-kubernetes/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-kubernetes/ #generated for pgd deploy-config-planning reorg --- EDB CloudNativePG Global Cluster is a Kubernetes operator designed, developed, and supported by EDB. It covers the full lifecycle of highly available Postgres database clusters with a multi-master architecture, using PGD replication. It's based on the open source CloudNativePG operator and provides additional value, such as compatibility with Oracle using EDB Postgres Advanced Server, Transparent Data Encryption (TDE) using EDB Postgres Extended or Advanced Server, and additional supported platforms including IBM Power and OpenShift. diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/01-provisioning-hosts.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/01-provisioning-hosts.mdx index 1c9b8d291ff..24376ab0465 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/01-provisioning-hosts.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/01-provisioning-hosts.mdx @@ -3,8 +3,8 @@ title: Step 1 - Provisioning hosts navTitle: Provisioning hosts deepToC: true redirects: - - /pgd/latest/install-admin/admin-manual/installing/01-provisioning-hosts/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-manual/installing/01-provisioning-hosts/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-manual/installing/01-provisioning-hosts/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-manual/installing/01-provisioning-hosts/ #generated for pgd deploy-config-planning reorg --- ## Provisioning hosts diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/02-install-postgres.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/02-install-postgres.mdx index dcc6a02b9c8..044c66a186c 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/02-install-postgres.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/02-install-postgres.mdx @@ -3,8 +3,8 @@ title: Step 2 - Installing Postgres navTitle: Installing Postgres deepToC: true redirects: - - /pgd/latest/install-admin/admin-manual/installing/02-install-postgres/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-manual/installing/02-install-postgres/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-manual/installing/02-install-postgres/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-manual/installing/02-install-postgres/ #generated for pgd deploy-config-planning reorg --- ## Installing Postgres diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/03-configuring-repositories.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/03-configuring-repositories.mdx index 2f908694bab..54b47e96ef8 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/03-configuring-repositories.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/03-configuring-repositories.mdx @@ -3,15 +3,15 @@ title: Step 3 - Configuring PGD repositories navTitle: Configuring PGD repositories deepToC: true redirects: - - /pgd/latest/install-admin/admin-manual/installing/03-configuring-repositories/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-manual/installing/03-configuring-repositories/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-manual/installing/03-configuring-repositories/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-manual/installing/03-configuring-repositories/ #generated for pgd deploy-config-planning reorg --- ## Configuring PGD repositories To install and run PGD requires that you configure repositories so that the system can download and install the appropriate packages. -Perform the following operations on each host. For the purposes of this exercise, each host is a standard data node, but the procedure would be the same for other [node types](/pgd/latest/nodes/overview), such as witness or subscriber-only nodes. +Perform the following operations on each host. For the purposes of this exercise, each host is a standard data node, but the procedure would be the same for other [node types](/pgd/5.6/nodes/overview), such as witness or subscriber-only nodes. * Use your EDB account. * Obtain your EDB repository token from the [EDB Repos 2.0](https://www.enterprisedb.com/repos-downloads) page. diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/04-installing-software.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/04-installing-software.mdx index 1384438cf71..c375611c0e4 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/04-installing-software.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/04-installing-software.mdx @@ -3,8 +3,8 @@ title: Step 4 - Installing the PGD software navTitle: Installing PGD software deepToC: true redirects: - - /pgd/latest/install-admin/admin-manual/installing/04-installing-software/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-manual/installing/04-installing-software/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-manual/installing/04-installing-software/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-manual/installing/04-installing-software/ #generated for pgd deploy-config-planning reorg --- ## Installing the PGD software diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/05-creating-cluster.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/05-creating-cluster.mdx index 009e2486ecf..de44cc26671 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/05-creating-cluster.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/05-creating-cluster.mdx @@ -3,8 +3,8 @@ title: Step 5 - Creating the PGD cluster navTitle: Creating the cluster deepToC: true redirects: - - /pgd/latest/install-admin/admin-manual/installing/05-creating-cluster/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-manual/installing/05-creating-cluster/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-manual/installing/05-creating-cluster/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-manual/installing/05-creating-cluster/ #generated for pgd deploy-config-planning reorg --- ## Creating the PGD cluster @@ -81,7 +81,7 @@ sudo -iu enterprisedb psql bdrdb ### Create the first node -Call the [`bdr.create_node`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node) function to create a node, passing it the node name and a connection string that other nodes can use to connect to it. +Call the [`bdr.create_node`](/pgd/5.6/reference/nodes-management-interfaces#bdrcreate_node) function to create a node, passing it the node name and a connection string that other nodes can use to connect to it. ``` select bdr.create_node('node-one','host=host-one dbname=bdrdb port=5444'); @@ -89,7 +89,7 @@ select bdr.create_node('node-one','host=host-one dbname=bdrdb port=5444'); #### Create the top-level group -Call the [`bdr.create_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node_group) function to create a top-level group for your PGD cluster. Passing a single string parameter creates the top-level group with that name. This example creates a top-level group named `pgd`. +Call the [`bdr.create_node_group`](/pgd/5.6/reference/nodes-management-interfaces#bdrcreate_node_group) function to create a top-level group for your PGD cluster. Passing a single string parameter creates the top-level group with that name. This example creates a top-level group named `pgd`. ``` select bdr.create_node_group('pgd'); @@ -101,7 +101,7 @@ Using subgroups to organize your nodes is preferred, as it allows services like In a larger PGD installation, multiple subgroups can exist. These subgroups provide organizational grouping that enables geographical mapping of clusters and localized resilience. For that reason, this example creates a subgroup for the first nodes to enable simpler expansion and the use of PGD Proxy. -Call the [`bdr.create_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node_group) function again to create a subgroup of the top-level group. +Call the [`bdr.create_node_group`](/pgd/5.6/reference/nodes-management-interfaces#bdrcreate_node_group) function again to create a subgroup of the top-level group. The subgroup name is the first parameter, and the parent group is the second parameter. This example creates a subgroup `dc1` as a child of `pgd`. @@ -121,7 +121,7 @@ sudo -iu enterprisedb psql bdrdb #### Create the second node -Call the [`bdr.create_node`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node) function to create this node, passing it the node name and a connection string that other nodes can use to connect to it. +Call the [`bdr.create_node`](/pgd/5.6/reference/nodes-management-interfaces#bdrcreate_node) function to create this node, passing it the node name and a connection string that other nodes can use to connect to it. ``` select bdr.create_node('node-two','host=host-two dbname=bdrdb port=5444'); @@ -129,7 +129,7 @@ select bdr.create_node('node-two','host=host-two dbname=bdrdb port=5444'); #### Join the second node to the cluster -Using [`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group), you can ask node-two to join node-one's `dc1` group. The function takes as a first parameter the connection string of a node already in the group and the group name as a second parameter. +Using [`bdr.join_node_group`](/pgd/5.6/reference/nodes-management-interfaces#bdrjoin_node_group), you can ask node-two to join node-one's `dc1` group. The function takes as a first parameter the connection string of a node already in the group and the group name as a second parameter. ``` select bdr.join_node_group('host=host-one dbname=bdrdb port=5444','dc1'); @@ -146,7 +146,7 @@ sudo -iu enterprisedb psql bdrdb #### Create the third node -Call the [`bdr.create_node`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node) function to create this node, passing it the node name and a connection string that other nodes can use to connect to it. +Call the [`bdr.create_node`](/pgd/5.6/reference/nodes-management-interfaces#bdrcreate_node) function to create this node, passing it the node name and a connection string that other nodes can use to connect to it. ``` select bdr.create_node('node-three','host=host-three dbname=bdrdb port=5444'); @@ -154,7 +154,7 @@ select bdr.create_node('node-three','host=host-three dbname=bdrdb port=5444'); #### Join the third node to the cluster -Using [`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group), you can ask node-three to join node-one's `dc1` group. The function takes as a first parameter the connection string of a node already in the group and the group name as a second parameter. +Using [`bdr.join_node_group`](/pgd/5.6/reference/nodes-management-interfaces#bdrjoin_node_group), you can ask node-three to join node-one's `dc1` group. The function takes as a first parameter the connection string of a node already in the group and the group name as a second parameter. ``` select bdr.join_node_group('host=host-one dbname=bdrdb port=5444','dc1'); diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/06-check-cluster.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/06-check-cluster.mdx index fc7938ce85c..365e6ee2ff4 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/06-check-cluster.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/06-check-cluster.mdx @@ -3,8 +3,8 @@ title: Step 6 - Checking the cluster navTitle: Checking the cluster deepToC: true redirects: - - /pgd/latest/install-admin/admin-manual/installing/06-check-cluster/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-manual/installing/06-check-cluster/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-manual/installing/06-check-cluster/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-manual/installing/06-check-cluster/ #generated for pgd deploy-config-planning reorg --- ## Checking the cluster diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx index 0bee3e06b9a..5505c0c5243 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/07-configure-proxies.mdx @@ -3,8 +3,8 @@ title: Step 7 - Configure proxies navTitle: Configure proxies deepToC: true redirects: - - /pgd/latest/install-admin/admin-manual/installing/07-configure-proxies/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-manual/installing/07-configure-proxies/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-manual/installing/07-configure-proxies/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-manual/installing/07-configure-proxies/ #generated for pgd deploy-config-planning reorg --- ## Configure proxies @@ -21,9 +21,9 @@ It's best practice to configure PGD Proxy for clusters to enable this behavior. To set up a proxy, you need to first prepare the cluster and subgroup the proxies will be working with by: -* Logging in and setting the `enable_raft` and `enable_proxy_routing` node group options to `true` for the subgroup. Use [`bdr.alter_node_group_option`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_group_option), passing the subgroup name, option name, and new value as parameters. -* Create as many uniquely named proxies as you plan to deploy using [`bdr.create_proxy`](/pgd/latest/reference/routing#bdrcreate_proxy) and passing the new proxy name and the subgroup to attach it to. The [`bdr.create_proxy`](/pgd/latest/reference/routing#bdrcreate_proxy) does not create a proxy, but creates a space for a proxy to register itself with the cluster. The space contains configuration values which can be modified later. Initially it is configured with default proxy options such as setting the `listen_address` to `0.0.0.0`. -* Configure proxy routes to each node by setting route_dsn for each node in the subgroup. The route_dsn is the connection string that the proxy should use to connect to that node. Use [`bdr.alter_node_option`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_option) to set the route_dsn for each node in the subgroup. +* Logging in and setting the `enable_raft` and `enable_proxy_routing` node group options to `true` for the subgroup. Use [`bdr.alter_node_group_option`](/pgd/5.6/reference/nodes-management-interfaces#bdralter_node_group_option), passing the subgroup name, option name, and new value as parameters. +* Create as many uniquely named proxies as you plan to deploy using [`bdr.create_proxy`](/pgd/5.6/reference/routing#bdrcreate_proxy) and passing the new proxy name and the subgroup to attach it to. The [`bdr.create_proxy`](/pgd/5.6/reference/routing#bdrcreate_proxy) does not create a proxy, but creates a space for a proxy to register itself with the cluster. The space contains configuration values which can be modified later. Initially it is configured with default proxy options such as setting the `listen_address` to `0.0.0.0`. +* Configure proxy routes to each node by setting route_dsn for each node in the subgroup. The route_dsn is the connection string that the proxy should use to connect to that node. Use [`bdr.alter_node_option`](/pgd/5.6/reference/nodes-management-interfaces#bdralter_node_option) to set the route_dsn for each node in the subgroup. * Create a pgdproxy user on the cluster with a password or other authentication. ### Configure each host as a proxy @@ -53,7 +53,7 @@ SELECT bdr.alter_node_group_option('dc1', 'enable_raft', 'true'); SELECT bdr.alter_node_group_option('dc1', 'enable_proxy_routing', 'true'); ``` -You can use the [`bdr.node_group_summary`](/pgd/latest/reference/catalogs-visible#bdrnode_group_summary) view to check the status of options previously set with `bdr.alter_node_group_option()`: +You can use the [`bdr.node_group_summary`](/pgd/5.6/reference/catalogs-visible#bdrnode_group_summary) view to check the status of options previously set with `bdr.alter_node_group_option()`: ```sql SELECT node_group_name, enable_proxy_routing, enable_raft @@ -80,7 +80,7 @@ SELECT bdr.create_proxy('pgd-proxy-two','dc1'); SELECT bdr.create_proxy('pgd-proxy-three','dc1'); ``` -You can use the [`bdr.proxy_config_summary`](/pgd/latest/reference/catalogs-internal#bdrproxy_config_summary) view to check that the proxies were created: +You can use the [`bdr.proxy_config_summary`](/pgd/5.6/reference/catalogs-internal#bdrproxy_config_summary) view to check that the proxies were created: ```sql SELECT proxy_name, node_group_name diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/08-using-pgd-cli.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/08-using-pgd-cli.mdx index ca05ecab43a..bc29265e4ff 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/08-using-pgd-cli.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/08-using-pgd-cli.mdx @@ -3,8 +3,8 @@ title: Step 8 - Using PGD CLI navTitle: Using PGD CLI deepToC: true redirects: - - /pgd/latest/install-admin/admin-manual/installing/08-using-pgd-cli/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-manual/installing/08-using-pgd-cli/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-manual/installing/08-using-pgd-cli/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-manual/installing/08-using-pgd-cli/ #generated for pgd deploy-config-planning reorg --- ## Using PGD CLI diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/index.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/index.mdx index 8fff69ab309..1f21981b24d 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/index.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/index.mdx @@ -11,8 +11,8 @@ navigation: - 07-configure-proxies - 08-using-pgd-cli redirects: - - /pgd/latest/install-admin/admin-manual/installing/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-manual/installing/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-manual/installing/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-manual/installing/ #generated for pgd deploy-config-planning reorg --- EDB offers automated PGD deployment using Trusted Postgres Architect (TPA) because it's generally more reliable than manual processes. diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/deploying/01-configuring.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/deploying/01-configuring.mdx index bedd73aec82..0519a62c15d 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/deploying/01-configuring.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/deploying/01-configuring.mdx @@ -2,8 +2,8 @@ title: Configuring a PGD cluster with TPA navTitle: Configuring redirects: - - /pgd/latest/install-admin/admin-tpa/installing/01-configuring/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-tpa/installing/01-configuring/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-tpa/installing/01-configuring/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-tpa/installing/01-configuring/ #generated for pgd deploy-config-planning reorg --- The `tpaexec configure` command generates a simple YAML configuration file to describe a cluster, based on the options you select. The configuration is ready for immediate use, and you can modify it to better suit your needs. Editing the configuration file is the usual way to make any configuration changes to your cluster both before and after it's created. diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/deploying/02-deploying.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/deploying/02-deploying.mdx index 51a0136d452..3931bf1f622 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/deploying/02-deploying.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/deploying/02-deploying.mdx @@ -2,8 +2,8 @@ title: Provisioning, deploying, and testing navTitle: Deploying redirects: - - /pgd/latest/install-admin/admin-tpa/installing/02-deploying/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-tpa/installing/02-deploying/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-tpa/installing/02-deploying/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-tpa/installing/02-deploying/ #generated for pgd deploy-config-planning reorg --- ## Provision diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/deploying/index.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/deploying/index.mdx index 31738207df9..c83176d1d59 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/deploying/index.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/deploying/index.mdx @@ -4,15 +4,15 @@ navTitle: Deploying with TPA description: > Detailed reference and examples for using TPA to configure and deploy PGD redirects: - - /pgd/latest/tpa/ - - /pgd/latest/deployments/tpaexec/using_tpaexec/ - - /pgd/latest/tpa/using_tpa/ + - /pgd/5.6/tpa/ + - /pgd/5.6/deployments/tpaexec/using_tpaexec/ + - /pgd/5.6/tpa/using_tpa/ - ../deployments/tpaexec - ../deployments/tpaexec/installing_tpaexec - ../deployments/using_tpa/ - ../tpa - - /pgd/latest/install-admin/admin-tpa/installing/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-tpa/installing/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-tpa/installing/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-tpa/installing/ #generated for pgd deploy-config-planning reorg --- The standard way of automatically deploying EDB Postgres Distributed in a self-managed setting is to use EDB's deployment tool: [Trusted Postgres Architect](/tpa/latest/) (TPA). @@ -22,11 +22,11 @@ This applies to physical and virtual machines, both self-hosted and in the cloud !!! Note Get started with TPA and PGD quickly - If you want to experiment with a local deployment as quickly as possible, you can [deploy an EDB Postgres Distributed example cluster on Docker](/pgd/latest/quickstart/quick_start_docker) to configure, provision, and deploy a PGD 5 Always-on cluster on Docker. + If you want to experiment with a local deployment as quickly as possible, you can [deploy an EDB Postgres Distributed example cluster on Docker](/pgd/5.6/quickstart/quick_start_docker) to configure, provision, and deploy a PGD 5 Always-on cluster on Docker. - If deploying to the cloud is your aim, you can [deploy an EDB Postgres Distributed example cluster on AWS](/pgd/latest/quickstart/quick_start_aws) to get a PGD 5 cluster on your own Amazon account. + If deploying to the cloud is your aim, you can [deploy an EDB Postgres Distributed example cluster on AWS](/pgd/5.6/quickstart/quick_start_aws) to get a PGD 5 cluster on your own Amazon account. - If you want to run on your own Linux systems or VMs, you can also use TPA to [deploy EDB Postgres Distributed directly to your own Linux hosts](/pgd/latest/quickstart/quick_start_linux). + If you want to run on your own Linux systems or VMs, you can also use TPA to [deploy EDB Postgres Distributed directly to your own Linux hosts](/pgd/5.6/quickstart/quick_start_linux). ## Prerequisite: Install TPA diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/index.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/index.mdx index e69081153d9..7cb74cf1196 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/index.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-tpa/index.mdx @@ -2,8 +2,8 @@ title: Deployment and management with TPA navTitle: Using TPA redirects: - - /pgd/latest/install-admin/admin-tpa/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-tpa/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-tpa/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-tpa/ #generated for pgd deploy-config-planning reorg --- TPA (Trusted Postgres Architect) is a standard automated way of installing PGD and Postgres on physical and virtual machines, diff --git a/product_docs/docs/pgd/5.6/index.mdx b/product_docs/docs/pgd/5.6/index.mdx index 3f41f908605..8a46597ab13 100644 --- a/product_docs/docs/pgd/5.6/index.mdx +++ b/product_docs/docs/pgd/5.6/index.mdx @@ -45,7 +45,7 @@ navigation: pdf: true directoryDefaults: version: "5.6.1" - displayBanner: 'Warning: You are not reading the most recent version of this documentation.
Documentation improvements are made only to the latest version.
As per semantic versioning, PGD minor releases remain backward compatible and may include important bug fixes and enhancements.
We recommend upgrading the latest minor release as soon as possible.
If you want up-to-date information, read the latest PGD documentation.' + displayBanner: 'Warning: You are not reading the most recent version of this documentation.
Documentation improvements are made only to the latest version.
As per semantic versioning, PGD minor releases remain backward compatible and may include important bug fixes and enhancements.
We recommend upgrading the latest minor release as soon as possible.
If you want up-to-date information, read the latest PGD documentation.' --- @@ -70,7 +70,7 @@ Read about why PostgreSQL is better when it’s distributed with EDB Postgres Di By default, EDB Postgres Distributed uses asynchronous replication, applying changes on the peer nodes only after the local commit. You can configure additional levels of synchronicity between different nodes, groups of nodes, or all nodes by configuring -[Synchronous Commit](/pgd/latest/commit-scopes/synchronous_commit/), [Group Commit](commit-scopes/group-commit) (optionally with [Eager Conflict Resolution](/pgd/latest/commit-scopes/group-commit/#eager-conflict-resolution)), or [CAMO](commit-scopes/camo). +[Synchronous Commit](/pgd/5.6/commit-scopes/synchronous_commit/), [Group Commit](commit-scopes/group-commit) (optionally with [Eager Conflict Resolution](/pgd/5.6/commit-scopes/group-commit/#eager-conflict-resolution)), or [CAMO](commit-scopes/camo). ## Compatibility diff --git a/product_docs/docs/pgd/5.6/known_issues.mdx b/product_docs/docs/pgd/5.6/known_issues.mdx index 92f945eac79..071fe7efdc8 100644 --- a/product_docs/docs/pgd/5.6/known_issues.mdx +++ b/product_docs/docs/pgd/5.6/known_issues.mdx @@ -38,7 +38,7 @@ Adding or removing a pair doesn't require a restart of Postgres or even a reload - Transactions using Eager Replication can't yet execute DDL. The TRUNCATE command is allowed. -- Parallel Apply isn't currently supported in combination with Group Commit. Make sure to disable it when using Group Commit by either (a) Setting `num_writers` to 1 for the node group using [`bdr.alter_node_group_option`](/pgd/latest/reference/nodes-management-interfaces/#bdralter_node_group_option) or (b) using the GUC [`bdr.writers_per_subscription`](/pgd/latest/reference/pgd-settings#bdrwriters_per_subscription). See [Configuration of generic replication](/pgd/latest/reference/pgd-settings#generic-replication). +- Parallel Apply isn't currently supported in combination with Group Commit. Make sure to disable it when using Group Commit by either (a) Setting `num_writers` to 1 for the node group using [`bdr.alter_node_group_option`](/pgd/5.6/reference/nodes-management-interfaces/#bdralter_node_group_option) or (b) using the GUC [`bdr.writers_per_subscription`](/pgd/5.6/reference/pgd-settings#bdrwriters_per_subscription). See [Configuration of generic replication](/pgd/5.6/reference/pgd-settings#generic-replication). - There currently is no protection against altering or removing a commit scope. Running transactions in a commit scope that's concurrently being altered or removed can lead to the transaction blocking or replication stalling completely due to an error on the downstream node attempting to apply the transaction. @@ -47,7 +47,7 @@ Make sure that any transactions using a specific commit scope have finished befo - The [PGD CLI](cli) can return stale data on the state of the cluster if it's still connecting to nodes that were previously parted from the cluster. Edit the [`pgd-cli-config.yml`](cli/configuring_cli/#using-a-configuration-file) file, or change your [`--dsn`](cli/configuring_cli/#using-database-connection-strings-in-the-command-line) settings to ensure only active nodes in the cluster are listed for connection. -To modify a commit scope safely, use [`bdr.alter_commit_scope`](/pgd/latest/reference/functions#bdralter_commit_scope). +To modify a commit scope safely, use [`bdr.alter_commit_scope`](/pgd/5.6/reference/functions#bdralter_commit_scope). - DDL run in serializable transactions can face the error: `ERROR: could not serialize access due to read/write dependencies among transactions`. A workaround is to run the DDL outside serializable transactions. diff --git a/product_docs/docs/pgd/5.6/monitoring/sql.mdx b/product_docs/docs/pgd/5.6/monitoring/sql.mdx index 4f5d18f198f..3cd7c776fd0 100644 --- a/product_docs/docs/pgd/5.6/monitoring/sql.mdx +++ b/product_docs/docs/pgd/5.6/monitoring/sql.mdx @@ -74,7 +74,7 @@ node_seq_id | 3 node_local_dbname | postgres ``` -Also, the table [`bdr.node_catchup_info`](/pgd/latest/reference/catalogs-visible/#bdrnode_catchup_info) gives information +Also, the table [`bdr.node_catchup_info`](/pgd/5.6/reference/catalogs-visible/#bdrnode_catchup_info) gives information on the catch-up state, which can be relevant to joining nodes or parting nodes. When a node is parted, some nodes in the cluster might not receive @@ -94,7 +94,7 @@ The `catchup_state` can be one of the following: The manager worker is responsible for many background tasks, including the managing of all the other workers. As such it is important to know what it's doing, especially in cases where it might seem stuck. -Accordingly, the [`bdr.stat_worker`](/pgd/latest/reference/catalogs-visible/#bdrstat_worker) view provides per worker statistics for PGD workers, including manager workers. With respect to ensuring manager workers do not get stuck, the current task they are executing would be reported in their `query` field prefixed by "pgd manager:". +Accordingly, the [`bdr.stat_worker`](/pgd/5.6/reference/catalogs-visible/#bdrstat_worker) view provides per worker statistics for PGD workers, including manager workers. With respect to ensuring manager workers do not get stuck, the current task they are executing would be reported in their `query` field prefixed by "pgd manager:". The `worker_backend_state` field for manager workers also reports whether the manager is idle or busy. @@ -104,15 +104,15 @@ Routing is a critical part of PGD for ensuring a seemless application experience Monitoring all of these is important for noticing issues, debugging issues, as well as informing more optimal configurations. Accoringly, there are two main views for monitoring statistics to do with routing: -- [`bdr.stat_routing_state`](/pgd/latest/reference/catalogs-visible/#bdrstat_routing_state) for monitoring the state of the connection routing with PGD Proxy uses to route the connections. -- [`bdr.stat_routing_candidate_state`](/pgd/latest/reference/catalogs-visible/#bdrstat_routing_candidate_state) for information about routing candidate nodes from the point of view of the Raft leader (the view is empty on other nodes). +- [`bdr.stat_routing_state`](/pgd/5.6/reference/catalogs-visible/#bdrstat_routing_state) for monitoring the state of the connection routing with PGD Proxy uses to route the connections. +- [`bdr.stat_routing_candidate_state`](/pgd/5.6/reference/catalogs-visible/#bdrstat_routing_candidate_state) for information about routing candidate nodes from the point of view of the Raft leader (the view is empty on other nodes). ## Monitoring Replication Peers You use two main views for monitoring of replication activity: -- [`bdr.node_slots`](/pgd/latest/reference/catalogs-visible/#bdrnode_slots) for monitoring outgoing replication -- [`bdr.subscription_summary`](/pgd/latest/reference/catalogs-visible/#bdrsubscription_summary) for monitoring incoming replication +- [`bdr.node_slots`](/pgd/5.6/reference/catalogs-visible/#bdrnode_slots) for monitoring outgoing replication +- [`bdr.subscription_summary`](/pgd/5.6/reference/catalogs-visible/#bdrsubscription_summary) for monitoring incoming replication You can also obtain most of the information provided by `bdr.node_slots` by querying the standard PostgreSQL replication monitoring views @@ -128,9 +128,9 @@ something is down or disconnected. See [Replication slots](../node_management/re You can use another view for monitoring of outgoing replication activity: -- [`bdr.node_replication_rates`](/pgd/latest/reference/catalogs-visible/#bdrnode_replication_rates) for monitoring outgoing replication +- [`bdr.node_replication_rates`](/pgd/5.6/reference/catalogs-visible/#bdrnode_replication_rates) for monitoring outgoing replication -The [`bdr.node_replication_rates`](/pgd/latest/reference/catalogs-visible/#bdrnode_replication_rates) view gives an overall picture of the outgoing +The [`bdr.node_replication_rates`](/pgd/5.6/reference/catalogs-visible/#bdrnode_replication_rates) view gives an overall picture of the outgoing replication activity along with the catchup estimates for peer nodes, specifically. @@ -163,10 +163,10 @@ at which the peer is consuming data from the local node. The `replay_lag` when a node reconnects to the cluster is immediately set to zero. This information will be fixed in a future release. As a workaround, we recommend using the `catchup_interval` column that refers to the time required for the peer node to catch up to the -local node data. The other fields are also available from the [`bdr.node_slots`](/pgd/latest/reference/catalogs-visible/#bdrnode_slots) +local node data. The other fields are also available from the [`bdr.node_slots`](/pgd/5.6/reference/catalogs-visible/#bdrnode_slots) view. -Administrators can query [`bdr.node_slots`](/pgd/latest/reference/catalogs-visible/#bdrnode_slots) for outgoing replication from the +Administrators can query [`bdr.node_slots`](/pgd/5.6/reference/catalogs-visible/#bdrnode_slots) for outgoing replication from the local node. It shows information about replication status of all other nodes in the group that are known to the current node as well as any additional replication slots created by PGD on the current node. @@ -283,13 +283,13 @@ sub_slot_name | bdr_postgres_bdrgroup_node1 subscription_status | replicating ``` -You can further monitor subscriptions by monitoring subscription summary statistics through [`bdr.stat_subscription`](/pgd/latest/reference/catalogs-visible/#bdrstat_subscription), and by monitoring the subscription replication receivers and subscription replication writers, using [`bdr.stat_receiver`](/pgd/latest/reference/catalogs-visible/#bdrstat_receiver) and [`bdr.stat_writer`](/pgd/latest/reference/catalogs-visible/#bdrstat_writer), respectively. +You can further monitor subscriptions by monitoring subscription summary statistics through [`bdr.stat_subscription`](/pgd/5.6/reference/catalogs-visible/#bdrstat_subscription), and by monitoring the subscription replication receivers and subscription replication writers, using [`bdr.stat_receiver`](/pgd/5.6/reference/catalogs-visible/#bdrstat_receiver) and [`bdr.stat_writer`](/pgd/5.6/reference/catalogs-visible/#bdrstat_writer), respectively. ### Monitoring WAL senders using LCR If the [decoding worker](../decoding_worker/) is enabled, you can monitor information about the current logical change record (LCR) file for each WAL sender -using the function [`bdr.wal_sender_stats()`](/pgd/latest/reference/functions/#bdrwal_sender_stats). For example: +using the function [`bdr.wal_sender_stats()`](/pgd/5.6/reference/functions/#bdrwal_sender_stats). For example: ``` postgres=# SELECT * FROM bdr.wal_sender_stats(); @@ -306,7 +306,7 @@ This is the case if the decoding worker isn't enabled or the WAL sender is serving a [logical standby](../nodes/logical_standby_nodes/). Also, you can monitor information about the decoding worker using the function -[`bdr.get_decoding_worker_stat()`](/pgd/latest/reference/functions/#bdrget_decoding_worker_stat). For example: +[`bdr.get_decoding_worker_stat()`](/pgd/5.6/reference/functions/#bdrget_decoding_worker_stat). For example: ``` postgres=# SELECT * FROM bdr.get_decoding_worker_stat(); @@ -365,9 +365,9 @@ Commit scopes are our durability and consistency configuration framework. As suc Accordingly, these two views show relevant statistics about commit scopes: -- [bdr.stat_commit_scope](/pgd/latest/reference/catalogs-visible/#bdrstat_commit_scope) for cumulative statistics for each commit scope. +- [bdr.stat_commit_scope](/pgd/5.6/reference/catalogs-visible/#bdrstat_commit_scope) for cumulative statistics for each commit scope. -- [bdr.stat_commit_scope_state](/pgd/latest/reference/catalogs-visible/#bdrstat_commit_scope_state) for information about the current use of commit scopes by backend processes. +- [bdr.stat_commit_scope_state](/pgd/5.6/reference/catalogs-visible/#bdrstat_commit_scope_state) for information about the current use of commit scopes by backend processes. ## Monitoring global locks @@ -384,7 +384,7 @@ There are currently two types of global locks: You can create either or both entry types for the same transaction, depending on the type of DDL operation and the value of the `bdr.ddl_locking` setting. -Global locks held on the local node are visible in the [`bdr.global_locks`](/pgd/latest/reference/catalogs-visible/#bdrglobal_locks) view. +Global locks held on the local node are visible in the [`bdr.global_locks`](/pgd/5.6/reference/catalogs-visible/#bdrglobal_locks) view. This view shows the type of the lock. For relation locks, it shows the relation that's being locked, the PID holding the lock (if local), and whether the lock was globally granted. In case @@ -406,7 +406,7 @@ relation | someschema.sometable pid | 15534 ``` -See [Catalogs](/pgd/latest/reference/catalogs-visible/) for details on all fields, including lock +See [Catalogs](/pgd/5.6/reference/catalogs-visible/) for details on all fields, including lock timing information. ## Monitoring conflicts @@ -421,7 +421,7 @@ row-level security to ensure they're visible only by owners of replicated tables. Owners should expect conflicts and analyze them to see which, if any, might be considered as problems to resolve. -For monitoring purposes, use [`bdr.conflict_history_summary`](/pgd/latest/reference/catalogs-visible#bdrconflict_history_summary), which doesn't +For monitoring purposes, use [`bdr.conflict_history_summary`](/pgd/5.6/reference/catalogs-visible#bdrconflict_history_summary), which doesn't contain user data. This example shows a query to count the number of conflicts seen in the current day using an efficient query plan: @@ -437,8 +437,8 @@ WHERE local_time > date_trunc('day', current_timestamp) PGD collects statistics about replication apply, both for each subscription and for each table. -Two monitoring views exist: [`bdr.stat_subscription`](/pgd/latest/reference/catalogs-visible#bdrstat_subscription) for subscription statistics -and [`bdr.stat_relation`](/pgd/latest/reference/catalogs-visible#bdrstat_relation) for relation statistics. These views both provide: +Two monitoring views exist: [`bdr.stat_subscription`](/pgd/5.6/reference/catalogs-visible#bdrstat_subscription) for subscription statistics +and [`bdr.stat_relation`](/pgd/5.6/reference/catalogs-visible#bdrstat_relation) for relation statistics. These views both provide: - Number of INSERTs/UPDATEs/DELETEs/TRUNCATEs replicated - Block accesses and cache hit ratio @@ -447,18 +447,18 @@ and [`bdr.stat_relation`](/pgd/latest/reference/catalogs-visible#bdrstat_relatio - Number of in-progress transactions streamed to writers - Number of in-progress streamed transactions committed/aborted -For relations only, [`bdr.stat_relation`](/pgd/latest/reference/catalogs-visible#bdrstat_relation) also includes: +For relations only, [`bdr.stat_relation`](/pgd/5.6/reference/catalogs-visible#bdrstat_relation) also includes: - Total time spent processing replication for the relation - Total lock wait time to acquire lock (if any) for the relation (only) -For subscriptions only, [`bdr.stat_subscription`](/pgd/latest/reference/catalogs-visible#bdrstat_subscription) includes: +For subscriptions only, [`bdr.stat_subscription`](/pgd/5.6/reference/catalogs-visible#bdrstat_subscription) includes: - Number of COMMITs/DDL replicated for the subscription - Number of times this subscription has connected upstream Tracking of these statistics is controlled by the PGD GUCs -[`bdr.track_subscription_apply`](/pgd/latest/reference/pgd-settings#bdrtrack_subscription_apply) and [`bdr.track_relation_apply`](/pgd/latest/reference/pgd-settings#bdrtrack_relation_apply), +[`bdr.track_subscription_apply`](/pgd/5.6/reference/pgd-settings#bdrtrack_subscription_apply) and [`bdr.track_relation_apply`](/pgd/5.6/reference/pgd-settings#bdrtrack_relation_apply), respectively. The following shows the example output from these: @@ -480,9 +480,9 @@ nddl | 2 In this case, the subscription connected three times to the upstream, inserted 10 rows, and performed two DDL commands inside five transactions. -You can reset the stats counters for these views to zero using the functions [`bdr.reset_subscription_stats`](/pgd/latest/reference/functions-internal#bdrreset_subscription_stats) and [`bdr.reset_relation_stats`](/pgd/latest/reference/functions-internal#bdrreset_relation_stats). +You can reset the stats counters for these views to zero using the functions [`bdr.reset_subscription_stats`](/pgd/5.6/reference/functions-internal#bdrreset_subscription_stats) and [`bdr.reset_relation_stats`](/pgd/5.6/reference/functions-internal#bdrreset_relation_stats). -PGD also monitors statistics regarding subscription replication receivers and subscription replication writers for each subscription, using [`bdr.stat_receiver`](/pgd/latest/reference/catalogs-visible/#bdrstat_receiver) and [`bdr.stat_writer`](/pgd/latest/reference/catalogs-visible/#bdrstat_writer), respectively. +PGD also monitors statistics regarding subscription replication receivers and subscription replication writers for each subscription, using [`bdr.stat_receiver`](/pgd/5.6/reference/catalogs-visible/#bdrstat_receiver) and [`bdr.stat_writer`](/pgd/5.6/reference/catalogs-visible/#bdrstat_writer), respectively. ## Standard PostgreSQL statistics views @@ -524,8 +524,8 @@ PGD allows running different Postgres versions as well as different BDR extension versions across the nodes in the same cluster. This capability is useful for upgrading. -The view [`bdr.group_versions_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_versions_details) uses the function -[`bdr.run_on_all_nodes()`](/pgd/latest/reference/functions#bdrrun_on_all_nodes) to retrieve Postgres and BDR extension versions from all +The view [`bdr.group_versions_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_versions_details) uses the function +[`bdr.run_on_all_nodes()`](/pgd/5.6/reference/functions#bdrrun_on_all_nodes) to retrieve Postgres and BDR extension versions from all nodes at the same time. For example: ```sql @@ -550,7 +550,7 @@ For monitoring purposes, we recommend the following alert levels: when compared to other nodes The described behavior is implemented in the function -[`bdr.monitor_group_versions()`](/pgd/latest/reference/functions#bdrmonitor_group_versions), which uses PGD version +[`bdr.monitor_group_versions()`](/pgd/5.6/reference/functions#bdrmonitor_group_versions), which uses PGD version information returned from the view `bdr.group_version_details` to provide a cluster-wide version check. For example: @@ -577,8 +577,8 @@ follows: - PGD group replication slot doesn't advance LSN and thus keeps WAL files on disk. -The view [`bdr.group_raft_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_raft_details) uses the functions -[`bdr.run_on_all_nodes()`](/pgd/latest/reference/functions#bdrrun_on_all_nodes) and [`bdr.get_raft_status()`](/pgd/latest/reference/functions#bdrget_raft_status) to retrieve Raft +The view [`bdr.group_raft_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_raft_details) uses the functions +[`bdr.run_on_all_nodes()`](/pgd/5.6/reference/functions#bdrrun_on_all_nodes) and [`bdr.get_raft_status()`](/pgd/5.6/reference/functions#bdrget_raft_status) to retrieve Raft consensus status from all nodes at the same time. For example: ```sql @@ -645,8 +645,8 @@ monitoring alert levels are defined as follows: than the node set as RAFT_LEADER The described behavior is implemented in the function -[`bdr.monitor_group_raft()`](/pgd/latest/reference/functions#bdrmonitor_group_raft), which uses Raft consensus status -information returned from the view [`bdr.group_raft_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_raft_details) +[`bdr.monitor_group_raft()`](/pgd/5.6/reference/functions#bdrmonitor_group_raft), which uses Raft consensus status +information returned from the view [`bdr.group_raft_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_raft_details) to provide a cluster-wide Raft check. For example: ```sql @@ -656,7 +656,7 @@ node_group_name | status | message mygroup | OK | Raft Consensus is working correctly ``` -Two further views that can give a finer-grained look at the state of Raft consensus are [`bdr.stat_raft_state`](/pgd/latest/reference/catalogs-visible/#bdrstat_raft_state), which provides the state of the Raft consensus on the local node, and [`bdr.stat_raft_followers_state`](/pgd/latest/reference/catalogs-visible/#bdrstat_raft_followers_state), which provides a view when on the Raft leader (it is empty on other nodes) regarding the state of the followers of that Raft leader. +Two further views that can give a finer-grained look at the state of Raft consensus are [`bdr.stat_raft_state`](/pgd/5.6/reference/catalogs-visible/#bdrstat_raft_state), which provides the state of the Raft consensus on the local node, and [`bdr.stat_raft_followers_state`](/pgd/5.6/reference/catalogs-visible/#bdrstat_raft_followers_state), which provides a view when on the Raft leader (it is empty on other nodes) regarding the state of the followers of that Raft leader. ## Monitoring replication slots @@ -681,7 +681,7 @@ FROM pg_replication_slots ORDER BY slot_name; Peer slot names follow the convention `bdr___`, while the PGD group slot name follows the convention `bdr__`. You can access the group slot using the function -[`bdr.local_group_slot_name()`](/pgd/latest/reference/functions#bdrlocal_group_slot_name). +[`bdr.local_group_slot_name()`](/pgd/5.6/reference/functions#bdrlocal_group_slot_name). Peer replication slots must be active on all nodes at all times. If a peer replication slot isn't active, then it might mean either: @@ -698,7 +698,7 @@ maintains this slot and advances its LSN when all other peers already consumed the corresponding transactions. Consequently, it's not necessary to monitor the status of the group slot. -The function [`bdr.monitor_local_replslots()`](/pgd/latest/reference/functions#bdrmonitor_local_replslots) provides a summary of whether all +The function [`bdr.monitor_local_replslots()`](/pgd/5.6/reference/functions#bdrmonitor_local_replslots) provides a summary of whether all PGD node replication slots are working as expected. This summary is also available on subscriber-only nodes that are operating as subscriber-only group leaders in a PGD cluster when [optimized topology](../nodes/subscriber_only/optimizing-so) is enabled. For example: ```sql @@ -724,6 +724,6 @@ One of the following status summaries is returned: By default, PGD transactions are committed only to the local node. In that case, a transaction's `COMMIT` is processed quickly. PGD's [Commit Scopes](../commit-scopes/commit-scopes) feature offers a range of synchronous transaction commit scopes that allow you to balance durability, consistency, and performance for your particular queries. -You can monitor these transactions by examining the [`bdr.stat_activity`](/pgd/latest/reference/catalogs-visible#bdrstat_activity) catalog. The processes report different `wait_event` states as a transaction is committed. This monitoring only covers transactions in progress and doesn't provide historical timing information. +You can monitor these transactions by examining the [`bdr.stat_activity`](/pgd/5.6/reference/catalogs-visible#bdrstat_activity) catalog. The processes report different `wait_event` states as a transaction is committed. This monitoring only covers transactions in progress and doesn't provide historical timing information. diff --git a/product_docs/docs/pgd/5.6/node_management/creating_and_joining.mdx b/product_docs/docs/pgd/5.6/node_management/creating_and_joining.mdx index 91d36338d36..fc9a4e404a5 100644 --- a/product_docs/docs/pgd/5.6/node_management/creating_and_joining.mdx +++ b/product_docs/docs/pgd/5.6/node_management/creating_and_joining.mdx @@ -18,7 +18,7 @@ format, like `host=myhost port=5432 dbname=mydb`, or URI format, like `postgresql://myhost:5432/mydb`. The SQL function -[`bdr.create_node_group()`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node_group) +[`bdr.create_node_group()`](/pgd/5.6/reference/nodes-management-interfaces#bdrcreate_node_group) creates the PGD group from the local node. Doing so activates PGD on that node and allows other nodes to join the PGD group, which consists of only one node at that point. At the time of creation, you must specify the connection string for @@ -26,11 +26,11 @@ other nodes to use to connect to this node. Once the node group is created, every further node can join the PGD group using the -[`bdr.join_node_group()`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) +[`bdr.join_node_group()`](/pgd/5.6/reference/nodes-management-interfaces#bdrjoin_node_group) function. Alternatively, use the command line utility -[bdr_init_physical](/pgd/latest/reference/nodes/#bdr_init_physical) to create a +[bdr_init_physical](/pgd/5.6/reference/nodes/#bdr_init_physical) to create a new node, using `pg_basebackup`. If using `pg_basebackup`, the bdr_init_physical utility can optionally specify the base backup of only the target database. The earlier behavior was to back up the entire database cluster. With this utility, @@ -62,7 +62,7 @@ more details, see [Connections and roles](../security/role-management#connection Optionally, you can skip the schema synchronization using the `synchronize_structure` parameter of the -[`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) +[`bdr.join_node_group`](/pgd/5.6/reference/nodes-management-interfaces#bdrjoin_node_group) function. In this case, the schema must already exist on the newly joining node. We recommend that you select the source node that has the best connection (logically close, ideally with low latency and high bandwidth) @@ -73,7 +73,7 @@ Coordinate the join procedure using the Raft consensus algorithm, which requires most existing nodes to be online and reachable. The logical join procedure (which uses the -[`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) +[`bdr.join_node_group`](/pgd/5.6/reference/nodes-management-interfaces#bdrjoin_node_group) function) performs data sync doing `COPY` operations and uses multiple writers (parallel apply) if those are enabled. @@ -99,6 +99,6 @@ If this is necessary, run LiveCompare on the newly joined node to correct any data divergence once all nodes are available and caught up. `pg_dump` can fail when there's concurrent DDL activity on the source node -because of cache-lookup failures. Since [`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) uses pg_dump +because of cache-lookup failures. Since [`bdr.join_node_group`](/pgd/5.6/reference/nodes-management-interfaces#bdrjoin_node_group) uses pg_dump internally, it might fail if there's concurrent DDL activity on the source node. Retrying the join works in that case. diff --git a/product_docs/docs/pgd/5.6/node_management/creating_nodes.mdx b/product_docs/docs/pgd/5.6/node_management/creating_nodes.mdx index e2fbbee1bc3..d46c68f8ff0 100644 --- a/product_docs/docs/pgd/5.6/node_management/creating_nodes.mdx +++ b/product_docs/docs/pgd/5.6/node_management/creating_nodes.mdx @@ -13,7 +13,7 @@ That means, in the most general terms, you can create a PGD node by installing P ## Which Postgres version? -PGD is built on top of Postgres, so the distribution and version of Postgres you use for your PGD nodes is important. The version of Postgres you use must be compatible with the version of PGD you are using. You can find the compatibility matrix in the [release notes](/pgd/latest/rel_notes). Features and functionality in PGD may depend on the distribution of Postgres you are using. The [EDB Postgres Advanced Server](/epas/latest/) is the recommended distribution for PGD. PGD also supports [EDB Postgres Extended Server](/pge/latest/) and [Community Postgres](https://www.postgresql.org/). You can find out what features are available in each distribution in the Planning section's [Choosing a server](../planning/choosing_server) page. +PGD is built on top of Postgres, so the distribution and version of Postgres you use for your PGD nodes is important. The version of Postgres you use must be compatible with the version of PGD you are using. You can find the compatibility matrix in the [release notes](/pgd/5.6/rel_notes). Features and functionality in PGD may depend on the distribution of Postgres you are using. The [EDB Postgres Advanced Server](/epas/latest/) is the recommended distribution for PGD. PGD also supports [EDB Postgres Extended Server](/pge/latest/) and [Community Postgres](https://www.postgresql.org/). You can find out what features are available in each distribution in the Planning section's [Choosing a server](../planning/choosing_server) page. ## Installing Postgres @@ -35,7 +35,7 @@ This process is specific to PGD and involves configuring the Postgres instance t * Increase the maximum worker processes to 16 or higher by setting `max_worker_processes` to `'16'` in `postgresql.conf`.

!!! Note The `max_worker_processes` value The `max_worker_processes` value is derived from the topology of the cluster, the number of peers, number of databases, and other factors. - To calculate the needed value, see [Postgres configuration/settings](/pgd/latest/postgres-configuration/#postgres-settings). + To calculate the needed value, see [Postgres configuration/settings](/pgd/5.6/postgres-configuration/#postgres-settings). The value of 16 was calculated for the size of cluster being deployed in this example. It must be increased for larger clusters. !!! * Set a password on the EnterprisedDB/Postgres user. diff --git a/product_docs/docs/pgd/5.6/node_management/heterogeneous_clusters.mdx b/product_docs/docs/pgd/5.6/node_management/heterogeneous_clusters.mdx index 62a3feed9c2..f28f10488a0 100644 --- a/product_docs/docs/pgd/5.6/node_management/heterogeneous_clusters.mdx +++ b/product_docs/docs/pgd/5.6/node_management/heterogeneous_clusters.mdx @@ -22,7 +22,7 @@ join the cluster. Don't run any DDLs that might not be available on the older versions and vice versa. A node joining with a different major PostgreSQL release can't use -physical backup taken with [`bdr_init_physical`](/pgd/latest/reference/nodes#bdr_init_physical), and the node must join +physical backup taken with [`bdr_init_physical`](/pgd/5.6/reference/nodes#bdr_init_physical), and the node must join using the logical join method. Using this method is necessary because the major PostgreSQL releases aren't on-disk compatible with each other. diff --git a/product_docs/docs/pgd/5.6/node_management/maintainance_with_proxies.mdx b/product_docs/docs/pgd/5.6/node_management/maintainance_with_proxies.mdx index 242d1436ab6..5101440baa0 100644 --- a/product_docs/docs/pgd/5.6/node_management/maintainance_with_proxies.mdx +++ b/product_docs/docs/pgd/5.6/node_management/maintainance_with_proxies.mdx @@ -39,7 +39,7 @@ select node_name from bdr.node; ``` !!! Tip -For more details, see the [`bdr.node`](/pgd/latest/reference/catalogs-visible#bdrnode) table. +For more details, see the [`bdr.node`](/pgd/5.6/reference/catalogs-visible#bdrnode) table. !!! This command lists just the node names. If you need to know the group they are a member of, use: @@ -49,7 +49,7 @@ select node_name, node_group_name from bdr.node_summary; ``` !!! Tip -For more details, see the [`bdr.node_summary`](/pgd/latest/reference/catalogs-visible#bdrnode_summary) table. +For more details, see the [`bdr.node_summary`](/pgd/5.6/reference/catalogs-visible#bdrnode_summary) table. !!! ## Finding the write leader diff --git a/product_docs/docs/pgd/5.6/node_management/node_recovery.mdx b/product_docs/docs/pgd/5.6/node_management/node_recovery.mdx index b05ac8daaea..69efdd1ed35 100644 --- a/product_docs/docs/pgd/5.6/node_management/node_recovery.mdx +++ b/product_docs/docs/pgd/5.6/node_management/node_recovery.mdx @@ -7,7 +7,7 @@ PGD is designed to recover from node restart or node disconnection. The disconnected node rejoins the group by reconnecting to each peer node and then replicating any missing data from that node. -When a node starts up, each connection begins showing up in [`bdr.node_slots`](/pgd/latest/reference/catalogs-visible#bdrnode_slots) with +When a node starts up, each connection begins showing up in [`bdr.node_slots`](/pgd/5.6/reference/catalogs-visible#bdrnode_slots) with `bdr.node_slots.state = catchup` and begins replicating missing data. Catching up continues for a period of time that depends on the amount of missing data from each peer node and will likely increase diff --git a/product_docs/docs/pgd/5.6/node_management/removing_nodes_and_groups.mdx b/product_docs/docs/pgd/5.6/node_management/removing_nodes_and_groups.mdx index 1ba218e14c8..70375e74a19 100644 --- a/product_docs/docs/pgd/5.6/node_management/removing_nodes_and_groups.mdx +++ b/product_docs/docs/pgd/5.6/node_management/removing_nodes_and_groups.mdx @@ -10,9 +10,9 @@ permanently. If you permanently shut down a node and don't tell the other nodes, then performance suffers and eventually the whole system stops working. -Node removal, also called *parting*, is done using the [`bdr.part_node()`](/pgd/latest/reference/nodes-management-interfaces#bdrpart_node) +Node removal, also called *parting*, is done using the [`bdr.part_node()`](/pgd/5.6/reference/nodes-management-interfaces#bdrpart_node) function. You must specify the node name (as passed during node creation) -to remove a node. You can call the [`bdr.part_node()`](/pgd/latest/reference/nodes-management-interfaces#bdrpart_node) function from any active +to remove a node. You can call the [`bdr.part_node()`](/pgd/5.6/reference/nodes-management-interfaces#bdrpart_node) function from any active node in the PGD group, including the node that you're removing. Just like the join procedure, parting is done using Raft consensus and requires a @@ -26,7 +26,7 @@ most recent node to allow them to catch up any missing data. A parted node still is known to PGD but doesn't consume resources. A node might be added again under the same name as a parted node. In rare cases, you might want to clear all metadata of a parted -node by using the function [`bdr.drop_node()`](/pgd/latest/reference/functions-internal#bdrdrop_node). +node by using the function [`bdr.drop_node()`](/pgd/5.6/reference/functions-internal#bdrdrop_node). ## Removing a whole PGD group diff --git a/product_docs/docs/pgd/5.6/node_management/replication_slots.mdx b/product_docs/docs/pgd/5.6/node_management/replication_slots.mdx index 8fbe149f7ff..d734c6c9c1a 100644 --- a/product_docs/docs/pgd/5.6/node_management/replication_slots.mdx +++ b/product_docs/docs/pgd/5.6/node_management/replication_slots.mdx @@ -42,7 +42,7 @@ The group slot is an internal slot used by PGD primarily to track the oldest safe position that any node in the PGD group (including all logical standbys) has caught up to, for any outbound replication from this node. -The group slot name is given by the function [`bdr.local_group_slot_name()`](/pgd/latest/reference/functions#bdrlocal_group_slot_name). +The group slot name is given by the function [`bdr.local_group_slot_name()`](/pgd/5.6/reference/functions#bdrlocal_group_slot_name). The group slot can: diff --git a/product_docs/docs/pgd/5.6/node_management/viewing_topology.mdx b/product_docs/docs/pgd/5.6/node_management/viewing_topology.mdx index e9732a872ff..9b5d54f288a 100644 --- a/product_docs/docs/pgd/5.6/node_management/viewing_topology.mdx +++ b/product_docs/docs/pgd/5.6/node_management/viewing_topology.mdx @@ -26,7 +26,7 @@ pgd show-groups The following simple query lists all the PGD node groups of which the current node is a member. It currently returns only one row from -[`bdr.local_node_summary`](/pgd/latest/reference/catalogs-visible#bdrlocal_node_summary). +[`bdr.local_node_summary`](/pgd/5.6/reference/catalogs-visible#bdrlocal_node_summary). ```sql SELECT node_group_name @@ -85,7 +85,7 @@ pgd show-nodes | grep group_b ### Using SQL You can extract the list of all nodes in a given node group (such as `mygroup`) -from the [`bdr.node_summary`](/pgd/latest/reference/catalogs-visible#bdrnode_summary)` view. For example: +from the [`bdr.node_summary`](/pgd/5.6/reference/catalogs-visible#bdrnode_summary)` view. For example: ```sql SELECT node_name AS name diff --git a/product_docs/docs/pgd/5.6/nodes/logical_standby_nodes.mdx b/product_docs/docs/pgd/5.6/nodes/logical_standby_nodes.mdx index a18d28fe430..44cc1e4ce39 100644 --- a/product_docs/docs/pgd/5.6/nodes/logical_standby_nodes.mdx +++ b/product_docs/docs/pgd/5.6/nodes/logical_standby_nodes.mdx @@ -14,17 +14,17 @@ A master node can have zero, one, or more logical standby nodes. location is always preferred. Logical standby nodes are nodes that are held in a state of continual recovery, -constantly updating until they're required. This behavior is similar to how Postgres physical standbys operate while using logical replication for better performance. [`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) has the `pause_in_standby` +constantly updating until they're required. This behavior is similar to how Postgres physical standbys operate while using logical replication for better performance. [`bdr.join_node_group`](/pgd/5.6/reference/nodes-management-interfaces#bdrjoin_node_group) has the `pause_in_standby` option to make the node stay in halfway-joined as a logical standby node. Logical standby nodes receive changes but don't send changes made locally to other nodes. Later, if you want, use -[`bdr.promote_node`](/pgd/latest/reference/nodes-management-interfaces#bdrpromote_node) +[`bdr.promote_node`](/pgd/5.6/reference/nodes-management-interfaces#bdrpromote_node) to move the logical standby into a full, normal send/receive node. A logical standby is sent data by one source node, defined by the DSN in -[`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group). +[`bdr.join_node_group`](/pgd/5.6/reference/nodes-management-interfaces#bdrjoin_node_group). Changes from all other nodes are received from this one source node, minimizing bandwidth between multiple sites. diff --git a/product_docs/docs/pgd/5.6/nodes/subscriber_only/creating-so.mdx b/product_docs/docs/pgd/5.6/nodes/subscriber_only/creating-so.mdx index b95a5b31985..323b953891a 100644 --- a/product_docs/docs/pgd/5.6/nodes/subscriber_only/creating-so.mdx +++ b/product_docs/docs/pgd/5.6/nodes/subscriber_only/creating-so.mdx @@ -28,7 +28,7 @@ This creates a Subscriber-only group named `sogroup` which is a child of the `to ## Adding a node to a new Subscriber-only group manually -You can now initialize a new data node and then add it to the Subscriber-only group. Create a data node and configure the bdr extension on it as you would for any other data node. If you deployed manually, see the [manual install guide](/pgd/latest/deploy-config/deploy-manual/deploying/04-installing-software/) for instructions on how to install and deploy a data node. +You can now initialize a new data node and then add it to the Subscriber-only group. Create a data node and configure the bdr extension on it as you would for any other data node. If you deployed manually, see the [manual install guide](/pgd/5.6/deploy-config/deploy-manual/deploying/04-installing-software/) for instructions on how to install and deploy a data node. You now have to create this new node as a `subscriber-only` node. To do this, log into the new node and run the following SQL command: diff --git a/product_docs/docs/pgd/5.6/nodes/subscriber_only/optimizing-so.mdx b/product_docs/docs/pgd/5.6/nodes/subscriber_only/optimizing-so.mdx index fbe4bd5416f..7ddaa7c19dc 100644 --- a/product_docs/docs/pgd/5.6/nodes/subscriber_only/optimizing-so.mdx +++ b/product_docs/docs/pgd/5.6/nodes/subscriber_only/optimizing-so.mdx @@ -56,7 +56,7 @@ The subscriber-only node and group form the building block for PGD tree topologi By default, PGD 5.6 forces the full mesh topology. This means the optimization described here is off. To enable the optimized topology, you must have your data nodes in subgroups, with proxy routing enabled on the subgroups. -You can then set the GUC [`bdr.force_full_mesh`](/pgd/latest/reference/pgd-settings#bdrforce_full_mesh) to `off` to allow the optimization to be activated. +You can then set the GUC [`bdr.force_full_mesh`](/pgd/5.6/reference/pgd-settings#bdrforce_full_mesh) to `off` to allow the optimization to be activated. !!! Note This GUC needs to be set in the `postgresql.conf` file on each data node and each node restarted for the change to take effect. diff --git a/product_docs/docs/pgd/5.6/parallelapply.mdx b/product_docs/docs/pgd/5.6/parallelapply.mdx index 726f0b79f61..1964444d8cb 100644 --- a/product_docs/docs/pgd/5.6/parallelapply.mdx +++ b/product_docs/docs/pgd/5.6/parallelapply.mdx @@ -13,9 +13,9 @@ subscription and improves replication performance. ### Configuring Parallel Apply Two variables control Parallel Apply in PGD 5: -[`bdr.max_writers_per_subscription`](/pgd/latest/reference/pgd-settings#bdrmax_writers_per_subscription) +[`bdr.max_writers_per_subscription`](/pgd/5.6/reference/pgd-settings#bdrmax_writers_per_subscription) (defaults to 8) and -[`bdr.writers_per_subscription`](/pgd/latest/reference/pgd-settings#bdrwriters_per_subscription) +[`bdr.writers_per_subscription`](/pgd/5.6/reference/pgd-settings#bdrwriters_per_subscription) (defaults to 2). ```plain @@ -26,18 +26,18 @@ bdr.writers_per_subscription = 2 This configuration gives each subscription two writers. However, in some circumstances, the system might allocate up to eight writers for a subscription. -Changing [`bdr.max_writers_per_subscription`](/pgd/latest/reference/pgd-settings#bdrmax_writers_per_subscription) +Changing [`bdr.max_writers_per_subscription`](/pgd/5.6/reference/pgd-settings#bdrmax_writers_per_subscription) requires a server restart to take effect. You can change -[`bdr.writers_per_subscription`](/pgd/latest/reference/pgd-settings#bdrwriters_per_subscription) +[`bdr.writers_per_subscription`](/pgd/5.6/reference/pgd-settings#bdrwriters_per_subscription) for a specific subscription without a restart by: 1. Halting the subscription using - [`bdr.alter_subscription_disable`](/pgd/latest/reference/nodes-management-interfaces#bdralter_subscription_disable). + [`bdr.alter_subscription_disable`](/pgd/5.6/reference/nodes-management-interfaces#bdralter_subscription_disable). 1. Setting the new value. 1. Resuming the subscription using - [`bdr.alter_subscription_enable`](/pgd/latest/reference/nodes-management-interfaces#bdralter_subscription_enable). + [`bdr.alter_subscription_enable`](/pgd/5.6/reference/nodes-management-interfaces#bdralter_subscription_enable). First though, establish the name of the subscription using `select * from @@ -61,7 +61,7 @@ Parallel Apply is always on by default and, for most operations, we recommend le ### Monitoring Parallel Apply To support Parallel Apply's deadlock mitigation, PGD 5.2 adds columns to -[`bdr.stat_subscription`](/pgd/latest/reference/catalogs-visible#bdrstat_subscription). +[`bdr.stat_subscription`](/pgd/5.6/reference/catalogs-visible#bdrstat_subscription). The new columns are `nprovisional_waits`, `ntuple_waits`, and `ncommmit_waits`. These are metrics that indicate how well Parallel Apply is managing what previously would have been deadlocks. They don't reflect overall system @@ -77,7 +77,7 @@ are counted in `ncommit_waits`. ### Disabling Parallel Apply -To disable Parallel Apply, set [`bdr.writers_per_subscription`](/pgd/latest/reference/pgd-settings#bdrwriters_per_subscription) to `1`. +To disable Parallel Apply, set [`bdr.writers_per_subscription`](/pgd/5.6/reference/pgd-settings#bdrwriters_per_subscription) to `1`. ### Deadlock mitigation diff --git a/product_docs/docs/pgd/5.6/planning/architectures.mdx b/product_docs/docs/pgd/5.6/planning/architectures.mdx index 45171806f3f..6d9091c1b95 100644 --- a/product_docs/docs/pgd/5.6/planning/architectures.mdx +++ b/product_docs/docs/pgd/5.6/planning/architectures.mdx @@ -1,11 +1,11 @@ --- title: "Choosing your architecture" redirects: - - /pgd/latest/architectures/bronze/ - - /pgd/latest/architectures/gold/ - - /pgd/latest/architectures/platinum/ - - /pgd/latest/architectures/silver/ - - /pgd/latest/architectures/ + - /pgd/5.6/architectures/bronze/ + - /pgd/5.6/architectures/gold/ + - /pgd/5.6/architectures/platinum/ + - /pgd/5.6/architectures/silver/ + - /pgd/5.6/architectures/ --- Always-on architectures reflect EDB’s Trusted Postgres architectures. They diff --git a/product_docs/docs/pgd/5.6/planning/choosing_server.mdx b/product_docs/docs/pgd/5.6/planning/choosing_server.mdx index 77fd46b098f..172740ff553 100644 --- a/product_docs/docs/pgd/5.6/planning/choosing_server.mdx +++ b/product_docs/docs/pgd/5.6/planning/choosing_server.mdx @@ -1,7 +1,7 @@ --- title: "Choosing a Postgres distribution" redirects: - - /pgd/latest/choosing_server/ + - /pgd/5.6/choosing_server/ --- EDB Postgres Distributed can be deployed with three different Postgres distributions: PostgreSQL, EDB Postgres Extended Server, or EDB Postgres Advanced Server. The availability of particular EDB Postgres Distributed features depends on the Postgres distribution being used. Therefore, it's essential to adopt the Postgres distribution best suited to your business needs. For example, if having the Commit At Most Once (CAMO) feature is mission critical to your use case, don't adopt open source PostgreSQL, which doesn't have the core capabilities required to handle CAMO. @@ -10,28 +10,28 @@ The following table lists features of EDB Postgres Distributed that are dependen | Feature | PostgreSQL | EDB Postgres Extended | EDB Postgres Advanced | | ----------------------------------------------------------------------------------------------------------------------- | ---------- | --------------------- | --------------------- | -| [Rolling application and database upgrades](/pgd/latest/upgrades/) | Y | Y | Y | -| [Row-level last-update wins conflict resolution](/pgd/latest/conflict-management/conflicts/) | Y | Y | Y | -| [DDL replication](/pgd/latest/ddl/) | Y | Y | Y | -| [Granular DDL Locking](/pgd/latest/ddl/ddl-locking/) | Y | Y | Y | -| [Streaming of large transactions](/pgd/latest/transaction-streaming/) | v14+ | v13+ | v14+ | -| [Distributed sequences](/pgd/latest/sequences/#pgd-global-sequences) | Y | Y | Y | -| [Subscriber-only nodes](/pgd/latest/nodes/subscriber_only/) | Y | Y | Y | -| [Monitoring](/pgd/latest/monitoring/) | Y | Y | Y | -| [OpenTelemetry support](/pgd/latest/monitoring/otel/) | Y | Y | Y | -| [Parallel apply](/pgd/latest/parallelapply) | Y | Y | Y | -| [Conflict-free replicated data types (CRDTs)](/pgd/latest/conflict-management/crdt/) | Y | Y | Y | -| [Column-level conflict resolution](/pgd/latest/conflict-management/column-level-conflicts/) | Y | Y | Y | -| [Transform triggers](/pgd/latest/striggers/#transform-triggers) | Y | Y | Y | -| [Conflict triggers](/pgd/latest/striggers/#conflict-triggers) | Y | Y | Y | -| [Asynchronous replication](/pgd/latest/commit-scopes/) | Y | Y | Y | -| [Legacy synchronous replication](/pgd/latest/commit-scopes/legacy-sync/) | Y | Y | Y | -| [Group Commit](/pgd/latest/commit-scopes/group-commit/) | N | Y | 14+ | -| [Commit At Most Once (CAMO)](/pgd/latest/commit-scopes/camo/) | N | Y | 14+ | -| [Eager Conflict Resolution](/pgd/latest/commit-scopes/group-commit/#eager-conflict-resolution) | N | Y | 14+ | -| [Lag Control](/pgd/latest/commit-scopes/lag-control/) | N | Y | 14+ | -| [Decoding Worker](/pgd/latest/decoding_worker) | N | 13+ | 14+ | -| [Lag tracker](/pgd/latest/monitoring/sql/#monitoring-outgoing-replication) | N | Y | 14+ | +| [Rolling application and database upgrades](/pgd/5.6/upgrades/) | Y | Y | Y | +| [Row-level last-update wins conflict resolution](/pgd/5.6/conflict-management/conflicts/) | Y | Y | Y | +| [DDL replication](/pgd/5.6/ddl/) | Y | Y | Y | +| [Granular DDL Locking](/pgd/5.6/ddl/ddl-locking/) | Y | Y | Y | +| [Streaming of large transactions](/pgd/5.6/transaction-streaming/) | v14+ | v13+ | v14+ | +| [Distributed sequences](/pgd/5.6/sequences/#pgd-global-sequences) | Y | Y | Y | +| [Subscriber-only nodes](/pgd/5.6/nodes/subscriber_only/) | Y | Y | Y | +| [Monitoring](/pgd/5.6/monitoring/) | Y | Y | Y | +| [OpenTelemetry support](/pgd/5.6/monitoring/otel/) | Y | Y | Y | +| [Parallel apply](/pgd/5.6/parallelapply) | Y | Y | Y | +| [Conflict-free replicated data types (CRDTs)](/pgd/5.6/conflict-management/crdt/) | Y | Y | Y | +| [Column-level conflict resolution](/pgd/5.6/conflict-management/column-level-conflicts/) | Y | Y | Y | +| [Transform triggers](/pgd/5.6/striggers/#transform-triggers) | Y | Y | Y | +| [Conflict triggers](/pgd/5.6/striggers/#conflict-triggers) | Y | Y | Y | +| [Asynchronous replication](/pgd/5.6/commit-scopes/) | Y | Y | Y | +| [Legacy synchronous replication](/pgd/5.6/commit-scopes/legacy-sync/) | Y | Y | Y | +| [Group Commit](/pgd/5.6/commit-scopes/group-commit/) | N | Y | 14+ | +| [Commit At Most Once (CAMO)](/pgd/5.6/commit-scopes/camo/) | N | Y | 14+ | +| [Eager Conflict Resolution](/pgd/5.6/commit-scopes/group-commit/#eager-conflict-resolution) | N | Y | 14+ | +| [Lag Control](/pgd/5.6/commit-scopes/lag-control/) | N | Y | 14+ | +| [Decoding Worker](/pgd/5.6/decoding_worker) | N | 13+ | 14+ | +| [Lag tracker](/pgd/5.6/monitoring/sql/#monitoring-outgoing-replication) | N | Y | 14+ | | [Missing partition conflict](../reference/conflicts/#target_table_note) | N | Y | 14+ | | [No need for UPDATE Trigger on tables with TOAST](../conflict-management/conflicts/02_types_of_conflict/#toast-support-details) | N | Y | 14+ | | [Automatically hold back FREEZE](../conflict-management/conflicts/03_conflict_detection/#origin-conflict-detection) | N | Y | 14+ | diff --git a/product_docs/docs/pgd/5.6/planning/deployments.mdx b/product_docs/docs/pgd/5.6/planning/deployments.mdx index d5116ed8e8a..f8c09038a8c 100644 --- a/product_docs/docs/pgd/5.6/planning/deployments.mdx +++ b/product_docs/docs/pgd/5.6/planning/deployments.mdx @@ -2,7 +2,7 @@ title: "Choosing your deployment method" indexCards: simple redirects: -- /pgd/latest/deployments +- /pgd/5.6/deployments --- You can deploy and install EDB Postgres Distributed products using the following methods: diff --git a/product_docs/docs/pgd/5.6/planning/limitations.mdx b/product_docs/docs/pgd/5.6/planning/limitations.mdx index c2c490c0c42..f1f183e76b7 100644 --- a/product_docs/docs/pgd/5.6/planning/limitations.mdx +++ b/product_docs/docs/pgd/5.6/planning/limitations.mdx @@ -1,7 +1,7 @@ --- title: "Limitations" redirects: -- /pgd/latest/limitations +- /pgd/5.6/limitations --- Take these EDB Postgres Distributed (PGD) design limitations @@ -71,37 +71,14 @@ Also, there are limitations on interoperability with legacy synchronous replicat interoperability with explicit two-phase commit, and unsupported combinations within commit scope rules. -See [Durability limitations](/pgd/latest/commit-scopes/limitations/) for a full +See [Durability limitations](/pgd/5.6/commit-scopes/limitations/) for a full and current listing. ## Mixed PGD versions -While PGD was developed to [enable rolling upgrades of -PGD](/pgd/latest/upgrades) by allowing mixed versions of PGD to operate during -the upgrade process, we expect users to run mixed versions only during upgrades -and for users to complete their upgrades as quickly as possible. We also -recommend that you test any rolling upgrade process in a non-production -environment before attempting it in production. - -When a node is upgraded, it returns to the cluster and communicates with the -other nodes in the cluster using the lowest version of the inter-node protocol -that is supported by all the other nodes in the cluster. This means that the -upgraded node will be able to communicate with all other nodes in the cluster, -but it will not be able to take advantage of any new features or improvements -that were introduced in the newer version of PGD. - -That will stay the case until all nodes in the cluster have been upgraded to the -same newer version. The longer you run mixed versions, the longer you will be -without the benefits of the new version, and the longer you will be exposed to -any potential interoperability issues that might arise from running mixed -versions. Mixed version clusters are not supported for extended periods of time. - -Therefore, once an PGD cluster upgrade has begun, you should complete the whole -cluster upgrade as quickly as possible. - -We don't support running mixed versions of PGD except during an upgrade, and we don't support clusters running mixed versions even while being upgraded, for extended periods. - -For more information on rolling upgrades and mixed versions, see [Rolling upgrade considerations](/pgd/latest/upgrades/manual_overview#rolling-upgrade-considerations). +PGD was developed to [enable rolling upgrades of PGD](/pgd/5.6/upgrades) by allowing mixed versions of PGD to operate during the upgrade process. +We expect users to run mixed versions only during upgrades and, once an upgrade starts, that they complete that upgrade. +We don't support running mixed versions of PGD except during an upgrade. ## Other limitations diff --git a/product_docs/docs/pgd/5.6/planning/other_considerations.mdx b/product_docs/docs/pgd/5.6/planning/other_considerations.mdx index 7c1025cab20..963a763a1b2 100644 --- a/product_docs/docs/pgd/5.6/planning/other_considerations.mdx +++ b/product_docs/docs/pgd/5.6/planning/other_considerations.mdx @@ -1,14 +1,14 @@ --- title: "Other considerations" redirects: -- /pgd/latest/other_considerations +- /pgd/5.6/other_considerations --- Review these other considerations when planning your deployment. ## Data consistency -Read about [Conflicts](/pgd/latest/conflict-management/conflicts/) to understand the implications of the asynchronous operation mode in terms of data consistency. +Read about [Conflicts](/pgd/5.6/conflict-management/conflicts/) to understand the implications of the asynchronous operation mode in terms of data consistency. ## Deployment @@ -32,4 +32,4 @@ EDB Postgres Distributed is designed to operate with nodes in multiple timezones Synchronize server clocks using NTP or other solutions. -Clock synchronization isn't critical to performance, as it is with some other solutions. Clock skew can affect origin conflict detection, though EDB Postgres Distributed provides controls to report and manage any skew that exists. EDB Postgres Distributed also provides row-version conflict detection, as described in [Conflict detection](/pgd/latest/conflict-management/conflicts/). +Clock synchronization isn't critical to performance, as it is with some other solutions. Clock skew can affect origin conflict detection, though EDB Postgres Distributed provides controls to report and manage any skew that exists. EDB Postgres Distributed also provides row-version conflict detection, as described in [Conflict detection](/pgd/5.6/conflict-management/conflicts/). diff --git a/product_docs/docs/pgd/5.6/quickstart/quick_start_aws.mdx b/product_docs/docs/pgd/5.6/quickstart/quick_start_aws.mdx index c120a37cfe9..e37d550c1c3 100644 --- a/product_docs/docs/pgd/5.6/quickstart/quick_start_aws.mdx +++ b/product_docs/docs/pgd/5.6/quickstart/quick_start_aws.mdx @@ -4,9 +4,9 @@ navTitle: "Deploying on AWS" description: > A quick demonstration of deploying a PGD architecture using TPA on Amazon EC2 redirects: - - /pgd/latest/deployments/tpaexec/quick_start/ - - /pgd/latest/tpa/quick_start/ - - /pgd/latest/quick_start_aws/ + - /pgd/5.6/deployments/tpaexec/quick_start/ + - /pgd/5.6/tpa/quick_start/ + - /pgd/5.6/quick_start_aws/ --- diff --git a/product_docs/docs/pgd/5.6/quickstart/quick_start_cloud.mdx b/product_docs/docs/pgd/5.6/quickstart/quick_start_cloud.mdx index 2e01eee8bf3..26068f9a9e7 100644 --- a/product_docs/docs/pgd/5.6/quickstart/quick_start_cloud.mdx +++ b/product_docs/docs/pgd/5.6/quickstart/quick_start_cloud.mdx @@ -4,7 +4,7 @@ navTitle: "Deploying on Azure and Google" description: > A quick guide to deploying a PGD architecture using TPA on Azure and Google clouds redirects: - - /pgd/latest/quick_start_cloud/ + - /pgd/5.6/quick_start_cloud/ hideToC: True --- diff --git a/product_docs/docs/pgd/5.6/quickstart/quick_start_docker.mdx b/product_docs/docs/pgd/5.6/quickstart/quick_start_docker.mdx index 61e9c0b885e..69ffe00ebc5 100644 --- a/product_docs/docs/pgd/5.6/quickstart/quick_start_docker.mdx +++ b/product_docs/docs/pgd/5.6/quickstart/quick_start_docker.mdx @@ -4,7 +4,7 @@ navTitle: "Deploying on Docker" description: > A quick demonstration of deploying a PGD architecture using TPA on Docker redirects: - - /pgd/latest/quick_start_docker/ + - /pgd/5.6/quick_start_docker/ --- diff --git a/product_docs/docs/pgd/5.6/quickstart/quick_start_linux.mdx b/product_docs/docs/pgd/5.6/quickstart/quick_start_linux.mdx index 1e5fbe0f393..c7ff9ccf2ef 100644 --- a/product_docs/docs/pgd/5.6/quickstart/quick_start_linux.mdx +++ b/product_docs/docs/pgd/5.6/quickstart/quick_start_linux.mdx @@ -4,7 +4,7 @@ navTitle: "Deploying on Linux hosts" description: > A quick demonstration of deploying a PGD architecture using TPA on Linux hosts redirects: - - /pgd/latest/quick_start_bare/ + - /pgd/5.6/quick_start_bare/ --- ## Introducing TPA and PGD diff --git a/product_docs/docs/pgd/5.6/reference/catalogs-internal.mdx b/product_docs/docs/pgd/5.6/reference/catalogs-internal.mdx index df6820f9b89..0fe425eb082 100644 --- a/product_docs/docs/pgd/5.6/reference/catalogs-internal.mdx +++ b/product_docs/docs/pgd/5.6/reference/catalogs-internal.mdx @@ -71,7 +71,7 @@ node. Specifically, it tracks: * Node joins (to the cluster) * Raft state changes (that is, whenever the node changes its role in the consensus protocol - leader, follower, or candidate to leader); see [Monitoring Raft consensus](../monitoring/sql#monitoring-raft-consensus) -* Whenever a worker has errored out (see [bdr.workers](/pgd/latest/reference/catalogs-visible/#bdrworkers) +* Whenever a worker has errored out (see [bdr.workers](/pgd/5.6/reference/catalogs-visible/#bdrworkers) and [Monitoring PGD replication workers](../monitoring/sql#monitoring-pgd-replication-workers)) #### `bdr.event_history` columns @@ -94,7 +94,7 @@ as textual representations rather than integers. ### `bdr.local_leader_change` -This is a local cache of the recent portion of leader change history. It has the same fields as [`bdr.leader`](/pgd/latest/reference/catalogs-visible#bdrleader), except that it is an ordered set of (node_group_id, leader_kind, generation) instead of a map tracking merely the current version. +This is a local cache of the recent portion of leader change history. It has the same fields as [`bdr.leader`](/pgd/5.6/reference/catalogs-visible#bdrleader), except that it is an ordered set of (node_group_id, leader_kind, generation) instead of a map tracking merely the current version. diff --git a/product_docs/docs/pgd/5.6/reference/catalogs-visible.mdx b/product_docs/docs/pgd/5.6/reference/catalogs-visible.mdx index 44355815073..be2d2b9363e 100644 --- a/product_docs/docs/pgd/5.6/reference/catalogs-visible.mdx +++ b/product_docs/docs/pgd/5.6/reference/catalogs-visible.mdx @@ -969,7 +969,7 @@ A view containing all the necessary info about the replication subscription rece | sub_slot_name | name | Replication slot name used by the receiver | source_name | name | Source node for this receiver (the one it connects to), this is normally the same as the origin node, but is different for forward mode subscriptions | origin_name | name | The origin node for this receiver (the one it receives forwarded changes from), this is normally the same as the source node, but is different for forward mode subscriptions -| subscription_mode | char | Mode of the subscription, see [`bdr.subscription_summary`](/pgd/latest/reference/catalogs-visible/#bdrsubscription_summary) for more details +| subscription_mode | char | Mode of the subscription, see [`bdr.subscription_summary`](/pgd/5.6/reference/catalogs-visible/#bdrsubscription_summary) for more details | sub_replication_sets| text[] | Replication sets this receiver is subscribed to | sub_apply_delay | interval | Apply delay interval | receive_lsn | pg_lsn | LSN of the last change received so far diff --git a/product_docs/docs/pgd/5.6/reference/commit-scopes.mdx b/product_docs/docs/pgd/5.6/reference/commit-scopes.mdx index 1dfcedd54a9..c202d0a7cf4 100644 --- a/product_docs/docs/pgd/5.6/reference/commit-scopes.mdx +++ b/product_docs/docs/pgd/5.6/reference/commit-scopes.mdx @@ -7,13 +7,13 @@ rootisheading: false deepToC: true --- -Commit scopes are rules that determine how transaction commits and conflicts are handled within a PGD system. You can read more about them in [Commit Scopes](/pgd/latest/commit-scopes/). +Commit scopes are rules that determine how transaction commits and conflicts are handled within a PGD system. You can read more about them in [Commit Scopes](/pgd/5.6/commit-scopes/). You can manipulate commit scopes using the following functions: -- [`bdr.create_commit_scope`](/pgd/latest/reference/functions#bdrcreate_commit_scope) -- [`bdr.alter_commit_scope`](/pgd/latest/reference/functions#bdralter_commit_scope) -- [`bdr.drop_commit_scope`](/pgd/latest/reference/functions#bdrdrop_commit_scope) +- [`bdr.create_commit_scope`](/pgd/5.6/reference/functions#bdrcreate_commit_scope) +- [`bdr.alter_commit_scope`](/pgd/5.6/reference/functions#bdralter_commit_scope) +- [`bdr.drop_commit_scope`](/pgd/5.6/reference/functions#bdrdrop_commit_scope) ## Commit scope syntax @@ -55,7 +55,7 @@ Where `node_group` is the name of a PGD data node group. The `commit_scope_degrade_operation` is either the same commit scope kind with a less restrictive commit scope group as the overall rule being defined, or is asynchronous (`ASYNC`). -For instance, [you can degrade](/pgd/latest/commit-scopes/degrading/) from an `ALL SYNCHRONOUS COMMIT` to a `MAJORITY SYNCHRONOUS COMMIT` or a `MAJORITY SYNCHRONOUS COMMIT` to an `ANY 3 SYNCHRONOUS COMMIT` or even an `ANY 3 SYNCHRONOUS COMMIT` to an `ANY 2 SYNCHRONOUS COMMIT`. You can also degrade from `SYNCHRONOUS COMMIT` to `ASYNC`. However, you cannot degrade from `SYNCHRONOUS COMMIT` to `GROUP COMMIT` or the other way around, regardless of the commit scope groups involved. +For instance, [you can degrade](/pgd/5.6/commit-scopes/degrading/) from an `ALL SYNCHRONOUS COMMIT` to a `MAJORITY SYNCHRONOUS COMMIT` or a `MAJORITY SYNCHRONOUS COMMIT` to an `ANY 3 SYNCHRONOUS COMMIT` or even an `ANY 3 SYNCHRONOUS COMMIT` to an `ANY 2 SYNCHRONOUS COMMIT`. You can also degrade from `SYNCHRONOUS COMMIT` to `ASYNC`. However, you cannot degrade from `SYNCHRONOUS COMMIT` to `GROUP COMMIT` or the other way around, regardless of the commit scope groups involved. It is also possible to combine rules using `AND`, each with their own degradation clause: diff --git a/product_docs/docs/pgd/5.6/reference/functions-internal.mdx b/product_docs/docs/pgd/5.6/reference/functions-internal.mdx index b275c29e62c..8ef4c635e9c 100644 --- a/product_docs/docs/pgd/5.6/reference/functions-internal.mdx +++ b/product_docs/docs/pgd/5.6/reference/functions-internal.mdx @@ -177,7 +177,7 @@ Use of this internal function is limited to: * When you're instructed to by EDB Technical Support. * Where you're specifically instructed to in the documentation. -Use [`bdr.part_node`](/pgd/latest/reference/nodes-management-interfaces#bdrpart_node) to remove a node from a PGD group. That function sets the node to `PARTED` state and enables reuse of the node name. +Use [`bdr.part_node`](/pgd/5.6/reference/nodes-management-interfaces#bdrpart_node) to remove a node from a PGD group. That function sets the node to `PARTED` state and enables reuse of the node name. !!! @@ -492,40 +492,40 @@ Internal function intended for use by PGD-CLI. ### `bdr.stat_get_activity` -Internal function underlying view `bdr.stat_activity`. Do not use directly. Use the [`bdr.stat_activity`](/pgd/latest/reference/catalogs-visible#bdrstat_activity) view instead. +Internal function underlying view `bdr.stat_activity`. Do not use directly. Use the [`bdr.stat_activity`](/pgd/5.6/reference/catalogs-visible#bdrstat_activity) view instead. ### `bdr.worker_role_id_name` -Internal helper function used when generating view `bdr.worker_tasks`. Do not use directly. Use the [`bdr.worker_tasks`](/pgd/latest/reference/catalogs-visible#bdrworker_tasks) view instead. +Internal helper function used when generating view `bdr.worker_tasks`. Do not use directly. Use the [`bdr.worker_tasks`](/pgd/5.6/reference/catalogs-visible#bdrworker_tasks) view instead. ### `bdr.lag_history` -Internal function used when generating view `bdr.node_replication_rates`. Do not use directly. Use the [`bdr.node_replication_rates`](/pgd/latest/reference/catalogs-visible#bdrnode_replication_rates) view instead. +Internal function used when generating view `bdr.node_replication_rates`. Do not use directly. Use the [`bdr.node_replication_rates`](/pgd/5.6/reference/catalogs-visible#bdrnode_replication_rates) view instead. ### `bdr.get_raft_instance_by_nodegroup` -Internal function used when generating view `bdr.group_raft_details`. Do not use directly. Use the [`bdr.group_raft_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_raft_details) view instead. +Internal function used when generating view `bdr.group_raft_details`. Do not use directly. Use the [`bdr.group_raft_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_raft_details) view instead. ### `bdr.monitor_camo_on_all_nodes` -Internal function used when generating view `bdr.group_camo_details`. Do not use directly. Use the [`bdr.group_camo_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_camo_details) view instead. +Internal function used when generating view `bdr.group_camo_details`. Do not use directly. Use the [`bdr.group_camo_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_camo_details) view instead. ### `bdr.monitor_raft_details_on_all_nodes` -Internal function used when generating view `bdr.group_raft_details`. Do not use directly. Use the [`bdr.group_raft_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_raft_details) view instead. +Internal function used when generating view `bdr.group_raft_details`. Do not use directly. Use the [`bdr.group_raft_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_raft_details) view instead. ### `bdr.monitor_replslots_details_on_all_nodes` -Internal function used when generating view `bdr.group_replslots_details`. Do not use directly. Use the [`bdr.group_replslots_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_replslots_details) view instead. +Internal function used when generating view `bdr.group_replslots_details`. Do not use directly. Use the [`bdr.group_replslots_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_replslots_details) view instead. ### `bdr.monitor_subscription_details_on_all_nodes` -Internal function used when generating view `bdr.group_subscription_summary`. Do not use directly. Use the [`bdr.group_subscription_summary`](/pgd/latest/reference/catalogs-visible#bdrgroup_subscription_summary) view instead. +Internal function used when generating view `bdr.group_subscription_summary`. Do not use directly. Use the [`bdr.group_subscription_summary`](/pgd/5.6/reference/catalogs-visible#bdrgroup_subscription_summary) view instead. ### `bdr.monitor_version_details_on_all_nodes` -Internal function used when generating view `bdr.group_versions_details`. Do not use directly. Use the [`bdr.group_versions_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_versions_details) view instead. +Internal function used when generating view `bdr.group_versions_details`. Do not use directly. Use the [`bdr.group_versions_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_versions_details) view instead. ### `bdr.node_group_member_info` -Internal function used when generating view `bdr.group_raft_details`. Do not use directly. Use the [`bdr.group_raft_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_raft_details) view instead. \ No newline at end of file +Internal function used when generating view `bdr.group_raft_details`. Do not use directly. Use the [`bdr.group_raft_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_raft_details) view instead. \ No newline at end of file diff --git a/product_docs/docs/pgd/5.6/reference/functions.mdx b/product_docs/docs/pgd/5.6/reference/functions.mdx index 20308f1d296..6701b927f8e 100644 --- a/product_docs/docs/pgd/5.6/reference/functions.mdx +++ b/product_docs/docs/pgd/5.6/reference/functions.mdx @@ -281,7 +281,7 @@ If a slot is dropped concurrently, the wait ends for that slot. If a node is currently down and isn't updating its slot, then the wait continues. You might want to set `statement_timeout` to complete earlier in that case. -If you are using [Optimized Topology](../nodes/subscriber_only/optimizing-so), we recommend using [`bdr.wait_node_confirm_lsn`](/pgd/latest/reference/functions#bdrwait_node_confirm_lsn) instead. +If you are using [Optimized Topology](../nodes/subscriber_only/optimizing-so), we recommend using [`bdr.wait_node_confirm_lsn`](/pgd/5.6/reference/functions#bdrwait_node_confirm_lsn) instead. ) #### Synopsis @@ -312,7 +312,7 @@ If no LSN is supplied, the current wal_flush_lsn (using the `pg_current_wal_flus Supplying a node name parameter tells the function to wait for that node to pass the LSN. If no node name is supplied (by passing NULL), the function waits until all the nodes pass the LSN. -We recommend using this function if you are using [Optimized Topology](../nodes/subscriber_only/optimizing-so) instead of [`bdr.wait_slot_confirm_lsn`](/pgd/latest/reference/functions#bdrwait_slot_confirm_lsn). +We recommend using this function if you are using [Optimized Topology](../nodes/subscriber_only/optimizing-so) instead of [`bdr.wait_slot_confirm_lsn`](/pgd/5.6/reference/functions#bdrwait_slot_confirm_lsn). This is because in an Optimized Topology, not all nodes have replication slots, so the function `bdr.wait_slot_confirm_lsn` might not work as expected. `bdr.wait_node_confirm_lsn` is designed to work with nodes that don't have replication slots, using alternative strategies to determine the progress of a node. @@ -433,7 +433,7 @@ bdr.replicate_ddl_command(ddl_cmd text, | --------- | ----------- | | `ddl_cmd` | DDL command to execute. | | `replication_sets` | An array of replication set names to apply the `ddlcommand` to. If NULL (or the function is passed only the `ddlcommand`), this parameter is set to the active PGD groups's default replication set. | -| `ddl_locking` | A string that sets the [`bdr.ddl_locking`](/pgd/latest/reference/pgd-settings#bdrddl_locking) value while replicating. Defaults to the GUC value for `bdr.ddl_locking` on the local system that's running `replicate_ddl_command`. | +| `ddl_locking` | A string that sets the [`bdr.ddl_locking`](/pgd/5.6/reference/pgd-settings#bdrddl_locking) value while replicating. Defaults to the GUC value for `bdr.ddl_locking` on the local system that's running `replicate_ddl_command`. | | `execute_locally` | A Boolean that determines whether the DDL command executes locally. Defaults to true. | #### Notes @@ -1054,7 +1054,7 @@ bdr.lag_control() | Column name | Description | |----------------------------|---------------------------------------------------------------------------------------------------------------------------| -| `commit_scope_id` | OID of the commit scope (see [`bdr.commit_scopes`](/pgd/latest/reference/catalogs-visible#bdrcommit_scopes)). | +| `commit_scope_id` | OID of the commit scope (see [`bdr.commit_scopes`](/pgd/5.6/reference/catalogs-visible#bdrcommit_scopes)). | | `sessions` | Number of sessions referencing the lag control entry. | | `current_commit_delay` | Current runtime commit delay, in fractional milliseconds. | | `maximum_commit_delay` | Configured maximum commit delay, in fractional milliseconds. | @@ -1174,7 +1174,7 @@ The client must be prepared to retry the function call on error. ### `bdr.add_commit_scope` -**Deprecated**. Use [`bdr.create_commit_scope`](/pgd/latest/reference/functions#bdrcreate_commit_scope) instead. Previously, this function was used to add a commit scope to a node group. It's now deprecated and will emit a warning until it is removed in a future release, at which point it will raise an error. +**Deprecated**. Use [`bdr.create_commit_scope`](/pgd/5.6/reference/functions#bdrcreate_commit_scope) instead. Previously, this function was used to add a commit scope to a node group. It's now deprecated and will emit a warning until it is removed in a future release, at which point it will raise an error. ### `bdr.create_commit_scope` @@ -1194,7 +1194,7 @@ bdr.create_commit_scope( #### Note -`bdr.create_commit_scope` replaces the deprecated [`bdr.add_commit_scope`](/pgd/latest/reference/functions#bdradd_commit_scope) function. Unlike `add_commit_scope`, it does not silently overwrite existing commit scopes when the same name is used. Instead, an error is reported. +`bdr.create_commit_scope` replaces the deprecated [`bdr.add_commit_scope`](/pgd/5.6/reference/functions#bdradd_commit_scope) function. Unlike `add_commit_scope`, it does not silently overwrite existing commit scopes when the same name is used. Instead, an error is reported. ### `bdr.alter_commit_scope` @@ -1226,4 +1226,4 @@ bdr.drop_commit_scope( ### `bdr.remove_commit_scope` -**Deprecated**. Use [`bdr.drop_commit_scope`](/pgd/latest/reference/functions#bdrdrop_commit_scope) instead. Previously, this function was used to remove a commit scope from a node group. It's now deprecated and will emit a warning until it is removed in a future release, at which point it will raise an error. +**Deprecated**. Use [`bdr.drop_commit_scope`](/pgd/5.6/reference/functions#bdrdrop_commit_scope) instead. Previously, this function was used to remove a commit scope from a node group. It's now deprecated and will emit a warning until it is removed in a future release, at which point it will raise an error. diff --git a/product_docs/docs/pgd/5.6/reference/nodes-management-interfaces.mdx b/product_docs/docs/pgd/5.6/reference/nodes-management-interfaces.mdx index 669df80c07e..56458f9be2e 100644 --- a/product_docs/docs/pgd/5.6/reference/nodes-management-interfaces.mdx +++ b/product_docs/docs/pgd/5.6/reference/nodes-management-interfaces.mdx @@ -317,7 +317,7 @@ bdr.join_node_group ( If `wait_for_completion` is specified as `false`, the function call returns as soon as the joining procedure starts. You can see the progress of the join in -the log files and the [`bdr.event_summary`](/pgd/latest/reference/catalogs-internal#bdrevent_summary) +the log files and the [`bdr.event_summary`](/pgd/5.6/reference/catalogs-internal#bdrevent_summary) information view. You can call the function [`bdr.wait_for_join_completion()`](#bdrwait_for_join_completion) after `bdr.join_node_group()` to wait for the join operation to complete. It can emit progress information if called with `verbose_progress` set to `true`. diff --git a/product_docs/docs/pgd/5.6/reference/pgd-settings.mdx b/product_docs/docs/pgd/5.6/reference/pgd-settings.mdx index 4c2bf954370..3130f39dcfb 100644 --- a/product_docs/docs/pgd/5.6/reference/pgd-settings.mdx +++ b/product_docs/docs/pgd/5.6/reference/pgd-settings.mdx @@ -489,15 +489,15 @@ archival, and rotation to prevent disk space exhaustion. ### `bdr.track_subscription_apply` -Tracks apply statistics for each subscription with [`bdr.stat_subscription`](/pgd/latest/reference/catalogs-visible#bdrstat_subscription) (default is `on`). +Tracks apply statistics for each subscription with [`bdr.stat_subscription`](/pgd/5.6/reference/catalogs-visible#bdrstat_subscription) (default is `on`). ### `bdr.track_relation_apply` -Tracks apply statistics for each relation with [`bdr.stat_relation`](/pgd/latest/reference/catalogs-visible#bdrstat_relation) (default is `off`). +Tracks apply statistics for each relation with [`bdr.stat_relation`](/pgd/5.6/reference/catalogs-visible#bdrstat_relation) (default is `off`). ### `bdr.track_apply_lock_timing` -Tracks lock timing when tracking statistics for relations with [`bdr.stat_relation`](/pgd/latest/reference/catalogs-visible#bdrstat_relation) (default is `off`). +Tracks lock timing when tracking statistics for relations with [`bdr.stat_relation`](/pgd/5.6/reference/catalogs-visible#bdrstat_relation) (default is `off`). ## Decoding worker diff --git a/product_docs/docs/pgd/5.6/rel_notes/pgd_5.4.0_rel_notes.mdx b/product_docs/docs/pgd/5.6/rel_notes/pgd_5.4.0_rel_notes.mdx index 2ba18fc19cf..bd294263980 100644 --- a/product_docs/docs/pgd/5.6/rel_notes/pgd_5.4.0_rel_notes.mdx +++ b/product_docs/docs/pgd/5.6/rel_notes/pgd_5.4.0_rel_notes.mdx @@ -17,7 +17,7 @@ We recommend that all users of PGD 5 upgrade to PGD 5.4. See [PGD/TPA upgrades]( Highlights of this 5.4.0 release include improvements to: * Group Commit, aiming to optimize performance by minimizing the effect of a node's downtime and simplifying overall operating of PGD clusters. -* `apply_delay`, enabling the creation of a delayed read-only [replica](/pgd/latest/nodes/subscriber_only/overview/) for additional options for disaster recovery and to mitigate the impact of human error, such as accidental DROP table statements. +* `apply_delay`, enabling the creation of a delayed read-only [replica](/pgd/5.6/nodes/subscriber_only/overview/) for additional options for disaster recovery and to mitigate the impact of human error, such as accidental DROP table statements. ## Compatibility diff --git a/product_docs/docs/pgd/5.6/repsets.mdx b/product_docs/docs/pgd/5.6/repsets.mdx index afcf3cf7bab..19009009ffb 100644 --- a/product_docs/docs/pgd/5.6/repsets.mdx +++ b/product_docs/docs/pgd/5.6/repsets.mdx @@ -17,7 +17,7 @@ In other words, by default, all user tables are replicated between all nodes. ## Using replication sets -You can create replication sets using [`bdr.create_replication_set`](/pgd/latest/reference/repsets-management#bdrcreate_replication_set), +You can create replication sets using [`bdr.create_replication_set`](/pgd/5.6/reference/repsets-management#bdrcreate_replication_set), specifying whether to include insert, update, delete, or truncate actions. One option lets you add existing tables to the set, and a second option defines whether to add tables when they're @@ -33,12 +33,12 @@ Once the node is joined, you can still remove tables from the replication set, but you must add new tables using a resync operation. By default, a newly defined replication set doesn't replicate DDL or PGD -administration function calls. Use [`bdr.replication_set_add_ddl_filter`](/pgd/latest/reference/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter) +administration function calls. Use [`bdr.replication_set_add_ddl_filter`](/pgd/5.6/reference/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter) to define the commands to replicate. PGD creates replication set definitions on all nodes. Each node can then be defined to publish or subscribe to each replication set using -[`bdr.alter_node_replication_sets`](/pgd/latest/reference/repsets-management#bdralter_node_replication_sets). +[`bdr.alter_node_replication_sets`](/pgd/5.6/reference/repsets-management#bdralter_node_replication_sets). You can use functions to alter these definitions later or to drop the replication set. @@ -146,7 +146,7 @@ of replication set A that replicates only INSERT actions and replication set B t replicates only UPDATE actions. Both INSERT and UPDATE actions are replicated if the target node is also subscribed to both replication set A and B. -You can control membership using [`bdr.replication_set_add_table`](/pgd/latest/reference/repsets-membership#bdrreplication_set_add_table) and [`bdr.replication_set_remove_table`](/pgd/latest/reference/repsets-membership#bdrreplication_set_remove_table). +You can control membership using [`bdr.replication_set_add_table`](/pgd/5.6/reference/repsets-membership#bdrreplication_set_add_table) and [`bdr.replication_set_remove_table`](/pgd/5.6/reference/repsets-membership#bdrreplication_set_remove_table). ## Listing replication sets @@ -245,7 +245,7 @@ filter, the regular expression applied to the command tag and to the role name: SELECT * FROM bdr.ddl_replication; ``` -You can use [`bdr.replication_set_add_ddl_filter`](/pgd/latest/reference/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter) and [`bdr.replication_set_remove_ddl_filter`](/pgd/latest/reference/repsets-ddl-filtering#bdrreplication_set_remove_ddl_filter) to manipulate DDL filters. +You can use [`bdr.replication_set_add_ddl_filter`](/pgd/5.6/reference/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter) and [`bdr.replication_set_remove_ddl_filter`](/pgd/5.6/reference/repsets-ddl-filtering#bdrreplication_set_remove_ddl_filter) to manipulate DDL filters. They're considered to be `DDL` and are therefore subject to DDL replication and global locking. diff --git a/product_docs/docs/pgd/5.6/routing/administering.mdx b/product_docs/docs/pgd/5.6/routing/administering.mdx index fe989098721..7610765d870 100644 --- a/product_docs/docs/pgd/5.6/routing/administering.mdx +++ b/product_docs/docs/pgd/5.6/routing/administering.mdx @@ -22,7 +22,7 @@ The switchover operation is not a guaranteed operation. If, due to a timeout or You can perform a switchover operation that explicitly changes the node that's the write leader to another node. -Use the [`bdr.routing_leadership_transfer()`](/pgd/latest/reference/routing#bdrrouting_leadership_transfer) function. +Use the [`bdr.routing_leadership_transfer()`](/pgd/5.6/reference/routing#bdrrouting_leadership_transfer) function. For example, to switch the write leader to node `node1` in group `group1`, use the following SQL command: diff --git a/product_docs/docs/pgd/5.6/routing/configuration.mdx b/product_docs/docs/pgd/5.6/routing/configuration.mdx index 3e11ee0964c..957bc3bd4aa 100644 --- a/product_docs/docs/pgd/5.6/routing/configuration.mdx +++ b/product_docs/docs/pgd/5.6/routing/configuration.mdx @@ -8,7 +8,7 @@ navTitle: "Configuration" Configuring the routing is done either through SQL interfaces or through PGD CLI. -You can enable routing decisions by calling the [`bdr.alter_node_group_option()`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_group_option) function. +You can enable routing decisions by calling the [`bdr.alter_node_group_option()`](/pgd/5.6/reference/nodes-management-interfaces#bdralter_node_group_option) function. For example: ```text @@ -27,7 +27,7 @@ Additional group-level options affect the routing decisions: ## Node-level configuration -Set per-node configuration of routing using [`bdr.alter_node_option()`](/pgd/latest/reference/nodes-management-interfaces#bdralter_node_option). The +Set per-node configuration of routing using [`bdr.alter_node_option()`](/pgd/5.6/reference/nodes-management-interfaces#bdralter_node_option). The available options that affect routing are: - `route_dsn` — The dsn used by proxy to connect to this node. @@ -45,7 +45,7 @@ You can configure the proxies using SQL interfaces. ### Creating and dropping proxy configurations -You can add a proxy configuration using [`bdr.create_proxy`](/pgd/latest/reference/routing#bdrcreate_proxy). +You can add a proxy configuration using [`bdr.create_proxy`](/pgd/5.6/reference/routing#bdrcreate_proxy). For example, `SELECT bdr.create_proxy('region1-proxy1', 'region1-group');` creates the default configuration for a proxy named `region1-proxy1` in the PGD group `region1-group`. @@ -56,7 +56,7 @@ Dropping a proxy deactivates it. ### Altering proxy configurations -You can configure options for each proxy using the [`bdr.alter_proxy_option()`](/pgd/latest/reference/routing#bdralter_proxy_option) function. +You can configure options for each proxy using the [`bdr.alter_proxy_option()`](/pgd/5.6/reference/routing#bdralter_proxy_option) function. The available options are: diff --git a/product_docs/docs/pgd/5.6/routing/index.mdx b/product_docs/docs/pgd/5.6/routing/index.mdx index 27308c310ab..ae297f30029 100644 --- a/product_docs/docs/pgd/5.6/routing/index.mdx +++ b/product_docs/docs/pgd/5.6/routing/index.mdx @@ -15,16 +15,16 @@ navigation: Managing application connections is an important part of high availability. PGD Proxy offers a way to manage connections to the EDB Postgres Distributed cluster. It acts as a proxy layer between the client application and the Postgres database. -* [PGD Proxy overview](/pgd/latest/routing/proxy) provides an overview of the PGD Proxy, its processes, and how it interacts with the EDB Postgres Distributed cluster. +* [PGD Proxy overview](/pgd/5.6/routing/proxy) provides an overview of the PGD Proxy, its processes, and how it interacts with the EDB Postgres Distributed cluster. -* [Installing the PGD Proxy service](/pgd/latest/routing/installing_proxy) covers installation of the PGD Proxy service on a host. +* [Installing the PGD Proxy service](/pgd/5.6/routing/installing_proxy) covers installation of the PGD Proxy service on a host. -* [Configuring PGD Proxy](/pgd/latest/routing/configuration) details the three levels (group, node, and proxy) of configuration on a cluster that control how the PGD Proxy service behaves. +* [Configuring PGD Proxy](/pgd/5.6/routing/configuration) details the three levels (group, node, and proxy) of configuration on a cluster that control how the PGD Proxy service behaves. -* [Administering PGD Proxy](/pgd/latest/routing/administering) shows how to switch the write leader and manage the PGD Proxy. +* [Administering PGD Proxy](/pgd/5.6/routing/administering) shows how to switch the write leader and manage the PGD Proxy. -* [Monitoring PGD Proxy](/pgd/latest/routing/monitoring) looks at how to monitor PGD Proxy through the cluster and at a service level. +* [Monitoring PGD Proxy](/pgd/5.6/routing/monitoring) looks at how to monitor PGD Proxy through the cluster and at a service level. -* [Read-only routing](/pgd/latest/routing/readonly) explains how the read-only routing feature in PGD Proxy enables read scalability. +* [Read-only routing](/pgd/5.6/routing/readonly) explains how the read-only routing feature in PGD Proxy enables read scalability. -* [Raft](/pgd/latest/routing/raft) provides an overview of the Raft consensus mechanism used to coordinate PGD Proxy. +* [Raft](/pgd/5.6/routing/raft) provides an overview of the Raft consensus mechanism used to coordinate PGD Proxy. diff --git a/product_docs/docs/pgd/5.6/routing/monitoring.mdx b/product_docs/docs/pgd/5.6/routing/monitoring.mdx index d8383e276be..d92962a6cbf 100644 --- a/product_docs/docs/pgd/5.6/routing/monitoring.mdx +++ b/product_docs/docs/pgd/5.6/routing/monitoring.mdx @@ -9,11 +9,11 @@ You cam monitor proxies at the cluster and group level or at the process level. ### Using SQL -The current configuration of every group is visible in the [`bdr.node_group_routing_config_summary`](/pgd/latest/reference/catalogs-internal#bdrnode_group_routing_config_summary) view. +The current configuration of every group is visible in the [`bdr.node_group_routing_config_summary`](/pgd/5.6/reference/catalogs-internal#bdrnode_group_routing_config_summary) view. -The [`bdr.node_routing_config_summary`](/pgd/latest/reference/catalogs-internal#bdrnode_routing_config_summary) view shows current per-node routing configuration. +The [`bdr.node_routing_config_summary`](/pgd/5.6/reference/catalogs-internal#bdrnode_routing_config_summary) view shows current per-node routing configuration. -[`bdr.proxy_config_summary`](/pgd/latest/reference/catalogs-internal#bdrproxy_config_summary) shows per-proxy configuration. +[`bdr.proxy_config_summary`](/pgd/5.6/reference/catalogs-internal#bdrproxy_config_summary) shows per-proxy configuration. ## Monitoring at the process level diff --git a/product_docs/docs/pgd/5.6/routing/proxy.mdx b/product_docs/docs/pgd/5.6/routing/proxy.mdx index 3ea91560070..f3a2f54a88a 100644 --- a/product_docs/docs/pgd/5.6/routing/proxy.mdx +++ b/product_docs/docs/pgd/5.6/routing/proxy.mdx @@ -69,7 +69,7 @@ Upon starting, PGD Proxy connects to one of the endpoints given in the local con - Proxy options like listen address, listen port. - Routing details including the current write leader in default mode, read nodes in read-only mode, or both in any mode. -The endpoints given in the config file are used only at startup. After that, actual endpoints are taken from the PGD catalog's `route_dsn` field in [`bdr.node_routing_config_summary`](/pgd/latest/reference/catalogs-internal#bdrnode_routing_config_summary). +The endpoints given in the config file are used only at startup. After that, actual endpoints are taken from the PGD catalog's `route_dsn` field in [`bdr.node_routing_config_summary`](/pgd/5.6/reference/catalogs-internal#bdrnode_routing_config_summary). PGD manages write leader election. PGD Proxy interacts with PGD to get write leader change events notifications on Postgres notify/listen channels and routes client traffic to the current write leader. PGD Proxy disconnects all existing client connections on write leader change or when write leader is unavailable. Write leader election is a Raft-backed activity and is subject to Raft leader availability. PGD Proxy closes the new client connections if the write leader is unavailable. diff --git a/product_docs/docs/pgd/5.6/scaling.mdx b/product_docs/docs/pgd/5.6/scaling.mdx index 49bb625b580..d29985e5d01 100644 --- a/product_docs/docs/pgd/5.6/scaling.mdx +++ b/product_docs/docs/pgd/5.6/scaling.mdx @@ -19,7 +19,7 @@ your search_path, you need to schema qualify the name of each function. ## Auto creation of partitions -PGD AutoPartition uses the [`bdr.autopartition()`](/pgd/latest/reference/autopartition#bdrautopartition) +PGD AutoPartition uses the [`bdr.autopartition()`](/pgd/5.6/reference/autopartition#bdrautopartition) function to create or alter the definition of automatic range partitioning for a table. If no definition exists, it's created. Otherwise, later executions will alter the definition. @@ -42,7 +42,7 @@ case, all partitions are managed locally on each node. Managing partitions locally is useful when the partitioned table isn't a replicated table. In that case, you might not need or want to have all partitions on all nodes. For example, the built-in -[`bdr.conflict_history`](/pgd/latest/reference/catalogs-visible#bdrconflict_history) +[`bdr.conflict_history`](/pgd/5.6/reference/catalogs-visible#bdrconflict_history) table isn't a replicated table. It's managed by AutoPartition locally. Each node creates partitions for this table locally and drops them once they're old enough. @@ -145,7 +145,7 @@ upper bound. ## Stopping automatic creation of partitions Use -[`bdr.drop_autopartition()`](/pgd/latest/reference/autopartition#bdrdrop_autopartition) +[`bdr.drop_autopartition()`](/pgd/5.6/reference/autopartition#bdrdrop_autopartition) to drop the autopartitioning rule for the given relation. All pending work items for the relation are deleted, and no new work items are created. @@ -155,7 +155,7 @@ Partition creation is an asynchronous process. AutoPartition provides a set of functions to wait for the partition to be created, locally or on all nodes. Use -[`bdr.autopartition_wait_for_partitions()`](/pgd/latest/reference/autopartition#bdrautopartition_wait_for_partitions) +[`bdr.autopartition_wait_for_partitions()`](/pgd/5.6/reference/autopartition#bdrautopartition_wait_for_partitions) to wait for the creation of partitions on the local node. The function takes the partitioned table name and a partition key column value and waits until the partition that holds that value is created. @@ -164,14 +164,14 @@ The function waits only for the partitions to be created locally. It doesn't guarantee that the partitions also exist on the remote nodes. To wait for the partition to be created on all PGD nodes, use the -[`bdr.autopartition_wait_for_partitions_on_all_nodes()`](/pgd/latest/reference/autopartition#bdrautopartition_wait_for_partitions_on_all_nodes) +[`bdr.autopartition_wait_for_partitions_on_all_nodes()`](/pgd/5.6/reference/autopartition#bdrautopartition_wait_for_partitions_on_all_nodes) function. This function internally checks local as well as all remote nodes and waits until the partition is created everywhere. ## Finding a partition Use the -[`bdr.autopartition_find_partition()`](/pgd/latest/reference/autopartition#bdrautopartition_find_partition) +[`bdr.autopartition_find_partition()`](/pgd/5.6/reference/autopartition#bdrautopartition_find_partition) function to find the partition for the given partition key value. If a partition to hold that value doesn't exist, then the function returns NULL. Otherwise it returns the Oid of the partition. @@ -179,10 +179,10 @@ of the partition. ## Enabling or disabling autopartitioning Use -[`bdr.autopartition_enable()`](/pgd/latest/reference/autopartition#bdrautopartition_enable) +[`bdr.autopartition_enable()`](/pgd/5.6/reference/autopartition#bdrautopartition_enable) to enable autopartitioning on the given table. If autopartitioning is already enabled, then no action occurs. Similarly, use -[`bdr.autopartition_disable()`](/pgd/latest/reference/autopartition#bdrautopartition_disable) +[`bdr.autopartition_disable()`](/pgd/5.6/reference/autopartition#bdrautopartition_disable) to disable autopartitioning on the given table. ## Restrictions on EDB Postgres Advanced Server-native automatic partitioning diff --git a/product_docs/docs/pgd/5.6/security/pgd-predefined-roles.mdx b/product_docs/docs/pgd/5.6/security/pgd-predefined-roles.mdx index 97e74fae2a0..e358af4d02b 100644 --- a/product_docs/docs/pgd/5.6/security/pgd-predefined-roles.mdx +++ b/product_docs/docs/pgd/5.6/security/pgd-predefined-roles.mdx @@ -25,71 +25,71 @@ This role provides read access to most of the tables, views, and functions that `SELECT` privilege on: -- [`bdr.autopartition_partitions`](/pgd/latest/reference/catalogs-internal#bdrautopartition_partitions) -- [`bdr.autopartition_rules`](/pgd/latest/reference/catalogs-internal#bdrautopartition_rules) -- [`bdr.ddl_epoch`](/pgd/latest/reference/catalogs-internal#bdrddl_epoch) -- [`bdr.ddl_replication`](/pgd/latest/reference/pgd-settings#bdrddl_replication) -- [`bdr.global_consensus_journal_details`](/pgd/latest/reference/catalogs-visible#bdrglobal_consensus_journal_details) -- [`bdr.global_lock`](/pgd/latest/reference/catalogs-visible#bdrglobal_lock) -- [`bdr.global_locks`](/pgd/latest/reference/catalogs-visible#bdrglobal_locks) -- [`bdr.group_camo_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_camo_details) -- [`bdr.local_consensus_state`](/pgd/latest/reference/catalogs-visible#bdrlocal_consensus_state) -- [`bdr.local_node_summary`](/pgd/latest/reference/catalogs-visible#bdrlocal_node_summary) -- [`bdr.node`](/pgd/latest/reference/catalogs-visible#bdrnode) -- [`bdr.node_catchup_info`](/pgd/latest/reference/catalogs-visible#bdrnode_catchup_info) -- [`bdr.node_catchup_info_details`](/pgd/latest/reference/catalogs-visible#bdrnode_catchup_info_details) -- [`bdr.node_conflict_resolvers`](/pgd/latest/reference/catalogs-visible#bdrnode_conflict_resolvers) -- [`bdr.node_group`](/pgd/latest/reference/catalogs-visible#bdrnode_group) -- [`bdr.node_local_info`](/pgd/latest/reference/catalogs-visible#bdrnode_local_info) -- [`bdr.node_peer_progress`](/pgd/latest/reference/catalogs-visible#bdrnode_peer_progress) -- [`bdr.node_replication_rates`](/pgd/latest/reference/catalogs-visible#bdrnode_replication_rates) -- [`bdr.node_slots`](/pgd/latest/reference/catalogs-visible#bdrnode_slots) -- [`bdr.node_summary`](/pgd/latest/reference/catalogs-visible#bdrnode_summary) -- [`bdr.replication_sets`](/pgd/latest/reference/catalogs-visible#bdrreplication_sets) +- [`bdr.autopartition_partitions`](/pgd/5.6/reference/catalogs-internal#bdrautopartition_partitions) +- [`bdr.autopartition_rules`](/pgd/5.6/reference/catalogs-internal#bdrautopartition_rules) +- [`bdr.ddl_epoch`](/pgd/5.6/reference/catalogs-internal#bdrddl_epoch) +- [`bdr.ddl_replication`](/pgd/5.6/reference/pgd-settings#bdrddl_replication) +- [`bdr.global_consensus_journal_details`](/pgd/5.6/reference/catalogs-visible#bdrglobal_consensus_journal_details) +- [`bdr.global_lock`](/pgd/5.6/reference/catalogs-visible#bdrglobal_lock) +- [`bdr.global_locks`](/pgd/5.6/reference/catalogs-visible#bdrglobal_locks) +- [`bdr.group_camo_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_camo_details) +- [`bdr.local_consensus_state`](/pgd/5.6/reference/catalogs-visible#bdrlocal_consensus_state) +- [`bdr.local_node_summary`](/pgd/5.6/reference/catalogs-visible#bdrlocal_node_summary) +- [`bdr.node`](/pgd/5.6/reference/catalogs-visible#bdrnode) +- [`bdr.node_catchup_info`](/pgd/5.6/reference/catalogs-visible#bdrnode_catchup_info) +- [`bdr.node_catchup_info_details`](/pgd/5.6/reference/catalogs-visible#bdrnode_catchup_info_details) +- [`bdr.node_conflict_resolvers`](/pgd/5.6/reference/catalogs-visible#bdrnode_conflict_resolvers) +- [`bdr.node_group`](/pgd/5.6/reference/catalogs-visible#bdrnode_group) +- [`bdr.node_local_info`](/pgd/5.6/reference/catalogs-visible#bdrnode_local_info) +- [`bdr.node_peer_progress`](/pgd/5.6/reference/catalogs-visible#bdrnode_peer_progress) +- [`bdr.node_replication_rates`](/pgd/5.6/reference/catalogs-visible#bdrnode_replication_rates) +- [`bdr.node_slots`](/pgd/5.6/reference/catalogs-visible#bdrnode_slots) +- [`bdr.node_summary`](/pgd/5.6/reference/catalogs-visible#bdrnode_summary) +- [`bdr.replication_sets`](/pgd/5.6/reference/catalogs-visible#bdrreplication_sets) - `bdr.replication_status` -- [`bdr.sequences`](/pgd/latest/reference/catalogs-visible#bdrsequences) -- [`bdr.stat_activity`](/pgd/latest/reference/catalogs-visible#bdrstat_activity) -- [`bdr.stat_relation`](/pgd/latest/reference/catalogs-visible#bdrstat_relation) -- [`bdr.stat_subscription`](/pgd/latest/reference/catalogs-visible#bdrstat_subscription) _deprecated_ -- [`bdr.state_journal_details`](/pgd/latest/reference/catalogs-visible#) -- [`bdr.subscription`](/pgd/latest/reference/catalogs-visible#bdrsubscription) -- [`bdr.subscription_summary`](/pgd/latest/reference/catalogs-visible#bdrsubscription_summary) -- [`bdr.tables`](/pgd/latest/reference/catalogs-visible#bdrtables) -- [`bdr.taskmgr_local_work_queue`](/pgd/latest/reference/catalogs-visible#bdrtaskmgr_local_work_queue) -- [`bdr.taskmgr_work_queue`](/pgd/latest/reference/catalogs-visible#bdrtaskmgr_work_queue) -- [`bdr.worker_errors`](/pgd/latest/reference/catalogs-visible#) _deprecated_ -- [`bdr.workers`](/pgd/latest/reference/catalogs-visible#bdrworkers) -- [`bdr.writers`](/pgd/latest/reference/catalogs-visible#bdrwriters) +- [`bdr.sequences`](/pgd/5.6/reference/catalogs-visible#bdrsequences) +- [`bdr.stat_activity`](/pgd/5.6/reference/catalogs-visible#bdrstat_activity) +- [`bdr.stat_relation`](/pgd/5.6/reference/catalogs-visible#bdrstat_relation) +- [`bdr.stat_subscription`](/pgd/5.6/reference/catalogs-visible#bdrstat_subscription) _deprecated_ +- [`bdr.state_journal_details`](/pgd/5.6/reference/catalogs-visible#) +- [`bdr.subscription`](/pgd/5.6/reference/catalogs-visible#bdrsubscription) +- [`bdr.subscription_summary`](/pgd/5.6/reference/catalogs-visible#bdrsubscription_summary) +- [`bdr.tables`](/pgd/5.6/reference/catalogs-visible#bdrtables) +- [`bdr.taskmgr_local_work_queue`](/pgd/5.6/reference/catalogs-visible#bdrtaskmgr_local_work_queue) +- [`bdr.taskmgr_work_queue`](/pgd/5.6/reference/catalogs-visible#bdrtaskmgr_work_queue) +- [`bdr.worker_errors`](/pgd/5.6/reference/catalogs-visible#) _deprecated_ +- [`bdr.workers`](/pgd/5.6/reference/catalogs-visible#bdrworkers) +- [`bdr.writers`](/pgd/5.6/reference/catalogs-visible#bdrwriters) - `bdr.xid_peer_progress` EXECUTE privilege on: - `bdr.bdr_edition` _deprecated_ -- [`bdr.bdr_version`](/pgd/latest/reference/functions#bdrbdr_version) -- [`bdr.bdr_version_num`](/pgd/latest/reference/functions#bdrbdr_version_num) -- [`bdr.decode_message_payload`](/pgd/latest/reference/functions-internal#bdrdecode_message_payload) -- [`bdr.get_consensus_status`](/pgd/latest/reference/functions#bdrget_consensus_status) -- [`bdr.get_decoding_worker_stat`](/pgd/latest/reference/functions#bdrget_decoding_worker_stat) -- [`bdr.get_global_locks`](/pgd/latest/reference/functions-internal#bdrget_global_locks) -- [`bdr.get_min_required_replication_slots`](/pgd/latest/reference/functions-internal#bdrget_min_required_replication_slots) -- [`bdr.get_min_required_worker_processes`](/pgd/latest/reference/functions-internal#bdrget_min_required_worker_processes) -- [`bdr.get_raft_status`](/pgd/latest/reference/functions#bdrget_raft_status) -- [`bdr.get_relation_stats`](/pgd/latest/reference/functions#bdrget_relation_stats) -- [`bdr.get_slot_flush_timestamp`](/pgd/latest/reference/functions-internal#bdrget_slot_flush_timestamp) +- [`bdr.bdr_version`](/pgd/5.6/reference/functions#bdrbdr_version) +- [`bdr.bdr_version_num`](/pgd/5.6/reference/functions#bdrbdr_version_num) +- [`bdr.decode_message_payload`](/pgd/5.6/reference/functions-internal#bdrdecode_message_payload) +- [`bdr.get_consensus_status`](/pgd/5.6/reference/functions#bdrget_consensus_status) +- [`bdr.get_decoding_worker_stat`](/pgd/5.6/reference/functions#bdrget_decoding_worker_stat) +- [`bdr.get_global_locks`](/pgd/5.6/reference/functions-internal#bdrget_global_locks) +- [`bdr.get_min_required_replication_slots`](/pgd/5.6/reference/functions-internal#bdrget_min_required_replication_slots) +- [`bdr.get_min_required_worker_processes`](/pgd/5.6/reference/functions-internal#bdrget_min_required_worker_processes) +- [`bdr.get_raft_status`](/pgd/5.6/reference/functions#bdrget_raft_status) +- [`bdr.get_relation_stats`](/pgd/5.6/reference/functions#bdrget_relation_stats) +- [`bdr.get_slot_flush_timestamp`](/pgd/5.6/reference/functions-internal#bdrget_slot_flush_timestamp) - `bdr.get_sub_progress_timestamp` -- [`bdr.get_subscription_stats`](/pgd/latest/reference/functions#bdrget_subscription_stats) -- [`bdr.lag_control`](/pgd/latest/reference/functions#bdrlag_control) -- [`bdr.lag_history`](/pgd/latest/reference/functions-internal#bdrlag_history) -- [`bdr.node_catchup_state_name`](/pgd/latest/reference/functions-internal#bdrnode_catchup_state_name) -- [`bdr.node_kind_name`](/pgd/latest/reference/functions-internal#bdrnode_kind_name) -- [`bdr.peer_state_name`](/pgd/latest/reference/functions-internal#bdrpeer_state_name) -- [`bdr.pglogical_proto_version_ranges`](/pgd/latest/reference/functions-internal#bdrpglogical_proto_version_ranges) -- [`bdr.show_subscription_status`](/pgd/latest/reference/functions-internal#bdrshow_subscription_status) -- [`bdr.show_workers`](/pgd/latest/reference/functions-internal#bdrshow_workers) -- [`bdr.show_writers`](/pgd/latest/reference/functions-internal#bdrshow_writers) -- [`bdr.stat_get_activity`](/pgd/latest/reference/functions-internal#bdrstat_get_activity) -- [`bdr.wal_sender_stats`](/pgd/latest/reference/functions#bdrwal_sender_stats) -- [`bdr.worker_role_id_name`](/pgd/latest/reference/functions-internal#bdrworker_role_id_name) +- [`bdr.get_subscription_stats`](/pgd/5.6/reference/functions#bdrget_subscription_stats) +- [`bdr.lag_control`](/pgd/5.6/reference/functions#bdrlag_control) +- [`bdr.lag_history`](/pgd/5.6/reference/functions-internal#bdrlag_history) +- [`bdr.node_catchup_state_name`](/pgd/5.6/reference/functions-internal#bdrnode_catchup_state_name) +- [`bdr.node_kind_name`](/pgd/5.6/reference/functions-internal#bdrnode_kind_name) +- [`bdr.peer_state_name`](/pgd/5.6/reference/functions-internal#bdrpeer_state_name) +- [`bdr.pglogical_proto_version_ranges`](/pgd/5.6/reference/functions-internal#bdrpglogical_proto_version_ranges) +- [`bdr.show_subscription_status`](/pgd/5.6/reference/functions-internal#bdrshow_subscription_status) +- [`bdr.show_workers`](/pgd/5.6/reference/functions-internal#bdrshow_workers) +- [`bdr.show_writers`](/pgd/5.6/reference/functions-internal#bdrshow_writers) +- [`bdr.stat_get_activity`](/pgd/5.6/reference/functions-internal#bdrstat_get_activity) +- [`bdr.wal_sender_stats`](/pgd/5.6/reference/functions#bdrwal_sender_stats) +- [`bdr.worker_role_id_name`](/pgd/5.6/reference/functions-internal#bdrworker_role_id_name) ### bdr_monitor @@ -101,24 +101,24 @@ All privileges from [`bdr_read_all_stats`](#bdr_read_all_stats) plus the followi `SELECT` privilege on: -- [`bdr.group_raft_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_raft_details) -- [`bdr.group_replslots_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_replslots_details) -- [`bdr.group_subscription_summary`](/pgd/latest/reference/catalogs-visible#bdrgroup_subscription_summary) -- [`bdr.group_versions_details`](/pgd/latest/reference/catalogs-visible#bdrgroup_versions_details) +- [`bdr.group_raft_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_raft_details) +- [`bdr.group_replslots_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_replslots_details) +- [`bdr.group_subscription_summary`](/pgd/5.6/reference/catalogs-visible#bdrgroup_subscription_summary) +- [`bdr.group_versions_details`](/pgd/5.6/reference/catalogs-visible#bdrgroup_versions_details) - `bdr.raft_instances` `EXECUTE` privilege on: -- [`bdr.get_raft_instance_by_nodegroup`](/pgd/latest/reference/functions-internal#bdrget_raft_instance_by_nodegroup) -- [`bdr.monitor_camo_on_all_nodes`](/pgd/latest/reference/functions-internal#bdrmonitor_camo_on_all_nodes) -- [`bdr.monitor_group_raft`](/pgd/latest/reference/functions#bdrmonitor_group_raft) -- [`bdr.monitor_group_versions`](/pgd/latest/reference/functions#bdrmonitor_group_versions) -- [`bdr.monitor_local_replslots`](/pgd/latest/reference/functions#bdrmonitor_local_replslots) -- [`bdr.monitor_raft_details_on_all_nodes`](/pgd/latest/reference/functions-internal#bdrmonitor_raft_details_on_all_nodes) -- [`bdr.monitor_replslots_details_on_all_nodes`](/pgd/latest/reference/functions-internal#bdrmonitor_replslots_details_on_all_nodes) -- [`bdr.monitor_subscription_details_on_all_nodes`](/pgd/latest/reference/functions-internal#bdrmonitor_subscription_details_on_all_nodes) -- [`bdr.monitor_version_details_on_all_nodes`](/pgd/latest/reference/functions-internal#bdrmonitor_version_details_on_all_nodes) -- [`bdr.node_group_member_info`](/pgd/latest/reference/functions-internal#bdrnode_group_member_info) +- [`bdr.get_raft_instance_by_nodegroup`](/pgd/5.6/reference/functions-internal#bdrget_raft_instance_by_nodegroup) +- [`bdr.monitor_camo_on_all_nodes`](/pgd/5.6/reference/functions-internal#bdrmonitor_camo_on_all_nodes) +- [`bdr.monitor_group_raft`](/pgd/5.6/reference/functions#bdrmonitor_group_raft) +- [`bdr.monitor_group_versions`](/pgd/5.6/reference/functions#bdrmonitor_group_versions) +- [`bdr.monitor_local_replslots`](/pgd/5.6/reference/functions#bdrmonitor_local_replslots) +- [`bdr.monitor_raft_details_on_all_nodes`](/pgd/5.6/reference/functions-internal#bdrmonitor_raft_details_on_all_nodes) +- [`bdr.monitor_replslots_details_on_all_nodes`](/pgd/5.6/reference/functions-internal#bdrmonitor_replslots_details_on_all_nodes) +- [`bdr.monitor_subscription_details_on_all_nodes`](/pgd/5.6/reference/functions-internal#bdrmonitor_subscription_details_on_all_nodes) +- [`bdr.monitor_version_details_on_all_nodes`](/pgd/5.6/reference/functions-internal#bdrmonitor_version_details_on_all_nodes) +- [`bdr.node_group_member_info`](/pgd/5.6/reference/functions-internal#bdrnode_group_member_info) ### bdr_application @@ -130,28 +130,28 @@ This role is designed for applications that require access to PGD features, obje - All functions for column_timestamps datatypes - All functions for CRDT datatypes -- [`bdr.alter_sequence_set_kind`](/pgd/latest/reference/sequences#bdralter_sequence_set_kind) -- [`bdr.create_conflict_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrcreate_conflict_trigger) -- [`bdr.create_transform_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrcreate_transform_trigger) -- [`bdr.drop_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrdrop_trigger) -- [`bdr.get_configured_camo_partner`](/pgd/latest/reference/functions#bdrget_configured_camo_partner) -- [`bdr.global_lock_table`](/pgd/latest/reference/functions#bdrglobal_lock_table) -- [`bdr.is_camo_partner_connected`](/pgd/latest/reference/functions#bdris_camo_partner_connected) -- [`bdr.is_camo_partner_ready`](/pgd/latest/reference/functions#bdris_camo_partner_ready) -- [`bdr.logical_transaction_status`](/pgd/latest/reference/functions#bdrlogical_transaction_status) +- [`bdr.alter_sequence_set_kind`](/pgd/5.6/reference/sequences#bdralter_sequence_set_kind) +- [`bdr.create_conflict_trigger`](/pgd/5.6/reference/streamtriggers/interfaces#bdrcreate_conflict_trigger) +- [`bdr.create_transform_trigger`](/pgd/5.6/reference/streamtriggers/interfaces#bdrcreate_transform_trigger) +- [`bdr.drop_trigger`](/pgd/5.6/reference/streamtriggers/interfaces#bdrdrop_trigger) +- [`bdr.get_configured_camo_partner`](/pgd/5.6/reference/functions#bdrget_configured_camo_partner) +- [`bdr.global_lock_table`](/pgd/5.6/reference/functions#bdrglobal_lock_table) +- [`bdr.is_camo_partner_connected`](/pgd/5.6/reference/functions#bdris_camo_partner_connected) +- [`bdr.is_camo_partner_ready`](/pgd/5.6/reference/functions#bdris_camo_partner_ready) +- [`bdr.logical_transaction_status`](/pgd/5.6/reference/functions#bdrlogical_transaction_status) - `bdr.ri_fkey_trigger` -- [`bdr.seq_nextval`](/pgd/latest/reference/functions-internal#bdrseq_nextval) -- [`bdr.seq_currval`](/pgd/latest/reference/functions-internal#bdrseq_currval) -- [`bdr.seq_lastval`](/pgd/latest/reference/functions-internal#bdrseq_lastval) -- [`bdr.trigger_get_committs`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_committs) -- [`bdr.trigger_get_conflict_type`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_conflict_type) -- [`bdr.trigger_get_origin_node_id`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_origin_node_id) -- [`bdr.trigger_get_row`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_row) -- [`bdr.trigger_get_type`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_type) -- [`bdr.trigger_get_xid`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_xid) -- [`bdr.wait_for_camo_partner_queue`](/pgd/latest/reference/functions#bdrwait_for_camo_partner_queue) -- [`bdr.wait_slot_confirm_lsn`](/pgd/latest/reference/functions#bdrwait_slot_confirm_lsn) -- [`bdr.wait_node_confirm_lsn`](/pgd/latest/reference/functions#bdrwait_node_confirm_lsn) +- [`bdr.seq_nextval`](/pgd/5.6/reference/functions-internal#bdrseq_nextval) +- [`bdr.seq_currval`](/pgd/5.6/reference/functions-internal#bdrseq_currval) +- [`bdr.seq_lastval`](/pgd/5.6/reference/functions-internal#bdrseq_lastval) +- [`bdr.trigger_get_committs`](/pgd/5.6/reference/streamtriggers/rowfunctions#bdrtrigger_get_committs) +- [`bdr.trigger_get_conflict_type`](/pgd/5.6/reference/streamtriggers/rowfunctions#bdrtrigger_get_conflict_type) +- [`bdr.trigger_get_origin_node_id`](/pgd/5.6/reference/streamtriggers/rowfunctions#bdrtrigger_get_origin_node_id) +- [`bdr.trigger_get_row`](/pgd/5.6/reference/streamtriggers/rowfunctions#bdrtrigger_get_row) +- [`bdr.trigger_get_type`](/pgd/5.6/reference/streamtriggers/rowfunctions#bdrtrigger_get_type) +- [`bdr.trigger_get_xid`](/pgd/5.6/reference/streamtriggers/rowfunctions#bdrtrigger_get_xid) +- [`bdr.wait_for_camo_partner_queue`](/pgd/5.6/reference/functions#bdrwait_for_camo_partner_queue) +- [`bdr.wait_slot_confirm_lsn`](/pgd/5.6/reference/functions#bdrwait_slot_confirm_lsn) +- [`bdr.wait_node_confirm_lsn`](/pgd/5.6/reference/functions#bdrwait_node_confirm_lsn) Many of these functions require additional privileges before you can use them. For example, you must be the table owner to successfully execute @@ -161,7 +161,7 @@ specific function. ### bdr_read_all_conflicts PGD logs conflicts into the -[`bdr.conflict_history`](/pgd/latest/reference/catalogs-visible#bdrconflict_history) +[`bdr.conflict_history`](/pgd/5.6/reference/catalogs-visible#bdrconflict_history) table. Conflicts are visible only to table owners, so no extra privileges are required for the owners to read the conflict history. @@ -170,4 +170,4 @@ you can optionally grant the role `bdr_read_all_conflicts` to that user. #### Privileges -An explicit policy is set on [`bdr.conflict_history`](/pgd/latest/reference/catalogs-visible#bdrconflict_history) that allows this role to read the `bdr.conflict_history` table. +An explicit policy is set on [`bdr.conflict_history`](/pgd/5.6/reference/catalogs-visible#bdrconflict_history) that allows this role to read the `bdr.conflict_history` table. diff --git a/product_docs/docs/pgd/5.6/security/role-management.mdx b/product_docs/docs/pgd/5.6/security/role-management.mdx index cc32a697155..f387d3e8da2 100644 --- a/product_docs/docs/pgd/5.6/security/role-management.mdx +++ b/product_docs/docs/pgd/5.6/security/role-management.mdx @@ -12,12 +12,12 @@ Remember that a user in Postgres terms is simply a role with login privileges. If you do create a role or user in a non-PGD, unreplicated database, it's especially important that you do not make an object in the PGD-replicated database rely on that role. It will break the replication process, as PGD cannot replicate a role that is not in the PGD-replicated database. -You can disable this automatic replication behavior by turning off the [`bdr.role_replication`](https://www.enterprisedb.com/docs/pgd/latest/reference/pgd-settings/#bdrrole_replication) setting, but we don't recommend that. +You can disable this automatic replication behavior by turning off the [`bdr.role_replication`](https://www.enterprisedb.com/docs/pgd/5.6/reference/pgd-settings/#bdrrole_replication) setting, but we don't recommend that. ## Roles for new nodes -New PGD nodes that are added using [`bdr_init_physical`](https://www.enterprisedb.com/docs/pgd/latest/reference/nodes/#bdr_init_physical) will automatically replicate the roles from other nodes of the PGD cluster. +New PGD nodes that are added using [`bdr_init_physical`](https://www.enterprisedb.com/docs/pgd/5.6/reference/nodes/#bdr_init_physical) will automatically replicate the roles from other nodes of the PGD cluster. If a PGD node is joined to a PGD group manually, without using `bdr_init_physical`, existing roles aren't copied to the newly joined node. This is intentional behavior to ensure that access isn't accidentally granted. @@ -37,7 +37,7 @@ When joining a new node, the “No unreplicated roles” rule also applies. If a ## Connections and roles When allocating a new PGD node, the user supplied in the DSN for the `local_dsn` -argument of [`bdr.create_node`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node) and the `join_target_dsn` of [`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) +argument of [`bdr.create_node`](/pgd/5.6/reference/nodes-management-interfaces#bdrcreate_node) and the `join_target_dsn` of [`bdr.join_node_group`](/pgd/5.6/reference/nodes-management-interfaces#bdrjoin_node_group) are used frequently to refer to, create, and manage database objects. PGD is carefully written to prevent privilege escalation attacks even when using diff --git a/product_docs/docs/pgd/5.6/security/roles.mdx b/product_docs/docs/pgd/5.6/security/roles.mdx index f058d2567bb..aebeee9b706 100644 --- a/product_docs/docs/pgd/5.6/security/roles.mdx +++ b/product_docs/docs/pgd/5.6/security/roles.mdx @@ -12,7 +12,7 @@ PGD are split across the following predefined roles. | [**bdr_read_all_stats**](pgd-predefined-roles/#bdr_read_all_stats) | The role having read-only access to the tables, views, and functions, sufficient to understand the state of PGD. | | [**bdr_monitor**](pgd-predefined-roles/#bdr_monitor) | Includes the privileges of bdr_read_all_stats, with some extra privileges for monitoring. | | [**bdr_application**](pgd-predefined-roles/#bdr_application) | The minimal privileges required by applications running PGD. | - | [**bdr_read_all_conflicts**](pgd-predefined-roles/#bdr_read_all_conflicts) | Can view all conflicts in [`bdr.conflict_history`](/pgd/latest/reference/catalogs-visible#bdrconflict_history). | + | [**bdr_read_all_conflicts**](pgd-predefined-roles/#bdr_read_all_conflicts) | Can view all conflicts in [`bdr.conflict_history`](/pgd/5.6/reference/catalogs-visible#bdrconflict_history). | These roles are named to be analogous to PostgreSQL's `pg_` [predefined @@ -25,9 +25,9 @@ role has. Managing PGD doesn't require that administrators have access to user data. Arrangements for securing information about conflicts are discussed in -[Logging conflicts to a table](/pgd/latest/reference/conflict_functions#logging-conflicts-to-a-table). +[Logging conflicts to a table](/pgd/5.6/reference/conflict_functions#logging-conflicts-to-a-table). -You can monitor conflicts using the [`bdr.conflict_history_summary`](/pgd/latest/reference/catalogs-visible#bdrconflict_history_summary) view. +You can monitor conflicts using the [`bdr.conflict_history_summary`](/pgd/5.6/reference/catalogs-visible#bdrconflict_history_summary) view. !!! Note The BDR extension and superuser access The one exception to the rule of not needing superuser access is in the diff --git a/product_docs/docs/pgd/5.6/sequences.mdx b/product_docs/docs/pgd/5.6/sequences.mdx index 78e9dfd457d..a9b9f47be77 100644 --- a/product_docs/docs/pgd/5.6/sequences.mdx +++ b/product_docs/docs/pgd/5.6/sequences.mdx @@ -66,7 +66,7 @@ function. This function takes a standard PostgreSQL sequence and marks it as a PGD global sequence. It can also convert the sequence back to the standard PostgreSQL sequence. -PGD also provides the configuration variable [`bdr.default_sequence_kind`](/pgd/latest/reference/pgd-settings/#bdrdefault_sequence_kind). This variable +PGD also provides the configuration variable [`bdr.default_sequence_kind`](/pgd/5.6/reference/pgd-settings/#bdrdefault_sequence_kind). This variable determines the kind of sequence to create when the `CREATE SEQUENCE` command is executed or when a `serial`, `bigserial`, or `GENERATED BY DEFAULT AS IDENTITY` column is created. Valid settings are: @@ -84,7 +84,7 @@ command is executed or when a `serial`, `bigserial`, or sequences (that is, `bigserial`) and `galloc` sequence for `int4` (that is, `serial`) and `int2` sequences. -The [`bdr.sequences`](/pgd/latest/reference/catalogs-visible/#bdrsequences) view shows information about individual sequence kinds. +The [`bdr.sequences`](/pgd/5.6/reference/catalogs-visible/#bdrsequences) view shows information about individual sequence kinds. `currval()` and `lastval()` work correctly for all types of global sequence. @@ -220,7 +220,7 @@ to or more than the above ranges assigned for each sequence datatype. `setval()` doesn't reset the global state for `galloc` sequences. Don't use it. A few limitations apply to `galloc` sequences. PGD tracks `galloc` sequences in a -special PGD catalog [bdr.sequence_alloc](/pgd/latest/reference/catalogs-visible/#bdrsequence_alloc). This +special PGD catalog [bdr.sequence_alloc](/pgd/5.6/reference/catalogs-visible/#bdrsequence_alloc). This catalog is required to track the currently allocated chunks for the `galloc` sequences. The sequence name and namespace is stored in this catalog. The sequence chunk allocation is managed by Raft, whereas any changes to the diff --git a/product_docs/docs/pgd/5.6/testingandtuning.mdx b/product_docs/docs/pgd/5.6/testingandtuning.mdx index e1965318d0d..f1905c09161 100644 --- a/product_docs/docs/pgd/5.6/testingandtuning.mdx +++ b/product_docs/docs/pgd/5.6/testingandtuning.mdx @@ -33,7 +33,7 @@ The Postgres benchmarking application [`pgbench`](https://www.postgresql.org/docs/current/pgbench.html) was extended in PGD 5.0 in the form of a new application: pgd_bench. -[pgd_bench](/pgd/latest/reference/testingandtuning#pgd_bench) is a regular command-line utility that's added to the PostgreSQL bin +[pgd_bench](/pgd/5.6/reference/testingandtuning#pgd_bench) is a regular command-line utility that's added to the PostgreSQL bin directory. The utility is based on the PostgreSQL pgbench tool but supports benchmarking CAMO transactions and PGD-specific workloads. diff --git a/product_docs/docs/pgd/5.6/transaction-streaming.mdx b/product_docs/docs/pgd/5.6/transaction-streaming.mdx index 8e6e53288fa..c1edfb191b0 100644 --- a/product_docs/docs/pgd/5.6/transaction-streaming.mdx +++ b/product_docs/docs/pgd/5.6/transaction-streaming.mdx @@ -56,8 +56,8 @@ processes on each subscriber. This capability is leveraged to provide the follow Configure transaction streaming in two locations: -- At node level, using the GUC [`bdr.default_streaming_mode`](/pgd/latest/reference/pgd-settings/#transaction-streaming) -- At group level, using the function [`bdr.alter_node_group_option()`](/pgd/latest/reference/nodes-management-interfaces/#bdralter_node_group_option) +- At node level, using the GUC [`bdr.default_streaming_mode`](/pgd/5.6/reference/pgd-settings/#transaction-streaming) +- At group level, using the function [`bdr.alter_node_group_option()`](/pgd/5.6/reference/nodes-management-interfaces/#bdralter_node_group_option) ### Node configuration using bdr.default_streaming_mode @@ -81,7 +81,7 @@ provided can also depend on the group configuration setting. See ### Group configuration using bdr.alter_node_group_option() -You can use the parameter `streaming_mode` in the function [`bdr.alter_node_group_option()`](/pgd/latest/reference/nodes-management-interfaces/#bdralter_node_group_option) +You can use the parameter `streaming_mode` in the function [`bdr.alter_node_group_option()`](/pgd/5.6/reference/nodes-management-interfaces/#bdralter_node_group_option) to set the group transaction streaming configuration. Permitted values are: @@ -95,7 +95,7 @@ Permitted values are: The default value is `default`. The value of the current setting is contained in the column `node_group_streaming_mode` -from the view [`bdr.node_group`](/pgd/latest/reference/catalogs-visible/#bdrnode_group). The value returned is +from the view [`bdr.node_group`](/pgd/5.6/reference/catalogs-visible/#bdrnode_group). The value returned is a single char type, and the possible values are `D` (`default`), `W` (`writer`), `F` (`file`), `A` (`auto`), and `O` (`off`). @@ -151,7 +151,7 @@ and can be safely handled by the writer. ## Monitoring -You can monitor the use of transaction streaming using the [`bdr.stat_subscription`](/pgd/latest/reference/catalogs-visible/#bdrstat_subscription) +You can monitor the use of transaction streaming using the [`bdr.stat_subscription`](/pgd/5.6/reference/catalogs-visible/#bdrstat_subscription) function on the subscriber node. - `nstream_writer` — Number of transactions streamed to a writer. diff --git a/product_docs/docs/pgd/5.6/upgrades/compatibility.mdx b/product_docs/docs/pgd/5.6/upgrades/compatibility.mdx index ac30086652a..88cfb6a4a5b 100644 --- a/product_docs/docs/pgd/5.6/upgrades/compatibility.mdx +++ b/product_docs/docs/pgd/5.6/upgrades/compatibility.mdx @@ -66,6 +66,6 @@ Similarly to CAMO and Eager, Lag Control configuration was also moved to - `bdr.network_monitoring` view was removed along with underlying tables and functions. - Many catalogs were added and some have new columns, as described in - [Catalogs](/pgd/latest/reference/catalogs-visible/). These + [Catalogs](/pgd/5.6/reference/catalogs-visible/). These aren't breaking changes strictly speaking, but we recommend reviewing them when upgrading. diff --git a/product_docs/docs/pgd/5.6/upgrades/upgrading_major_rolling.mdx b/product_docs/docs/pgd/5.6/upgrades/upgrading_major_rolling.mdx index 140bd3aa3a1..eab13212cd4 100644 --- a/product_docs/docs/pgd/5.6/upgrades/upgrading_major_rolling.mdx +++ b/product_docs/docs/pgd/5.6/upgrades/upgrading_major_rolling.mdx @@ -3,8 +3,8 @@ title: Performing a Postgres major version rolling upgrade on a PGD cluster buil navTitle: Upgrading Postgres major versions deepToC: true redirects: - - /pgd/latest/install-admin/admin-tpa/upgrading_major_rolling/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-tpa/upgrading_major_rolling/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/install-admin/admin-tpa/upgrading_major_rolling/ #generated for pgd deploy-config-planning reorg + - /pgd/5.6/admin-tpa/upgrading_major_rolling/ #generated for pgd deploy-config-planning reorg --- ## Upgrading Postgres major versions @@ -169,7 +169,7 @@ The worked example that follows shows upgrading the Postgres major version from ## Worked example -This worked example starts with a TPA-managed PGD cluster deployed using the [AWS quick start](/pgd/latest/quickstart/quick_start_aws/). The cluster has three nodes: kaboom, kaolin, and kaftan, all running Postgres 15. +This worked example starts with a TPA-managed PGD cluster deployed using the [AWS quick start](/pgd/5.6/quickstart/quick_start_aws/). The cluster has three nodes: kaboom, kaolin, and kaftan, all running Postgres 15. This example starts with kaboom. diff --git a/product_docs/docs/pgd/6/known_issues.mdx b/product_docs/docs/pgd/6/known_issues.mdx index f0e1d7d7b82..d850002b897 100644 --- a/product_docs/docs/pgd/6/known_issues.mdx +++ b/product_docs/docs/pgd/6/known_issues.mdx @@ -7,9 +7,7 @@ description: 'Known issues and limitations in EDB Postgres Distributed 6' ## Known issues These are currently known issues in EDB Postgres Distributed 6. -These known issues are tracked in PGD's -ticketing system and are expected to be resolved in a future -release. +These known issues are tracked in PGD's ticketing system and are expected to be resolved in a future release. - If the resolver for the `update_origin_change` conflict is set to `skip`, `synchronous_commit=remote_apply` is used, and From 717b6ffb1e823d025f556265b72094fba816f79a Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 1 May 2025 12:08:46 +0100 Subject: [PATCH 036/145] Fix KI line Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/known_issues.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/product_docs/docs/pgd/6/known_issues.mdx b/product_docs/docs/pgd/6/known_issues.mdx index d850002b897..b1ab43f8c47 100644 --- a/product_docs/docs/pgd/6/known_issues.mdx +++ b/product_docs/docs/pgd/6/known_issues.mdx @@ -1,6 +1,6 @@ --- title: 'Known issues and limitations' -nav_title: 'Known issues and limitations' +navTitle: 'Known issues and limitations' description: 'Known issues and limitations in EDB Postgres Distributed 6' --- @@ -14,7 +14,7 @@ These known issues are tracked in PGD's ticketing system and are expected to be concurrent updates of the same row are repeatedly applied on two different nodes, then one of the update statements might hang due to a deadlock with the PGD writer. As mentioned in - [Conflicts](/pgd/advanced/conflict-management/conflicts/), `skip` isn't the default + [Conflicts](/pgd/latest/reference/conflict-management/conflicts/), `skip` isn't the default resolver for the `update_origin_change` conflict, and this combination isn't intended to be used in production. It discards one of the two conflicting updates based on the order of arrival From 6f328f10b0b1e6aed32098eeea190850be18092f Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 1 May 2025 15:19:26 +0100 Subject: [PATCH 037/145] Fixes for deployment Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/5.6/planning/index.mdx | 10 +++++----- .../essential-how-to/architectures/near-far/index.mdx | 4 ++-- .../pgd/6/get-started/essential-near-far/index.mdx | 2 +- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/product_docs/docs/pgd/5.6/planning/index.mdx b/product_docs/docs/pgd/5.6/planning/index.mdx index 3415e3e20b6..40dfdfa7ac4 100644 --- a/product_docs/docs/pgd/5.6/planning/index.mdx +++ b/product_docs/docs/pgd/5.6/planning/index.mdx @@ -3,11 +3,11 @@ title: Planning your PGD deployment navTitle: Planning description: Understand the requirements of your application and the capabilities of PGD to plan your deployment. navigation: - - architectures - - choosing_server - - deployments - - other_considerations - - limitations +- architectures +- choosing_server +- deployments +- other_considerations +- limitations --- Planning your PGD deployment involves understanding the requirements of your application and the capabilities of PGD. This section provides an overview of the key considerations for planning your PGD deployment. diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/index.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/index.mdx index b9c9d3ef8a9..b31381070a3 100644 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/index.mdx @@ -2,7 +2,7 @@ title: Near-Far Architecture navTitle: Near-Far navigation: - - manual-deployments - - kubernetes-deployments +- manual-deployments +- kubernetes-deployments --- diff --git a/product_docs/docs/pgd/6/get-started/essential-near-far/index.mdx b/product_docs/docs/pgd/6/get-started/essential-near-far/index.mdx index 4d025466b36..ad39c736d0b 100644 --- a/product_docs/docs/pgd/6/get-started/essential-near-far/index.mdx +++ b/product_docs/docs/pgd/6/get-started/essential-near-far/index.mdx @@ -1,4 +1,4 @@ --- title: PGD Essential Near-Far navTitle: PGD Near-Far -.--- \ No newline at end of file +--- \ No newline at end of file From 91dca24769ec71daf63194f894b224d2cd064961 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 1 May 2025 18:29:50 +0100 Subject: [PATCH 038/145] Mods and additions Signed-off-by: Dj Walker-Morgan --- .../essential-how-to/architectures/index.mdx | 20 ++++++++++++++++++- .../01-prerequisites.mdx | 0 .../02-installing-database-and-pgd.mdx | 0 .../03-configuring-cluster.mdx | 0 .../04-check-cluster.mdx | 2 +- .../05-using-pgd-cli.mdx | 2 +- .../images/edbrepos2.0.png | 0 .../{deploy-manual => deploy}/index.mdx | 0 .../docs/pgd/6/essential-how-to/index.mdx | 3 ++- .../architectures.mdx | 2 +- .../essential-one-location/index.mdx | 4 ++-- product_docs/docs/pgd/6/get-started/index.mdx | 6 +++++- 12 files changed, 31 insertions(+), 8 deletions(-) rename product_docs/docs/pgd/6/essential-how-to/{deploy-manual => deploy}/01-prerequisites.mdx (100%) rename product_docs/docs/pgd/6/essential-how-to/{deploy-manual => deploy}/02-installing-database-and-pgd.mdx (100%) rename product_docs/docs/pgd/6/essential-how-to/{deploy-manual => deploy}/03-configuring-cluster.mdx (100%) rename product_docs/docs/pgd/6/essential-how-to/{deploy-manual => deploy}/04-check-cluster.mdx (99%) rename product_docs/docs/pgd/6/essential-how-to/{deploy-manual => deploy}/05-using-pgd-cli.mdx (99%) rename product_docs/docs/pgd/6/essential-how-to/{deploy-manual => deploy}/images/edbrepos2.0.png (100%) rename product_docs/docs/pgd/6/essential-how-to/{deploy-manual => deploy}/index.mdx (100%) rename product_docs/docs/pgd/6/{essential-how-to/architectures => expanded-how-to}/architectures.mdx (99%) diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx index ae68037f022..9b123e8f5b7 100644 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx @@ -1,5 +1,5 @@ --- -title: PGD Architectures +title: PGD Essential Architectures navTitle: Architectures navigation: - standard @@ -14,6 +14,24 @@ They are standard and near/far. ## Standard architecture - Ideal for a highly available single location +The standard, or one-location, architecture is designed for a single location which needs to be highly available. Built around three data nodes, the Essential standard architecture ensures that data is replicated across all three nodes and that, in the event of a failure, the system can continue to operate without data loss. + +Using core PGD capabilites, the standard architecture configures the three nodes in a multi-master replication configuration. That is, each node operates as a master node and logically replicates its data to the other nodes. Now, while PGD is capable of handling conflicts between data changes on nodes, the Essential standard architecture use PGD's integrated connection manager to ensure that all writes are directed to a single node, the write leader. Conflicts are avoided by allowing that singular leader to handle all updates to the data. Changes are then replicated to the other nodes in the cluster. + +If the write leader fails, the remaining nodes in the cluster will elect a new write leader and the connection managers in those nodes will then automatically failover to send writes to the new leader. When the failed node comes back online, it will automatically rejoin the cluster and begin replicating data from the new write leader. + +The Essential standard architecture has been created to be easy to deploy and manage, based on user experience. Unlike other high availability solutions, because Essential is built on PGD, moving to a more complex architecture is simple and straightforward; move to Expanded PGD and then add new data groups to the cluster as needed. ## Near/far architecture - Ideal for disaster recovery +The Near/Far architecture is designed for a single location which needs to be reasonably highly available, but also needs to be able to recover from a disaster. It does this by having a two data node cluster in the primary location and a single data node in a secondary location. + +The two data nodes in the primary location are configured in a multi-master replication configuration, just like the standard architecture. The single data node in the secondary location is configured as a subscriber to the primary location. This means that all changes made to the data in the primary location are replicated to the secondary location. + +In the event of a partial failure at the primary location, the system will switch to the other data node, also with a complete replica of the data, and continue to operate. It will also continue replication to the secondary location. When the failed node at the primary location comes back, it will rejoin and begin replicating data from the node that is currently primary. + +In the event of a complete failure in the primary location, the secondary location's database has a complete replica of the data. The connection manager in the primary location will automatically failover to the secondary location and all writes will be directed to that node. When the primary location comes back online, it will automatically rejoin the cluster and begin replicating data from the secondary location. + + + + diff --git a/product_docs/docs/pgd/6/essential-how-to/deploy-manual/01-prerequisites.mdx b/product_docs/docs/pgd/6/essential-how-to/deploy/01-prerequisites.mdx similarity index 100% rename from product_docs/docs/pgd/6/essential-how-to/deploy-manual/01-prerequisites.mdx rename to product_docs/docs/pgd/6/essential-how-to/deploy/01-prerequisites.mdx diff --git a/product_docs/docs/pgd/6/essential-how-to/deploy-manual/02-installing-database-and-pgd.mdx b/product_docs/docs/pgd/6/essential-how-to/deploy/02-installing-database-and-pgd.mdx similarity index 100% rename from product_docs/docs/pgd/6/essential-how-to/deploy-manual/02-installing-database-and-pgd.mdx rename to product_docs/docs/pgd/6/essential-how-to/deploy/02-installing-database-and-pgd.mdx diff --git a/product_docs/docs/pgd/6/essential-how-to/deploy-manual/03-configuring-cluster.mdx b/product_docs/docs/pgd/6/essential-how-to/deploy/03-configuring-cluster.mdx similarity index 100% rename from product_docs/docs/pgd/6/essential-how-to/deploy-manual/03-configuring-cluster.mdx rename to product_docs/docs/pgd/6/essential-how-to/deploy/03-configuring-cluster.mdx diff --git a/product_docs/docs/pgd/6/essential-how-to/deploy-manual/04-check-cluster.mdx b/product_docs/docs/pgd/6/essential-how-to/deploy/04-check-cluster.mdx similarity index 99% rename from product_docs/docs/pgd/6/essential-how-to/deploy-manual/04-check-cluster.mdx rename to product_docs/docs/pgd/6/essential-how-to/deploy/04-check-cluster.mdx index fc7938ce85c..3db88ceac36 100644 --- a/product_docs/docs/pgd/6/essential-how-to/deploy-manual/04-check-cluster.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/deploy/04-check-cluster.mdx @@ -1,5 +1,5 @@ --- -title: Step 6 - Checking the cluster +title: Step 4 - Checking the cluster navTitle: Checking the cluster deepToC: true redirects: diff --git a/product_docs/docs/pgd/6/essential-how-to/deploy-manual/05-using-pgd-cli.mdx b/product_docs/docs/pgd/6/essential-how-to/deploy/05-using-pgd-cli.mdx similarity index 99% rename from product_docs/docs/pgd/6/essential-how-to/deploy-manual/05-using-pgd-cli.mdx rename to product_docs/docs/pgd/6/essential-how-to/deploy/05-using-pgd-cli.mdx index 4361a3625ad..dd382e5c57d 100644 --- a/product_docs/docs/pgd/6/essential-how-to/deploy-manual/05-using-pgd-cli.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/deploy/05-using-pgd-cli.mdx @@ -1,5 +1,5 @@ --- -title: Step 8 - Using PGD CLI +title: Step 5 - Using PGD CLI navTitle: Using PGD CLI deepToC: true redirects: diff --git a/product_docs/docs/pgd/6/essential-how-to/deploy-manual/images/edbrepos2.0.png b/product_docs/docs/pgd/6/essential-how-to/deploy/images/edbrepos2.0.png similarity index 100% rename from product_docs/docs/pgd/6/essential-how-to/deploy-manual/images/edbrepos2.0.png rename to product_docs/docs/pgd/6/essential-how-to/deploy/images/edbrepos2.0.png diff --git a/product_docs/docs/pgd/6/essential-how-to/deploy-manual/index.mdx b/product_docs/docs/pgd/6/essential-how-to/deploy/index.mdx similarity index 100% rename from product_docs/docs/pgd/6/essential-how-to/deploy-manual/index.mdx rename to product_docs/docs/pgd/6/essential-how-to/deploy/index.mdx diff --git a/product_docs/docs/pgd/6/essential-how-to/index.mdx b/product_docs/docs/pgd/6/essential-how-to/index.mdx index e3958ff842e..a4f887517bd 100644 --- a/product_docs/docs/pgd/6/essential-how-to/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/index.mdx @@ -3,11 +3,12 @@ title: Essential How-To navTitle: Essential How-To navigation: - architectures -- deployment +- deploy - durability - autopartition - production-best-practices - sop +description: Essential how-to guides for deploying and managing your PGD cluster. --- This section provides essential how-to guides for deploying and managing your PGD cluster. It includes information on architectures, deployment, durability, autopartition, production best practices, and standard operating procedures (SOPs). diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/architectures.mdx b/product_docs/docs/pgd/6/expanded-how-to/architectures.mdx similarity index 99% rename from product_docs/docs/pgd/6/essential-how-to/architectures/architectures.mdx rename to product_docs/docs/pgd/6/expanded-how-to/architectures.mdx index 3aa2d259545..60627c5ee35 100644 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/architectures.mdx +++ b/product_docs/docs/pgd/6/expanded-how-to/architectures.mdx @@ -17,7 +17,7 @@ Postgres Distributed’s multi-master capability and its ability to achieve You can use EDB Postgres Distributed for architectures beyond the examples described here. Use-case-specific variations have been successfully deployed in production. However, these variations must undergo rigorous architecture review -first. +first. Always-on architectures can be deployed using EDB’s standard deployment tool Trusted Postgres Architect (TPA) or configured manually. diff --git a/product_docs/docs/pgd/6/get-started/essential-one-location/index.mdx b/product_docs/docs/pgd/6/get-started/essential-one-location/index.mdx index 814a450831c..1b782d63db9 100644 --- a/product_docs/docs/pgd/6/get-started/essential-one-location/index.mdx +++ b/product_docs/docs/pgd/6/get-started/essential-one-location/index.mdx @@ -1,6 +1,6 @@ --- -title: PGD Essential in One Location -navTitle: PGD in One Location +title: PGD Essential in one Location +navTitle: PGD in one Location --- ## About the one-location architecture diff --git a/product_docs/docs/pgd/6/get-started/index.mdx b/product_docs/docs/pgd/6/get-started/index.mdx index 84e22d8ac05..4bb0eb414dc 100644 --- a/product_docs/docs/pgd/6/get-started/index.mdx +++ b/product_docs/docs/pgd/6/get-started/index.mdx @@ -1,6 +1,10 @@ --- title: Get started with PGD navTitle: Get started -description: Get started with EDB Postgres Distributed, installing and configuring the software, and creating your first cluster. +description: "Get started with EDB Postgres Distributed, installing and configuring the software, and creating your first cluster." +navigation: +- essential-one-location +- essential-near-far +- expanded-examples --- From a5b193b38c3bf85b613998374f3b0a0a2577ee5a Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Tue, 6 May 2025 08:57:20 +0100 Subject: [PATCH 039/145] More reorg of installer Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/essential-how-to/index.mdx | 2 +- .../{deploy => install}/01-prerequisites.mdx | 0 .../02-installing-database-and-pgd.mdx | 3 +- .../03-configuring-cluster.mdx | 0 .../{deploy => install}/04-check-cluster.mdx | 0 .../{deploy => install}/05-using-pgd-cli.mdx | 47 ++++---- .../images/edbrepos2.0.png | 0 .../{deploy => install}/index.mdx | 5 +- product_docs/docs/pgd/6/get-started/index.mdx | 1 + product_docs/docs/pgd/6/index.mdx | 13 ++- product_docs/docs/pgd/6/known_issues.mdx | 2 +- .../pgd/6/reference/cli/command_ref/index.mdx | 1 + .../reference/cli/command_ref/node/setup.mdx | 21 ++-- .../docs/pgd/6/reference/cli/index.mdx | 3 +- .../pgd/6/reference/commit-scopes/index.mdx | 10 +- .../predefined-commit-scopes.mdx | 58 ++++++++++ .../docs/pgd/6/reference/monitoring/index.mdx | 25 ++--- .../docs/pgd/6/reference/monitoring/otel.mdx | 106 ------------------ 18 files changed, 126 insertions(+), 171 deletions(-) rename product_docs/docs/pgd/6/essential-how-to/{deploy => install}/01-prerequisites.mdx (100%) rename product_docs/docs/pgd/6/essential-how-to/{deploy => install}/02-installing-database-and-pgd.mdx (97%) rename product_docs/docs/pgd/6/essential-how-to/{deploy => install}/03-configuring-cluster.mdx (100%) rename product_docs/docs/pgd/6/essential-how-to/{deploy => install}/04-check-cluster.mdx (100%) rename product_docs/docs/pgd/6/essential-how-to/{deploy => install}/05-using-pgd-cli.mdx (86%) rename product_docs/docs/pgd/6/essential-how-to/{deploy => install}/images/edbrepos2.0.png (100%) rename product_docs/docs/pgd/6/essential-how-to/{deploy => install}/index.mdx (78%) create mode 100644 product_docs/docs/pgd/6/reference/commit-scopes/predefined-commit-scopes.mdx delete mode 100644 product_docs/docs/pgd/6/reference/monitoring/otel.mdx diff --git a/product_docs/docs/pgd/6/essential-how-to/index.mdx b/product_docs/docs/pgd/6/essential-how-to/index.mdx index a4f887517bd..5bc1db439f1 100644 --- a/product_docs/docs/pgd/6/essential-how-to/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/index.mdx @@ -3,7 +3,7 @@ title: Essential How-To navTitle: Essential How-To navigation: - architectures -- deploy +- install - durability - autopartition - production-best-practices diff --git a/product_docs/docs/pgd/6/essential-how-to/deploy/01-prerequisites.mdx b/product_docs/docs/pgd/6/essential-how-to/install/01-prerequisites.mdx similarity index 100% rename from product_docs/docs/pgd/6/essential-how-to/deploy/01-prerequisites.mdx rename to product_docs/docs/pgd/6/essential-how-to/install/01-prerequisites.mdx diff --git a/product_docs/docs/pgd/6/essential-how-to/deploy/02-installing-database-and-pgd.mdx b/product_docs/docs/pgd/6/essential-how-to/install/02-installing-database-and-pgd.mdx similarity index 97% rename from product_docs/docs/pgd/6/essential-how-to/deploy/02-installing-database-and-pgd.mdx rename to product_docs/docs/pgd/6/essential-how-to/install/02-installing-database-and-pgd.mdx index 5185ea7f40a..e4b8c45bca4 100644 --- a/product_docs/docs/pgd/6/essential-how-to/deploy/02-installing-database-and-pgd.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/02-installing-database-and-pgd.mdx @@ -107,10 +107,11 @@ export PGD_EDITION=essential ```bash - export EDB_PACKAGES="edb-pge$PG_VERSION edb-pgd6-$PGD_EDITION-pgextended$PG_VERSION" + export EDB_PACKAGES="edb-postgresextended-$PG_VERSION edb-pgd6-$PGD_EDITION-pgextended$PG_VERSION" ``` + ```bash diff --git a/product_docs/docs/pgd/6/essential-how-to/deploy/03-configuring-cluster.mdx b/product_docs/docs/pgd/6/essential-how-to/install/03-configuring-cluster.mdx similarity index 100% rename from product_docs/docs/pgd/6/essential-how-to/deploy/03-configuring-cluster.mdx rename to product_docs/docs/pgd/6/essential-how-to/install/03-configuring-cluster.mdx diff --git a/product_docs/docs/pgd/6/essential-how-to/deploy/04-check-cluster.mdx b/product_docs/docs/pgd/6/essential-how-to/install/04-check-cluster.mdx similarity index 100% rename from product_docs/docs/pgd/6/essential-how-to/deploy/04-check-cluster.mdx rename to product_docs/docs/pgd/6/essential-how-to/install/04-check-cluster.mdx diff --git a/product_docs/docs/pgd/6/essential-how-to/deploy/05-using-pgd-cli.mdx b/product_docs/docs/pgd/6/essential-how-to/install/05-using-pgd-cli.mdx similarity index 86% rename from product_docs/docs/pgd/6/essential-how-to/deploy/05-using-pgd-cli.mdx rename to product_docs/docs/pgd/6/essential-how-to/install/05-using-pgd-cli.mdx index dd382e5c57d..fbb000c220f 100644 --- a/product_docs/docs/pgd/6/essential-how-to/deploy/05-using-pgd-cli.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/05-using-pgd-cli.mdx @@ -25,25 +25,26 @@ We recommend the first option, as the other options don't scale well with multip ### Configuring and connecting PGD CLI -* Ensure PGD CLI is installed. - * If PGD CLI was already installed, move to the next step. - * For any system, repeat the [configure repositories](03-configuring-repositories) step on that system. - * Then run the package installation command appropriate for that platform. - * RHEL and derivatives: `sudo dnf install edb-pgd6-cli` - * Debian, Ubuntu, and derivatives: `sudo apt-get install edb-pgd6-cli` -* Create a configuration file. - * This is a YAML file that specifies the cluster and endpoints for PGD CLI to use. -* Install the configuration file. - * Copy the YAML configuration file to a default config directory `/etc/edb/pgd-cli/` as `pgd-cli-config.yml`. - * Repeat this process on any system where you want to run PGD CLI. -* Run pgd-cli. +- Ensure PGD CLI is installed. + - If PGD CLI was already installed, move to the next step. + - For any system, repeat the [configure repositories](02-installing-database-and-pgd#configuring_repositories) step on that system. + - Then run the package installation command appropriate for that platform. + - RHEL and derivatives: `sudo dnf install edb-pgd6-cli` + - Debian, Ubuntu, and derivatives: `sudo apt-get install edb-pgd6-cli` +- Create a configuration file. + - This is a YAML file that specifies the cluster and endpoints for PGD CLI to use. +- Install the configuration file. + - Copy the YAML configuration file to a default config directory `/etc/edb/pgd-cli/` as `pgd-cli-config.yml`. + - Repeat this process on any system where you want to run PGD CLI. +- Run pgd-cli. ### Use PGD CLI to explore the cluster -* Check the health of the cluster with the `cluster show --health` command. -* Show the nodes in the cluster with the `nodes list` command. -* Show the groups in the cluster with the `groups list` command. -* Set a group option with the `group set-option` command. -* Switch write leader with the `group set-leader` command. + +- Check the health of the cluster with the `cluster show --health` command. +- Show the nodes in the cluster with the `nodes list` command. +- Show the groups in the cluster with the `groups list` command. +- Set a group option with the `group set-option` command. +- Switch write leader with the `group set-leader` command. For more details about these commands, see the worked example that follows. @@ -61,8 +62,8 @@ You don't need to install PGD CLI again. The PGD CLI configuration file is a YAML file that contains a cluster object. This has two properties: -* The name of the PGD cluster's top-level group (as `name`) -* An array of endpoints of databases (as `endpoints`) +- The name of the PGD cluster's top-level group (as `name`) +- An array of endpoints of databases (as `endpoints`) ``` cluster: @@ -178,10 +179,10 @@ dc1 pgd data 3 ``` This command shows: -* The groups -* Their types -* Their parent group -* The number of nodes in each group +- The groups +- Their types +- Their parent group +- The number of nodes in each group ### Set a group option diff --git a/product_docs/docs/pgd/6/essential-how-to/deploy/images/edbrepos2.0.png b/product_docs/docs/pgd/6/essential-how-to/install/images/edbrepos2.0.png similarity index 100% rename from product_docs/docs/pgd/6/essential-how-to/deploy/images/edbrepos2.0.png rename to product_docs/docs/pgd/6/essential-how-to/install/images/edbrepos2.0.png diff --git a/product_docs/docs/pgd/6/essential-how-to/deploy/index.mdx b/product_docs/docs/pgd/6/essential-how-to/install/index.mdx similarity index 78% rename from product_docs/docs/pgd/6/essential-how-to/deploy/index.mdx rename to product_docs/docs/pgd/6/essential-how-to/install/index.mdx index d7761d5a6a5..beabb962d7d 100644 --- a/product_docs/docs/pgd/6/essential-how-to/deploy/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/index.mdx @@ -1,6 +1,6 @@ --- -title: Manual deployment and configuration of PGD -navTitle: Manually +title: Installing and configuring EDB Postgres Distributed 6 +navTitle: Installing and configuring --- This section covers how to manually deploy and configure EDB Postgres Distributed 6. @@ -10,4 +10,3 @@ This section covers how to manually deploy and configure EDB Postgres Distribute * [Creating the cluster](03-configuring-cluster.mdx) * [Checking the cluster](04-check-cluster.mdx) * [Using PGD CLI](05-using-pgd-cli.mdx) - diff --git a/product_docs/docs/pgd/6/get-started/index.mdx b/product_docs/docs/pgd/6/get-started/index.mdx index 4bb0eb414dc..d823ecd6fbc 100644 --- a/product_docs/docs/pgd/6/get-started/index.mdx +++ b/product_docs/docs/pgd/6/get-started/index.mdx @@ -8,3 +8,4 @@ navigation: - expanded-examples --- +To begin using any edition of EDB Postgres Distributed, we recommend you first try our local installation and configuration guide. This guide will help you set up a Docker-compose cluster on your local machine, which is ideal for testing and learning purposes. diff --git a/product_docs/docs/pgd/6/index.mdx b/product_docs/docs/pgd/6/index.mdx index 226c18a0291..926f43c1a0a 100644 --- a/product_docs/docs/pgd/6/index.mdx +++ b/product_docs/docs/pgd/6/index.mdx @@ -10,9 +10,6 @@ navigation: - get-started - "#Essential PGD" - essential-how-to - - durability - - partitioning - - production-best-practices - "#Expanded PGD" - expanded-how-to - "#Concepts" @@ -38,9 +35,15 @@ Welcome to the PGD 6.0 documentation. PGD 6.0 is now available in two editions, Modern data architectures require an extensible approach to data management, whether the requirement is for high availability, disaster recovery or multi-region data distribution. PGD is designed to meet these needs, and in PGD 6.0 we have made it easier to get started with PGD, while also providing a pathway to using advanced features as your use case becomes more complex. -## What are the differences between PGD Essential and PGD Expanded? +## What does PGD enable? + +PGD enables you to build a distributed database architecture that can span multiple regions, data centers, or cloud providers. It provides multi-master replication and data distribution. Postgres databases can be deployed into data groups within the cluster and data within each node can be distributed across multiple nodes. -PGD Essential is a simplified version of PGD Expanded. It is designed for users who want to get started with PGD quickly and easily, without the need for advanced features or complex configurations. PGD Essential includes the core features of PGD, such as multi-master replication, conflict management, and data-loss protection, but does not include some of the more advanced features available in PGD Expanded. +## What are the differences between PGD Essential and PGD Expanded? PGD Expanded is the full-featured version of PGD. It includes all the features of PGD Essential, as well as additional features such as advanced conflict management, data distribution, and support for large-scale deployments. PGD Expanded is designed for users who need the most advanced features and capabilities of PGD. +PGD Essential is a simplified version of PGD Expanded. It is designed for users who want to get started with PGD quickly and easily, without the need for advanced features or complex configurations. PGD Essential includes the core features of PGD but enables them in a way that makes replication and availability simple. It therefore does not include some of the more advanced features available in PGD Expanded. + +PGD Essential limits the number of nodes in a cluster to 4 and the number of groups to 2. It also limits the number of nodes in a group to 4. PGD Expanded does not have these limitations. + diff --git a/product_docs/docs/pgd/6/known_issues.mdx b/product_docs/docs/pgd/6/known_issues.mdx index b1ab43f8c47..1ed8d130b78 100644 --- a/product_docs/docs/pgd/6/known_issues.mdx +++ b/product_docs/docs/pgd/6/known_issues.mdx @@ -114,7 +114,7 @@ doing so incurs many immediate risks and current limitations: synchronous commit confirmation can come from any database, not necessarily in the right order of commits. -- CLI and OTEL integration assumes one database. +- CLI integration assumes one database. ### Durability options (Group Commit/CAMO) diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/index.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/index.mdx index c3bfef126cb..e0a6cc5ffea 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/index.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/index.mdx @@ -26,6 +26,7 @@ cluster resources. - [groups](groups): Group related commands for listing groups. - [list](groups/list): List groups. - [node](node): Node-level commands for managing nodes. + - [setup](node/setup): Setup a node in the cluster. - [show](node/show): Show node-level information. - [set-option](node/set-option): Set node-level options. - [get-option](node/get-option): Get node-level options. diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx index 936cc3dbfe6..d176c3533a6 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx @@ -52,27 +52,20 @@ See also [Global Options](/pgd/latest/cli/command_ref/#global-options). ## Examples -### Configuring a new node +In these examples, we will set up a cluster with on three hosts, `host-1`, `host-2` and `host-3`, to create three nodes: `node-one`, `node-two`, and `node-three`. +The three nodes will be data nodes, and part a cluster named `dc1-cluster` with the group name `dc1`. -```shell -pgd node kaboom setup --pgdata /var/lib/edb/pgd/data --group-name dc1 --cluster-name dc1-cluster --cluster-dsn "host=localhost port=5444 user=postgres dbname=bdrdb" -``` - -This command will create a new node named `kaboom` in the cluster `dc1-cluster` with the group name `dc1`. The data directory for the node is set to `/var/lib/edb/pgd/data`. - -### Configuring a new node with a custom postgresql.conf file +### Configuring the first node ```shell -pgd node kaboom setup --pgdata /var/lib/edb/pgd/data --group-name dc1 --cluster-name dc1-cluster --cluster-dsn "host=localhost port=5444 user=postgres dbname=bdrdb" --postgresql-conf /path/to/postgresql.conf +pgd node node-one setup --pgdata /var/lib/edb-pge/17/main --group-name dc1 --cluster-name dc1-cluster --cluster-dsn "host=localhost port=5444 user=postgres dbname=bdrdb" --create-group ``` -This command will create a new node named `kaboom` in the cluster `dc1-cluster` with the group name `dc1`. The data directory for the node is set to `/var/lib/edb/pgd/data`, and the postgresql.conf file is set to `/path/to/postgresql.conf`. +This command will create the first node named `node-one` in the cluster `dc1-cluster` with the group name `dc1`. The data directory for the node is set to `/var/lib/edb-pge/17/main`. -### Configuring a new node with a custom pg_hba.conf file +### Configuring the second node ```shell -pgd node kaboom setup --pgdata /var/lib/edb/pgd/data --group-name dc1 --cluster-name dc1-cluster --cluster-dsn "host=localhost port=5444 user=postgres dbname=bdrdb" --hba-conf /path/to/pg_hba.conf +pgd node node-two setup --pgdata /var/lib/edb-pge/17/main --group-name dc1 --cluster-name dc1-cluster --cluster-dsn "host= port=5444 user=postgres dbname=bdrdb" --create-group ``` -This command will create a new node named `kaboom` in the cluster `dc1-cluster` with the group name `dc1`. The data directory for the node is set to `/var/lib/edb/pgd/data`, and the pg_hba.conf file is set to `/path/to/pg_hba.conf`. - diff --git a/product_docs/docs/pgd/6/reference/cli/index.mdx b/product_docs/docs/pgd/6/reference/cli/index.mdx index 5b304494230..e2758f8e1a1 100644 --- a/product_docs/docs/pgd/6/reference/cli/index.mdx +++ b/product_docs/docs/pgd/6/reference/cli/index.mdx @@ -23,7 +23,7 @@ It allows you to run commands against EDB Postgres Distributed clusters to: * Inspect and manage the cluster's nodes and groups. * Perform a write-leader change operation on the group. -PGD CLI is installed automatically on systems in a TPA-deployed PGD cluster. +PGD CLI is installed automatically on systems in a TPA-deployed PGD cluster. You can also install it manually on Linux and macOS systems that can connect to a PGD cluster, including: @@ -31,4 +31,3 @@ You can also install it manually on Linux and macOS systems that can connect to * PGD clusters deployed using the CloudNative Postgres Global Clusters operator. * Manually deployed PGD clusters. * TPA-deployed PGD clusters. - diff --git a/product_docs/docs/pgd/6/reference/commit-scopes/index.mdx b/product_docs/docs/pgd/6/reference/commit-scopes/index.mdx index 7c7710869d0..cf1243e92e6 100644 --- a/product_docs/docs/pgd/6/reference/commit-scopes/index.mdx +++ b/product_docs/docs/pgd/6/reference/commit-scopes/index.mdx @@ -25,12 +25,16 @@ redirects: - /pgd/latest/durability/ --- -EDB Postgres Distributed (PGD) offers a range of synchronous modes to complement its +Fully managable and configurable commit scopes are a feature of PGD Expanded. + +PGD Expanded offers a range of synchronous modes to complement its default asynchronous replication. You use commit scopes to configure these synchronous modes. Commit scopes are rules that define how PGD handles synchronous operations and when the system considers a transaction committed. -## Introducing +PGD Essential offers a limited set of commit scopes that are pre-defined and cannot be changed. + +## Introducing * [Overview](overview) introduces the concepts and some of the essential terminology that's used when discussing synchronous commits. @@ -41,6 +45,8 @@ durability options, including how to refer to nodes in replication. * [Commit scopes](commit-scopes) is a more in-depth look at the structure of commit scopes and how to define them for your needs. +* [Predefined commit scopes](predefined-commit-scopes) lists the pre-defined commit scopes that are available in PGD Essential. + * [Origin groups](origin_groups) introduces the notion of an origin group, and how to leverage these when defining commit scopes rules. * [Commit scope rules](commit-scope-rules) looks at the syntax of and how to formulate diff --git a/product_docs/docs/pgd/6/reference/commit-scopes/predefined-commit-scopes.mdx b/product_docs/docs/pgd/6/reference/commit-scopes/predefined-commit-scopes.mdx new file mode 100644 index 00000000000..49698f963fe --- /dev/null +++ b/product_docs/docs/pgd/6/reference/commit-scopes/predefined-commit-scopes.mdx @@ -0,0 +1,58 @@ +--- +title: Predefined Commit Scopes +navTitle: Predefined +--- + + +## `local protect` + +```text +ASYNCHRONOUS COMMIT +``` + +The `local protect` commit scope is the default commit scope for PGD Essential. +It provides asynchronous commit with no durability guarantees. +This means that transactions are considered committed as soon as they are written to the local node's WAL, without waiting for any confirmation from other nodes in the cluster. + +This commit scope is suitable for scenarios where high availability and low latency are more important than data durability. +However, it does not provide any guarantees against data loss in case of node failures or network issues. + +## `lag protect` + +```text +MAJORITY ORIGIN GROUP LAG CONTROL (max_lag_time = 30s, max_commit_delay = 10s) +``` + +The `lag protect` commit scope provides a durability guarantee based on the lag time of the majority origin group. +It ensures that transactions are considered committed only when the lag time is within a specified limit (30 seconds in this case) and the commit delay is also within a specified limit (10 seconds in this case). +This helps to prevent data loss in case of network issues or node failures. + +This commit scope is useful in scenarios where data consistency and durability are important, but some latency is acceptable. +It allows for a balance between performance and data safety by ensuring that transactions are not considered committed until they have been confirmed by the majority of nodes in the origin group within the specified lag and commit delay limits. + +## `majority protect` + +```text +MAJORITY ORIGIN GROUP SYNCHRONOUS COMMIT +``` + +The `majority protect` commit scope provides a durability guarantee based on the majority origin group. +It ensures that transactions are considered committed only when they are confirmed by the majority of nodes in the origin group. +This helps to ensure data consistency and durability in case of node failures or network issues. + +This commit scope is suitable for scenarios where data consistency and durability are critical, and it provides a higher level of protection against data loss compared to the `local protect` commit scope. +However, it may introduce some latency due to the need for confirmation from multiple nodes before considering a transaction as committed. + +## `adaptive protect` + +```text +MAJORITY ORIGIN GROUP SYNCHRONOUS COMMIT DEGRADE ON (timeout = 10s, require_write_lead = true) TO ASYNCHRONOUS COMMIT +``` + +The `adaptive protect` commit scope provides a more flexible durability guarantee. +It allows transactions to be considered committed based on the majority origin group synchronous commit, but it can degrade to asynchronous commit if the transaction cannot be confirmed within a specified timeout (10 seconds in this case). +This is useful in scenarios where network latency or node failures may cause delays in confirming transactions. + +This commit scope is suitable for scenarios where data consistency and durability are important, but some flexibility is needed to handle potential delays. +It provides a balance between performance and data safety by allowing transactions to be considered committed even if they cannot be confirmed by the majority of nodes within the specified timeout, while still providing a higher level of protection compared to the `local protect` commit scope. + diff --git a/product_docs/docs/pgd/6/reference/monitoring/index.mdx b/product_docs/docs/pgd/6/reference/monitoring/index.mdx index b9240d7e0ff..f624cd71e12 100644 --- a/product_docs/docs/pgd/6/reference/monitoring/index.mdx +++ b/product_docs/docs/pgd/6/reference/monitoring/index.mdx @@ -6,20 +6,19 @@ description: Monitoring EDB Postgres Distributed through Postgres Enterprise Man Monitoring replication setups is important to ensure that your system: -- Performs optimally -- Doesn't run out of disk space -- Doesn't encounter other faults that might halt operations +- Performs optimally +- Doesn't run out of disk space +- Doesn't encounter other faults that might halt operations -It's important to have automated monitoring in place to ensure that the administrator is alerted and can -take proactive action when issues occur. For example, the administrator can be alerted if -replication slots start falling badly behind. +It's important to have automated monitoring in place to ensure that the +administrator is alerted and can take proactive action when issues occur. For +example, the administrator can be alerted if replication slots start falling +badly behind. -EDB provides Postgres Enterprise Manager (PEM), which supports PGD starting with version 8.1. See [Monitoring EDB Postgres Distributed](/pem/latest/monitoring_BDR_nodes/) for more information. +EDB provides Postgres Enterprise Manager (PEM), which supports PGD starting with +version 8.1. See [Monitoring EDB Postgres +Distributed](/pem/latest/monitoring_BDR_nodes/) for more information. Alternatively, tools or users can make their own calls into information views -and functions provided by the BDR extension. See [Monitoring through SQL](sql) for -details. - -EDB Postgres Distributed also integrates with OpenTelemetry, allowing you to -use an existing reporting setup to follow the state of the EDB Postgres Distributed -cluster. See [OpenTelemetry integration](otel) for details. +and functions provided by the BDR extension. See [Monitoring through SQL](sql) +for details. diff --git a/product_docs/docs/pgd/6/reference/monitoring/otel.mdx b/product_docs/docs/pgd/6/reference/monitoring/otel.mdx deleted file mode 100644 index 172090dff80..00000000000 --- a/product_docs/docs/pgd/6/reference/monitoring/otel.mdx +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: OpenTelemetry integration ---- - -You can configure EDB Postgres Distributed to report monitoring information -as well as traces to the [OpenTelemetry](https://opentelemetry.io/) collector. - -EDB Postgres Distributed OTEL collector fills several resource attributes. -These are attached to all metrics and traces: - - - The `service.name` is configurable with the `bdr.otel_service_name` configuration setting. - - The `service.namespace` is always set to `edb_postgres_distributed`. - - The `service.instance.id` is always set to the system identifier of the Postgres instance. - - The `service.version` is set to the current version of the BDR extension loaded in the Postgresql instance. - -## OTEL and OLTP compatibility - -For OTEL connections, the integration supports OLTP/HTTP version 1.0.0 only, -over HTTP or HTTPS. It doesn't support OLTP/gRPC. - -## Metrics collection - -Setting the configuration option -`bdr.metrics_otel_http_url` to a non-empty URL enables the metric collection. - -Different kinds of metrics are collected, as shown in the tables that follow. - -### Generic metrics - -| Metric name | Type | Labels | Description -| ----------- | ---- | ------ | ----------- -| pg_backends_by_state | gauge | conn_state - idle, active, idle in transaction, fastpath functioncall, idle in transaction (aborted), disabled, undefined | Number of backends in a given state -| pg_oldest_xact_start | gauge | | Oldest transaction start time -| pg_oldest_activity_start | gauge | | Oldest query start time -| pg_waiting_backends | gauge | wait_type - LWLock, Lock, BufferPin, Activity, Client, Extension, IPC, Timeout, IO, ??? (for unknown) | Number of currently waiting backends by wait type -| pg_start_time | gauge | | Timestamp at which the server has started -| pg_reload_time | gauge | | Timestamp at which the server has last reloaded configuration - - -### Replication metrics - -| Metric name | Type | Labels | Description -| ----------- | ---- | ------ | ----------- -| bdr_slot_sent_lag | gauge | slot_name - name of a slot | Current sent lag in bytes for each replication slot -| bdr_slot_write_lag | gauge | slot_name - name of a slot | Current write lag in bytes for each replication slot -| bdr_slot_flush_lag | gauge | slot_name - name of a slot | Current flush lag in bytes for each replication slot -| bdr_slot_apply_lag | gauge | slot_name - name of a slot | Current apply lag in bytes for each replication slot -| bdr_subscription_receive_lsn | gauge | sub_name - name of subscription | Current received LSN for each subscription -| bdr_subscription_flush_lsn | gauge | sub_name - name of subscription | Current flushed LSN for each subscription -| bdr_subscription_apply_lsn | gauge | sub_name - name of subscription | Current applied LSN for each subscription -| bdr_subscription_receiver | gauge | sub_name - name of subscription | Whether subscription receiver is currently running (1) or not (0) - -### Consensus metric - -See also [Monitoring Raft consensus](sql/#monitoring-raft-consensus) - -| Metric name | Type | Labels | Description -| ----------- | ---- | ------ | ----------- -| bdr_raft_state | gauge | state_str - RAFT_FOLLOWER, RAFT_CANDIDATE, RAFT_LEADER, RAFT_STOPPED | Raft state of the consensus on this node -| bdr_raft_protocol_version | gauge | | Consensus protocol version used by this node -| bdr_raft_leader_node | gauge | | Id of a node that this node considers to be current leader -| bdr_raft_nodes | gauge | | Total number of nodes that participate in consensus (includes learner/non-voting nodes) -| bdr_raft_voting_nodes | gauge | | Number of actual voting nodes in consensus -| bdr_raft_term | gauge | | Current raft term this node is on -| bdr_raft_commit_index | gauge | | Raft commit index committed by this node -| bdr_raft_apply_index | gauge | | Raft commit index applied by this node - -## Tracing - -Tracing collection to OpenTelemetry requires configuring `bdr.trace_otel_http_url` -and enabling tracing using `bdr.trace_enable`. - -The tracing is currently limited to only some subsystems, primarily to the -cluster management functionality. The following spans can be seen in traces. - -| Span name | Description | -| --------- | ----------- | -| create_node_group | Group creation -| alter_node_group_config | Change of group config options -| alter_node_config | Change of node config option -| join_node_group | Node joining a group -| join_send_remote_request | Join source sending the join request on behalf of the joining node -| add_camo_pair | Add CAMO pair -| alter_camo_pair | Change CAMO pair -| remove_camo_pair | Delete CAMO pair -| alter_commit_scope | Change commit scope definition (either create new or update existing) -| alter_proxy_config | Change config for PGD-Proxy instance (either create new or update existing) -| walmsg_global_lock_send | Send global locking WAL message -| walmsg_global_lock_recv | Received global locking WAL message -| ddl_epoch_apply | Global locking epoch apply (ensure cluster is synchronized enough for new epoch to start) -| walmsg_catchup | Catchup during node removal WAL message -| raft_send_appendentries | Internal Raft book keeping message -| raft_recv_appendentries | Internal Raft book keeping message -| raft_request | Raft request execution -| raft_query | Raft query execution -| msgb_send | Consensus messaging layer message -| msgb_recv_receive | Consensus messaging layer message -| msgb_recv_deliver | Consensus messaging layer message delivery -| preprocess_ddl | DDL command preprocessing - -## TLS support - -The metrics and tracing endpoints can be HTTP or HTTPS. You can -configure paths to the CA bundle, client key, and client certificate using -`bdr.otel_https_ca_path`, `bdr.otel_https_key_path`, and `bdr.otel_https_cert_path` -configuration options. From da4360995eb5705b1c73728352790d099ce1b3f6 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Wed, 7 May 2025 10:01:43 +0100 Subject: [PATCH 040/145] WIP Commit Signed-off-by: Dj Walker-Morgan --- .../6/essential-how-to/durability/index.mdx | 5 ++ .../install/03-configuring-cluster.mdx | 12 ++-- .../get-started/essential-near-far/index.mdx | 5 +- .../essential-one-location/index.mdx | 16 ------ .../get-started/essential-standard/index.mdx | 15 +++++ .../pgd/6/get-started/first-cluster/index.mdx | 13 +++++ .../reference/cli/command_ref/node/setup.mdx | 53 +++++++++++------- .../predefined-commit-scopes.mdx | 4 +- .../docs/pgd/6/reference/sequences.mdx | 56 +++++++------------ .../tables-views-functions/index.json | 1 + .../tables-views-functions/index.mdx | 1 + .../tables-views-functions/sequences.mdx | 24 ++++++++ 12 files changed, 125 insertions(+), 80 deletions(-) create mode 100644 product_docs/docs/pgd/6/essential-how-to/durability/index.mdx delete mode 100644 product_docs/docs/pgd/6/get-started/essential-one-location/index.mdx create mode 100644 product_docs/docs/pgd/6/get-started/essential-standard/index.mdx create mode 100644 product_docs/docs/pgd/6/get-started/first-cluster/index.mdx diff --git a/product_docs/docs/pgd/6/essential-how-to/durability/index.mdx b/product_docs/docs/pgd/6/essential-how-to/durability/index.mdx new file mode 100644 index 00000000000..d63a00aa6fa --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/durability/index.mdx @@ -0,0 +1,5 @@ +--- +title: Durability and PGD Essential +navTitle: Durability +--- + diff --git a/product_docs/docs/pgd/6/essential-how-to/install/03-configuring-cluster.mdx b/product_docs/docs/pgd/6/essential-how-to/install/03-configuring-cluster.mdx index 951863b34f9..a9e23738257 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/03-configuring-cluster.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/03-configuring-cluster.mdx @@ -128,23 +128,23 @@ We will now create a cluster called `pgd` with three nodes called `node1`, `node #### On the first host ```bash -sudo su - enterprisedb +sudo su - postgres export PATH=$PATH:/usr/edb/pge17/bin/ -pgd node node1 setup "host=host-1 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --group-name group1 --cluster-name pgd --create-group +pgd node node1 setup "host=host-1 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --group-name group1 --cluster-name pgd --create-group --initial-node-count 3 ``` #### On the second host ```bash -sudo su - enterprisedb +sudo su - postgres export PATH=$PATH:/usr/edb/pge17/bin/ -pgd node node2 setup "host=host-2 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --cluster-dsn "host=host-1 user=enterprisedb port=5432 dbname=bdrdb" +pgd node node2 setup "host=host-2 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --cluster-dsn "host=host-1 user=postgres port=5432 dbname=bdrdb" --initial-node-count 3 ``` #### On the third host ```bash -sudo su - enterprisedb +sudo su - postgres export PATH=$PATH:/usr/edb/pge17/bin/ -pgd node node3 setup "host=host-3 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --cluster-dsn "host=host-1 user=postgres port=5432 dbname=bdrdb" +pgd node node3 setup "host=host-3 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --cluster-dsn "host=host-1 user=postgres port=5432 dbname=bdrdb" --initial-node-count 3 ``` diff --git a/product_docs/docs/pgd/6/get-started/essential-near-far/index.mdx b/product_docs/docs/pgd/6/get-started/essential-near-far/index.mdx index ad39c736d0b..7ceaa173542 100644 --- a/product_docs/docs/pgd/6/get-started/essential-near-far/index.mdx +++ b/product_docs/docs/pgd/6/get-started/essential-near-far/index.mdx @@ -1,4 +1,5 @@ --- title: PGD Essential Near-Far -navTitle: PGD Near-Far ---- \ No newline at end of file +navTitle: Near-Far +--- + diff --git a/product_docs/docs/pgd/6/get-started/essential-one-location/index.mdx b/product_docs/docs/pgd/6/get-started/essential-one-location/index.mdx deleted file mode 100644 index 1b782d63db9..00000000000 --- a/product_docs/docs/pgd/6/get-started/essential-one-location/index.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: PGD Essential in one Location -navTitle: PGD in one Location ---- - -## About the one-location architecture - -The one-location architecture is ideal for a highly available single location. It is the simplest architecture to set up and manage. It is also the most cost-effective architecture for a single location. - -You can create a one-location architecture with PGD Essential or PGD Expanded. - -## One-location architecture - -The one-location architecture consists of a single PGD cluster with three nodes. The nodes are located in the same data center or availability zone. The nodes are connected to each other using a high-speed network. - -The nodes are configured in a replication group. The replication group is responsible for replicating data between the nodes. The replication group is also responsible for ensuring that the data is consistent across the nodes. diff --git a/product_docs/docs/pgd/6/get-started/essential-standard/index.mdx b/product_docs/docs/pgd/6/get-started/essential-standard/index.mdx new file mode 100644 index 00000000000..92b62e23c91 --- /dev/null +++ b/product_docs/docs/pgd/6/get-started/essential-standard/index.mdx @@ -0,0 +1,15 @@ +--- +title: PGD Essential Standard/One-location Architecture +navTitle: Standard Architecture +--- + +The standard architecture is the basic building block for EDB Postgres Distributed. It is most commonly used on a single location where the nodes are in the same data center, and it is also called the one-location architecture. + +## Standard/One-location architecture + +The one-location architecture consists of a single PGD cluster with three nodes. The nodes are located in the same data center or availability zone. The nodes are connected to each other using a high-speed network. + +The nodes are configured as a data sub-group which means that they replicate data to each other within the same group. In PGD Essential, the group also uses the same write leader node, one node selected by the nodes in the group. The write leader node is responsible for accepting write transactions and replicating them to the other nodes in the group. If the write leade node fails, the other nodes in the group will elect a new write leader node. + +Applications can connect to any node in the cluster using PGD's connection manager which runs on every data node. It will automatically route read and write transactions to the write leader. It can also route read only transactions to the other nodes in the group. + diff --git a/product_docs/docs/pgd/6/get-started/first-cluster/index.mdx b/product_docs/docs/pgd/6/get-started/first-cluster/index.mdx new file mode 100644 index 00000000000..8894b9bc0e4 --- /dev/null +++ b/product_docs/docs/pgd/6/get-started/first-cluster/index.mdx @@ -0,0 +1,13 @@ +--- +title: Creating your first cluster (PGD Essential) +navTitle: First Cluster +description: "Creating your first cluster with EDB Postgres Distributed Essential." +--- + +This part of the Getting Started guide will help you create a local cluster using Docker Compose. This is a great way to get familiar with the EDB Postgres Distributed (PGD) Essential features and functionality. + +## Prerequisites + +- Docker and Docker Compose installed on your local machine. + +## \ No newline at end of file diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx index d176c3533a6..8902c65ae4f 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx @@ -1,6 +1,6 @@ --- title: pgd node setup -navTitle: setup +navTitle: Setup deepToC: true --- @@ -21,7 +21,7 @@ If the local node is up and running and remote node dsn is not provided, `pgd no ## Syntax ```plaintext -pgd node setup [OPTIONS] --pgdata ``` +pgd node setup [OPTIONS] -D ``` ## Arguments @@ -33,35 +33,50 @@ This is a mandatory argument and should be in the format `host=localhost port=54 ## Options -| Option | Description | -|------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------| -| -D, --pgdata | Data directory of the node. | -| --dbname | DB name. Default is bdrdb. | -| --node-kind | Node kind. Default is data. Applicable for first node only. [possible values: data, witness, subscriber-only] | -| --group-name | Node group name. If not provided, the node will be added to the group of the active node. It becomes a mandatory argument for the first node. | -| --create-group | Set this to create the given group if not already present. This will be true by default for the first node. | -| --cluster-name | Name of the cluster to join the node to. This is a mandatory argument and is used as global group name for the first node of the cluster. | -| --cluster-dsn | A DSN to connect to active PGD cluster. | -| --postgresql-conf | Path of the postgresql.conf file to be used for the node. | -| --postgresql-auto-conf | Path of the postgresql.auto.conf file to be used for the node. | -| --hba-conf | Path of the pg_hba.conf file to be used for the node. | -| --debug | Print debug messages, useful while troubleshooting. | -| -f, --config-file | Sets the configuration file path. | +| Option                                              | Description | +|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------| +| -D, --pgdata | Uses as the data directory of the node. (Also set with environment variable `PGDATA`) | +| --listen-address | Sets listen address the new node should listen to (defaults to `localhost`) | +| --initial-node-count | Number of nodes in the cluster (or planned to be in the cluster). Used to calculate various resource settings for the node. Default is 3. | +| --bindir | Specifies the directory where the binaries are located. Defaults to the directory where the running pgd binary is located. | +| --superuser | The superuser to use for the connection. | +| --node-kind | Specifies the kind of node to be created. Applies to first node only. Default is `data`.Possible values are `data`, `witness`, `subscriber-only`. | +| --group-name | Node group name. If not provided, the node will be added to the group of the active node. It is a mandatory argument for the first node of a group. | +| --create-group | Set this flag to create the given group, if it is not already present. This will be true by default for the first node. | +| --cluster-name | Name of the cluster to join the node to. Defaults to `pgd` | +| --cluster-dsn | A DSN which belongs to the active PGD cluster. When configuring the first node of a cluster, should point to the DSN for the first node. | +| --postgresql-conf | Optional path of the postgresql.conf file to be used for the node. | +| --postgresql-auto-conf     | Optional path of the postgresql.auto.conf file to be used for the node. | +| --hba-conf | Optional path of the pg_hba.conf file to be used for the node. | +| --update-pgpass | If set, the pgpass file for the new nodes password will be stored in the current user's `.pgpass` file. | +| --debug | Print debug messages, useful while troubleshooting. | +| --verbose | Print verbose messages. | +| --log-file | Log file to write the log messages to. Records log messages for any external commands executed. Default is to write a file in the current directory named `postgres-.log` where the port value | See also [Global Options](/pgd/latest/cli/command_ref/#global-options). ## Examples In these examples, we will set up a cluster with on three hosts, `host-1`, `host-2` and `host-3`, to create three nodes: `node-one`, `node-two`, and `node-three`. -The three nodes will be data nodes, and part a cluster named `dc1-cluster` with the group name `dc1`. +The three nodes will be data nodes, and part of a cluster named `dc1-cluster` with the group name `dc1`. ### Configuring the first node ```shell -pgd node node-one setup --pgdata /var/lib/edb-pge/17/main --group-name dc1 --cluster-name dc1-cluster --cluster-dsn "host=localhost port=5444 user=postgres dbname=bdrdb" --create-group +pgd node node-one setup +--group-name dc1 --cluster-name dc1-cluster --create-group \ +--cluster-dsn "host=localhost port=5432 user=postgres dbname=bdrdb" \ +--pgdata /var/lib/edb-pge/17/main ``` -This command will create the first node named `node-one` in the cluster `dc1-cluster` with the group name `dc1`. The data directory for the node is set to `/var/lib/edb-pge/17/main`. +Stepping through the command, we are setting up "node-one". This is the first node in the cluster, so we set the group name to `dc1` and the cluster name to `dc1-cluster`. The `--create-group` option indicates that this is the first node in the group, so it will create the group as well. + +We also need to provide the `--cluster-dsn` option, which is the connection string for the first node. This is typically set to `host=localhost port=5432 user=postgres dbname=bdrdb`, which is a typical connection string for a local Postgres instance. + +Finally, we set the data directory for the node with the `--pgdata` option; this is where the Postgres data files will be stored. In this example, we are using `/var/lib/edb-pge/17/main` as the data directory. + +The command will create the data directory and initialize the database correctly for PGD. It will then start the node and make it available for new connections, including the other nodes joining the cluster. + ### Configuring the second node diff --git a/product_docs/docs/pgd/6/reference/commit-scopes/predefined-commit-scopes.mdx b/product_docs/docs/pgd/6/reference/commit-scopes/predefined-commit-scopes.mdx index 49698f963fe..77c625fd041 100644 --- a/product_docs/docs/pgd/6/reference/commit-scopes/predefined-commit-scopes.mdx +++ b/product_docs/docs/pgd/6/reference/commit-scopes/predefined-commit-scopes.mdx @@ -3,6 +3,9 @@ title: Predefined Commit Scopes navTitle: Predefined --- +Both PGD Essential and PGD Expanded provide a set of predefined commit scopes that are available for use. + +The difference between the two editions is that PGD Essential has a limited set of predefined commit scopes that cannot be changed, while PGD Expanded allows for fully manageable and configurable commit scopes. The predefined commit scopes in PGD Essential are designed to provide a balance between performance and data safety, while the configurable commit scopes in PGD Expanded offer more flexibility and control over the durability guarantees. ## `local protect` @@ -55,4 +58,3 @@ This is useful in scenarios where network latency or node failures may cause del This commit scope is suitable for scenarios where data consistency and durability are important, but some flexibility is needed to handle potential delays. It provides a balance between performance and data safety by allowing transactions to be considered committed even if they cannot be confirmed by the majority of nodes within the specified timeout, while still providing a higher level of protection compared to the `local protect` commit scope. - diff --git a/product_docs/docs/pgd/6/reference/sequences.mdx b/product_docs/docs/pgd/6/reference/sequences.mdx index 2687424fa30..cf923587616 100644 --- a/product_docs/docs/pgd/6/reference/sequences.mdx +++ b/product_docs/docs/pgd/6/reference/sequences.mdx @@ -61,12 +61,12 @@ Globally allocated sequences allocate a local range of values that can be replenished as needed by inter-node consensus, making them suitable for either BIGINT or INTEGER sequences. -You can create a global sequence using the [`bdr.alter_sequence_set_kind()`](/pgd/latest/reference/tables-views-functions/sequences/#bdralter_sequence_set_kind) +You can create a global sequence using the [`bdr.alter_sequence_set_kind()`](tables-views-functions/sequences/#bdralter_sequence_set_kind) function. This function takes a standard PostgreSQL sequence and marks it as a PGD global sequence. It can also convert the sequence back to the standard PostgreSQL sequence. -PGD also provides the configuration variable [`bdr.default_sequence_kind`](/pgd/latest/reference/tables-views-functions/pgd-settings/#bdrdefault_sequence_kind). This variable +PGD also provides the configuration variable [`bdr.default_sequence_kind`](/pgd/latest/reference/pgd-settings/#bdrdefault_sequence_kind). This variable determines the kind of sequence to create when the `CREATE SEQUENCE` command is executed or when a `serial`, `bigserial`, or `GENERATED BY DEFAULT AS IDENTITY` column is created. Valid settings are: @@ -80,11 +80,11 @@ command is executed or when a `serial`, `bigserial`, or - `timeshard` — The older version of SnowflakeId sequence. Provided for backward compatibility only. The SnowflakeId is preferred. - `distributed` (default) — A special value that you can use only for - [`bdr.default_sequence_kind`](/pgd/latest/reference/tables-views-functions/pgd-settings/#global-sequence-parameters). It selects `snowflakeid` for `int8` + [`bdr.default_sequence_kind`](reference/pgd-settings/#global-sequence-parameters). It selects `snowflakeid` for `int8` sequences (that is, `bigserial`) and `galloc` sequence for `int4` (that is, `serial`) and `int2` sequences. -The [`bdr.sequences`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrsequences) view shows information about individual sequence kinds. +The [`bdr.sequences`](/pgd/latest/reference/catalogs-visible/#bdrsequences) view shows information about individual sequence kinds. `currval()` and `lastval()` work correctly for all types of global sequence. @@ -220,7 +220,7 @@ to or more than the above ranges assigned for each sequence datatype. `setval()` doesn't reset the global state for `galloc` sequences. Don't use it. A few limitations apply to `galloc` sequences. PGD tracks `galloc` sequences in a -special PGD catalog [bdr.sequence_alloc](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrsequence_alloc). This +special PGD catalog [bdr.sequence_alloc](/pgd/latest/reference/catalogs-visible/#bdrsequence_alloc). This catalog is required to track the currently allocated chunks for the `galloc` sequences. The sequence name and namespace is stored in this catalog. The sequence chunk allocation is managed by Raft, whereas any changes to the @@ -296,7 +296,7 @@ When the sequence kind is altered to `galloc`, it's rewritten and restarts from the defined start value of the local sequence. If this happens on an existing sequence in a production database, you need to query the current value and then set the start value appropriately. To help with this use case, PGD -lets you pass a starting value with the function [`bdr.alter_sequence_set_kind()`](/pgd/latest/reference/tables-views-functions/sequences/#bdralter_sequence_set_kind). +lets you pass a starting value with the function [`bdr.alter_sequence_set_kind()`](tables-views-functions/sequences/#bdralter_sequence_set_kind). If you're already using offset and you have writes from multiple nodes, you need to check what's the greatest used value and restart the sequence to at least the next value: @@ -316,7 +316,7 @@ SELECT bdr.alter_sequence_set_kind('public.sequence'::regclass, 'galloc', $MAX + Since users can't lock a sequence, you must leave a `$MARGIN` value to allow operations to continue while the `max()` value is queried. -The [`bdr.sequence_alloc`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrsequence_alloc) table gives information on the chunk size and the +The [`bdr.sequence_alloc`](reference/catalogs-visible/#bdrsequence_alloc) table gives information on the chunk size and the ranges allocated around the whole cluster. In this example, the sequence starts at `333`, and the cluster has two nodes. @@ -332,48 +332,32 @@ SELECT * FROM bdr.sequence_alloc (1 row) ``` -To see the ranges currently assigned to a given sequence on each node, use -these queries: + +To see the ranges currently assigned to a given sequence on each node, execute the function +[`bdr.galloc_chunk_info`](tables-views-functions/sequences/#bdrgalloc_chunk_info). * Node `Node1` is using range from `333` to `2000333`. ```sql -SELECT last_value AS range_start, log_cnt AS range_end - FROM categories_category_seq WHERE ctid = '(0,2)'; -- first range - range_start | range_end +SELECT * FROM bdr.galloc_chunk_info('categories_category_seq'); + chunk_start | chunk_end -------------+----------- 334 | 1000333 -(1 row) - -SELECT last_value AS range_start, log_cnt AS range_end - FROM categories_category_seq WHERE ctid = '(0,3)'; -- second range - range_start | range_end --------------+----------- 1000334 | 2000333 -(1 row) +(2 rows) ``` * Node `Node2` is using range from `2000334` to `4000333`. ```sql -SELECT last_value AS range_start, log_cnt AS range_end - FROM categories_category_seq WHERE ctid = '(0,2)'; -- first range - range_start | range_end --------------+----------- - 2000334 | 3000333 -(1 row) -SELECT last_value AS range_start, log_cnt AS range_end - FROM categories_category_seq WHERE ctid = '(0,3)'; -- second range - range_start | range_end +SELECT * FROM bdr.galloc_chunk_info('categories_category_seq'); + chunk_start | chunk_end -------------+----------- + 2000334 | 3000333 3000334 | 4000333 ``` -!!! NOTE - You can't combine it to a single query (like `WHERE ctid IN ('(0,2)', '(0,3)')`), - as that still shows only the first range. - When a node finishes a chunk, it asks a consensus for a new one and gets the first available. In the example, it's from 4000334 to 5000333. This is the new reserved chunk and starts to consume the old reserved chunk. @@ -464,7 +448,7 @@ The internal contents of v1 and v2 aren't compatible. As such, the functions to manipulate them also aren't compatible. The v2 of `KSUUID` also no longer stores the `UUID` version number. -See [KSUUID v2 functions](/pgd/latest/reference/tables-views-functions/sequences/#ksuuid-v2-functions) and [KSUUID v1 functions](/pgd/latest/reference/tables-views-functions/sequences/#ksuuid-v1-functions) in the PGD reference. +See [KSUUID v2 functions](tables-views-functions/sequences/#ksuuid-v2-functions) and [KSUUID v1 functions](tables-views-functions/sequences/#ksuuid-v1-functions) in the PGD reference. ### Step and offset sequences @@ -526,6 +510,6 @@ a one-row table that isn't part of a replication set to store a different value in each node. ## See also -* [Global Sequence management interfaces](/pgd/latest/reference/tables-views-functions/sequences/) -* [KSUUID v2 functions](/pgd/latest/reference/tables-views-functions/sequences/#ksuuid-v2-functions) -* [KSUUID v1 functions](/pgd/latest/reference/tables-views-functions/sequences/#ksuuid-v1-functions) +* [Global Sequence management interfaces](tables-views-functions/sequences/) +* [KSUUID v2 functions](tables-views-functions/sequences/#ksuuid-v2-functions) +* [KSUUID v1 functions](tables-views-functions/sequences/#ksuuid-v1-functions) diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/index.json b/product_docs/docs/pgd/6/reference/tables-views-functions/index.json index 38e37103ca3..9ffb6a073a1 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/index.json +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/index.json @@ -267,6 +267,7 @@ "bdrextract_nodeid_from_timeshard": "/pgd/6/reference/tables-views-functions/sequences#bdrextract_nodeid_from_timeshard", "bdrextract_localseqid_from_timeshard": "/pgd/6/reference/tables-views-functions/sequences#bdrextract_localseqid_from_timeshard", "bdrtimestamp_to_timeshard": "/pgd/6/reference/tables-views-functions/sequences#bdrtimestamp_to_timeshard", + "bdrgalloc_chunk_info": "/pgd/6/reference/tables-views-functions/sequences#bdrgalloc_chunk_info", "bdrgen_ksuuid_v2": "/pgd/6/reference/tables-views-functions/sequences#bdrgen_ksuuid_v2", "bdrksuuid_v2_cmp": "/pgd/6/reference/tables-views-functions/sequences#bdrksuuid_v2_cmp", "bdrextract_timestamp_from_ksuuid_v2": "/pgd/6/reference/tables-views-functions/sequences#bdrextract_timestamp_from_ksuuid_v2", diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx index 4267094f2c6..f72bf71ce09 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx @@ -375,6 +375,7 @@ The reference section is a definitive listing of all functions, views, and comma * [`bdr.extract_nodeid_from_timeshard`](sequences#bdrextract_nodeid_from_timeshard) * [`bdr.extract_localseqid_from_timeshard`](sequences#bdrextract_localseqid_from_timeshard) * [`bdr.timestamp_to_timeshard`](sequences#bdrtimestamp_to_timeshard) + * [`bdr.galloc_chunk_info`](sequences#bdrgalloc_chunk_info) ### [KSUUID v2 functions](sequences#ksuuid-v2-functions) * [`bdr.gen_ksuuid_v2`](sequences#bdrgen_ksuuid_v2) * [`bdr.ksuuid_v2_cmp`](sequences#bdrksuuid_v2_cmp) diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/sequences.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/sequences.mdx index 7755189c680..6278d051bd3 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/sequences.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/sequences.mdx @@ -224,6 +224,30 @@ bdr.timestamp_to_timeshard(ts timestamptz) This function executes only on the local node. +### `bdr.galloc_chunk_info` + +This function retrieves the ranges allocated to a galloc sequence on the local +node. + +An empty result set will be returned if the sequence has not yet been accessed +on the local node. + +An ERROR will be raised if the provided sequence name is not a galloc sequence. + +#### Synopsis + +```sql +bdr.galloc_chunk_info(seqname regclass) +``` + +#### Parameters + +- `seqname` - the name of the galloc sequence to query + +#### Notes + +This function executes only on the local node. + ## KSUUID v2 functions Functions for working with `KSUUID` v2 data, K-Sortable UUID data. See also [KSUUID in the sequences documentation](../sequences/#ksuuids). From 553f5d069a0c9c76d1e4f73a6bb0a3c675584a43 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Wed, 7 May 2025 11:41:04 +0100 Subject: [PATCH 041/145] Link fix test Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/concepts/index.mdx | 14 ++ .../pgd/6/essential-how-to/autopartition.mdx | 191 ------------------ product_docs/docs/pgd/6/index.mdx | 5 - .../docs/pgd/6/reference/autopartition.mdx | 191 ++++++++++++++++++ product_docs/docs/pgd/6/reference/index.mdx | 1 + 5 files changed, 206 insertions(+), 196 deletions(-) create mode 100644 product_docs/docs/pgd/6/reference/autopartition.mdx diff --git a/product_docs/docs/pgd/6/concepts/index.mdx b/product_docs/docs/pgd/6/concepts/index.mdx index 4d8aabc785f..184da4f9944 100644 --- a/product_docs/docs/pgd/6/concepts/index.mdx +++ b/product_docs/docs/pgd/6/concepts/index.mdx @@ -4,3 +4,17 @@ navTitle: PGD Explained navigation: --- +## PGD Essential concepts + +* Replication in PGD +* Logical replication +* Data nodes and data node groups +* Locking +* Durability +* Lag Control + +## PGD Expanded concepts + +* Commit scopes +* Geo-distributed clusters + diff --git a/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx b/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx index 5e4dd94928a..e69de29bb2d 100644 --- a/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx @@ -1,191 +0,0 @@ ---- -title: AutoPartition in PGD -navTitle: AutoPartition -description: How to use autopartitioning in PGD to split tables into several partitions. ---- - -PGD AutoPartition allows you to split tables into several partitions. It lets -tables grow easily to large sizes using automatic partitioning management. This -capability uses features of PGD, such as low-conflict locking of creating and -dropping partitions. - -You can create new partitions regularly and then drop them when the -data retention period expires. - -You perform PGD management primarily by using functions that can be called by SQL. -All functions in PGD are exposed in the `bdr` schema. Unless you put it into -your search_path, you need to schema qualify the name of each function. - -## Auto creation of partitions - -PGD AutoPartition uses the [`bdr.autopartition()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition) -function to create or alter the definition of automatic range partitioning for a table. If -no definition exists, it's created. Otherwise, later executions will alter the -definition. - -PGD AutoPartition in PGD 5.5 and later leverages underlying Postgres features that allow a -partition to be attached or detached/dropped without locking the rest of the -table. Versions of PGD earlier than 5.5 don't support this feature and lock the tables. - -An error is raised if the table isn't RANGE partitioned or a multi-column -partition key is used. - -By default, AutoPartition manages partitions locally. Managing partitions -locally is useful when the partitioned table isn't a replicated table. In that -case, you might not need or want to have all partitions on all nodes. For -example, the built-in [`bdr.conflict_history`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrconflict_history) -table isn't a replicated table. It's managed by AutoPartition locally. Each node -creates partitions for this table locally and drops them once they're old -enough. - -Also consider: - -- Activities are performed only when the entry is marked `enabled = on`. - -- We recommend that you don't manually create or drop partitions for tables -managed by AutoPartition. Doing so can make the AutoPartition metadata -inconsistent and might cause it to fail. - -## AutoPartition examples - -Daily partitions, keep data for one month: - -```sql -CREATE TABLE measurement ( -logdate date not null, -peaktemp int, -unitsales int -) PARTITION BY RANGE (logdate); - -bdr.autopartition('measurement', '1 day', data_retention_period := '30 days'); -``` - -Create five advance partitions when there are only two more partitions -remaining. Each partition can hold 1 billion orders. - -```sql -bdr.autopartition('Orders', '1000000000', - partition_initial_lowerbound := '0', - minimum_advance_partitions := 2, - maximum_advance_partitions := 5 - ); -``` - - -## RANGE-partitioned tables - -A new partition is added for every `partition_increment` range of values. -Lower and upper bound are `partition_increment` apart. For tables with a partition -key of type `timestamp` or `date`, the `partition_increment` must be a valid -constant of type `interval`. For example, specifying `1 Day` causes a new -partition to be added each day, with partition bounds that are one day apart. - -If the partition column is connected to a `snowflakeid`, `timeshard`, or -`ksuuid` sequence, you must specify the `partition_increment` as type -`interval`. Otherwise, if the partition key is integer or numeric, then the -`partition_increment` must be a valid constant of the same datatype. For -example, specifying `1000000` causes new partitions to be added every 1 million -values. - -If the table has no existing partition, then the specified -`partition_initial_lowerbound` is used as the lower bound for the first -partition. If you don't specify `partition_initial_lowerbound`, then the system -tries to derive its value from the partition column type and the specified -`partition_increment`. For example, if `partition_increment` is specified as `1 -Day`, then `partition_initial_lowerbound` is set to CURRENT DATE. If -`partition_increment` is specified as `1 Hour`, then -`partition_initial_lowerbound` is set to the current hour of the current date. -The bounds for the subsequent partitions are set using the `partition_increment` -value. - -The system always tries to have a certain minimum number of advance partitions. -To decide whether to create new partitions, it uses the specified -`partition_autocreate_expression`. This can be an expression that can be -evaluated by SQL that's evaluated every time a check is performed. For -example, for a partitioned table on column type `date`, suppose -`partition_autocreate_expression` is specified as -`DATE_TRUNC('day',CURRENT_DATE)`, `partition_increment` is specified as `1 Day`, -and `minimum_advance_partitions` is specified as `2`. New partitions are then -created until the upper bound of the last partition is less than -`DATE_TRUNC('day', CURRENT_DATE) + '2 Days'::interval`. - -The expression is evaluated each time the system checks for new partitions. - -For a partitioned table on column type `integer`, you can specify the -`partition_autocreate_expression` as `SELECT max(partcol) FROM -schema.partitioned_table`. The system then regularly checks if the maximum value -of the partitioned column is within the distance of `minimum_advance_partitions * partition_increment` -of the last partition's upper bound. Create an index on -the `partcol` so that the query runs efficiently. If you don't specify the -`partition_autocreate_expression` for a partition table on column type -`integer`, `smallint`, or `bigint`, then the system sets it to `max(partcol)`. - -If the `data_retention_period` is set, partitions are dropped after this period. -To minimize locking, partitions are dropped at the same time as new partitions are added. -If you don't set this value, you must drop the partitions manually. - -The `data_retention_period` parameter is supported only for timestamp-based (and -related) partitions. The period is calculated by considering the upper -bound of the partition. The partition is dropped if the given period expires, relative to the -upper bound. - -## Stopping automatic creation of partitions - -Use -[`bdr.drop_autopartition()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrdrop_autopartition) -to drop the autopartitioning rule for the given relation. All pending work items -for the relation are deleted, and no new work items are created. - -## Waiting for partition creation - -Partition creation is an asynchronous process. AutoPartition provides a set of -functions to wait for the partition to be created, locally or on all nodes. - -Use -[`bdr.autopartition_wait_for_partitions()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_wait_for_partitions) -to wait for the creation of partitions on the local node. The function takes the -partitioned table name and a partition key column value and waits until the -partition that holds that value is created. - -The function waits only for the partitions to be created locally. It doesn't -guarantee that the partitions also exist on the remote nodes. - -To wait for the partition to be created on all PGD nodes, use the -[`bdr.autopartition_wait_for_partitions_on_all_nodes()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_wait_for_partitions_on_all_nodes) -function. This function internally checks local as well as all remote nodes and -waits until the partition is created everywhere. - -## Finding a partition - -Use the -[`bdr.autopartition_find_partition()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_find_partition) -function to find the partition for the given partition key value. If a partition -to hold that value doesn't exist, then the function returns NULL. Otherwise it returns the Oid -of the partition. - -## Enabling or disabling autopartitioning - -Use -[`bdr.autopartition_enable()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_enable) -to enable autopartitioning on the given table. If autopartitioning is already -enabled, then no action occurs. Similarly, use -[`bdr.autopartition_disable()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_disable) -to disable autopartitioning on the given table. - -## Restrictions on EDB Postgres Advanced Server-native automatic partitioning - -EDB Postgres Advanced Server-native automatic partitioning is not supported in PGD. - -If the PGD extension is active on an EDB Postgres Advanced Server database, DDL commands to configure -EDB Postgres Advanced Server automatic partitioning (`ALTER TABLE ... SET AUTOMATIC` and `ALTER TABLE ... SET INTERVAL`) -are rejected. - -While it's possible to enable the PGD extension on an EDB Postgres Advanced Server database -containing tables configured to use EDB Postgres Advanced Server-native automatic partitioning, it -isn't possible to join more nodes using this node as a source node. - -You can disable EDB Postgres Advanced Server-native automatic partitioning with one of the following -commands: - -- `ALTER TABLE ... SET MANUAL` (for list partitioned tables) -- `ALTER TABLE ... SET INTERVAL ()` (for interval partitioned tables) diff --git a/product_docs/docs/pgd/6/index.mdx b/product_docs/docs/pgd/6/index.mdx index 926f43c1a0a..70aa669c29b 100644 --- a/product_docs/docs/pgd/6/index.mdx +++ b/product_docs/docs/pgd/6/index.mdx @@ -6,15 +6,10 @@ indexCards: full redirects: - /edb-postgres-ai/migration-etl/pgd/ navigation: - - "#Get Started" - get-started - - "#Essential PGD" - essential-how-to - - "#Expanded PGD" - expanded-how-to - - "#Concepts" - concepts - - "#Reference" - reference - "#Appendix" - terminology diff --git a/product_docs/docs/pgd/6/reference/autopartition.mdx b/product_docs/docs/pgd/6/reference/autopartition.mdx new file mode 100644 index 00000000000..5e4dd94928a --- /dev/null +++ b/product_docs/docs/pgd/6/reference/autopartition.mdx @@ -0,0 +1,191 @@ +--- +title: AutoPartition in PGD +navTitle: AutoPartition +description: How to use autopartitioning in PGD to split tables into several partitions. +--- + +PGD AutoPartition allows you to split tables into several partitions. It lets +tables grow easily to large sizes using automatic partitioning management. This +capability uses features of PGD, such as low-conflict locking of creating and +dropping partitions. + +You can create new partitions regularly and then drop them when the +data retention period expires. + +You perform PGD management primarily by using functions that can be called by SQL. +All functions in PGD are exposed in the `bdr` schema. Unless you put it into +your search_path, you need to schema qualify the name of each function. + +## Auto creation of partitions + +PGD AutoPartition uses the [`bdr.autopartition()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition) +function to create or alter the definition of automatic range partitioning for a table. If +no definition exists, it's created. Otherwise, later executions will alter the +definition. + +PGD AutoPartition in PGD 5.5 and later leverages underlying Postgres features that allow a +partition to be attached or detached/dropped without locking the rest of the +table. Versions of PGD earlier than 5.5 don't support this feature and lock the tables. + +An error is raised if the table isn't RANGE partitioned or a multi-column +partition key is used. + +By default, AutoPartition manages partitions locally. Managing partitions +locally is useful when the partitioned table isn't a replicated table. In that +case, you might not need or want to have all partitions on all nodes. For +example, the built-in [`bdr.conflict_history`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrconflict_history) +table isn't a replicated table. It's managed by AutoPartition locally. Each node +creates partitions for this table locally and drops them once they're old +enough. + +Also consider: + +- Activities are performed only when the entry is marked `enabled = on`. + +- We recommend that you don't manually create or drop partitions for tables +managed by AutoPartition. Doing so can make the AutoPartition metadata +inconsistent and might cause it to fail. + +## AutoPartition examples + +Daily partitions, keep data for one month: + +```sql +CREATE TABLE measurement ( +logdate date not null, +peaktemp int, +unitsales int +) PARTITION BY RANGE (logdate); + +bdr.autopartition('measurement', '1 day', data_retention_period := '30 days'); +``` + +Create five advance partitions when there are only two more partitions +remaining. Each partition can hold 1 billion orders. + +```sql +bdr.autopartition('Orders', '1000000000', + partition_initial_lowerbound := '0', + minimum_advance_partitions := 2, + maximum_advance_partitions := 5 + ); +``` + + +## RANGE-partitioned tables + +A new partition is added for every `partition_increment` range of values. +Lower and upper bound are `partition_increment` apart. For tables with a partition +key of type `timestamp` or `date`, the `partition_increment` must be a valid +constant of type `interval`. For example, specifying `1 Day` causes a new +partition to be added each day, with partition bounds that are one day apart. + +If the partition column is connected to a `snowflakeid`, `timeshard`, or +`ksuuid` sequence, you must specify the `partition_increment` as type +`interval`. Otherwise, if the partition key is integer or numeric, then the +`partition_increment` must be a valid constant of the same datatype. For +example, specifying `1000000` causes new partitions to be added every 1 million +values. + +If the table has no existing partition, then the specified +`partition_initial_lowerbound` is used as the lower bound for the first +partition. If you don't specify `partition_initial_lowerbound`, then the system +tries to derive its value from the partition column type and the specified +`partition_increment`. For example, if `partition_increment` is specified as `1 +Day`, then `partition_initial_lowerbound` is set to CURRENT DATE. If +`partition_increment` is specified as `1 Hour`, then +`partition_initial_lowerbound` is set to the current hour of the current date. +The bounds for the subsequent partitions are set using the `partition_increment` +value. + +The system always tries to have a certain minimum number of advance partitions. +To decide whether to create new partitions, it uses the specified +`partition_autocreate_expression`. This can be an expression that can be +evaluated by SQL that's evaluated every time a check is performed. For +example, for a partitioned table on column type `date`, suppose +`partition_autocreate_expression` is specified as +`DATE_TRUNC('day',CURRENT_DATE)`, `partition_increment` is specified as `1 Day`, +and `minimum_advance_partitions` is specified as `2`. New partitions are then +created until the upper bound of the last partition is less than +`DATE_TRUNC('day', CURRENT_DATE) + '2 Days'::interval`. + +The expression is evaluated each time the system checks for new partitions. + +For a partitioned table on column type `integer`, you can specify the +`partition_autocreate_expression` as `SELECT max(partcol) FROM +schema.partitioned_table`. The system then regularly checks if the maximum value +of the partitioned column is within the distance of `minimum_advance_partitions * partition_increment` +of the last partition's upper bound. Create an index on +the `partcol` so that the query runs efficiently. If you don't specify the +`partition_autocreate_expression` for a partition table on column type +`integer`, `smallint`, or `bigint`, then the system sets it to `max(partcol)`. + +If the `data_retention_period` is set, partitions are dropped after this period. +To minimize locking, partitions are dropped at the same time as new partitions are added. +If you don't set this value, you must drop the partitions manually. + +The `data_retention_period` parameter is supported only for timestamp-based (and +related) partitions. The period is calculated by considering the upper +bound of the partition. The partition is dropped if the given period expires, relative to the +upper bound. + +## Stopping automatic creation of partitions + +Use +[`bdr.drop_autopartition()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrdrop_autopartition) +to drop the autopartitioning rule for the given relation. All pending work items +for the relation are deleted, and no new work items are created. + +## Waiting for partition creation + +Partition creation is an asynchronous process. AutoPartition provides a set of +functions to wait for the partition to be created, locally or on all nodes. + +Use +[`bdr.autopartition_wait_for_partitions()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_wait_for_partitions) +to wait for the creation of partitions on the local node. The function takes the +partitioned table name and a partition key column value and waits until the +partition that holds that value is created. + +The function waits only for the partitions to be created locally. It doesn't +guarantee that the partitions also exist on the remote nodes. + +To wait for the partition to be created on all PGD nodes, use the +[`bdr.autopartition_wait_for_partitions_on_all_nodes()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_wait_for_partitions_on_all_nodes) +function. This function internally checks local as well as all remote nodes and +waits until the partition is created everywhere. + +## Finding a partition + +Use the +[`bdr.autopartition_find_partition()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_find_partition) +function to find the partition for the given partition key value. If a partition +to hold that value doesn't exist, then the function returns NULL. Otherwise it returns the Oid +of the partition. + +## Enabling or disabling autopartitioning + +Use +[`bdr.autopartition_enable()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_enable) +to enable autopartitioning on the given table. If autopartitioning is already +enabled, then no action occurs. Similarly, use +[`bdr.autopartition_disable()`](/pgd/latest/reference/tables-views-functions/autopartition#bdrautopartition_disable) +to disable autopartitioning on the given table. + +## Restrictions on EDB Postgres Advanced Server-native automatic partitioning + +EDB Postgres Advanced Server-native automatic partitioning is not supported in PGD. + +If the PGD extension is active on an EDB Postgres Advanced Server database, DDL commands to configure +EDB Postgres Advanced Server automatic partitioning (`ALTER TABLE ... SET AUTOMATIC` and `ALTER TABLE ... SET INTERVAL`) +are rejected. + +While it's possible to enable the PGD extension on an EDB Postgres Advanced Server database +containing tables configured to use EDB Postgres Advanced Server-native automatic partitioning, it +isn't possible to join more nodes using this node as a source node. + +You can disable EDB Postgres Advanced Server-native automatic partitioning with one of the following +commands: + +- `ALTER TABLE ... SET MANUAL` (for list partitioned tables) +- `ALTER TABLE ... SET INTERVAL ()` (for interval partitioned tables) diff --git a/product_docs/docs/pgd/6/reference/index.mdx b/product_docs/docs/pgd/6/reference/index.mdx index 9e6f0cce767..40913b1c3ff 100644 --- a/product_docs/docs/pgd/6/reference/index.mdx +++ b/product_docs/docs/pgd/6/reference/index.mdx @@ -4,6 +4,7 @@ navTitle: Reference navigation: - tables-views-functions - appusage +- autopartition - architectures - cdc-failover - cli From 3b32c709ff6ce93b9ef23355ef43cf4b67c59872 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Wed, 7 May 2025 13:34:47 +0100 Subject: [PATCH 042/145] Small fixups before link checks Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/essential-how-to/autopartition.mdx | 6 ++++++ product_docs/docs/pgd/6/get-started/index.mdx | 4 +++- product_docs/docs/pgd/6/reference/index.mdx | 2 ++ product_docs/docs/pgd/6/reference/monitoring/sql.mdx | 8 ++++---- product_docs/docs/pgd/6/reference/sequences.mdx | 2 +- 5 files changed, 16 insertions(+), 6 deletions(-) diff --git a/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx b/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx index e69de29bb2d..0931b4db2fb 100644 --- a/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx @@ -0,0 +1,6 @@ +--- +title: Auto Partitioning +navTitle: Auto Partitioning +description: A guide on how to use auto partitioning in PGD. +--- + diff --git a/product_docs/docs/pgd/6/get-started/index.mdx b/product_docs/docs/pgd/6/get-started/index.mdx index d823ecd6fbc..e0d7ec01239 100644 --- a/product_docs/docs/pgd/6/get-started/index.mdx +++ b/product_docs/docs/pgd/6/get-started/index.mdx @@ -3,9 +3,11 @@ title: Get started with PGD navTitle: Get started description: "Get started with EDB Postgres Distributed, installing and configuring the software, and creating your first cluster." navigation: -- essential-one-location +- essential-standard - essential-near-far +- first-cluster - expanded-examples --- To begin using any edition of EDB Postgres Distributed, we recommend you first try our local installation and configuration guide. This guide will help you set up a Docker-compose cluster on your local machine, which is ideal for testing and learning purposes. + diff --git a/product_docs/docs/pgd/6/reference/index.mdx b/product_docs/docs/pgd/6/reference/index.mdx index 40913b1c3ff..2261ca6a46d 100644 --- a/product_docs/docs/pgd/6/reference/index.mdx +++ b/product_docs/docs/pgd/6/reference/index.mdx @@ -19,6 +19,7 @@ navigation: - postgres-configuration - repsets - security +- sequences - striggers - testing-tuning - transaction-streaming @@ -27,4 +28,5 @@ navigation: --- +The PGD Reference section provides detailed information about PGD's features. diff --git a/product_docs/docs/pgd/6/reference/monitoring/sql.mdx b/product_docs/docs/pgd/6/reference/monitoring/sql.mdx index 45a43ba6eb3..2aa91953e0e 100644 --- a/product_docs/docs/pgd/6/reference/monitoring/sql.mdx +++ b/product_docs/docs/pgd/6/reference/monitoring/sql.mdx @@ -14,10 +14,10 @@ nodes to ensure the health of the whole group. The bdr_monitor role can execute the `bdr.monitor` functions to provide an assessment of PGD health using one of three levels: -- `OK` — Often shown as green. -- `WARNING` — Often shown as yellow. -- `CRITICAL` — Often shown as red. -- `UNKNOWN` — For unrecognized situations, often shown as red. +- `OK` — Often shown as green. +- `WARNING` — Often shown as yellow. +- `CRITICAL` — Often shown as red. +- `UNKNOWN` — For unrecognized situations, often shown as red. PGD also provides dynamic catalog views that show the instantaneous state of various internal metrics. It also provides metadata catalogs that store the configuration diff --git a/product_docs/docs/pgd/6/reference/sequences.mdx b/product_docs/docs/pgd/6/reference/sequences.mdx index cf923587616..1be6c2ef7e4 100644 --- a/product_docs/docs/pgd/6/reference/sequences.mdx +++ b/product_docs/docs/pgd/6/reference/sequences.mdx @@ -61,7 +61,7 @@ Globally allocated sequences allocate a local range of values that can be replenished as needed by inter-node consensus, making them suitable for either BIGINT or INTEGER sequences. -You can create a global sequence using the [`bdr.alter_sequence_set_kind()`](tables-views-functions/sequences/#bdralter_sequence_set_kind) +You can create a global sequence using the [`bdr.alter_sequence_set_kind()`](/pgd/latest/reference/tables-views-functions/sequences/#bdralter_sequence_set_kind) function. This function takes a standard PostgreSQL sequence and marks it as a PGD global sequence. It can also convert the sequence back to the standard PostgreSQL sequence. From 5e1e7741de86d6687fb00acff1eb0b9d2acb3d37 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Wed, 7 May 2025 15:13:20 +0100 Subject: [PATCH 043/145] remove kubernetes sections for 6.0 release Signed-off-by: Dj Walker-Morgan --- .../architectures/near-far/index.mdx | 1 - .../near-far/kubernetes-deployments/index.mdx | 6 ----- .../architectures/standard/index.mdx | 1 - .../standard/kubernetes-deployments/index.mdx | 6 ----- .../pgd/6/get-started/first-cluster/index.mdx | 22 ++++++++++++++++++- 5 files changed, 21 insertions(+), 15 deletions(-) delete mode 100644 product_docs/docs/pgd/6/essential-how-to/architectures/near-far/kubernetes-deployments/index.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/architectures/standard/kubernetes-deployments/index.mdx diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/index.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/index.mdx index b31381070a3..c0fe87cc3d5 100644 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/index.mdx @@ -3,6 +3,5 @@ title: Near-Far Architecture navTitle: Near-Far navigation: - manual-deployments -- kubernetes-deployments --- diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/kubernetes-deployments/index.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/kubernetes-deployments/index.mdx deleted file mode 100644 index 5545edf4ce9..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/kubernetes-deployments/index.mdx +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Kubernetes Deployments" ---- - -# Kubernetes Deployments - diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/standard/index.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/standard/index.mdx index 45cf2d6ea47..aaf86db74d4 100644 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/standard/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/architectures/standard/index.mdx @@ -3,7 +3,6 @@ title: Standard PGD Architectures navTitle: Standard Architectures navigation: - manual-deployments -- kubernetes-deployments --- diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/standard/kubernetes-deployments/index.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/standard/kubernetes-deployments/index.mdx deleted file mode 100644 index 5545edf4ce9..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/standard/kubernetes-deployments/index.mdx +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Kubernetes Deployments" ---- - -# Kubernetes Deployments - diff --git a/product_docs/docs/pgd/6/get-started/first-cluster/index.mdx b/product_docs/docs/pgd/6/get-started/first-cluster/index.mdx index 8894b9bc0e4..2c4b0ddb95f 100644 --- a/product_docs/docs/pgd/6/get-started/first-cluster/index.mdx +++ b/product_docs/docs/pgd/6/get-started/first-cluster/index.mdx @@ -10,4 +10,24 @@ This part of the Getting Started guide will help you create a local cluster usin - Docker and Docker Compose installed on your local machine. -## \ No newline at end of file +## Download the PGD Docker Compose kit + +1. Download the Docker kit from the [EDB website](https://www.enterprisedb.com/downloads/postgres-distributed). +2. Extract the contents of the downloaded file to a directory on your local machine. +3. Navigate to the extracted directory. +4. Open a terminal window and run the following command to start the Docker containers: + +```bash +make up +``` + +This command will start the Docker containers and create a local cluster with the default configuration. + +5. Once the containers are up and running, you can access the PGD cluster using the following command: + +```bash +make psql +``` + +This command will connect you to the primary node of the cluster using the `psql` command-line interface. + From c8dcee84b5b799917f4d56da0afd87733535d9c6 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 8 May 2025 10:53:25 +0100 Subject: [PATCH 044/145] Removed entries, corrected cli output to match Signed-off-by: Dj Walker-Morgan --- .../cli/command_ref/cluster/verify.mdx | 2 - .../tables-views-functions/index.json | 2 - .../tables-views-functions/index.mdx | 3 -- .../tables-views-functions/pgd-settings.mdx | 53 ------------------- 4 files changed, 60 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/cluster/verify.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/cluster/verify.mdx index a260592fd72..de204fa84bf 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/cluster/verify.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/cluster/verify.mdx @@ -51,8 +51,6 @@ bdr.max_writers_per_subscription Ok bdr.raft_group_max_connections Ok bdr.replay_progress_frequency Ok bdr.role_replication Ok -bdr.standby_slot_names Ok -bdr.standby_slots_min_confirmed Ok bdr.start_workers Ok bdr.writers_per_subscription Ok bdr.xact_replication Ok diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/index.json b/product_docs/docs/pgd/6/reference/tables-views-functions/index.json index 9ffb6a073a1..d6e8e8b4ee0 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/index.json +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/index.json @@ -140,7 +140,6 @@ "bdrlock_table_locking": "/pgd/6/reference/tables-views-functions/pgd-settings#bdrlock_table_locking", "bdrpredictive_checks": "/pgd/6/reference/tables-views-functions/pgd-settings#bdrpredictive_checks", "bdrreplay_progress_frequency": "/pgd/6/reference/tables-views-functions/pgd-settings#bdrreplay_progress_frequency", - "bdrstandby_slot_names": "/pgd/6/reference/tables-views-functions/pgd-settings#bdrstandby_slot_names", "bdrwriters_per_subscription": "/pgd/6/reference/tables-views-functions/pgd-settings#bdrwriters_per_subscription", "bdrmax_writers_per_subscription": "/pgd/6/reference/tables-views-functions/pgd-settings#bdrmax_writers_per_subscription", "bdrxact_replication": "/pgd/6/reference/tables-views-functions/pgd-settings#bdrxact_replication", @@ -149,7 +148,6 @@ "bdrmaximum_clock_skew": "/pgd/6/reference/tables-views-functions/pgd-settings#bdrmaximum_clock_skew", "bdrmaximum_clock_skew_action": "/pgd/6/reference/tables-views-functions/pgd-settings#bdrmaximum_clock_skew_action", "bdraccept_connections": "/pgd/6/reference/tables-views-functions/pgd-settings#bdraccept_connections", - "bdrstandby_slots_min_confirmed": "/pgd/6/reference/tables-views-functions/pgd-settings#bdrstandby_slots_min_confirmed", "bdrwriter_input_queue_size": "/pgd/6/reference/tables-views-functions/pgd-settings#bdrwriter_input_queue_size", "bdrwriter_output_queue_size": "/pgd/6/reference/tables-views-functions/pgd-settings#bdrwriter_output_queue_size", "bdrmin_worker_backoff_delay": "/pgd/6/reference/tables-views-functions/pgd-settings#bdrmin_worker_backoff_delay", diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx index f72bf71ce09..c2651fe2f39 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx @@ -196,7 +196,6 @@ The reference section is a definitive listing of all functions, views, and comma * [`bdr.predictive_checks`](pgd-settings#bdrpredictive_checks) ### [Node management](pgd-settings#node-management) * [`bdr.replay_progress_frequency`](pgd-settings#bdrreplay_progress_frequency) - * [`bdr.standby_slot_names`](pgd-settings#bdrstandby_slot_names) ### [Generic replication](pgd-settings#generic-replication) * [`bdr.writers_per_subscription`](pgd-settings#bdrwriters_per_subscription) * [`bdr.max_writers_per_subscription`](pgd-settings#bdrmax_writers_per_subscription) @@ -206,8 +205,6 @@ The reference section is a definitive listing of all functions, views, and comma * [`bdr.maximum_clock_skew`](pgd-settings#bdrmaximum_clock_skew) * [`bdr.maximum_clock_skew_action`](pgd-settings#bdrmaximum_clock_skew_action) * [`bdr.accept_connections`](pgd-settings#bdraccept_connections) - * [`bdr.standby_slot_names`](pgd-settings#bdrstandby_slot_names) - * [`bdr.standby_slots_min_confirmed`](pgd-settings#bdrstandby_slots_min_confirmed) * [`bdr.writer_input_queue_size`](pgd-settings#bdrwriter_input_queue_size) * [`bdr.writer_output_queue_size`](pgd-settings#bdrwriter_output_queue_size) * [`bdr.min_worker_backoff_delay`](pgd-settings#bdrmin_worker_backoff_delay) diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/pgd-settings.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/pgd-settings.mdx index b3cdfa95fe0..8d1da073433 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/pgd-settings.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/pgd-settings.mdx @@ -180,12 +180,6 @@ withing reasonable lag limit for getting the quorum needed by the global lock. Sets the interval for sending replication position info to the rest of the cluster (default is 1 minute). -### `bdr.standby_slot_names` - -Sets the slots required to receive and confirm replication changes before any -other ones. This setting is useful primarily when using physical standbys for -failover or when using subscribe-only nodes. - ## Generic replication ### `bdr.writers_per_subscription` @@ -275,53 +269,6 @@ Enables or disables connections to PGD (default is `on`). Requires bdr_superuser or PostgreSQL superuser. -### `bdr.standby_slot_names` - -This setting is typically used in failover configurations to ensure that the -failover-candidates streaming physical replicas for this PGD node have received -and flushed all changes before they ever become visible to subscribers. That -guarantees that a commit can't vanish on failover to a standby for the provider. - -Replication slots whose names are listed in the comma-separated -`bdr.standby_slot_names` list are treated specially by the WAL sender on a PGD -node. - -PGD's logical replication WAL senders ensure that all local changes are sent and -flushed to the replication slots in `bdr.standby_slot_names` before the node -sends those changes to any other PGD replication clients. Effectively, it -provides a synchronous replication barrier between the named list of slots and -all other replication clients. - -Any replication slot can be listed in `bdr.standby_slot_names`. Both logical and -physical slots work, but it's generally used for physical slots. - -Without this safeguard, two anomalies are possible where a commit can be -received by a subscriber and then vanish from the provider on failover because -the failover candidate hadn't received it yet: - -- For 1+ subscribers, the subscriber might have applied the change but the new - provider might execute new transactions that conflict with the received change, - as it never happened as far as the provider is concerned. - -- For 2+ subscribers, at the time of failover, not all subscribers have applied - the change. The subscribers now have inconsistent and irreconcilable states - because the subscribers that didn't receive the commit have no way to get it. - -Setting `bdr.standby_slot_names` by design causes other subscribers not listed -in there to lag behind the provider if the required number of listed nodes are -not keeping up. Monitoring is thus essential. - -Another use case where `bdr.standby_slot_names` is useful is when using a -subscriber-only node, to ensure that it doesn't move ahead of any of the -regular PGD nodes. This can best be achieved by listing the logical slots of all -regular PGD peer nodes in combination with setting -`bdr.standby_slots_min_confirmed` to at least 1. - -### `bdr.standby_slots_min_confirmed` - -Controls how many of the `bdr.standby_slot_names` have to confirm before -sending data to PGD subscribers. - ### `bdr.writer_input_queue_size` Specifies the size of the shared memory queue used by the receiver From 25dbd789bb4d07bb666530380f52f1c9c924252c Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 8 May 2025 11:38:52 +0100 Subject: [PATCH 045/145] Added text for unlogged sequences Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/reference/sequences.mdx | 85 ++++++++----------- 1 file changed, 37 insertions(+), 48 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/sequences.mdx b/product_docs/docs/pgd/6/reference/sequences.mdx index 1be6c2ef7e4..f14b4255cd5 100644 --- a/product_docs/docs/pgd/6/reference/sequences.mdx +++ b/product_docs/docs/pgd/6/reference/sequences.mdx @@ -71,18 +71,18 @@ determines the kind of sequence to create when the `CREATE SEQUENCE` command is executed or when a `serial`, `bigserial`, or `GENERATED BY DEFAULT AS IDENTITY` column is created. Valid settings are: -- `local` — Newly created - sequences are the standard PostgreSQL (local) sequences. -- `galloc` — Always creates globally allocated range sequences. -- `snowflakeid` — Creates global sequences for BIGINT sequences that - consist of time, nodeid, and counter components. You can't use it with - INTEGER sequences (so you can use it for `bigserial` but not for `serial`). -- `timeshard` — The older version of SnowflakeId sequence. Provided for - backward compatibility only. The SnowflakeId is preferred. -- `distributed` (default) — A special value that you can use only for - [`bdr.default_sequence_kind`](reference/pgd-settings/#global-sequence-parameters). It selects `snowflakeid` for `int8` - sequences (that is, `bigserial`) and `galloc` sequence for `int4` - (that is, `serial`) and `int2` sequences. +- `local` — Newly created + sequences are the standard PostgreSQL (local) sequences. +- `galloc` — Always creates globally allocated range sequences. +- `snowflakeid` — Creates global sequences for BIGINT sequences that + consist of time, nodeid, and counter components. You can't use it with + INTEGER sequences (so you can use it for `bigserial` but not for `serial`). +- `timeshard` — The older version of SnowflakeId sequence. Provided for + backward compatibility only. The SnowflakeId is preferred. +- `distributed` (default) — A special value that you can use only for + [`bdr.default_sequence_kind`](reference/pgd-settings/#global-sequence-parameters). It selects `snowflakeid` for `int8` + sequences (that is, `bigserial`) and `galloc` sequence for `int4` + (that is, `serial`) and `int2` sequences. The [`bdr.sequences`](/pgd/latest/reference/catalogs-visible/#bdrsequences) view shows information about individual sequence kinds. @@ -163,19 +163,27 @@ protections, and slower performance. The differences between timeshard and SnowflakeId are as follows: - - Timeshard can generate up to 16384 per millisecond (about 16 million per - second), which is more than SnowflakeId. However, there's no protection - against wraparound within a given millisecond. Schemas using the timeshard - sequence must protect the use of the `UNIQUE` constraint when using timeshard values - for a given column. - - The timestamp component of timeshard sequence runs out of values in - the year 2050 and, if used in combination with bigint, the values wrap - to negative numbers in the year 2033. This means that sequences generated - after 2033 have negative values. This is a considerably shorter time - span than SnowflakeId and is the main reason why SnowflakeId is preferred. - - Timeshard sequences require occasional disk writes (similar to standard local - sequences). SnowflakeIds are calculated in memory so the SnowflakeId - sequences are in general a little faster than timeshard sequences. +- Timeshard can generate up to 16384 per millisecond (about 16 million per + second), which is more than SnowflakeId. However, there's no protection + against wraparound within a given millisecond. Schemas using the timeshard + sequence must protect the use of the `UNIQUE` constraint when using timeshard values + for a given column. +- The timestamp component of timeshard sequence runs out of values in + the year 2050 and, if used in combination with bigint, the values wrap + to negative numbers in the year 2033. This means that sequences generated + after 2033 have negative values. This is a considerably shorter time + span than SnowflakeId and is the main reason why SnowflakeId is preferred. +- Timeshard sequences require occasional disk writes (similar to standard local + sequences). SnowflakeIds are calculated in memory so the SnowflakeId + sequences are in general a little faster than timeshard sequences. + +### Unlogged sequences and PGD + +Since Postgres 15, it has been possible to create unlogged sequences. These are +related and similar to unlogged tables, which are not written to the WAL and are not replicated. +In the context of PGD and unlogged sequences, it is not a sensible configuration to have an unlogged +PGD sequence and it could cause unexpected problems in the event of a node failure. Therefore, we prevent the +creation of unlogged PGD sequences or the conversion of an unlogged sequence to a PGD sequence. ### Globally allocated range sequences @@ -367,30 +375,11 @@ the new reserved chunk and starts to consume the old reserved chunk. You can generate globally unique ids in other ways without using the global sequences that can be used with PGD. For example: +- UUIDs and their PGD variant, KSUUIDs +- Local sequences with a different offset per node (i.e., manual) +- An externally coordinated natural key -### `bdr.galloc_chunk_info` - -This function retrieves the ranges allocated to a galloc sequence on the local -node. - -An empty result set will be returned if the sequence has not yet been accessed -on the local node. - -An ERROR will be raised if the provided sequence name is not a galloc sequence. - -#### Synopsis - -```sql -bdr.galloc_chunk_info(seqname regclass) -``` - -#### Parameters - -- `seqname` - the name of the galloc sequence to query - -#### Notes - -This function executes only on the local node. +PGD applications can't use other methods safely. Counter-table-based approaches relying on `SELECT ... FOR UPDATE`, `UPDATE ... RETURNING ...` or similar for sequence generation don't work correctly in PGD because PGD doesn't take row locks between nodes. The same values are generated on more than one node. For the same reason, the usual strategies for "gapless" sequence generation don't work with PGD. In most cases, the application coordinates generating sequences that must be gapless from some external source using two-phase commit. Or it generates them only on one node in the PGD group. ## KSUUID v2 functions From 98b7df99127bb490c54f41792b553f9ce73ee919 Mon Sep 17 00:00:00 2001 From: Ian Barwick Date: Fri, 9 May 2025 16:33:06 +0900 Subject: [PATCH 046/145] Update sequences.mdx PGD sequences can't be converted to unlogged. Other way round will work, as there's no reason to prevent it. --- product_docs/docs/pgd/6/reference/sequences.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/6/reference/sequences.mdx b/product_docs/docs/pgd/6/reference/sequences.mdx index f14b4255cd5..38d62ff09d0 100644 --- a/product_docs/docs/pgd/6/reference/sequences.mdx +++ b/product_docs/docs/pgd/6/reference/sequences.mdx @@ -183,7 +183,7 @@ Since Postgres 15, it has been possible to create unlogged sequences. These are related and similar to unlogged tables, which are not written to the WAL and are not replicated. In the context of PGD and unlogged sequences, it is not a sensible configuration to have an unlogged PGD sequence and it could cause unexpected problems in the event of a node failure. Therefore, we prevent the -creation of unlogged PGD sequences or the conversion of an unlogged sequence to a PGD sequence. +creation of unlogged PGD sequences or the conversion of a PGD sequence to an unlogged sequence. ### Globally allocated range sequences From a53ab3bfb8750a5a559db11995de45577899bc4d Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 8 May 2025 14:25:32 +0100 Subject: [PATCH 047/145] PGD Link fixes and content clean up Signed-off-by: Dj Walker-Morgan --- .../distributed_highavailability.mdx | 4 +- .../latest-release-news/2025q1release.mdx | 6 +- .../overview/latest-release-news/index.mdx | 6 +- .../deploying/04-installing-software.mdx | 2 +- .../02-installing-database-and-pgd.mdx | 2 +- .../install/05-using-pgd-cli.mdx | 4 +- .../sop/{backup.mdx => backup-restore.mdx} | 7 +- .../pgd/6/essential-how-to/sop/configure.mdx | 5 + .../essential-how-to/sop/how-to-use-sops.mdx | 24 + .../docs/pgd/6/essential-how-to/sop/index.mdx | 19 + .../pgd/6/essential-how-to/sop/install.mdx | 7 + .../pgd/6/essential-how-to/sop/monitoring.mdx | 5 + .../essential-how-to/sop/troubleshooting.mdx | 0 .../pgd/6/essential-how-to/sop/upgrade.mdx | 0 .../sop/upgrades/app_upgrades.mdx | 90 --- .../sop/upgrades/compatibility.mdx | 64 -- .../6/essential-how-to/sop/upgrades/index.mdx | 37 -- .../sop/upgrades/inplace_upgrade.mdx | 196 ------ .../sop/upgrades/manual_overview.mdx | 228 ------- .../sop/upgrades/tpa_overview.mdx | 63 -- .../sop/upgrades/upgrade_paths.mdx | 36 - .../sop/upgrades/upgrading_major_rolling.mdx | 622 ------------------ product_docs/docs/pgd/6/known_issues.mdx | 108 ++- .../pgd/6/reference/commit-scopes/camo.mdx | 2 +- .../reference/commit-scopes/group-commit.mdx | 4 +- .../pgd/6/reference/commit-scopes/index.mdx | 4 - .../6/reference/commit-scopes/limitations.mdx | 106 --- .../01_overview_clcd.mdx | 2 +- .../conflicts/03_conflict_detection.mdx | 2 +- .../conflicts/04_conflict_resolution.mdx | 2 +- .../conflicts/05_conflict_logging.mdx | 2 +- .../connection-manager/monitoring.mdx | 2 +- .../ddl/ddl-pgd-functions-like-ddl.mdx | 2 +- .../docs/pgd/6/reference/ddl/index.mdx | 2 +- .../node_management/automatic_sync.mdx | 8 +- .../node_management/creating_nodes.mdx | 10 +- .../overview/architecture-and-performance.mdx | 2 +- .../docs/pgd/6/reference/sequences.mdx | 26 +- .../catalogs-visible.mdx | 2 +- .../docs/pgd/6/reference/twophase.mdx | 2 +- 40 files changed, 215 insertions(+), 1500 deletions(-) rename product_docs/docs/pgd/6/essential-how-to/sop/{backup.mdx => backup-restore.mdx} (99%) create mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/configure.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/how-to-use-sops.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/install.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/monitoring.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/troubleshooting.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/upgrades/app_upgrades.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/upgrades/compatibility.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/upgrades/index.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/upgrades/inplace_upgrade.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/upgrades/manual_overview.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/upgrades/tpa_overview.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/upgrades/upgrade_paths.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/upgrades/upgrading_major_rolling.mdx delete mode 100644 product_docs/docs/pgd/6/reference/commit-scopes/limitations.mdx diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/distributed_highavailability.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/distributed_highavailability.mdx index c9610372858..2e68f2d7660 100644 --- a/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/distributed_highavailability.mdx +++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/supported_cluster_types/distributed_highavailability.mdx @@ -11,7 +11,7 @@ This configuration provides a true active-active solution as each data group is Distributed high-availability clusters support both EDB Postgres Advanced Server and EDB Postgres Extended Server database distributions. -Distributed high-availability clusters contain one or two data groups. Your data groups can contain either three data nodes or two data nodes and one witness node. At any given time, one of these data nodes in each group is the leader and accepts writes, while the rest are referred to as [shadow nodes](/pgd/latest/terminology/#write-leader). We recommend that you don't use two data nodes and one witness node in production unless you use asynchronous [commit scopes](/pgd/latest/commit-scopes/commit-scopes/). +Distributed high-availability clusters contain one or two data groups. Your data groups can contain either three data nodes or two data nodes and one witness node. At any given time, one of these data nodes in each group is the leader and accepts writes, while the rest are referred to as [shadow nodes](/pgd/latest/terminology/#write-leader). We recommend that you don't use two data nodes and one witness node in production unless you use asynchronous [commit scopes](/pgd/latest/reference/commit-scopes/commit-scopes/). [PGD Proxy](/pgd/latest/routing/proxy) routes all application traffic to the leader node, which acts as the principal write target to reduce the potential for data conflicts. PGD Proxy leverages a distributed consensus model to determine availability of the data nodes in the cluster. On failure or unavailability of the leader, PGD Proxy elects a new leader and redirects application traffic. Together with the core capabilities of EDB Postgres Distributed, this mechanism of routing application traffic to the leader node enables fast failover and switchover. @@ -19,7 +19,7 @@ The witness node/witness group doesn't host data but exists for management purpo !!!Note - Operations against a distributed high-availability cluster leverage the [EDB Postgres Distributed set-leader](/pgd/latest/cli/command_ref/group/set-leader) feature, which provides subsecond interruptions during planned lifecycle operations. + Operations against a distributed high-availability cluster leverage the [EDB Postgres Distributed set-leader](/pgd/latest/reference/cli/command_ref/group/set-leader) feature, which provides subsecond interruptions during planned lifecycle operations. ## Single data location diff --git a/advocacy_docs/edb-postgres-ai/overview/latest-release-news/2025q1release.mdx b/advocacy_docs/edb-postgres-ai/overview/latest-release-news/2025q1release.mdx index f660c0a4681..6650e145ebb 100644 --- a/advocacy_docs/edb-postgres-ai/overview/latest-release-news/2025q1release.mdx +++ b/advocacy_docs/edb-postgres-ai/overview/latest-release-news/2025q1release.mdx @@ -67,11 +67,11 @@ Refer to the [Rubrik Partner Page](https://www.enterprisedb.com/partners/rubrik EDB Postgres AI leads the way for applications that require high availability for critical business continuity. With [EDB Postgres Distributed (PGD)](https://www.enterprisedb.com/products/edb-postgres-distributed), customers can build [geo-distributed](https://www.enterprisedb.com/use-case/geo-distributed) architectures that ensure continuous availability, improve performance by placing data closer to users, and enable safe, zero-downtime software deployments. -The latest version, [PGD 5.7.0](https://www.enterprisedb.com/docs/pgd/latest/), is now generally available. It delivers up to 99.999% availability with improved reliability and streamlined operations through enhanced integration with [third party change data capture (CDC) functionality](https://www.enterprisedb.com/docs/pgd/latest/cdc-failover/). This allows seamless failover of logical slots for common CDC plugins like `test_decoding` and `pgoutput`, eliminating the need for third party subscribers to reseed tables during lead primary changes and ensuring continuous data replication. +The latest version, [PGD 5.7.0](https://www.enterprisedb.com/docs/pgd/latest/), is now generally available. It delivers up to 99.999% availability with improved reliability and streamlined operations through enhanced integration with [third party change data capture (CDC) functionality](https://www.enterprisedb.com/docs/pgd/reference/latest/cdc-failover/). This allows seamless failover of logical slots for common CDC plugins like `test_decoding` and `pgoutput`, eliminating the need for third party subscribers to reseed tables during lead primary changes and ensuring continuous data replication. -Additionally, the new [`Assess`](https://www.enterprisedb.com/docs/pgd/latest/cli/command_ref/assess/) command in the PGD CLI ensures seamless migrations to PGD. The tool proactively identifies PostgreSQL incompatibilities before upgrades, especially those impacting logical replication, so you can address them before upgrading to PGD. +Additionally, the new `Assess` command in the PGD CLI ensures seamless migrations to PGD. The tool proactively identifies PostgreSQL incompatibilities before upgrades, especially those impacting logical replication, so you can address them before upgrading to PGD. -PGD 5.7.0 also introduces the [`pgd node upgrade`](https://www.enterprisedb.com/docs/pgd/latest/cli/command_ref/node/upgrade/) command, which enables upgrades to the latest versions of PGD and PostgreSQL with a single command, limiting the manual work required for maintenance and reducing complexity and potential errors. These updates collectively enhance the robustness and usability of PGD to provide users with a more reliable and efficient data management experience. +PGD 5.7.0 also introduces the `pgd node upgrade` command, which enables upgrades to the latest versions of PGD and PostgreSQL with a single command, limiting the manual work required for maintenance and reducing complexity and potential errors. These updates collectively enhance the robustness and usability of PGD to provide users with a more reliable and efficient data management experience. Learn more about how [PGD](https://www.enterprisedb.com/products/edb-postgres-distributed) enables high availability for enterprise applications. diff --git a/advocacy_docs/edb-postgres-ai/overview/latest-release-news/index.mdx b/advocacy_docs/edb-postgres-ai/overview/latest-release-news/index.mdx index 95d677395b6..addc73752d9 100644 --- a/advocacy_docs/edb-postgres-ai/overview/latest-release-news/index.mdx +++ b/advocacy_docs/edb-postgres-ai/overview/latest-release-news/index.mdx @@ -73,11 +73,11 @@ Refer to the [Rubrik Partner Page](https://www.enterprisedb.com/partners/rubrik EDB Postgres AI leads the way for applications that require high availability for critical business continuity. With [EDB Postgres Distributed (PGD)](https://www.enterprisedb.com/products/edb-postgres-distributed), customers can build [geo-distributed](https://www.enterprisedb.com/use-case/geo-distributed) architectures that ensure continuous availability, improve performance by placing data closer to users, and enable safe, zero-downtime software deployments. -The latest version, [PGD 5.7.0](https://www.enterprisedb.com/docs/pgd/5.7/), is now generally available. It delivers up to 99.999% availability with improved reliability and streamlined operations through enhanced integration with [third party change data capture (CDC) functionality](https://www.enterprisedb.com/docs/pgd/latest/cdc-failover/). This allows seamless failover of logical slots for common CDC plugins like `test_decoding` and `pgoutput`, eliminating the need for third party subscribers to reseed tables during lead primary changes and ensuring continuous data replication. +The latest version, [PGD 5.7.0](https://www.enterprisedb.com/docs/pgd/5.7/), is now generally available. It delivers up to 99.999% availability with improved reliability and streamlined operations through enhanced integration with third party change data capture (CDC) functionality. This allows seamless failover of logical slots for common CDC plugins like `test_decoding` and `pgoutput`, eliminating the need for third party subscribers to reseed tables during lead primary changes and ensuring continuous data replication. -Additionally, the new [`Assess`](https://www.enterprisedb.com/docs/pgd/latest/cli/command_ref/assess/) command in the PGD CLI ensures seamless migrations to PGD. The tool proactively identifies PostgreSQL incompatibilities before upgrades, especially those impacting logical replication, so you can address them before upgrading to PGD. +Additionally, the new `Assess` command in the PGD CLI ensures seamless migrations to PGD. The tool proactively identifies PostgreSQL incompatibilities before upgrades, especially those impacting logical replication, so you can address them before upgrading to PGD. -PGD 5.7.0 also introduces the [`pgd node upgrade`](https://www.enterprisedb.com/docs/pgd/5.7/cli/command_ref/node/upgrade/) command, which enables upgrades to the latest versions of PGD and PostgreSQL with a single command, limiting the manual work required for maintenance and reducing complexity and potential errors. These updates collectively enhance the robustness and usability of PGD to provide users with a more reliable and efficient data management experience. +PGD 5.7.0 also introduces the `pgd node upgrade` command, which enables upgrades to the latest versions of PGD and PostgreSQL with a single command, limiting the manual work required for maintenance and reducing complexity and potential errors. These updates collectively enhance the robustness and usability of PGD to provide users with a more reliable and efficient data management experience. Learn more about how [PGD](https://www.enterprisedb.com/products/edb-postgres-distributed) enables high availability for enterprise applications. diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/04-installing-software.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/04-installing-software.mdx index c375611c0e4..7ca1bc1f314 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/04-installing-software.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/04-installing-software.mdx @@ -28,7 +28,7 @@ You must perform these steps on each host before proceeding to the next step. * Increase the maximum worker processes to 16 or higher by setting `max_worker_processes` to `'16'` in `postgresql.conf`.

!!! Note The `max_worker_processes` value The `max_worker_processes` value is derived from the topology of the cluster, the number of peers, number of databases, and other factors. - To calculate the needed value, see [Postgres configuration/settings](../../../postgres-configuration/#postgres-settings). + To calculate the needed value, see [Postgres configuration/settings](/pgd/latest/reference//postgres-configuration/#postgres-settings). The value of 16 was calculated for the size of cluster being deployed in this example. It must be increased for larger clusters. !!! * Set a password on the EnterprisedDB/Postgres user. diff --git a/product_docs/docs/pgd/6/essential-how-to/install/02-installing-database-and-pgd.mdx b/product_docs/docs/pgd/6/essential-how-to/install/02-installing-database-and-pgd.mdx index e4b8c45bca4..5b49e62b7ae 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/02-installing-database-and-pgd.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/02-installing-database-and-pgd.mdx @@ -7,7 +7,7 @@ deepToC: true On each host which you want to use as a PGD data node, you need to install the database and the PGD software. -## Configure the repository +## Configure repositories Set the following environment variables: diff --git a/product_docs/docs/pgd/6/essential-how-to/install/05-using-pgd-cli.mdx b/product_docs/docs/pgd/6/essential-how-to/install/05-using-pgd-cli.mdx index fbb000c220f..d9f0365fd6d 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/05-using-pgd-cli.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/05-using-pgd-cli.mdx @@ -27,7 +27,7 @@ We recommend the first option, as the other options don't scale well with multip - Ensure PGD CLI is installed. - If PGD CLI was already installed, move to the next step. - - For any system, repeat the [configure repositories](02-installing-database-and-pgd#configuring_repositories) step on that system. + - For any system, repeat the [configure repositories](02-installing-database-and-pgd#configure_repositories) step on that system. - Then run the package installation command appropriate for that platform. - RHEL and derivatives: `sudo dnf install edb-pgd6-cli` - Debian, Ubuntu, and derivatives: `sudo apt-get install edb-pgd6-cli` @@ -234,5 +234,5 @@ Write Leader node-two Commit Scope ``` -More details on the available commands in PGD CLI are available in the [PGD CLI command reference](../../../cli/command_ref/). +More details on the available commands in PGD CLI are available in the [PGD CLI command reference](/pgd/latest/reference/cli/command_ref/). diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/backup.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/backup-restore.mdx similarity index 99% rename from product_docs/docs/pgd/6/essential-how-to/sop/backup.mdx rename to product_docs/docs/pgd/6/essential-how-to/sop/backup-restore.mdx index 4b1666a709d..e1a57033e79 100644 --- a/product_docs/docs/pgd/6/essential-how-to/sop/backup.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/sop/backup-restore.mdx @@ -1,13 +1,14 @@ --- -title: Backup and recovery -description: Backup and recovery in PGD +title: Backup and recovery SOPs +description: Backup and recovery originalFilePath: backup.md redirects: - /bdr/latest/backup/ - /bdr/latest/monitoring/ - --- +**TODO**: Split? + PGD is designed to be a distributed, highly available system. If one or more nodes of a cluster are lost, the best way to replace them is to clone new nodes directly from the remaining nodes. diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/configure.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/configure.mdx new file mode 100644 index 00000000000..5a17d905b45 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sop/configure.mdx @@ -0,0 +1,5 @@ +--- +title: Configuration SOPs +navTitle: Configuration +--- + diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/how-to-use-sops.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/how-to-use-sops.mdx new file mode 100644 index 00000000000..1e102b6bab9 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sop/how-to-use-sops.mdx @@ -0,0 +1,24 @@ +--- +title: How to use Standard Operating Procedures +navTitle: How to use +description: How to use Standard Operating Procedures (SOPs) for EDB Postgres Distributed (PGD). +--- + +Standard Operating Procedures, or SOPs, are a set of instructions that cover the essential tasks for the successful operation of EDB Postgres Distributed (PGD). + +They are designed to be easy to follow and provide step-by-step guidance for performing various tasks. + +To make it easy to follow, each SOP is divided into sections that cover the following: + +- **Overview**: A brief description of the task and its purpose. +- **Prerequisites**: Any requirements or dependencies that must be met before performing the task. +- **Instructions**: Step-by-step generic instructions for performing the task. +- **Worked Example**: A specific example of how to perform the task, including any relevant commands or configurations. +- **Notes**: Additional information or tips that may be helpful. +- **Troubleshooting**: Common issues that may arise during the task and how to resolve them. +- **References**: Links to related documentation or resources. + +## How to use SOPs + +**TODO**: Add a description of how to use SOPs. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/index.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/index.mdx index 26b51e97e6d..cfb898f49b6 100644 --- a/product_docs/docs/pgd/6/essential-how-to/sop/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/sop/index.mdx @@ -1,5 +1,24 @@ --- title: Essential Standard Operating Procedures navTitle: Essential Standard Operating Procedures +navigation: +- how-to-use-sops +- install +- configure +- backup-restore +- upgrade +- monitoring +- troubleshooting --- +## Overview + +Standard Operating Procedures (SOPs) are a set of procedures that are essential for the successful operation of EDB Postgres Distributed (PGD). These procedures cover various aspects of the system, including installation, configuration, backup and restore, upgrades, monitoring, and troubleshooting. + +This document provides an overview of the SOPs and links to detailed instructions for each procedure. + + +## Backup and Restore + +## Upgrades + diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/install.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/install.mdx new file mode 100644 index 00000000000..ffcf47f09f6 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sop/install.mdx @@ -0,0 +1,7 @@ +--- +title: Installation SOPs +navTitle: Installation +--- + +Part of the nature of a distributed system like PGD is that new nodes can be added (and removed) at any time. This means that you do need to know how to install PGD on a fresh node, how to configure it, and how to add it to an existing cluster. This section covers the essential SOPs for installing PGD on a new node, configuring it, and adding it to an existing cluster. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/monitoring.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/monitoring.mdx new file mode 100644 index 00000000000..993b94b8aea --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sop/monitoring.mdx @@ -0,0 +1,5 @@ +--- +title: Monitoring SOPs +navTitle: Monitoring +--- + diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/troubleshooting.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/troubleshooting.mdx new file mode 100644 index 00000000000..e69de29bb2d diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx new file mode 100644 index 00000000000..e69de29bb2d diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/app_upgrades.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/app_upgrades.mdx deleted file mode 100644 index c2adf3e909d..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/app_upgrades.mdx +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: "Application schema upgrades" ---- - -Similar to the upgrade of EDB Postgres Distributed, there are two -approaches to upgrading the application schema. The simpler option is to -stop all applications affected, preform the schema upgrade, and restart the -application upgraded to use the new schema variant. This approach -imposes some downtime. - -To eliminate this downtime, EDB Postgres Distributed offers useful tools to -perform a rolling application schema upgrade. - -The following recommendations and tips reduce the impact of the -application schema upgrade on the cluster. - -### Rolling application schema upgrades - -By default, DDL is automatically sent to all nodes. You can control this behavior -manually, as described in -[DDL replication](/pgd/latest/reference/ddl/). You can use this approach -to create differences between database schemas across nodes. - -PGD is designed to allow replication to continue even with minor -differences between nodes. These features are designed to allow -application schema migration without downtime or to allow logical -standby nodes for reporting or testing. - -!!! Warning - You must manage rolling application schema upgrades outside of PGD. - - Careful scripting is required to make this work correctly - on production clusters. We recommend extensive testing. - -See [Replicating between nodes with differences](/pgd/latest/reference/appusage/) for details. - -When one node runs DDL that adds a new table, nodes that haven't -yet received the latest DDL need to handle the extra table. -In view of this, the appropriate setting for rolling schema upgrades -is to configure all nodes to apply the `skip` resolver in case of a -`target_table_missing` conflict. Perform this configuration before adding tables to any -node. This setting is intended to be permanent. - -Execute the following query **separately on each node**. Replace `node1` with the actual -node name. - -```sql -SELECT bdr.alter_node_set_conflict_resolver('node1', - 'target_table_missing', 'skip'); -``` - -When one node runs DDL that adds a column to a table, nodes that haven't -yet received the latest DDL need to handle the extra columns. -In view of this, the appropriate setting for rolling schema -upgrades is to configure all nodes to apply the `ignore` resolver in -case of a `target_column_missing` conflict. Perform this before adding columns to -one node. This setting is intended to be -permanent. - -Execute the following query **separately on each node**. Replace `node1` with the actual -node name. - -```sql -SELECT bdr.alter_node_set_conflict_resolver('node1', - 'target_column_missing', 'ignore'); -``` - -When one node runs DDL that removes a column from a table, nodes that -haven't yet received the latest DDL need to handle the missing column. -This situation causes a `source_column_missing` conflict, which uses -the `use_default_value` resolver. Thus, columns that don't -accept NULLs and don't have a DEFAULT value require a two-step process: - -1. Remove the NOT NULL constraint, or add a DEFAULT value for a column - on all nodes. -2. Remove the column. - -You can remove constraints in a rolling manner. -There's currently no supported way for handling adding table -constraints in a rolling manner, one node at a time. - -When one node runs a DDL that changes the type of an existing column, -depending on the existence of binary coercibility between the current -type and the target type, the operation might not rewrite the underlying -table data. In that case, it's only a metadata update of the -underlying column type. Rewriting a table is normally restricted. -However, in controlled DBA environments, you can change -the type of a column to an automatically castable one by adopting -a rolling upgrade for the type of this column in a non-replicated -environment on all the nodes, one by one. See [ALTER TABLE](/pgd/latest/reference/ddl/ddl-command-handling/#alter-table) for more details. diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/compatibility.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/compatibility.mdx deleted file mode 100644 index d4cf7ede27b..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/compatibility.mdx +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: Compatibility changes ---- - -Upgrading BDR from 4.x to 6.x is possible. - -## Connection routing - -HARP Manager and Proxy and it's replacement, PGD Proxy have been replaced. -They are supreceded by the new integrated [connection management](../routing) system. - -## Commit At Most Once - -CAMO configuration is now done through [commit scopes](../commit-scopes/commit-scopes). The -`bdr.camo_pairs` catalog and any related manipulation functions don't exist -anymore. - -The `synchronous_replication_availability` GUC doesn't affect CAMO anymore. -Use the `DEGRADE ON ... TO ASYNC` clause of a commit scope. - - -## Eager All-Node Replication - -The `global` scope no longer exists. To create scope with the same -behavior, use [Group Commit](../commit-scopes/group-commit). - -```sql -SELECT bdr.create_commit_scope( - commit_scope_name := 'eager_scope', - origin_node_group := 'top_group', - rule := 'ALL (top_group) GROUP COMMIT (conflict_resolution = eager, commit_decision = raft) ABORT ON (timeout = 60s)', - wait_for_ready := true -); -``` - -## Lag Control - -Similarly to CAMO and Eager, Lag Control configuration was also moved to -[commit scopes](../commit-scopes/commit-scopes) for more flexible durability configuration. - -## Catalogs - -- `bdr.workers` doesn't show worker-specific info like `worker_commit_timestamp` anymore. -- `bdr.worker_errors` is deprecated and lost most of the info. -- `bdr.state_journal_details` is deprecated and lost most of the info. -- `bdr.event_summary` replaces `bdr.worker_errors` and - `bdr.state_journal_details` with additional info like Raft role changes. -- The table `bdr.node_catchup_info` now has the user-consumable view - `bdr.node_catchup_info_details`, which shows info in a more friendly way. -- Witness node is no longer distinguished by the replication sets - it replicates but by using the `node_kind` value in `bdr.node_summary`. -- All the Raft (consensus) related tables and functions were adjusted to support - multiple Raft instances (sub-group Raft). -- `bdr.node_pre_commit` view and the underlying table was removed, as the - information is no longer stored in a table. -- `bdr.commit_decisions` view was added and replaces the `bdr.node_pre_commit` one. -- Multiple internal autopartition tables were replaced by taskmgr ones, as the - mechanism behind it was generalized. -- `bdr.network_monitoring` view was removed along with underlying tables and - functions. -- Many catalogs were added and some have new columns, as described in - [Catalogs](/pgd/latest/reference/tables-views-functions/catalogs-visible/). These - aren't breaking changes strictly speaking, but we recommend reviewing them - when upgrading. diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/index.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/index.mdx deleted file mode 100644 index 6c30639dba7..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/index.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Upgrading" -description: Upgrading EDB Postgres Distributed and Postgres -navigation: -- tpa_overview -- manual_overview -- upgrade_paths -- compatibility -- bdr_pg_upgrade -- app_upgrades ---- - -While PGD and Postgres are closely related, they're separate products with separate upgrade paths. This section covers how to upgrade both PGD and Postgres. - -## Upgrading PGD - -EDB Postgres Distributed is a flexible platform. This means that your upgrade path depends largely on how you installed PGD. - -* **[Upgrading with TPA](tpa_overview)** — If you installed using TPA, you can use its automated upgrade feature to upgrade to the latest minor versions. - -* **[Upgrading manually](manual_overview)** — If you manually installed and configured your PGD cluster, you can move a cluster between versions, both minor and major. - -* **[Upgrade paths](upgrade_paths)** — Several supported upgrade paths are available. - -* **[Compatibility changes](compatibility)** — If you're upgrading from PGD 4.x to PGD 6.x or later, you need to understand the compatibility changes between versions. - - -## Upgrading Postgres or Postgres and PGD major versions - -* **[In-place Postgres major version upgrades](inplace_upgrade)** — How to use `pgd node upgrade` to manually upgrade the Postgres version or Postgres and PGD major version on one or more nodes. - -* **[Rolling major version upgrades](upgrading_major_rolling)** — How to perform a major version upgrade of Postgres on a cluster. - - -## Other upgrades - -* **[Application schema upgrades](app_upgrades)** — A guide for safely upgrading your application's schema when running multiple distributed servers with PGD. diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/inplace_upgrade.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/inplace_upgrade.mdx deleted file mode 100644 index c1f71baa4f6..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/inplace_upgrade.mdx +++ /dev/null @@ -1,196 +0,0 @@ ---- -title: In-place Postgres or Postgres and PGD major version upgrades -redirects: - - pgd/latest/upgrades/bdr_pg_upgrade/ ---- - -You can upgrade a PGD node to a newer major version of Postgres or a major version of Postgres and PGD using the command-line utility [pgd node upgrade](/pgd/5.7/cli/command_ref/node/upgrade.mdx). - -!!!Note -In previous versions before 5.7.0, the command used for in-place major version upgrades was `bdr_pg_upgrade`. -However, this command didn't have an option to upgrade both Postgres major versions and PGD versions simultaneously, as `pgd node upgrade` does. -!!! - -`pgd node upgrade` is a wrapper around the standard [pg_upgrade](https://www.postgresql.org/docs/current/pgupgrade.html) that -adds PGD-specific logic to the process to ensure a smooth upgrade. - -## Terminology - -This terminology is used when describing the upgrade process and components involved: - -*Postgres cluster* — The database files, both executables and data, that make up a Postgres database instance on a system when run. - -*Old Postgres cluster* — The existing Postgres cluster to upgrade, the one from which to migrate data. - -*New Postgres cluster* — The new Postgres cluster that data is migrated to. -This Postgres cluster must be one major version ahead of the old cluster. - -## Precautions - -Standard Postgres major version upgrade precautions apply, including the fact both Postgres clusters must meet -all the requirements for [pg_upgrade](https://www.postgresql.org/docs/current/pgupgrade.html#id-1.9.5.12.7.). - -Additionally, don't use `pgd node upgrade` if other tools are using replication slots and replication origins. -Only PGD slots and origins are restored after the upgrade. - -You must meet several prerequisites for `pgd node upgrade`: - -- Disconnect applications using the old Postgres cluster. You can, for example, - redirect them to another node in the PGD cluster. -- Configure peer authentication for both Postgres clusters. bdr_pg_upgrade - requires peer authentication. -- The same PGD version must be installed on both clusters. -- The PGD version must be 4.1.0 or later. Version 3.7.22 and later is also supported. -- The new cluster must be in a shutdown state. -- You must install PGD packages in the new cluster. -- The new cluster must already be initialized and configured as needed to - match the old cluster configuration. -- Databases, tables, and other objects must not exist in the new cluster. - -!!! Note -When upgrading to PGD 5.7.0+, you don't need to have both clusters run the same PGD version. -The new cluster must be running 5.7.0+. -In that case `pgd node upgrade` will upgrade the PGD version to 5.7.x and upgrade the Postgres major version. -!!! - -We also recommend having the old Postgres cluster up prior to running `pgd node upgrade`. -The CLI starts the old Postgres cluster if it's shut down. - -## Usage - -To upgrade to a newer major version of Postgres or Postgres and PGD, you must first install the new version packages. - -### `pgd node upgrade` command-line - -`pgd node upgrade` passes all parameters to pg_upgrade. -Therefore, you can specify any parameters supported by [pg_upgrade](https://www.postgresql.org/docs/current/pgupgrade.html#id-1.9.5.12.6). - -#### Synopsis - -```plaintext -pgd node upgrade [OPTION] ... -``` - -#### Options - -In addition to the options for pg_upgrade, you can pass the following parameters -to `pgd node upgrade`. - -##### Required parameters - -Specify these parameters either in the command line or, for all but the `--database` parameter, in their equivalent environment variable. They're used by `pgd node upgrade`. - -- `-b, --old-bindir` — Old Postgres cluster bin directory. -- `-B, --new-bindir`— New Postgres cluster bin directory. -- `-d, --old-datadir` — Old Postgres cluster data directory. -- `-D, --new-datadir` — New Postgres cluster data directory. -- `--database` — PGD database name. - -##### Optional parameters - -These parameters are optional and are used by `pgd node upgrade`: - -- `-p, --old-port` — Old cluster port number. -- `-s, --socketdir` — Directory to use for postmaster sockets during upgrade. -- `--check` — Specify to only perform checks and not modify clusters. - -##### Other parameters - -Any other parameter that's not one of the above is passed to pg_upgrade. pg_upgrade accepts the following parameters: - -- `-j, --jobs` — Number of simultaneous processes or threads to use. -- `-k, --link` — Use hard links instead of copying files to the new cluster. -- `-o, --old-options` — Option to pass to old postgres command. Multiple invocations are appended. -- `-O, --new-options` — Option to pass to new postgres command. Multiple invocations are appended. -- `-N, --no-sync` — Don't wait for all files in the upgraded cluster to be written to disk. -- `-P, --new-port` — New cluster port number. -- `-r, --retain` — Retain SQL and log files even after successful completion. -- `-U, --username` — Cluster's install user name. -- `--clone` — Use efficient file cloning. - -#### Environment variables - -You can use these environment variables in place of command-line parameters: - -- `PGBINOLD` — Old Postgres cluster bin directory. -- `PGBINNEW` — New Postgres cluster bin directory. -- `PGDATAOLD` — Old Postgres cluster data directory. -- `PGDATANEW` — New Postgres cluster data directory. -- `PGPORTOLD` — Old Postgres cluster port number. -- `PGSOCKETDIR` — Directory to use for postmaster sockets during upgrade. - - -### Example - -Given a scenario where: - -- Node name of the cluster you want to upgrade is kaolin. -- Old Postgres cluster bin directory is `/usr/lib/postgresql/16/bin`. -- New Postgres cluster bin directory is `/usr/lib/postgresql/17/bin`. -- Old Postgres cluster data directory is `/var/lib/postgresql/16/main`. -- New Postgres cluster data directory is `/var/lib/postgresql/17/main`. -- Database name is `bdrdb`. - - -You can use the following command to upgrade the cluster: - -``` -pgd node kaolin upgrade \ ---old-bindir /usr/lib/postgresql/16/bin \ ---new-bindir /usr/lib/postgresql/17/bin \ ---old-datadir /var/lib/postgresql/16/main \ ---new-datadir /var/lib/postgresql/17/main \ ---database bdrdb -``` - -### Steps performed - -These steps are performed when running `pgd node upgrade`. - -!!! Note - When `--check` is supplied as an argument to `pgd node upgrade`, the CLI skips steps that modify the database. - -#### PGD Postgres checks - - -| Steps | `--check` supplied | -| :-----------------------------------------------|:------------------:| -| Collecting pre-upgrade new cluster control data | `run` | -| Checking new cluster state is shutdown | `run` | -| Checking PGD versions | `run` | -| Starting old cluster (if shutdown) | `skip` | -| Connecting to old cluster | `skip` | -| Checking if bdr schema exists | `skip` | -| Turning DDL replication off | `skip` | -| Terminating connections to database | `skip` | -| Waiting for all slots to be flushed | `skip` | -| Disconnecting from old cluster | `skip` | -| Stopping old cluster | `skip` | -| Starting old cluster with PGD disabled | `skip` | -| Connecting to old cluster | `skip` | -| Collecting replication origins | `skip` | -| Collecting replication slots | `skip` | -| Disconnecting from old cluster | `skip` | -| Stopping old cluster | `skip` | - -#### pg_upgrade steps - -Standard pg_upgrade steps are performed. - -!!! Note - If supplied, `--check` is passed to pg_upgrade. - - -#### PGD post-upgrade steps - -| Steps | `--check` supplied | -| :-----------------------------------------------|:------------------:| -| Collecting old cluster control data | `skip` | -| Collecting new cluster control data | `skip` | -| Advancing LSN of new cluster | `skip` | -| Starting new cluster with PGD disabled | `skip` | -| Connecting to new cluster | `skip` | -| Creating replication origin, repeated for each origin | `skip` | -| Advancing replication origin, repeated for each origin | `skip` | -| Creating replication slot, repeated for each slot | `skip` | -| Stopping new cluster | `skip` | diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/manual_overview.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/manual_overview.mdx deleted file mode 100644 index 839dedee2a5..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/manual_overview.mdx +++ /dev/null @@ -1,228 +0,0 @@ ---- -title: "Upgrading PGD clusters manually" ---- - -Because EDB Postgres Distributed consists of multiple software components, -the upgrade strategy depends partially on the components that are being upgraded. - -In general, you can upgrade the cluster with almost zero downtime by -using an approach called *rolling upgrade*. Using this approach, nodes are upgraded one by one, and -the application connections are switched over to already upgraded nodes. - -You can also stop all nodes, perform the upgrade on all nodes, and -only then restart the entire cluster. This approach is the same as with a standard PostgreSQL setup. -This strategy of upgrading all nodes at the same time avoids running with -mixed versions of software and therefore is the simplest. However, it incurs -downtime and we don't recommend it unless you can't perform the rolling upgrade -for some reason. - -To upgrade an EDB Postgres Distributed cluster: - -1. Plan the upgrade. -2. Prepare for the upgrade. -3. Upgrade the server software. -4. Check and validate the upgrade. - -## Upgrade planning - -There are broadly two ways to upgrade each node: - -* Upgrade nodes in place to the newer software version. See [Rolling server - software upgrades](#rolling-server-software-upgrades). -* Replace nodes with ones that have the newer version installed. See [Rolling - upgrade using node join](#rolling-upgrade-using-node-join). - -You can use both of these approaches in a rolling manner. - -### Rolling upgrade considerations - -While the cluster is going through a rolling upgrade, mixed versions of software -are running in the cluster. For example, suppose nodeA has PGD 4.3.6, while -nodeB and nodeC have 5.6.1. In this state, the replication and group -management uses the protocol and features from the oldest version (4.3.6 -in this example), so any new features provided by the newer version -that require changes in the protocol are disabled. Once all nodes are -upgraded to the same version, the new features are enabled. - -Similarly, when a cluster with WAL-decoder-enabled nodes is going through a -rolling upgrade, WAL decoder on a higher version of PGD node produces -[logical change records (LCRs)](../decoding_worker/#enabling) with a -higher pglogical version. WAL decoder on a lower version of PGD node produces -LCRs with a lower pglogical version. As a result, WAL senders on a higher version -of PGD nodes aren't expected to use LCRs due to a mismatch in protocol -versions. On a lower version of PGD nodes, WAL senders can continue to use LCRs. -Once all the PGD nodes are on the same PGD version, WAL senders use LCRs. - -A rolling upgrade starts with a cluster with all nodes at a prior release. It -then proceeds by upgrading one node at a time to the newer release, until all -nodes are at the newer release. There must be no more than two versions of the -software running at the same time. An upgrade must be completed, with all nodes -fully upgraded, before starting another upgrade. - -Where additional caution is required to reduce business risk, more time may be required to perform an upgrade. -For maximum caution and to reduce the time required upgrading production systems, we suggest performing the upgrades in a separate test environment first. - -Don't run with mixed versions of the software for any longer than is absolutely necessary to complete the upgrade. -You can check on the versions in the cluster using the [`pgd nodes list --versions`](/pgd/5.8/cli/command_ref/nodes/list/) command. - -The longer you run with mixed versions, the more likely you are to encounter issues, the more difficult it is to diagnose and resolve them. -We recommend upgrading in off peak hours for your business, and over a short period of time. - -While you can use a rolling upgrade for upgrading a major version of the software, we don't support mixing PostgreSQL, EDB Postgres Extended, and EDB Postgres Advanced Server in one cluster. So you can't use this approach to change the Postgres variant. - -!!! Warning - Downgrades of EDB Postgres Distributed aren't supported. They require - that you manually rebuild the cluster. - -### Rolling server software upgrades - -A rolling upgrade is where the [server software -upgrade](#server-software-upgrade) is upgraded sequentially on each node in a -cluster without stopping the cluster. Each node is temporarily stopped from -participating in the cluster and its server software is upgraded. Once updated, it's -returned to the cluster, and it then catches up with the cluster's activity -during its absence. - -The actual procedure depends on whether the Postgres component is being -upgraded to a new major version. - -During the upgrade process, you can switch the application over to a node -that's currently not being upgraded to provide continuous availability of -the database for applications. - -### Rolling upgrade using node join - -The other method to upgrade the server software is to join a new node -to the cluster and later drop one of the existing nodes running -the older version of the software. - -For this approach, the procedure is always the same. However, because it -includes node join, a potentially large data transfer is required. - -Take care not to use features that are available only in -the newer Postgres version until all nodes are upgraded to the -newer and same release of Postgres. This is especially true for any -new DDL syntax that was added to a newer release of Postgres. - -!!! Note - `bdr_init_physical` makes a byte-by-byte copy of the source node - so you can't use it while upgrading from one major Postgres version - to another. In fact, currently `bdr_init_physical` requires that even the - PGD version of the source and the joining node be exactly the same. - You can't use it for rolling upgrades by way of joining a new node method. Instead, use a logical join. - -### Upgrading a CAMO-enabled cluster - -Upgrading a CAMO-enabled cluster requires upgrading CAMO groups one by one while -disabling the CAMO protection for the group being upgraded and reconfiguring it -using the new [commit scope](../commit-scopes/commit-scopes)-based settings. - -We recommended the following approach for upgrading two BDR nodes that -constitute a CAMO pair from BDR 4.x to PGD 6.0: - -1. Ensure `bdr.enable_camo` remains `off` for transactions on any of - the two 4.x nodes, or redirect clients away from the two 4.x nodes. Removing - the CAMO pairing while attempting to use CAMO leads to errors - and prevents further transactions. -1. Uncouple the pair by deconfiguring CAMO by using `bdr.remove_camo_pair`. -1. Upgrade the two nodes to PGD 6.0. -1. Create a dedicated node group for the two nodes and move them into - that node group. -1. Create a [commit scope](../commit-scopes/commit-scopes) for this node - group and thus the pair of nodes to use CAMO. -1. Reactivate CAMO protection again either by setting a - `default_commit_scope` or by changing the clients to explicitly set - `bdr.commit_scope`. -1. If necessary, allow clients to connect to the CAMO-protected nodes - again. - -## Upgrade preparation - -Each major release of the software contains several changes that might affect -compatibility with previous releases. These might affect the Postgres -configuration, deployment scripts, as well as applications using PGD. We -recommend considering these changes and making any needed adjustments in advance of the upgrade. - -See individual changes mentioned in the [release notes](../rel_notes/) and any version-specific upgrade notes. - -## Server software upgrade - -Upgrading EDB Postgres Distributed on individual nodes happens in place. -You don't need to back up and restore when upgrading the BDR extension. - -### BDR extension upgrade - -The BDR extension upgrade process consists of a few steps. - -#### Stop Postgres - -During the upgrade of binary packages, it's usually best to stop the running -Postgres server first. Doing so ensures that mixed versions don't get loaded in case -of an unexpected restart during the upgrade. - -#### Upgrade packages - -The first step in the upgrade is to install the new version of the BDR packages. This installation -installs both the new binary and the extension SQL script. This step is specific to the operating system. - -#### Start Postgres - -Once packages are upgraded, you can start the Postgres instance. The BDR -extension is upgraded upon start when the new binaries -detect the older version of the extension. - -### Postgres upgrade - -The process of in-place upgrade of Postgres depends on whether you're -upgrading to a new minor version of Postgres or to a new major version of Postgres. - -#### Minor version Postgres upgrade - -Upgrading to a new minor version of Postgres is similar to [upgrading -the BDR extension](#bdr-extension-upgrade). Stopping Postgres, upgrading packages, -and starting Postgres again is typically all that's needed. - -However, sometimes more steps, like reindexing, might be recommended for -specific minor version upgrades. Refer to the release notes of the -version of Postgres you're upgrading to. - -#### Major version Postgres upgrade - -Upgrading to a new major version of Postgres is more complicated than upgrading to a minor version. - -EDB Postgres Distributed provides a `pgd node upgrade` command line utility, -which you can use to do [in-place Postgres major version upgrades](inplace_upgrade). - -!!! Note - When upgrading to a new major version of any software, including Postgres, the - BDR extension, and others, it's always important to ensure - your application is compatible with the target version of the software you're upgrading. - -## Upgrade check and validation - -After you upgrade your PGD node, you can verify the current -version of the binary: - -```sql -SELECT bdr.bdr_version(); -``` - -Always check your [monitoring](../monitoring) after upgrading a node to confirm -that the upgraded node is working as expected. - -## Moving from HARP to PGD Proxy - -HARP can temporarily coexist with the new -[connection management](../routing) configuration. This means you can: - -- Upgrade a whole pre-5 cluster to a PGD 5 cluster. -- Set up the connection routing. -- Replace HARP Proxy with PGD Proxy. -- Move application connections to PGD Proxy instances. -- Remove the HARP Manager from all servers. - -We strongly recommend doing this as soon as possible after upgrading nodes to -PGD 5. HARP isn't certified for long-term use with PGD 5. - -TPA provides some useful tools for this and will eventually provide a single-command -upgrade path between PGD 4 and PGD 5. diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/tpa_overview.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/tpa_overview.mdx deleted file mode 100644 index e8f60c80300..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/tpa_overview.mdx +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: Upgrading PGD clusters with TPA ---- - -!!! Note No Postgres major version upgrades -TPA doesn't currently support major version upgrades of Postgres. - -To perform a major version upgrade of Postgres, see [In-place Postgres major version upgrades](inplace_upgrade). -!!! - -If you used TPA to install your cluster, you can also use TPA to upgrade it. The techniques outlined here can perform minor and major version upgrades of the PGD software. They can also perform minor version upgrades of Postgres. - -You can read more about the capabilities of TPA upgrades in [Upgrading your cluster](/tpa/latest/tpaexec-upgrade/) in the TPA documentation. - -!!! Warning Always test first -Always test upgrade processes in a QA environment first. This helps to ensure that there are no unexpected factors to take into account. TPA's ability to reproducibly deploy a PGD configuration makes it much easier to build a test environment to work with. -!!! - -## Minor and major PGD upgrades - -TPA automatically manages minor version upgrades of PGD. - -Major version upgrades of PGD require changes to the TPA `config.yml` file, which contains the deployment configuration. - -When upgrading to PGD 5 from previous PGD major versions, you can use [`tpaexec reconfigure`](/tpa/latest/reference/tpaexec-reconfigure/). This command helps you make appropriate modifications to your deployment configuration. - -The `reconfigure` command requires settings for architecture (the only supported setting is `PGD_Always_ON`) and PGD Proxy routing (`--pgd-proxy-routing `) to run. Remember to back up your deployment configuration before running, and use the `--describe` and `--output` options to preview the reconfiguration. - -## Prerequisites - -* You need the cluster configuration directory created when TPA deployed your PGD cluster. - -* If performing a major version upgrade of PGD, ensure that `tpaexec reconfigure` was run and [appropriate configuration changes](#minor-and-major-pgd-upgrades) were made. - - -## Upgrading - -Run: - -``` -tpaexec upgrade clustername -``` - -Where `clustername` is the name of the cluster and the path to the cluster configuration directory. By default, TPA upgrades each node of the cluster to the latest minor versions of the software the nodes were configured with. - - -## TPA's automated rolling upgrade procedure - -TPA first tests the cluster and then the nodes. - -Each node is then isolated from the cluster, upgraded, and returned to operation within the cluster. - -### TPA upgrades - step by step - -* Checks that all preconditions for upgrading the cluster are met. -* For each instance in the cluster: - * Checks that it has the correct repositories configured. - * Checks that the required Postgres packages are available in those repositories. - * For each BDR node in the cluster, one at a time: - * Fences the node off to ensure that pgd-proxy doesn't send any connections to it. - * Stops, updates, and restarts Postgres. - * Unfences the node so it can receive connections again. - * Updates pgbouncer, pgd-proxy, and pgd-cli, as applicable for this node. diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/upgrade_paths.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/upgrade_paths.mdx deleted file mode 100644 index 6292bb1033f..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/upgrade_paths.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Supported PGD upgrade paths ---- - -## Upgrading within version 5 - -EDB Postgres Distributed uses [semantic versioning](https://semver.org/). -All changes within the same major version are backward compatible, lowering the risk when upgrading and allowing you to choose any later minor or patch release as the upgrade target. - -You can upgrade from any version 5.x release to a later 5.x release. - -## Upgrading from version 4 to version 5 - -Upgrades from PGD 4 to PGD 5 are supported from version 4.3.0. For earlier -versions, upgrade to 4.3.0 before upgrading to 5. See [Upgrading within -4](/pgd/4/upgrades/upgrade_paths/#upgrading-within-version-4) for more -information. - -Generally, we recommend that you upgrade to the latest version 4 -release before upgrading to the latest version 5 release. After upgrading to -4.3.0 or later, the following upgrade paths are possible. - -| From version | To version | -| ---- | -- | -| 4.3.0 | 5.0.0 or later | -| 4.3.1 | 5.1.0 or later | -| 4.3.2 | 5.1.0 or later | -| 4.3.3 | 5.1.0 or later | -| 4.3.7 | 5.7.0 or later | - -## Upgrading from version 3.7 to version 5 - -Starting with version 3.7.23, you can upgrade directly to version 5.3.0 or later. -For earlier versions, upgrade to 3.7.23 before upgrading to 5. -See [Upgrading within version 3.7](/pgd/3.7/bdr/upgrades/supported_paths/#upgrading-within-version-37) -for more information. diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/upgrading_major_rolling.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/upgrading_major_rolling.mdx deleted file mode 100644 index 795dd661426..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sop/upgrades/upgrading_major_rolling.mdx +++ /dev/null @@ -1,622 +0,0 @@ ---- -title: Performing a Postgres major version rolling upgrade on a PGD cluster -navTitle: Rolling Postgres major version upgrade -deepToC: true -redirects: - - /pgd/latest/install-admin/admin-tpa/upgrading_major_rolling/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-tpa/upgrading_major_rolling/ #generated for pgd deploy-config-planning reorg ---- - -## Upgrading Postgres major versions - -Upgrading a Postgres database's major version to access improved features, performance enhancements, and security updates is a common administration task. -Doing the same for an EDB Postgres Distributed (PGD) cluster is essentially the same process but performed as a rolling upgrade. - -The rolling upgrade process allows updating individual cluster nodes to a new major Postgres version while maintaining cluster availability and operational continuity. -This approach minimizes downtime and ensures data integrity by allowing the rest of the cluster to remain operational as each node is upgraded sequentially. - -The following overview of the general instructions and [worked example](#worked-example) help to provide a smooth and controlled upgrade process. - -!!!Note -The following overview and worked example assume you're upgrading to or from 5.7.0+. -For upgrading to older versions of PGD, you need to use the command `bdr_pg_upgrade`, which has almost the same behavior and requirements as `pgd node upgrade`. -The only difference is that with `bdr_pg_upgrade` you can only upgrade major versions of Postgres (community/PGE/EDB Postgres Advanced Server), but with `pgd node upgrade` you can upgrade major versions of PGD and Postgres at once. -!!! - -### Prepare the upgrade - -To prepare for the upgrade, identify the subgroups and nodes you're trying to upgrade and note an initial upgrade order. - -To do this, connect to one of the nodes using SSH and run the `pgd nodes list` command: - -```bash -sudo -u postgres pgd nodes list -``` - -The `pgd nodes list` command shows you all the nodes in your PGD cluster and the subgroup to which each node belongs. -Then you want to find out which node is the write leader in each subgroup: - -```bash -sudo -u postgres pgd group show --summary -``` - -This command shows you information about the pgd group tokened by your `` running in your cluster, including which node is the write leader. -To maintain operational continuity, you need to switch write leaders over to another node in their subgroup before you can upgrade them. -To keep the number of planned switchovers to a minimum, when upgrading a subgroup of nodes, upgrade the writer leaders last. - -Even though you verified which node is the current write leader for planning purposes, the write leader of a subgroup could change to another node at any moment for operational reasons before you upgrade that node. -Therefore, you still need to verify that a node isn't the write leader just before upgrading that node. - -You now have enough information to determine your upgrade order, one subgroup at a time, aiming to upgrade the identified write leader node last in each subgroup. - -### Perform the upgrade on each node - -!!! Note -To help prevent data loss, before starting the upgrade process, ensure that your databases and configuration files are backed up. -!!! - -Using the [preliminary order](#prepare-the-upgrade), perform the following steps on each node while connected via SSH: - -* **Confirm the current Postgres version** - * View versions from PGD: - - `sudo -u postgres pgd nodes list --versions`. - * Ensure that the expected major version is running. - - -* **Verify that the target node isn't the write leader** - * Check whether the target node is the write leader for the group you're upgrading: - - `sudo -u postgres pgd group show --summary` - * If the target node is the current write leader for the group/subgroup you're upgrading, perform a [planned switchover](#perform-a-planned-switchover) to another node: - - `sudo -u postgres pgd group set-leader ` - - -* **Stop Postgres on the target node** - * Stop the Postgres service on the current node: - - `sudo systemctl stop postgres` - - The target node is no longer actively participating as a node in the cluster. - - -* **Install PGD and utilities** - * Install PGD and its utilities compatible with the Postgres version you're upgrading to: - - `sudo apt install edb-bdr5-pg edb-bdr-utilities` - -* **Initialize the new Postgres instance** - * Create a directory to house the database files for the new version of PostgreSQL: - - `sudo mkdir -p /opt/postgres/datanew` - * Ensure that the user postgres has ownership permissions to the directory using `chown`. - * Initialize a new PostgreSQL database cluster in the directory you just created. This step involves using the `initdb` command provided by the newly installed version of PostgreSQL. - Include the `--data-checksums` flag to ensure the cluster uses data checksums. - - `sudo -u postgres /initdb -D /opt/postgres/datanew --data-checksums` - - Replace `` with the path to the bin directory of the newly installed PostgreSQL version. - - You may need to run this command as the postgres user or another user with appropriate permissions. - -* **Migrate configuration to the new Postgres version** - * Locate the following configuration files in your current PostgreSQL data directory: - * `postgresql.conf` — The main configuration file containing settings related to the database system. - * `postgresql.auto.conf`— Contains settings set by PostgreSQL, such as those modified by the `ALTER SYSTEM` command. - * `pg_hba.conf` — Manages client authentication, specifying which users can connect to which databases from which hosts. - * The entire `conf.d` directory (if present) — Allows for organizing configuration settings into separate files for better manageability. - * Copy these files and the `conf.d` directory to the new data directory you created for the upgraded version of PostgreSQL. - - -* **Verify the Postgres service is inactive** - * Before proceeding, it's important to ensure that no PostgreSQL processes are active for both the old and the new data directories. This verification step prevents any data corruption or conflicts during the upgrade process. - - Use the `sudo systemctl status postgres` command to verify that Postgres was stopped. If it isn't stopped, run `systemctl stop postgres` and verify again that it was stopped. - - -* **Swap PGDATA directories for version upgrade** - * Rename `/opt/postgres/data` to `/opt/postgres/dataold` and `/opt/postgres/datanew` to `/opt/postgres/data`. - - This step readies your system for the next crucial phase: running pgd node upgrade to finalize the PostgreSQL version transition. - - -* **Verify upgrade feasibility** - * The `pgd node upgrade` tool offers a `--check` option designed to perform a preliminary scan of your current setup, identifying any potential issues that could hinder the upgrade process. - - You need to run this check from an upgrade directory with ownership given to user postgres, such as `/home/upgrade/`, so that the upgrade log files created by `pgd node upgrade` can be stored. - To initiate the safety check, append the `--check` option to your `pgd node upgrade` command. - - This operation simulates the upgrade process without making any changes, providing insights into any compatibility issues, deprecated features, or configuration adjustments required for a successful upgrade. - * Address any warnings or errors indicated by this check to ensure an uneventful transition to the new version. - - -* **Execute the Postgres major version upgrade** - * Execute the upgrade process by running the `pgd node upgrade` command without the `--check` option. - * It's essential to monitor the command output for any errors or warnings that require attention. - * The time the upgrade process take depends on the size of your database and the complexity of your setup. - - -* **Update the Postgres service configuration** - * Update the service configuration to reflect the new PostgreSQL version by updating the version number in the `postgres.service` file: - - `sudo sed -i -e 's///g' /etc/systemd/system/postgres.service` - * Refresh the system's service manager to apply these changes: - - `sudo systemctl daemon-reload` - - -* **Restart Postgres** - * Proceed to restart the PostgreSQL service: - - `systemctl start postgres` - - -* **Validate the new Postgres version** - * Verify that your PostgreSQL instance is now upgraded: - - `sudo -u postgres pgd nodes list --versions` - - -* **Clean up post-upgrade** - * Run `vacuumdb` with the `ANALYZE` option immediately after the upgrade but before introducing a heavy production load. Running this command minimizes the immediate performance impact, preparing the database for more accurate testing. - * Remove the old version's data directory, `/opt/postgres/dataold`. - - -The worked example that follows shows upgrading the Postgres major version from 16 to 17 on a PGD 5 cluster deployed with TPA in detail. - -## Worked example - -This worked example starts with a TPA-managed PGD cluster deployed using the [AWS quick start](/pgd/latest/quickstart/quick_start_aws/), which create Debian OS nodes. The cluster has three nodes: kaboom, kaolin, and kaftan, all running Postgres 16. - -This example starts with the node named `kaboom`. - -!!! Note -Some steps of this process involve running commands as the Postgres owner. We refer to this user as postgres throughout, when appropriate. If you're running EDB Postgres Advanced Server, substitute the postgres user with enterprisedb in all relevant commands. -!!! - -### Confirm the current Postgres version - -SSH into kaboom to confirm the major version of Postgres is expected: - -```bash -sudo -u postgres pgd nodes list --versions -``` - -The output will be similar to this for your cluster: - -``` -Node Name BDR Version Postgres Version ---------- ------------------------------ -------------------------------- -kaboom 5.7.0-dev (snapshot 8516bb3ab) 16.6 (Debian 16.6-1EDB.bullseye) -kaftan 5.7.0-dev (snapshot 8516bb3ab) 16.6 (Debian 16.6-1EDB.bullseye) -kaolin 5.7.0-dev (snapshot 8516bb3ab) 16.6 (Debian 16.6-1EDB.bullseye) - -``` - -Confirm that the Postgres version is the expected version. - -### Verify that the target node isn't the write leader - -The cluster must be available throughout the process (that is, a *rolling* upgrade). There must always be an available write leader to maintain continuous cluster availability. -So, if the target node is the current write leader, you must [perform a planned switchover](#perform-a-planned-switchover) of the [write leader](/pgd/latest/terminology/#write-leader) node before upgrading it so that a write leader is always available. - -While connected via SSH to kaboom, see which node is the current write leader of the group you're upgrading using the `pgd group show --summary` command: - -```bash -sudo -u postgres pgd group dc1_subgroup show --summary -``` - -In this case, you can see that kaboom is the current write leader of the sole subgroup `dc1_subgroup`: - -``` -Group Property Value ------------------ ------------ -Group Name dc1_subgroup -Parent Group Name democluster -Group Type data -Write Leader kaboom -Commit Scope -``` - -So you must perform a planned switchover of the write leader of `dc1_subgroup` to another node in the cluster. - -#### Perform a planned switchover - -Change the write leader to kaftan so kaboom's Postgres instance can be stopped: - -```bash -sudo -u postgres pgd group dc1_subgroup set-leader kaftan -``` - -After the switchover is successful, this message appears: - -``` -Command executed successfully -``` - -Then it's safe to stop Postgres on the target node. -Of course, if kaftan is switched back to being the write leader when you come to upgrading it, you'll need to perform another planned switchover at that time. - -### Stop Postgres on the target node - -While connected via SSH to the target node (in this case, kaboom), stop Postgres on the node by running: - -```bash -sudo systemctl stop postgres -``` - -This command halts the server on kaboom. Your cluster continues running using the other two nodes. - -### Install PGD and utilities - -Next, install the new version of Postgres (PG16) and the upgrade tool: - -```bash -sudo apt install edb-bdr5-pg17 edb-bdr-utilities -``` - -### Initialize the new Postgres instance - -Make a new data directory for the upgraded Postgres, and give the postgres user ownership of the directory: - -```bash -sudo mkdir /opt/postgres/datanew -sudo chown -R postgres:postgres /opt/postgres/datanew -``` - -Then, initialize Postgres 17 in the new directory: - -```bash -sudo -u postgres /usr/lib/postgresql/17/bin/initdb \ - -D /opt/postgres/datanew \ - -E UTF8 \ - --lc-collate=en_US.UTF-8 \ - --lc-ctype=en_US.UTF-8 \ - --data-checksums -``` - -This command populates the PG17 data directory for configuration, `/opt/postgres/datanew`. - -### Migrate configuration to the new Postgres version - -The next step copies the configuration files from the old Postgres version (PG16) to the new Postgres version's (PG17). Configuration files reside in each version's data directory. - -Copy over the `postgresql.conf`, `postgresql.auto.conf`, and `pg_hba.conf` files and the whole `conf.d` directory: - -```bash -sudo -u postgres cp /opt/postgres/data/postgresql.conf /opt/postgres/datanew/ -sudo -u postgres cp /opt/postgres/data/postgresql.auto.conf /opt/postgres/datanew/ -sudo -u postgres cp /opt/postgres/data/pg_hba.conf /opt/postgres/datanew/ -sudo -u postgres cp -r /opt/postgres/data/conf.d/ /opt/postgres/datanew/ -``` - -### Verify the Postgres service is inactive - -Although you [previously stopped the Postgres service on the target node](#stop-postgres-on-the-target-node), kaboom, to verify it's stopped, run the `systemctl status postgres` command: - -```bash -sudo systemctl status postgres -``` - -The output of the `status` command shows that the Postgres service has stopped running: - -``` -● postgres.service - Postgres 16 (TPA) - Loaded: loaded (/etc/systemd/system/postgres.service; enabled; vendor preset: enabled) - Active: inactive (dead) since Tue 2025-02-11 18:14:25 UTC; 7min ago - Main PID: 20370 (code=exited, status=0/SUCCESS) - CPU: 11.375s - -Feb 11 18:14:25 kaboom postgres[21066]: [22-1] 2025-02-11 18:14:25 UTC [pgdproxy@10.33.217.238(194> -Feb 11 18:14:25 kaboom postgres[20372]: [24-1] 2025-02-11 18:14:25 UTC [@//:20372]: [15] LOG: che> -Feb 11 18:14:25 kaboom postgres[21067]: [22-1] 2025-02-11 18:14:25 UTC [pgdproxy@10.33.217.237(426> -Feb 11 18:14:25 kaboom postgres[21068]: [22-1] 2025-02-11 18:14:25 UTC [pgdproxy@10.33.217.237(426> -Feb 11 18:14:25 kaboom postgres[20370]: [22-1] 2025-02-11 18:14:25 UTC [@//:20370]: [23] LOG: dat> -Feb 11 18:14:25 kaboom systemd[1]: postgres.service: Succeeded. -Feb 11 18:14:25 kaboom systemd[1]: Stopped Postgres 16 (TPA). -``` - -### Swap PGDATA directories for version upgrade - -Next, swap the PG15 and PG16 data directories: - -```bash -sudo mv /opt/postgres/data /opt/postgres/dataold -sudo mv /opt/postgres/datanew /opt/postgres/data -``` - -!!! Important -If something goes wrong at some point during the procedure, you may want to roll back/revert a node to the older major version. To do this, rename directories again so that the current data directory, `/opt/postgres/data`, becomes `/opt/postgres/datafailed` and the old data directory, `/opt/postgres/dataold`, becomes the current data directory: - -```bash -sudo mv /opt/postgres/data /opt/postgres/datafailed -sudo mv /opt/postgres/dataold /opt/postgres/data -``` - -This rolls back/reverts the node to the previous major version of Postgres. -!!! - -### Verify upgrade feasibility - -The `pgd node upgrade` tool has a `--check` option, which performs a dry run of some of the upgrade process. You can use this option to ensure the upgrade goes smoothly. - -However, first, you need a directory for the files created by `pgd node upgrade`. For this example, create an `/upgrade` directory in the `/home` directory. Then give ownership of the directory to the user postgres. - -```bash -sudo mkdir /home/upgrade -sudo chown postgres:postgres /home/upgrade -``` - -Next, navigate to `/home/upgrade` and run: - -```bash -sudo -u postgres pgd node kaboom upgrade \ - --old-bindir /usr/lib/postgresql/16/bin/ \ - --new-bindir /usr/lib/postgresql/17/bin/ \ - --old-datadir /opt/postgres/dataold/ \ - --new-datadir /opt/postgres/data/ \ - --database bdrdb \ - --username postgres \ - --check -``` - -The following is the output: - -``` -Performing BDR Postgres Checks ------------------------------- -Getting old PG instance shared directory ok -Getting new PG instance shared directory ok -Collecting pre-upgrade new PG instance control data ok -Checking new cluster state is shutdown ok -Checking BDR extension versions ok -Checking Postgres versions ok - -Finished BDR pre-upgrade steps, calling pg_upgrade --------------------------------------------------- - -Performing Consistency Checks ------------------------------ -Checking cluster versions ok -Checking database user is the install user ok -Checking database connection settings ok -Checking for prepared transactions ok -Checking for contrib/isn with bigint-passing mismatch ok -Checking data type usage ok -Checking for presence of required libraries ok -Checking database user is the install user ok -Checking for prepared transactions ok -Checking for new cluster tablespace directories ok - -*Clusters are compatible* -``` - -!!! Note -If you didn't initialize Postgres 17 with checksums using the `--data-checksums` option but did initialize checksums with your Postgres 16 instance, an error tells you about the incompatibility: - -```bash -old cluster uses data checksums but the new one does not -``` -!!! - -### Execute the Postgres major version upgrade - -You're ready to run the upgrade. On the target node, run: - -```bash -sudo -u postgres pgd node kaboom upgrade \ - --old-bindir /usr/lib/postgresql/16/bin/ \ - --new-bindir /usr/lib/postgresql/17/bin/ \ - --old-datadir /opt/postgres/dataold/ \ - --new-datadir /opt/postgres/data/ \ - --database bdrdb \ - --username postgres -``` - -The following is the expected output: - -``` -Performing BDR Postgres Checks ------------------------------- -Getting old PG instance shared directory ok -Getting new PG instance shared directory ok -Collecting pre-upgrade new PG instance control data ok -Checking new cluster state is shutdown ok -Checking BDR extension versions ok -Checking Postgres versions ok - -Collecting Pre-Upgrade BDR Information --------------------------------------- -Collecting pre-upgrade old PG instance control data ok -Starting old PG instance ok -Connecting to the old PG instance ok -Checking for BDR extension ok -Checking BDR node name ok -Terminating connections to database ok -Waiting for all slots to be flushed ok -Disconnecting from old cluster PG instance ok -Stopping old PG instance ok -Starting old PG instance with BDR disabled ok -Connecting to the old PG instance ok -Collecting replication origins ok -Collecting replication slots ok -Disconnecting from old cluster PG instance ok -Stopping old PG instance ok - -Finished BDR pre-upgrade steps, calling pg_upgrade --------------------------------------------------- - -Performing Consistency Checks ------------------------------ -Checking cluster versions ok -Checking database user is the install user ok -Checking database connection settings ok -Checking for prepared transactions ok -Checking for contrib/isn with bigint-passing mismatch ok -Checking data type usage ok -Creating dump of global objects ok -Creating dump of database schemas - ok -Checking for presence of required libraries ok -Checking database user is the install user ok -Checking for prepared transactions ok -Checking for new cluster tablespace directories ok - -If pg_upgrade fails after this point, you must re-initdb the -new cluster before continuing. - -Performing Upgrade ------------------- -Setting locale and encoding for new cluster ok -Analyzing all rows in the new cluster ok -Freezing all rows in the new cluster ok -Deleting files from new pg_xact ok -Copying old pg_xact to new server ok -Setting oldest XID for new cluster ok -Setting next transaction ID and epoch for new cluster ok -Deleting files from new pg_multixact/offsets ok -Copying old pg_multixact/offsets to new server ok -Deleting files from new pg_multixact/members ok -Copying old pg_multixact/members to new server ok -Setting next multixact ID and offset for new cluster ok -Resetting WAL archives ok -Setting frozenxid and minmxid counters in new cluster ok -Restoring global objects in the new cluster ok -Restoring database schemas in the new cluster - ok -Copying user relation files - ok -Setting next OID for new cluster ok -Sync data directory to disk ok -Creating script to delete old cluster ok -Checking for extension updates notice - -Your installation contains extensions that should be updated -with the ALTER EXTENSION command. The file - update_extensions.sql -when executed by psql by the database superuser will update -these extensions. - -Upgrade Complete ----------------- -Optimizer statistics are not transferred by pg_upgrade. -Once you start the new server, consider running: - /usr/lib/postgresql/17/bin/vacuumdb -U postgres --all --analyze-in-stages -Running this script will delete the old cluster's data files: - ./delete_old_cluster.sh - -pg_upgrade complete, performing BDR post-upgrade steps ------------------------------------------------------- -Collecting post-upgrade old PG instance control data ok -Collecting post-upgrade new PG instance control data ok -Checking LSN of the new PG instance ok -Starting new PG instance with BDR disabled ok -Connecting to the new PG instance ok -Creating replication origin bdr_bdrdb_democluster11_kaolin ok -Advancing replication origin bdr_bdrdb_democluster11_kaol... ok -Creating replication origin pgl_writer_origin_2_1 ok -Advancing replication origin pgl_writer_origin_2_1 to 0/2... ok -Creating replication origin bdr_bdrdb_democluster11_kaftan ok -Advancing replication origin bdr_bdrdb_democluster11_kaft... ok -Creating replication origin pgl_writer_origin_4_1 ok -Advancing replication origin pgl_writer_origin_4_1 to 0/2... ok -Creating replication slot bdr_bdrdb_democluster11_kaolin ok -Creating replication slot bdr_bdrdb_democluster11_kaftan ok -Creating replication slot bdr_bdrdb_democluster11 ok -Stopping new PG instance -``` - -### Update the Postgres service configuration - -The Postgres service on the system is configured to start the old version of Postgres (PG16). You need to modify the `postgres.service` file to start the new version (PG17). - -You can do this using `sed` to replace the old version number `15` with `16` throughout the file. - -```bash -sudo sed -i -e 's/16/17/g' /etc/systemd/system/postgres.service -``` - -After you've changed the version number, you can tell the systemd daemon to reload the configuration. On the target node, run: - -```bash -sudo systemctl daemon-reload -``` - -### Restart Postgres - -Start the modified Postgres service: - -```bash -sudo systemctl start postgres -``` - -### Validate the new Postgres version - -Repeating the first step, check the version of Postgres to confirm that you upgraded kaboom correctly. While still on kaboom, run: - -```bash -sudo -u postgres pgd nodes list --versions -``` - -Use the output to confirm that kaboom is running the upgraded Postgres version: - - ``` -Node Name BDR Version Postgres Version ---------- ----------- -------------------------------- -kaboom 5.7.0 17.3 (Debian 17.3-1EDB.bullseye) -kaftan 5.7.0 16.7 (Debian 16.7-1EDB.bullseye) -kaolin 5.7.0 16.7 (Debian 16.7-1EDB.bullseye) -``` - -Here kaboom has been upgraded to major version 17. - -### Clean up post-upgrade - -As a best practice, run a vacuum over the database at this point. When the upgrade ran, you may have noticed the post-upgrade report included: - -``` -Once you start the new server, consider running: - /usr/lib/postgresql/17/bin/vacuumdb --all --analyze-in-stages -``` - -You can run the vacuum now. On the target node, run: - -```bash -sudo -u postgres /usr/lib/postgresql/17/bin/vacuumdb --all --analyze-in-stages -``` - -If you're sure you don't need to revert this node, you can also clean up the old data directory folder `dataold`: - -```bash -sudo rm -r /opt/postgres/dataold -``` - -Upgrading the target node is now complete. - -### Next steps - -After completing the upgrade on kaboom, run the same steps on kaolin and kaftan. - -If you followed along with this example and kaftan is the write leader, to ensure availability, you must [perform a planned switchover](#perform-a-planned-switchover) to another node that was already upgraded before running the upgrade steps on kaftan. - -#### Check Postgres versions across the cluster - -After completing the upgrade on all nodes, while connected to one of the nodes, you can check your versions again: - -```bash -sudo -u postgres pgd nodes list --versions -``` - -The output will be similar to the following: - - ``` -Node Name BDR Version Postgres Version ---------- ----------- -------------------------------- -kaboom 5.7.0 17.3 (Debian 17.3-1EDB.bullseye) -kaftan 5.7.0 17.3 (Debian 17.3-1EDB.bullseye) -kaolin 5.7.0 17.3 (Debian 17.3-1EDB.bullseye) - -``` - -This output shows that all the nodes are successfully upgraded to the new Postgres version 17. diff --git a/product_docs/docs/pgd/6/known_issues.mdx b/product_docs/docs/pgd/6/known_issues.mdx index 1ed8d130b78..10d58ee570a 100644 --- a/product_docs/docs/pgd/6/known_issues.mdx +++ b/product_docs/docs/pgd/6/known_issues.mdx @@ -58,8 +58,7 @@ To modify a commit scope safely, use [`bdr.alter_commit_scope`](/pgd/latest/refe ## Limitations -Take these EDB Postgres Distributed (PGD) design limitations -into account when planning your deployment. +Take these EDB Postgres Distributed (PGD) design limitations into account when planning your deployment. ### Nodes @@ -125,8 +124,109 @@ Also, there are limitations on interoperability with legacy synchronous replicat interoperability with explicit two-phase commit, and unsupported combinations within commit scope rules. -See [Durability limitations](/pgd/latest/reference/commit-scopes/limitations/) for a full -and current listing. +The following limitations apply to the use of commit scopes and the various durability options they enable. + +#### General durability limitations + +- [Legacy synchronous replication](/pgd/latest/reference/commit-scopes/legacy-sync) uses a mechanism for transaction confirmation + different from the one used by CAMO, Eager, and Group Commit. The two aren't + compatible, so don't use them together. Whenever you use Group Commit, CAMO, + or Eager, make sure none of the PGD nodes are configured in + `synchronous_standby_names`. + +- Postgres two-phase commit (2PC) transactions (that is, [`PREPARE + TRANSACTION`](https://www.postgresql.org/docs/current/sql-prepare-transaction.html)) + can't be used with CAMO, Group Commit, or Eager because those + features use two-phase commit underneath. + +#### Group Commit + +[Group Commit](/pgd/latest/reference/commit-scopes/group-commit) enables configurable synchronous commits over +nodes in a group. If you use this feature, take the following limitations into account: + +- Not all DDL can run when you use Group Commit. If you use unsupported DDL, a warning is logged, and the transactions commit scope is set to local. The only supported DDL operations are: + - Nonconcurrent `CREATE INDEX` + - Nonconcurrent `DROP INDEX` + - Nonconcurrent `REINDEX` of an individual table or index + - `CLUSTER` (of a single relation or index only) + - `ANALYZE` + - `TRUNCATE` + + +- Explicit two-phase commit isn't supported by Group Commit as it already uses two-phase commit. + +- Combining different commit decision options in the same transaction or + combining different conflict resolution options in the same transaction isn't + supported. + +- Currently, Raft commit decisions are extremely slow, producing very low TPS. + We recommended using them only with the `eager` conflict resolution setting + to get the Eager All-Node Replication behavior of PGD 4 and older. + +#### Eager + +[Eager](/pgd/latest/commit-scopes/group-commit/#eager-conflict-resolution) is available through Group Commit. It avoids conflicts by eagerly aborting transactions that might clash. It's subject to the same limitations as Group Commit. + +Eager doesn't allow the `NOTIFY` SQL command or the `pg_notify()` function. It +also doesn't allow `LISTEN` or `UNLISTEN`. + +## CAMO + +[Commit At Most Once](/pgd/latest/reference/commit-scopes/camo) (CAMO) is a feature that aims to prevent +applications committing more than once. If you use this feature, take +these limitations into account when planning: + +- CAMO is designed to query the results of a recently failed COMMIT on the +origin node. In case of disconnection, the application must request the +transaction status from the CAMO partner. Ensure that you have as little delay +as possible after the failure before requesting the status. Applications must +not rely on CAMO decisions being stored for longer than 15 minutes. + +- If the application forgets the global identifier assigned, for example, +as a result of a restart, there's no easy way to recover +it. Therefore, we recommend that applications wait for outstanding +transactions to end before shutting down. + +- For the client to apply proper checks, a transaction protected by CAMO +can't be a single statement with implicit transaction control. You also can't +use CAMO with a transaction-controlling procedure or +in a `DO` block that tries to start or end transactions. + +- CAMO resolves commit status but doesn't resolve pending +notifications on commit. CAMO doesn't +allow the `NOTIFY` SQL command or the `pg_notify()` function. +They also don't allow `LISTEN` or `UNLISTEN`. + +- When replaying changes, CAMO transactions might detect conflicts just +the same as other transactions. If timestamp-conflict detection is used, +the CAMO transaction uses the timestamp of the prepare-on-the-origin +node, which is before the transaction becomes visible on the origin +node itself. + +- CAMO isn't currently compatible with transaction streaming. +Be sure to disable transaction streaming when planning to use +CAMO. You can configure this option globally or in the PGD node group. See +[Transaction streaming configuration](/pgd/latest/reference/transaction-streaming#configuration). + +- CAMO isn't currently compatible with decoding worker. +Be sure to not enable decoding worker when planning to use +CAMO. You can configure this option in the PGD node group. See +[Decoding worker disabling](/pgd/latest/reference/decoding_worker#enabling). + +- Not all DDL can run when you use CAMO. If you use unsupported DDL, a warning is logged and the transactions commit scope is set to local only. The only supported DDL operations are: + - Nonconcurrent `CREATE INDEX` + - Nonconcurrent `DROP INDEX` + - Nonconcurrent `REINDEX` of an individual table or index + - `CLUSTER` (of a single relation or index only) + - `ANALYZE` + - `TRUNCATE` + + +- Explicit two-phase commit isn't supported by CAMO as it already uses two-phase commit. + +- You can combine only CAMO transactions with the `DEGRADE TO` clause for +switching to asynchronous operation in case of lowered availability. + ### Mixed PGD versions diff --git a/product_docs/docs/pgd/6/reference/commit-scopes/camo.mdx b/product_docs/docs/pgd/6/reference/commit-scopes/camo.mdx index 39270a4de9f..c4173b15a1f 100644 --- a/product_docs/docs/pgd/6/reference/commit-scopes/camo.mdx +++ b/product_docs/docs/pgd/6/reference/commit-scopes/camo.mdx @@ -267,7 +267,7 @@ For CAMO in `received` mode, a proxy that potentially switches between the CAMO ## CAMO limitations -CAMO limitations are covered in [Durability limitations](limitations/#camo). +CAMO limitations are covered in [Known Issues and Limitations](/pgd/latest/known-issues#camo). ## Performance implications diff --git a/product_docs/docs/pgd/6/reference/commit-scopes/group-commit.mdx b/product_docs/docs/pgd/6/reference/commit-scopes/group-commit.mdx index b5d8892da7d..932ab300704 100644 --- a/product_docs/docs/pgd/6/reference/commit-scopes/group-commit.mdx +++ b/product_docs/docs/pgd/6/reference/commit-scopes/group-commit.mdx @@ -53,7 +53,7 @@ originating per node. ## Limitations -See the Group Commit section of [Limitations](pgd/latest/known_issues#group-commit). +See the Group Commit section of [Known Issues and Limitations](/pgd/latest/known-issues#group-commit). ## Configuration @@ -127,7 +127,7 @@ transaction abort is requested. If the transaction is already decided to be committed at the time the abort request is sent, the transaction does eventually COMMIT even though the client might receive an abort message. -See also [Limitations](limitations). +See also [Limitations](/pgd/latest/known-issues#limitations). ### Transaction reconciliation diff --git a/product_docs/docs/pgd/6/reference/commit-scopes/index.mdx b/product_docs/docs/pgd/6/reference/commit-scopes/index.mdx index cf1243e92e6..9345c58edb9 100644 --- a/product_docs/docs/pgd/6/reference/commit-scopes/index.mdx +++ b/product_docs/docs/pgd/6/reference/commit-scopes/index.mdx @@ -77,10 +77,6 @@ out of sync nodes may go when a database node goes out of service. * [Administering](administering) addresses how to manage a PGD cluster with Group Commit in use. -* [Limitations](limitations) lists the various combinations of durability options -that aren't currently supported or aren't possible. Refer to this before deciding -on a durability strategy. - * [Legacy synchronous replication](legacy-sync) shows how you can still access traditional Postgres synchronous operations under PGD. * [Internal timing of operations](timing) compares legacy replication with PGD's async and synchronous operations, especially the difference in the order by which transactions are flushed to disk or made visible. diff --git a/product_docs/docs/pgd/6/reference/commit-scopes/limitations.mdx b/product_docs/docs/pgd/6/reference/commit-scopes/limitations.mdx deleted file mode 100644 index a67b71db097..00000000000 --- a/product_docs/docs/pgd/6/reference/commit-scopes/limitations.mdx +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: Limitations ---- - -The following limitations apply to the use of commit scopes and the various durability options they enable. - -## General limitations - -- [Legacy synchronous replication](legacy-sync) uses a mechanism for transaction confirmation - different from the one used by CAMO, Eager, and Group Commit. The two aren't - compatible, so don't use them together. Whenever you use Group Commit, CAMO, - or Eager, make sure none of the PGD nodes are configured in - `synchronous_standby_names`. - -- Postgres two-phase commit (2PC) transactions (that is, [`PREPARE - TRANSACTION`](https://www.postgresql.org/docs/current/sql-prepare-transaction.html)) - can't be used with CAMO, Group Commit, or Eager because those - features use two-phase commit underneath. - -## Group Commit - -[Group Commit](group-commit) enables configurable synchronous commits over -nodes in a group. If you use this feature, take the following limitations into account: - -- Not all DDL can run when you use Group Commit. If you use unsupported DDL, a warning is logged, and the transactions commit scope is set to local. The only supported DDL operations are: - - Nonconcurrent `CREATE INDEX` - - Nonconcurrent `DROP INDEX` - - Nonconcurrent `REINDEX` of an individual table or index - - `CLUSTER` (of a single relation or index only) - - `ANALYZE` - - `TRUNCATE` - - -- Explicit two-phase commit isn't supported by Group Commit as it already uses two-phase commit. - -- Combining different commit decision options in the same transaction or - combining different conflict resolution options in the same transaction isn't - supported. - -- Currently, Raft commit decisions are extremely slow, producing very low TPS. - We recommended using them only with the `eager` conflict resolution setting - to get the Eager All-Node Replication behavior of PGD 4 and older. - -## Eager - -[Eager](/pgd/latest/commit-scopes/group-commit/#eager-conflict-resolution) is available through Group Commit. It avoids conflicts by eagerly aborting transactions that might clash. It's subject to the same limitations as Group Commit. - -Eager doesn't allow the `NOTIFY` SQL command or the `pg_notify()` function. It -also doesn't allow `LISTEN` or `UNLISTEN`. - -## CAMO - -[Commit At Most Once](camo) (CAMO) is a feature that aims to prevent -applications committing more than once. If you use this feature, take -these limitations into account when planning: - -- CAMO is designed to query the results of a recently failed COMMIT on the -origin node. In case of disconnection, the application must request the -transaction status from the CAMO partner. Ensure that you have as little delay -as possible after the failure before requesting the status. Applications must -not rely on CAMO decisions being stored for longer than 15 minutes. - -- If the application forgets the global identifier assigned, for example, -as a result of a restart, there's no easy way to recover -it. Therefore, we recommend that applications wait for outstanding -transactions to end before shutting down. - -- For the client to apply proper checks, a transaction protected by CAMO -can't be a single statement with implicit transaction control. You also can't -use CAMO with a transaction-controlling procedure or -in a `DO` block that tries to start or end transactions. - -- CAMO resolves commit status but doesn't resolve pending -notifications on commit. CAMO doesn't -allow the `NOTIFY` SQL command or the `pg_notify()` function. -They also don't allow `LISTEN` or `UNLISTEN`. - -- When replaying changes, CAMO transactions might detect conflicts just -the same as other transactions. If timestamp-conflict detection is used, -the CAMO transaction uses the timestamp of the prepare-on-the-origin -node, which is before the transaction becomes visible on the origin -node itself. - -- CAMO isn't currently compatible with transaction streaming. -Be sure to disable transaction streaming when planning to use -CAMO. You can configure this option globally or in the PGD node group. See -[Transaction streaming configuration](../transaction-streaming#configuration). - -- CAMO isn't currently compatible with decoding worker. -Be sure to not enable decoding worker when planning to use -CAMO. You can configure this option in the PGD node group. See -[Decoding worker disabling](../decoding_worker#enabling). - -- Not all DDL can run when you use CAMO. If you use unsupported DDL, a warning is logged and the transactions commit scope is set to local only. The only supported DDL operations are: - - Nonconcurrent `CREATE INDEX` - - Nonconcurrent `DROP INDEX` - - Nonconcurrent `REINDEX` of an individual table or index - - `CLUSTER` (of a single relation or index only) - - `ANALYZE` - - `TRUNCATE` - - -- Explicit two-phase commit isn't supported by CAMO as it already uses two-phase commit. - -- You can combine only CAMO transactions with the `DEGRADE TO` clause for -switching to asynchronous operation in case of lowered availability. diff --git a/product_docs/docs/pgd/6/reference/conflict-management/column-level-conflicts/01_overview_clcd.mdx b/product_docs/docs/pgd/6/reference/conflict-management/column-level-conflicts/01_overview_clcd.mdx index 0e3b3810a57..1baed994f2a 100644 --- a/product_docs/docs/pgd/6/reference/conflict-management/column-level-conflicts/01_overview_clcd.mdx +++ b/product_docs/docs/pgd/6/reference/conflict-management/column-level-conflicts/01_overview_clcd.mdx @@ -25,7 +25,7 @@ UPDATE t SET b = 100 The attributes modified by an `UPDATE` are determined by comparing the old and new row in a trigger. This means that if the attribute doesn't change a value, it isn't detected as modified even if it's explicitly set. For example, `UPDATE t SET a = a` doesn't mark `a` as modified for any row. Similarly, `UPDATE t SET a = 1` doesn't mark `a` as modified for rows that are already set to `1`. !!! -This sequence results in an `UPDATE-UPDATE` conflict. With the [`update_if_newer`](../../reference/conflicts/#default-conflict-resolvers) conflict resolution, the commit timestamps are compared, and the new row version is kept. Assuming the second node committed last, the result is `(1,100)`, which effectively discards the change to column a. +This sequence results in an `UPDATE-UPDATE` conflict. With the [`update_if_newer`](/pgd/latest/reference/conflicts/#default-conflict-resolvers) conflict resolution, the commit timestamps are compared, and the new row version is kept. Assuming the second node committed last, the result is `(1,100)`, which effectively discards the change to column a. For many use cases, this behavior is desired and expected. However, for some use cases, this might be an issue. Consider, for example, a multi-node cluster where each part of the application is connected to a different node, updating a dedicated subset of columns in a shared table. In that case, the different components might conflict and overwrite changes. diff --git a/product_docs/docs/pgd/6/reference/conflict-management/conflicts/03_conflict_detection.mdx b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/03_conflict_detection.mdx index f1c9fbd42e8..c2bd4a6f801 100644 --- a/product_docs/docs/pgd/6/reference/conflict-management/conflicts/03_conflict_detection.mdx +++ b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/03_conflict_detection.mdx @@ -77,4 +77,4 @@ This approach resembles Lamport timestamps and fully prevents the ABA problem fo To determine the current conflict detection strategy used for a specific table, refer to the column `conflict_detection` of the view `bdr.tables`. -To change the current conflict detection strategy, use [bdr.alter_table_conflict_detection](../../reference/conflict_functions/#bdralter_table_conflict_detection). +To change the current conflict detection strategy, use [bdr.alter_table_conflict_detection](/pgd/latest/reference/conflict_functions/#bdralter_table_conflict_detection). diff --git a/product_docs/docs/pgd/6/reference/conflict-management/conflicts/04_conflict_resolution.mdx b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/04_conflict_resolution.mdx index f7406c36d60..19e237303e5 100644 --- a/product_docs/docs/pgd/6/reference/conflict-management/conflicts/04_conflict_resolution.mdx +++ b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/04_conflict_resolution.mdx @@ -6,4 +6,4 @@ deepToC: true Most conflicts can be resolved automatically. PGD defaults to a last-update-wins mechanism or, more accurately, the `update_if_newer` conflict resolver. This mechanism retains the most recently inserted or changed row of the two conflicting ones based on the same commit timestamps used for conflict detection. The behavior in certain corner-case scenarios depends on the settings used for `bdr.create_node_group` and alternatively for `bdr.alter_node_group`. -PGD lets you override the default behavior of conflict resolution by using [bdr.alter_node_set_conflict_resolver](../../reference/conflict_functions/#bdralter_node_set_conflict_resolver). \ No newline at end of file +PGD lets you override the default behavior of conflict resolution by using [bdr.alter_node_set_conflict_resolver](/pgd/latest/reference/conflict_functions/#bdralter_node_set_conflict_resolver). \ No newline at end of file diff --git a/product_docs/docs/pgd/6/reference/conflict-management/conflicts/05_conflict_logging.mdx b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/05_conflict_logging.mdx index bb0ff2a6414..c2bb54c37fd 100644 --- a/product_docs/docs/pgd/6/reference/conflict-management/conflicts/05_conflict_logging.mdx +++ b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/05_conflict_logging.mdx @@ -4,7 +4,7 @@ Description: How PGD logs database conflicts. deepToC: true --- -To ease diagnosing and handling multi-master conflicts, PGD, by default, logs every conflict into the `bdr.conflict_history` table. You can change this behavior with more granularity using [bdr.alter_node_set_log_config](../../reference/conflict_functions/#bdralter_node_set_log_config). +To ease diagnosing and handling multi-master conflicts, PGD, by default, logs every conflict into the `bdr.conflict_history` table. You can change this behavior with more granularity using [bdr.alter_node_set_log_config](/pgd/latest/reference/conflict_functions/#bdralter_node_set_log_config). ## Conflict reporting diff --git a/product_docs/docs/pgd/6/reference/connection-manager/monitoring.mdx b/product_docs/docs/pgd/6/reference/connection-manager/monitoring.mdx index 3c8b05b3c88..e82deaebc2b 100644 --- a/product_docs/docs/pgd/6/reference/connection-manager/monitoring.mdx +++ b/product_docs/docs/pgd/6/reference/connection-manager/monitoring.mdx @@ -12,7 +12,7 @@ The Connection Manager provides a number of tables and views that can be used to - [`bdr.stat_activity`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_activity) — which is information from `pg_stat_activity` enhanced with addition columns regarding the `connection_manager_client_addr` and `connection_manager_client_port` is the connection has come through the connection manager, and `session_read_only` if it has connected through the read-only port. - [`bdr.stat_connection_manager`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_connection_manager) — which is a view that provides statistics about the Connection Manager's status. - [`bdr.stat_connection_manager_connections`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_connection_manager_connections) — which is a view that provides statistics about the Connection Manager's connections. -- [`bdr.stat_connection_manager_nodes_stats`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_connection_manager_nodes) — which is a view that provides statistics about the Connection Manager on each of the data nodes. +- [`bdr.stat_connection_manager_node_stats`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_connection_manager_node_stats) — which is a view that provides statistics about the Connection Manager on each of the data nodes. - [`bdr.stat_connection_manager_hba_file_rules`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_connection_manager_hba_file_rules) — which is a view that shows which HBA file rules for the connection manager are being used on this node. ## Monitoring the Connection Manager diff --git a/product_docs/docs/pgd/6/reference/ddl/ddl-pgd-functions-like-ddl.mdx b/product_docs/docs/pgd/6/reference/ddl/ddl-pgd-functions-like-ddl.mdx index 7a9d6bb3066..eb6ec91eed9 100644 --- a/product_docs/docs/pgd/6/reference/ddl/ddl-pgd-functions-like-ddl.mdx +++ b/product_docs/docs/pgd/6/reference/ddl/ddl-pgd-functions-like-ddl.mdx @@ -20,7 +20,7 @@ Replication set management: Conflict management: -- [`bdr.alter_table_conflict_detection`](../reference/conflict_functions/#bdralter_table_conflict_detection) +- [`bdr.alter_table_conflict_detection`](/pgd/latest/reference/tables-views-functions/conflict_functions/#bdralter_table_conflict_detection) - `bdr.column_timestamps_enable` (deprecated; use `bdr.alter_table_conflict_detection()`) - `bdr.column_timestamps_disable` (deprecated; use `bdr.alter_table_conflict_detection()`) diff --git a/product_docs/docs/pgd/6/reference/ddl/index.mdx b/product_docs/docs/pgd/6/reference/ddl/index.mdx index 4ff76b4b9dc..4295b112247 100644 --- a/product_docs/docs/pgd/6/reference/ddl/index.mdx +++ b/product_docs/docs/pgd/6/reference/ddl/index.mdx @@ -33,5 +33,5 @@ This section looks at how DDL replication is handled in PGD. * [DDL-like PGD functions](ddl-pgd-functions-like-ddl) details the PGD functions that behave like DDL and therefore behave in a similar way and are subject to similar restrictions. -Further information on DDL replication can be found in the [PGD Reference](../reference/ddl). +Further information on DDL replication can be found in the [PGD reference](/pgd/latest/reference/tables-views-functions/ddl). diff --git a/product_docs/docs/pgd/6/reference/node_management/automatic_sync.mdx b/product_docs/docs/pgd/6/reference/node_management/automatic_sync.mdx index 937056b9386..4e8c99b8199 100644 --- a/product_docs/docs/pgd/6/reference/node_management/automatic_sync.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/automatic_sync.mdx @@ -6,11 +6,11 @@ description: Automatic synchronization in PGD. ## Auto-triggering the Sync -The BDR manager process does the auto-triggering of sync requests. When there are no updates from a node for an interval of time greater than 3 times [`bdr.replay_progress_frequency`](/pgd/6.0/reference/pgd-settings#bdrreplay_progress_frequency), it is considered to be down. +The BDR manager process does the auto-triggering of sync requests. When there are no updates from a node for an interval of time greater than 3 times [`bdr.replay_progress_frequency`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrreplay_progress_frequency), it is considered to be down. Nodes are checked for their closeness to each other. If all nodes are equally caught up, no sync is needed. If not, the node that is furthest ahead from the "down" node is chosen as a source. Once a source is determined, for each target - nodes other than the origin and source - a sync request is set up. Witness and standby nodes do not need to be targets in the sync. -The view [`bdr.sync_node_requests_summary`](/pgd/6.0/reference/catalogs-internal#bdrsync_node_requests_summary) tracks the sync requests. +The view [`bdr.sync_node_requests_summary`](/pgd/latest/reference/tables-views-functions/catalogs-internal#bdrsync_node_requests_summary) tracks the sync requests. Origin: origin node is the down node Source: source node is the node furthest ahead from origin @@ -25,7 +25,7 @@ Once a sync request is entered in the catalog, it is carried forward to completi If the source node chosen is found to be down, the manager will cancel the sync operation. This is because some other node can be up which if not furthest, is at least further ahead than some targets. And it may be used to sync the nodes. Therefore the manager will cancel all sync operations which have the down node as source, and will choose another node that is not down as the source for sync. The state machine is described below for a successful sync as well as a cancelled sync. -The sync cancellation API, [`bdr.sync_node_cancel()`](/pgd/6/reference/nodes-management-interfaces#bdrsync_node_cancel) is meant only to be used manually and only if the sync request gets stuck for any reason and is blocking normal functioning of the cluster. +The sync cancellation API, [`bdr.sync_node_cancel()`](/pgd/latest/reference/tables-views-functions/nodes-management-interfaces#bdrsync_node_cancel) is meant only to be used manually and only if the sync request gets stuck for any reason and is blocking normal functioning of the cluster. ```sql select bdr.sync_node_cancel(origin, source) @@ -51,5 +51,5 @@ A cancellation of sync can happen too automatically if the chosen source node is ## GUC -The GUC that controls automatic sync is [`bdr.enable_auto_sync_reconcile`](/pgd/6.0/reference/pgd-settings#bdrenable_auto_sync_reconcile) and it is set to true by default. To turn it off, it needs to be set to false on all nodes and the server restarted. +The GUC that controls automatic sync is [`bdr.enable_auto_sync_reconcile`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrenable_auto_sync_reconcile) and it is set to true by default. To turn it off, it needs to be set to false on all nodes and the server restarted. diff --git a/product_docs/docs/pgd/6/reference/node_management/creating_nodes.mdx b/product_docs/docs/pgd/6/reference/node_management/creating_nodes.mdx index 243d410f982..10c089a079f 100644 --- a/product_docs/docs/pgd/6/reference/node_management/creating_nodes.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/creating_nodes.mdx @@ -6,13 +6,13 @@ navTitle: Creating PGD nodes ## It's just Postgres -A PGD node is just a Postgres instance with the BDR extension installed. The BDR extension enables bidirectional replication between nodes and is the foundation of PGD. +A PGD node is just a Postgres instance with the BDR extension installed. The BDR extension enables bidirectional replication between nodes and is the foundation of PGD. That means, in the most general terms, you can create a PGD node by installing Postgres and the BDR extension, and then configuring the node to connect to the other nodes in the PGD group. But there are some specifics to consider. ## Which Postgres version? -PGD is built on top of Postgres, so the distribution and version of Postgres you use for your PGD nodes is important. The version of Postgres you use must be compatible with the version of PGD you are using. You can find the compatibility matrix in the [release notes](/pgd/latest/rel_notes). Features and functionality in PGD may depend on the distribution of Postgres you are using. The [EDB Postgres Advanced Server](/epas/latest/) is the recommended distribution for PGD. PGD also supports [EDB Postgres Extended Server](/pge/latest/) and [Community Postgres](https://www.postgresql.org/). You can find out what features are available in each distribution in the Planning section's [Choosing a server](../planning/choosing_server) page. +PGD is built on top of Postgres, so the distribution and version of Postgres you use for your PGD nodes is important. The version of Postgres you use must be compatible with the version of PGD you are using. You can find the compatibility matrix in the [release notes](/pgd/latest/rel_notes). Features and functionality in PGD may depend on the distribution of Postgres you are using. The [EDB Postgres Advanced Server](/epas/latest/) is the recommended distribution for PGD. PGD also supports [EDB Postgres Extended Server](/pge/latest/) and [Community Postgres](https://www.postgresql.org/). ## Installing Postgres @@ -20,13 +20,13 @@ You must install your selected Postgres distribution on each node you are config ## Installing the BDR extension -The BDR extension is the key to PGD's distributed architecture. You need to install the BDR extension on each node in your PGD cluster. The BDR extension is available from the EDB Postgres Distributed repository. You need to add the `postgres_distributed` repository to your package management system on Linux and then install the `edb-bdr` package. You can find the repository configuration instructions in the [PGD manual installation guide](../deploy-config/deploy-manual/deploying/03-configuring-repositories). +The BDR extension is the key to PGD's distributed architecture. You need to install the BDR extension on each node in your PGD cluster. The BDR extension is available from the EDB Postgres Distributed repository. You need to add the `postgres_distributed` repository to your package management system on Linux and then install the `edb-bdr` package. You can find the repository configuration instructions in the [PGD manual installation guide](/pgd/latest/essential-how-to/install/02-configuring-repositories). Once the repository is configured, you can install the BDR package with your package manager. The package name is `edb-pgd6-` where `` is the version of Postgres you are using. For example, if you are using Postgres 14, the package name is `edb-pgd6-14`. ### Configuring the database for PGD -This process is specific to PGD and involves configuring the Postgres instance to work with the BDR extension and adjusting various settings to work with the PGD cluster. This process is also detailed in the [PGD manual installation guide](../deploy-config/deploy-manual/deploying/04-installing-software) The steps are as follows: +This process is specific to PGD and involves configuring the Postgres instance to work with the BDR extension and adjusting various settings to work with the PGD cluster. The steps are as follows: * Add the BDR extension `$libdir/bdr` at the start of the `shared_preload_libraries` setting in `postgresql.conf`. * Set the `wal_level` GUC variable to `logical` in `postgresql.conf`. @@ -63,5 +63,5 @@ The created database should be the name of the database that other nodes in the ## Next steps The node is now configured and ready to be join a group, or start a group, in the PGD cluster. -You can find instructions for joining a node to a group in the [Joining a node to a group](/creating_and_joining) section. +You can find instructions for joining a node to a group in the [Joining a node to a group](/pgd/latest/reference/node_management/creating_and_joining) section. diff --git a/product_docs/docs/pgd/6/reference/overview/architecture-and-performance.mdx b/product_docs/docs/pgd/6/reference/overview/architecture-and-performance.mdx index 1a8d9f943a8..fbc3a9004dc 100644 --- a/product_docs/docs/pgd/6/reference/overview/architecture-and-performance.mdx +++ b/product_docs/docs/pgd/6/reference/overview/architecture-and-performance.mdx @@ -29,7 +29,7 @@ In the future, one node will be elected as the main replicator to other groups, ### Supported Postgres database servers -PGD is compatible with [PostgreSQL](https://www.postgresql.org/), [EDB Postgres Extended Server](/pge/latest), and [EDB Postgres Advanced Server](/epas/latest) and is deployed as a standard Postgres extension named BDR. See [Compatibility](../#compatibility) for details about supported version combinations. +PGD is compatible with [PostgreSQL](https://www.postgresql.org/), [EDB Postgres Extended Server](/pge/latest), and [EDB Postgres Advanced Server](/epas/latest) and is deployed as a standard Postgres extension named BDR. See [Compatibility](/pgd/latest/compatibility) for details about supported version combinations. Some key PGD features depend on certain core capabilities being available in the target Postgres database server. Therefore, PGD users must also adopt the Postgres database server distribution that's best suited to their business needs. For example, if having the PGD feature Commit At Most Once (CAMO) is mission critical to your use case, don't adopt the community PostgreSQL distribution. It doesn't have the core capability required to handle CAMO. See the full feature matrix compatibility in [Choosing a Postgres distribution](../planning/choosing_server/). diff --git a/product_docs/docs/pgd/6/reference/sequences.mdx b/product_docs/docs/pgd/6/reference/sequences.mdx index 38d62ff09d0..fc2bee16929 100644 --- a/product_docs/docs/pgd/6/reference/sequences.mdx +++ b/product_docs/docs/pgd/6/reference/sequences.mdx @@ -71,18 +71,18 @@ determines the kind of sequence to create when the `CREATE SEQUENCE` command is executed or when a `serial`, `bigserial`, or `GENERATED BY DEFAULT AS IDENTITY` column is created. Valid settings are: -- `local` — Newly created - sequences are the standard PostgreSQL (local) sequences. -- `galloc` — Always creates globally allocated range sequences. -- `snowflakeid` — Creates global sequences for BIGINT sequences that - consist of time, nodeid, and counter components. You can't use it with - INTEGER sequences (so you can use it for `bigserial` but not for `serial`). -- `timeshard` — The older version of SnowflakeId sequence. Provided for - backward compatibility only. The SnowflakeId is preferred. -- `distributed` (default) — A special value that you can use only for - [`bdr.default_sequence_kind`](reference/pgd-settings/#global-sequence-parameters). It selects `snowflakeid` for `int8` - sequences (that is, `bigserial`) and `galloc` sequence for `int4` - (that is, `serial`) and `int2` sequences. +- `local` — Newly created + sequences are the standard PostgreSQL (local) sequences. +- `galloc` — Always creates globally allocated range sequences. +- `snowflakeid` — Creates global sequences for BIGINT sequences that + consist of time, nodeid, and counter components. You can't use it with + INTEGER sequences (so you can use it for `bigserial` but not for `serial`). +- `timeshard` — The older version of SnowflakeId sequence. Provided for + backward compatibility only. The SnowflakeId is preferred. +- `distributed` (default) — A special value that you can use only for + [`bdr.default_sequence_kind`](/pgd/latest/reference/tables-views-functions/pgd-settings/#global-sequence-parameters). It selects `snowflakeid` for `int8` + sequences (that is, `bigserial`) and `galloc` sequence for `int4` + (that is, `serial`) and `int2` sequences. The [`bdr.sequences`](/pgd/latest/reference/catalogs-visible/#bdrsequences) view shows information about individual sequence kinds. @@ -324,7 +324,7 @@ SELECT bdr.alter_sequence_set_kind('public.sequence'::regclass, 'galloc', $MAX + Since users can't lock a sequence, you must leave a `$MARGIN` value to allow operations to continue while the `max()` value is queried. -The [`bdr.sequence_alloc`](reference/catalogs-visible/#bdrsequence_alloc) table gives information on the chunk size and the +The [`bdr.sequence_alloc`](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrsequence_alloc) table gives information on the chunk size and the ranges allocated around the whole cluster. In this example, the sequence starts at `333`, and the cluster has two nodes. diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx index ce6d993770f..362db71ded8 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx @@ -143,7 +143,7 @@ This table tracks internal object dependencies inside PGD catalogs. ### `bdr.failover_replication_slots` -This table tracks the status of logical replication slots that are being used with failover support. For more information on failover replication slots, see [CDC Failover support](/pgd/latest/cdc-failover). +This table tracks the status of logical replication slots that are being used with failover support. For more information on failover replication slots, see [CDC Failover support](/pgd/latest/reference/cdc-failover). #### `bdr.failover_replication_slots` columns diff --git a/product_docs/docs/pgd/6/reference/twophase.mdx b/product_docs/docs/pgd/6/reference/twophase.mdx index d45082876f1..643620c3f85 100644 --- a/product_docs/docs/pgd/6/reference/twophase.mdx +++ b/product_docs/docs/pgd/6/reference/twophase.mdx @@ -8,7 +8,7 @@ redirects: --- !!!Note -Two-phase commit isn't available with Group Commit or CAMO. See [Commit scope limitations](commit-scopes/limitations). +Two-phase commit isn't available with Group Commit or CAMO. See [Commit scope limitations](/pgd/latest/known-issues#general-durability-limitations). !!! An application can explicitly opt to use two-phase commit with PGD. See From 24f892edbfd49eadb95cef4097c28f02cbcc8ffa Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 8 May 2025 17:56:31 +0100 Subject: [PATCH 048/145] Fixing up SOP sections Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/essential-how-to/sop/backup-restore.mdx | 3 ++- .../docs/pgd/6/essential-how-to/sop/troubleshooting.mdx | 5 +++++ product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx | 5 +++++ 3 files changed, 12 insertions(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/backup-restore.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/backup-restore.mdx index e1a57033e79..34e87d2dfcd 100644 --- a/product_docs/docs/pgd/6/essential-how-to/sop/backup-restore.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/sop/backup-restore.mdx @@ -1,5 +1,5 @@ --- -title: Backup and recovery SOPs +title: Backup and recovery description: Backup and recovery originalFilePath: backup.md redirects: @@ -7,6 +7,7 @@ redirects: - /bdr/latest/monitoring/ --- + **TODO**: Split? PGD is designed to be a distributed, highly available system. If diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/troubleshooting.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/troubleshooting.mdx index e69de29bb2d..cac5f087fe0 100644 --- a/product_docs/docs/pgd/6/essential-how-to/sop/troubleshooting.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/sop/troubleshooting.mdx @@ -0,0 +1,5 @@ +--- +title: Troubleshooting +navTitle: Troubleshooting +--- + diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx index e69de29bb2d..973efd341ea 100644 --- a/product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx @@ -0,0 +1,5 @@ +--- +title: Upgrading +navTitle: Upgrade +--- + From efaaaa02fbef465b65d1780bbc16a0b3b881e3f4 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 8 May 2025 18:49:06 +0100 Subject: [PATCH 049/145] More linky fixys Signed-off-by: Dj Walker-Morgan --- .../deploy-manual/deploying/04-installing-software.mdx | 2 +- .../production-best-practices/time-and-pgd.mdx | 2 +- product_docs/docs/pgd/6/reference/commit-scopes/camo.mdx | 4 ++-- .../docs/pgd/6/reference/commit-scopes/group-commit.mdx | 4 ++-- product_docs/docs/pgd/6/reference/ddl/index.mdx | 4 ---- .../docs/pgd/6/reference/overview/basic-architecture.mdx | 6 +++--- product_docs/docs/pgd/6/reference/twophase.mdx | 2 +- 7 files changed, 10 insertions(+), 14 deletions(-) diff --git a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/04-installing-software.mdx b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/04-installing-software.mdx index 7ca1bc1f314..39ed6634bde 100644 --- a/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/04-installing-software.mdx +++ b/product_docs/docs/pgd/5.6/deploy-config/deploy-manual/deploying/04-installing-software.mdx @@ -28,7 +28,7 @@ You must perform these steps on each host before proceeding to the next step. * Increase the maximum worker processes to 16 or higher by setting `max_worker_processes` to `'16'` in `postgresql.conf`.

!!! Note The `max_worker_processes` value The `max_worker_processes` value is derived from the topology of the cluster, the number of peers, number of databases, and other factors. - To calculate the needed value, see [Postgres configuration/settings](/pgd/latest/reference//postgres-configuration/#postgres-settings). + To calculate the needed value, see [Postgres configuration/settings](/pgd/latest/reference/postgres-configuration/#postgres-settings). The value of 16 was calculated for the size of cluster being deployed in this example. It must be increased for larger clusters. !!! * Set a password on the EnterprisedDB/Postgres user. diff --git a/product_docs/docs/pgd/6/essential-how-to/production-best-practices/time-and-pgd.mdx b/product_docs/docs/pgd/6/essential-how-to/production-best-practices/time-and-pgd.mdx index fb29a2449ca..77763893132 100644 --- a/product_docs/docs/pgd/6/essential-how-to/production-best-practices/time-and-pgd.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/production-best-practices/time-and-pgd.mdx @@ -9,5 +9,5 @@ EDB Postgres Distributed is designed to operate with nodes in multiple timezones Synchronize server clocks using NTP or other solutions. -Clock synchronization isn't critical to performance, as it is with some other solutions. Clock skew can affect origin conflict detection, though EDB Postgres Distributed provides controls to report and manage any skew that exists. EDB Postgres Distributed also provides row-version conflict detection, as described in [Conflict detection](/pgd/latest/conflict-management/conflicts/). +Clock synchronization isn't critical to performance, as it is with some other solutions. Clock skew can affect origin conflict detection, though EDB Postgres Distributed provides controls to report and manage any skew that exists. EDB Postgres Distributed also provides row-version conflict detection, as described in [Conflict detection](/pgd/latest/reference/conflict-management/conflicts/). diff --git a/product_docs/docs/pgd/6/reference/commit-scopes/camo.mdx b/product_docs/docs/pgd/6/reference/commit-scopes/camo.mdx index c4173b15a1f..cdf413d3f62 100644 --- a/product_docs/docs/pgd/6/reference/commit-scopes/camo.mdx +++ b/product_docs/docs/pgd/6/reference/commit-scopes/camo.mdx @@ -56,7 +56,7 @@ See the[`CAMO`](/pgd/latest/reference/tables-views-functions/commit-scopes/#camo ## Limitations -See the CAMO section of [Limitations](limitations#camo). +See the CAMO section of [Limitations](/pgd/latest/known_issues/#camo). ## Failure scenarios @@ -267,7 +267,7 @@ For CAMO in `received` mode, a proxy that potentially switches between the CAMO ## CAMO limitations -CAMO limitations are covered in [Known Issues and Limitations](/pgd/latest/known-issues#camo). +CAMO limitations are covered in [Known Issues and Limitations](/pgd/latest/known_issues#camo). ## Performance implications diff --git a/product_docs/docs/pgd/6/reference/commit-scopes/group-commit.mdx b/product_docs/docs/pgd/6/reference/commit-scopes/group-commit.mdx index 932ab300704..e6b55f2ddae 100644 --- a/product_docs/docs/pgd/6/reference/commit-scopes/group-commit.mdx +++ b/product_docs/docs/pgd/6/reference/commit-scopes/group-commit.mdx @@ -53,7 +53,7 @@ originating per node. ## Limitations -See the Group Commit section of [Known Issues and Limitations](/pgd/latest/known-issues#group-commit). +See the Group Commit section of [Known Issues and Limitations](/pgd/latest/known_issues/#group-commit). ## Configuration @@ -127,7 +127,7 @@ transaction abort is requested. If the transaction is already decided to be committed at the time the abort request is sent, the transaction does eventually COMMIT even though the client might receive an abort message. -See also [Limitations](/pgd/latest/known-issues#limitations). +See also [Limitations](/pgd/latest/known_issues/#general-durability-limitations). ### Transaction reconciliation diff --git a/product_docs/docs/pgd/6/reference/ddl/index.mdx b/product_docs/docs/pgd/6/reference/ddl/index.mdx index 4295b112247..5c34d0f2579 100644 --- a/product_docs/docs/pgd/6/reference/ddl/index.mdx +++ b/product_docs/docs/pgd/6/reference/ddl/index.mdx @@ -31,7 +31,3 @@ This section looks at how DDL replication is handled in PGD. * [Workarounds](ddl-workarounds) gives a range of options for handling situations where DDL replication may present restrictions, such as altering columns, constraints, and types. * [DDL-like PGD functions](ddl-pgd-functions-like-ddl) details the PGD functions that behave like DDL and therefore behave in a similar way and are subject to similar restrictions. - - -Further information on DDL replication can be found in the [PGD reference](/pgd/latest/reference/tables-views-functions/ddl). - diff --git a/product_docs/docs/pgd/6/reference/overview/basic-architecture.mdx b/product_docs/docs/pgd/6/reference/overview/basic-architecture.mdx index 623ff888963..91bc6da491b 100644 --- a/product_docs/docs/pgd/6/reference/overview/basic-architecture.mdx +++ b/product_docs/docs/pgd/6/reference/overview/basic-architecture.mdx @@ -24,10 +24,10 @@ BDR is a Postgres extension that enables a multi-master replication mesh between ![Diagram showing 3 application nodes, 3 proxy instances, and 3 PGD nodes. Traffic is being directed from each of the proxy instances to the write leader node.](./images/always_on_1x3_updated.png) 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](../commit-scopes/commit-scopes) options offer immediate consistency and durability guarantees via [CAMO](/pgd/latest/commit-scopes/camo/), [group](../commit-scopes/group-commit) and [synchronous](../commit-scopes/synchronous_commit) commits. +[Logical replication](/pgd/latest/terminology/#logical-replication) in PGD is asynchronous by default, so only eventual consistency is guaranteed (within seconds usually). +However, [commit scope](/pgd/latest/reference/commit-scopes/commit-scopes) options offer immediate consistency and durability guarantees via [CAMO](/pgd/latest/reference/commit-scopes/camo/), [group](/pgd/latest/reference/commit-scopes/group-commit) and [synchronous](/pgd/latest/reference/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 to add or subtract from the cluster. It generally ensures that the distributed system remains consistent and fault tolerant, even in the face of node failures. +The Raft algorithm provides a mechanism for electing leaders (both Raft leader and write leader), deciding which nodes to add or subtract from the cluster. It generally ensures that the distributed system remains consistent and fault tolerant, even in the face of node failures. ## Architectural elements diff --git a/product_docs/docs/pgd/6/reference/twophase.mdx b/product_docs/docs/pgd/6/reference/twophase.mdx index 643620c3f85..2fb6ef11d3f 100644 --- a/product_docs/docs/pgd/6/reference/twophase.mdx +++ b/product_docs/docs/pgd/6/reference/twophase.mdx @@ -8,7 +8,7 @@ redirects: --- !!!Note -Two-phase commit isn't available with Group Commit or CAMO. See [Commit scope limitations](/pgd/latest/known-issues#general-durability-limitations). +Two-phase commit isn't available with Group Commit or CAMO. See [Commit scope limitations](/pgd/latest/known_issues/#general-durability-limitations). !!! An application can explicitly opt to use two-phase commit with PGD. See From 4af42a9b6ed192d4d510538fb87f85982162c197 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Fri, 9 May 2025 09:06:30 +0100 Subject: [PATCH 050/145] Hard lock to 5.7 Signed-off-by: Dj Walker-Morgan --- .../overview/latest-release-news/2025q1release.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/advocacy_docs/edb-postgres-ai/overview/latest-release-news/2025q1release.mdx b/advocacy_docs/edb-postgres-ai/overview/latest-release-news/2025q1release.mdx index 6650e145ebb..5b08ce87ca1 100644 --- a/advocacy_docs/edb-postgres-ai/overview/latest-release-news/2025q1release.mdx +++ b/advocacy_docs/edb-postgres-ai/overview/latest-release-news/2025q1release.mdx @@ -67,7 +67,7 @@ Refer to the [Rubrik Partner Page](https://www.enterprisedb.com/partners/rubrik EDB Postgres AI leads the way for applications that require high availability for critical business continuity. With [EDB Postgres Distributed (PGD)](https://www.enterprisedb.com/products/edb-postgres-distributed), customers can build [geo-distributed](https://www.enterprisedb.com/use-case/geo-distributed) architectures that ensure continuous availability, improve performance by placing data closer to users, and enable safe, zero-downtime software deployments. -The latest version, [PGD 5.7.0](https://www.enterprisedb.com/docs/pgd/latest/), is now generally available. It delivers up to 99.999% availability with improved reliability and streamlined operations through enhanced integration with [third party change data capture (CDC) functionality](https://www.enterprisedb.com/docs/pgd/reference/latest/cdc-failover/). This allows seamless failover of logical slots for common CDC plugins like `test_decoding` and `pgoutput`, eliminating the need for third party subscribers to reseed tables during lead primary changes and ensuring continuous data replication. +The latest version, [PGD 5.7.0](https://www.enterprisedb.com/docs/pgd/latest/), is now generally available. It delivers up to 99.999% availability with improved reliability and streamlined operations through enhanced integration with [third party change data capture (CDC) functionality](https://www.enterprisedb.com/docs/pgd/5.7/cdc-failover/). This allows seamless failover of logical slots for common CDC plugins like `test_decoding` and `pgoutput`, eliminating the need for third party subscribers to reseed tables during lead primary changes and ensuring continuous data replication. Additionally, the new `Assess` command in the PGD CLI ensures seamless migrations to PGD. The tool proactively identifies PostgreSQL incompatibilities before upgrades, especially those impacting logical replication, so you can address them before upgrading to PGD. From 986a25d76909e7dedda0d68d0d18e156c9078c17 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Fri, 9 May 2025 11:06:12 +0100 Subject: [PATCH 051/145] fix unlogged sequence format Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/reference/sequences.mdx | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/sequences.mdx b/product_docs/docs/pgd/6/reference/sequences.mdx index fc2bee16929..8e671997cec 100644 --- a/product_docs/docs/pgd/6/reference/sequences.mdx +++ b/product_docs/docs/pgd/6/reference/sequences.mdx @@ -182,8 +182,7 @@ The differences between timeshard and SnowflakeId are as follows: Since Postgres 15, it has been possible to create unlogged sequences. These are related and similar to unlogged tables, which are not written to the WAL and are not replicated. In the context of PGD and unlogged sequences, it is not a sensible configuration to have an unlogged -PGD sequence and it could cause unexpected problems in the event of a node failure. Therefore, we prevent the -creation of unlogged PGD sequences or the conversion of a PGD sequence to an unlogged sequence. +PGD sequence and it could cause unexpected problems in the event of a node failure. Therefore, we prevent the creation of unlogged PGD sequences or the conversion of a PGD sequence to an unlogged sequence. ### Globally allocated range sequences From 10d0e1fd84e45b717f08aad20c2486b879379fa6 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Fri, 9 May 2025 11:34:19 +0100 Subject: [PATCH 052/145] Fixes for bdr.run_on... Signed-off-by: Dj Walker-Morgan --- .../ddl/ddl-managing-with-pgd-replication.mdx | 4 +--- .../6/reference/tables-views-functions/functions.mdx | 12 ++++++++++++ 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/ddl/ddl-managing-with-pgd-replication.mdx b/product_docs/docs/pgd/6/reference/ddl/ddl-managing-with-pgd-replication.mdx index feff34206e6..459a21c80d1 100644 --- a/product_docs/docs/pgd/6/reference/ddl/ddl-managing-with-pgd-replication.mdx +++ b/product_docs/docs/pgd/6/reference/ddl/ddl-managing-with-pgd-replication.mdx @@ -37,11 +37,9 @@ INDEX CONCURRENTLY`, noting that DDL replication must be disabled for the whole session because `CREATE INDEX CONCURRENTLY` is a multi-transaction command. Avoid `CREATE INDEX` on production systems since it prevents writes while it executes. -`REINDEX` is not replicated in versions 3.6 and earlier but not with PGD 3.7 or later. Avoid using `REINDEX` because of the AccessExclusiveLocks it holds. -Instead, use `REINDEX CONCURRENTLY` (or `reindexdb --concurrently`), -which is available in PG12+ or 2QPG11+. +Instead, use `REINDEX CONCURRENTLY` (or `reindexdb --concurrently`). You can disable DDL replication when using command-line utilities like this: diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx index affc011c80d..bc53ec43db8 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx @@ -477,6 +477,10 @@ connection to all known nodes. By default, the connection is created with `bdr.ddl_replication = off`, since the commands are already being sent to all of the nodes in the cluster. +From PGD 6 onwards, this function also sets `bdr.xact_replication=off` on the +connection, to ensure that transactions only run locally when the command is +executed on another node. + Be careful when using this function since you risk breaking replication and causing inconsistencies between nodes. Use either transparent DDL replication or `bdr.replicate_ddl_command()` to replicate DDL. @@ -570,6 +574,10 @@ connection to all known nodes. By default, the connection is created with `bdr.ddl_replication = off` to avoid replication issues when the same replicated DDL command is sent to multiple nodes. +From PGD 6 onwards, this function also sets `bdr.xact_replication=off` on the +connection, to ensure that transactions only run locally when the command is +executed on another node. + Be careful when using this function since you risk breaking replication and causing inconsistencies between nodes. For global schema changes, to replicate DDL, use @@ -611,6 +619,10 @@ connection to all known nodes. By default, the connection is created with `bdr.ddl_replication = off` to avoid replication issues when the same replicated DDL command is sent to multiple nodes. +From PGD 6 onwards, this function also sets `bdr.xact_replication=off` on the +connection, to ensure that transactions only run locally when the command is +executed on another node. + Be careful when using this function since you risk breaking replication and causing inconsistencies between nodes in the group. For global schema changes, to replicate DDL, use From 8f056e2cc351d76894acd59689ce837cb781d32d Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Fri, 9 May 2025 13:52:00 +0100 Subject: [PATCH 053/145] remove reference to disabling CAMO in twophase Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/reference/twophase.mdx | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/twophase.mdx b/product_docs/docs/pgd/6/reference/twophase.mdx index 2fb6ef11d3f..d39a31c9cfd 100644 --- a/product_docs/docs/pgd/6/reference/twophase.mdx +++ b/product_docs/docs/pgd/6/reference/twophase.mdx @@ -44,12 +44,10 @@ or the global commit scope. Future releases might enable this combination. ## Use Two-phase commits with a local commit scope work exactly like standard -PostgreSQL. Use the local commit scope and disable CAMO: +PostgreSQL. Use the local commit scope: ```sql BEGIN; - -SET LOCAL bdr.enable_camo = 'off'; SET LOCAL bdr.commit_scope = 'local'; ... other commands possible... From be564bb124b7c1634b0d4782bfccf078ab9af7e1 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Fri, 9 May 2025 14:12:16 +0100 Subject: [PATCH 054/145] Removal of most TPA references Signed-off-by: Dj Walker-Morgan --- .../pgd/6/expanded-how-to/architectures.mdx | 3 - .../pgd/6/reference/appusage/extensions.mdx | 2 +- .../6/reference/cli/discover_connections.mdx | 64 +------------------ .../docs/pgd/6/reference/cli/index.mdx | 4 +- .../pgd/6/reference/cli/installing/tpa.mdx | 11 ---- 5 files changed, 4 insertions(+), 80 deletions(-) delete mode 100644 product_docs/docs/pgd/6/reference/cli/installing/tpa.mdx diff --git a/product_docs/docs/pgd/6/expanded-how-to/architectures.mdx b/product_docs/docs/pgd/6/expanded-how-to/architectures.mdx index 60627c5ee35..58476db80d9 100644 --- a/product_docs/docs/pgd/6/expanded-how-to/architectures.mdx +++ b/product_docs/docs/pgd/6/expanded-how-to/architectures.mdx @@ -19,9 +19,6 @@ described here. Use-case-specific variations have been successfully deployed in production. However, these variations must undergo rigorous architecture review first. -Always-on architectures can be deployed using EDB’s standard deployment tool -Trusted Postgres Architect (TPA) or configured manually. - ## Standard EDB Always-on architectures EDB has identified a set of standardized architectures to support single- or diff --git a/product_docs/docs/pgd/6/reference/appusage/extensions.mdx b/product_docs/docs/pgd/6/reference/appusage/extensions.mdx index c74a2df8153..d97cab4d933 100644 --- a/product_docs/docs/pgd/6/reference/appusage/extensions.mdx +++ b/product_docs/docs/pgd/6/reference/appusage/extensions.mdx @@ -45,7 +45,7 @@ PostgreSQL extensions provide SQL objects, such as functions, datatypes, and, op The relevant extension packages must be available on all nodes in the cluster. Otherwise extension installation can fail and impact cluster stability. -If PGD is deployed using [Trusted Postgres Architect](/tpa/latest/), configure extensions using that tool. +If PGD is deployed using [Trusted Postgres Architect](/tpa/latest/), configure extensions using that tool. For details, see [Adding Postgres extensions](/tpa/latest/reference/postgres_extension_configuration). The following is relevant for manually configured PGD installations. diff --git a/product_docs/docs/pgd/6/reference/cli/discover_connections.mdx b/product_docs/docs/pgd/6/reference/cli/discover_connections.mdx index 5c8033843ac..f8f9fa6ef60 100644 --- a/product_docs/docs/pgd/6/reference/cli/discover_connections.mdx +++ b/product_docs/docs/pgd/6/reference/cli/discover_connections.mdx @@ -16,69 +16,9 @@ You might not need a database connection string. For example, when Trusted Postg Because of the range of different configurations that PGD supports, every deployment method has a different way of deriving a connection string for it. Generally, you can obtain the required information from the configuration of your deployment. You can then assemble that information into connection strings. -### For a TPA-deployed PGD cluster +### For a cluster deployed with EDB CloudNative Postgres Global Cluster -**TODO [DOCS-1498]** - -Because TPA is so flexible, you have to derive your connection string from your cluster configuration file (`config.yml`). - -- You need the name or IP address of any data host. By default all PGD 6 data hosts have a connection manager you can connect to. Usually the connection manager listens on port 6432. -- The default database name is `bdrdb`. (Check the setting `bdr_database` in the config to confirm.) -- The default PGD superuser is enterprisedb for EDB Postgres Advanced Server and postgres for PostgreSQL and EDB Postgres Extended Server. - -You can then assemble a connection string based on that information: - -``` -"host= port= dbname= user= sslmode=require" -``` - -To illustrate this, here are some excerpts of a `config.yml` file for a cluster: - -```yaml -... -cluster_vars: - ... - bdr_database: bdrdb - ... - default_pgd_proxy_options: - listen_port: 6432 - ... - -instances: -- Name: kaboom - backup: kapok - location: dc1 - node: 1 - role: - - bdr - - pgd-proxy - networks: - - ipv4_address: 192.168.100.2 - name: tpanet -... -``` - -The connection string for this cluster is: - -``` -"host=192.168.100.2 port=6432 dbname=bdrdb user=enterprisedb sslmode=require" -``` - -!!! Note Host name versus IP address -The example uses the IP address because the configuration is from a Docker TPA install with no name resolution available. Generally, you can use the host name as configured. -!!! - -### For an EDB Cloud Service distributed high-availability cluster - -1. Log in to the [Cloud Service clusters](https://portal.biganimal.com/clusters) view. -1. In the filter, set **Cluster Type** to **Distributed High Availability** to show only clusters that work with PGD CLI. -1. Select your cluster. -1. In the view of your cluster, select the **Connect** tab. -1. Copy the read/write URI from the connection info. This is your connection string. - -### For a cluster deployed with EDB PGD for Kubernetes - -As with TPA, EDB PGD for Kubernetes is very flexible, and there are multiple ways to obtain a connection string. It depends, in large part, on the configuration of the deployment's [services](/postgres_distributed_for_kubernetes/latest/connectivity/#services): +If you are using EDB CloudNative Postgres Global Cluster (CNPG-GC), the connection string is derived from the configuration of the deployment. It is very flexible so there are multiple ways to obtain a connection string. It depends, in large part, on the configuration of the deployment's [services](/postgres_distributed_for_kubernetes/latest/connectivity/#services): - If you use the Node Service Template, direct connectivity to each node and proxy service is available. - If you use the Group Service Template, there's a gateway service to each group. diff --git a/product_docs/docs/pgd/6/reference/cli/index.mdx b/product_docs/docs/pgd/6/reference/cli/index.mdx index e2758f8e1a1..56097dde9fa 100644 --- a/product_docs/docs/pgd/6/reference/cli/index.mdx +++ b/product_docs/docs/pgd/6/reference/cli/index.mdx @@ -23,11 +23,9 @@ It allows you to run commands against EDB Postgres Distributed clusters to: * Inspect and manage the cluster's nodes and groups. * Perform a write-leader change operation on the group. -PGD CLI is installed automatically on systems in a TPA-deployed PGD cluster. - You can also install it manually on Linux and macOS systems that can connect to a PGD cluster, including: * HCP advanced and distributed high-availability clusters. * PGD clusters deployed using the CloudNative Postgres Global Clusters operator. * Manually deployed PGD clusters. -* TPA-deployed PGD clusters. + diff --git a/product_docs/docs/pgd/6/reference/cli/installing/tpa.mdx b/product_docs/docs/pgd/6/reference/cli/installing/tpa.mdx deleted file mode 100644 index bcf865e2423..00000000000 --- a/product_docs/docs/pgd/6/reference/cli/installing/tpa.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: "Installing PGD CLI with TPA" -navTitle: "TPA" -description: "Installing PGD CLI with Trusted Postgres Architect" ---- - -By default, Trusted Postgres Architect installs and configures PGD CLI on each PGD node. - -If you want to install PGD CLI on any non-PGD instance in the cluster, attach the pgdcli role to that instance in Trusted Postgres Architect's configuration file before deploying. - -See [Trusted Postgres Architect](/tpa/latest/) for more information. From 96ed8fbe3db8fd6469eb4685a68084830d74d9d8 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Fri, 9 May 2025 14:18:09 +0100 Subject: [PATCH 055/145] linting fixes Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/reference/cli/index.mdx | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/cli/index.mdx b/product_docs/docs/pgd/6/reference/cli/index.mdx index 56097dde9fa..c9b07027b75 100644 --- a/product_docs/docs/pgd/6/reference/cli/index.mdx +++ b/product_docs/docs/pgd/6/reference/cli/index.mdx @@ -19,7 +19,7 @@ The EDB Postgres Distributed Command Line Interface (PGD CLI) is a tool for mana It allows you to run commands against EDB Postgres Distributed clusters to: -* Determine the health of the cluster, inspect the cluster's configuration, and manage the cluster's resources. +* Determine the health of the cluster, inspect the cluster's configuration, and manage the cluster's resources. * Inspect and manage the cluster's nodes and groups. * Perform a write-leader change operation on the group. @@ -28,4 +28,3 @@ You can also install it manually on Linux and macOS systems that can connect to * HCP advanced and distributed high-availability clusters. * PGD clusters deployed using the CloudNative Postgres Global Clusters operator. * Manually deployed PGD clusters. - From e11d25c46c8cd59fd2aac03078277f32b6a5b8dd Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Fri, 9 May 2025 14:45:15 +0100 Subject: [PATCH 056/145] Missong KI updates Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/known_issues.mdx | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/product_docs/docs/pgd/6/known_issues.mdx b/product_docs/docs/pgd/6/known_issues.mdx index 10d58ee570a..e0fbcc0cb69 100644 --- a/product_docs/docs/pgd/6/known_issues.mdx +++ b/product_docs/docs/pgd/6/known_issues.mdx @@ -84,8 +84,7 @@ operationally and functionally is no longer viable in a multi-database design. It's best practice and we recommend that you configure only one database per PGD instance. -The deployment automation with TPA and the tooling such as the CLI -and Connection Manager already codify that recommendation. +The tooling such as the CLI and Connection Manager currently codify that recommendation. While it's still possible to host up to 10 databases in a single instance, doing so incurs many immediate risks and current limitations: @@ -96,9 +95,6 @@ doing so incurs many immediate risks and current limitations: - You must monitor each database separately, adding overhead. -- TPAexec assumes one database. Additional coding is needed by customers or by the EDB Professional Services team - in a post-deploy hook to set up replication for more databases. - - Connection Manager works at the Postgres instance level, not at the database level, meaning the leader node is the same for all databases. From 5b0321d6875b233a8ae935f587b494ef30baf783 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Fri, 9 May 2025 15:31:58 +0100 Subject: [PATCH 057/145] Streamlines compatibility Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/compatibility.mdx | 58 ++++++++++++----------- 1 file changed, 30 insertions(+), 28 deletions(-) diff --git a/product_docs/docs/pgd/6/compatibility.mdx b/product_docs/docs/pgd/6/compatibility.mdx index 47c64cb1e6c..46f5d0e7c8a 100644 --- a/product_docs/docs/pgd/6/compatibility.mdx +++ b/product_docs/docs/pgd/6/compatibility.mdx @@ -7,15 +7,14 @@ deepToC: true ## PGD compatibility with PostgreSQL versions -The following table shows the major versions of PostgreSQL and each version of EDB Postgres Distributed (PGD) they are compatible with. +The following table shows the major versions of PostgreSQL that EDB Postgres Distributed (PGD) is compatible with. -| Postgres Version | PGD 6 | PGD 5 | PGD 4 | -|------------------|--------------|--------------------|--------------| -| 17.3 | [6+](/pgd/6) | [5.7+](/pgd/5.7) | | -| 17 | [6+](/pgd/6) | [5.6.1+](/pgd/5.6) | | -| 16 | [6+](/pgd/6) | [5.3+](/pgd/5.6/) | | -| 15 | [6+](/pgd/6) | [5](/pgd/5.6/) | | -| 14 | [6+](/pgd/6) | [5](/pgd/5.6/) | [4](/pgd/4/) | +| PGD 6 | Postgres Version | +|-------------|------------------| +| [6](/pgd/6) | 17.5.0+ | +| [6](/pgd/6) | 16.9.0+ | +| [6](/pgd/6) | 15.13.0+ | +| [6](/pgd/6) | 14.18.0+ | EDB recommends that you use the latest minor version of any Postgres major version with a supported PGD. @@ -25,30 +24,33 @@ The following tables show the versions of EDB Postgres Distributed and their com ### Linux x86_64 (amd64) -| Operating System | PGD 6 | PGD 5 | PGD 4 | -|------------------------------------|----------|-----------|-------| -| RHEL 8/9 | Yes | Yes | Yes | -| Oracle Linux 8/9 | Yes | Yes | Yes | -| Rocky Linux/AlmaLinux | Yes | Yes | Yes | -| SUSE Linux Enterprise Server 15SP5 | Yes | Yes | Yes | -| Ubuntu 20.04/22.04 | Yes | Yes | Yes | -| Ubuntu 24.04 | Yes⊃ | Yes¹ | No | -| Debian 11/12 | Yes | Yes | Yes | - -¹ from PGD 5.7 onwards +| Operating System | PGD 6 | +|------------------------------------|-------| +| RHEL 8 | Yes | +| RHEL 9 | Yes | +| Oracle Linux 8 | Yes | +| Oracle Linux 9 | Yes | +| Rocky Linux/AlmaLinux | Yes | +| SUSE Linux Enterprise Server 15SP6 | Yes | +| Ubuntu 22.04 | Yes | +| Ubuntu 24.04 | Yes | +| Debian 12 | Yes | ### Linux ppc64le -| Operating System | PGD 6 | PGD 5 | PGD 4 | -|------------------|-------|-------|-------| -| RHEL 8/9 | Yes | Yes | No | - +| Operating System | PGD 6 | +|------------------------------------|-------| +| RHEL 8 | Yes | +| RHEL 9 | Yes | +| SUSE Linux Enterprise Server 15SP6 | Yes | ### Linux arm64/aarch64 -| Operating System | PGD 6 | PGD 5¹ | PGD 4 | -|------------------|-------|-------------|-------| -| Debian 12 | Yes | Yes | No | -| RHEL 9 | Yes | Yes | No | +| Operating System | PGD 6 | +|------------------|-------| +| Debian 12 | Yes | +| RHEL 9 | Yes | -¹ From PGD 5.6.1 onwards +!!! Note +See [PGD 5 Compatibility](/pgd/5.8/compatibility) for previous versions of PGD. +!!! From 5794a8c93288bd0f6d308285a9020fe953527e97 Mon Sep 17 00:00:00 2001 From: Ian Barwick Date: Fri, 9 May 2025 17:01:13 +0900 Subject: [PATCH 058/145] pgd: add some notes about pgd_bench, scripts and "-m camo" Explicitly note that pgd_bench does not automatically initiate database transations, so any custom scripts will need to include SQL transaction statements, particularly for running in CAMO mode. DOCS-1529 --- .../6/reference/tables-views-functions/testingandtuning.mdx | 4 ++++ product_docs/docs/pgd/6/reference/testing-tuning.mdx | 6 ++++++ 2 files changed, 10 insertions(+) diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/testingandtuning.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/testingandtuning.mdx index 0f8d9638d59..c2ecf67d8ff 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/testingandtuning.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/testingandtuning.mdx @@ -43,6 +43,10 @@ When using `-m failover`, an additional option `--retry` is available. This opti instructs pgd_bench to retry transactions when there's a failover. The `--retry` option is automatically enabled when `-m camo` is used. +When using `-m camo` and providing a custom script, the SQL commands in the script must +be wrapped in SQL transaction commands, i.e. the first SQL command must be `BEGIN`, +and the final SQL command must be `COMMIT`. + #### Setting GUC variables `-o` or `--set-option` diff --git a/product_docs/docs/pgd/6/reference/testing-tuning.mdx b/product_docs/docs/pgd/6/reference/testing-tuning.mdx index ea2b67dc663..e6a1278c12d 100644 --- a/product_docs/docs/pgd/6/reference/testing-tuning.mdx +++ b/product_docs/docs/pgd/6/reference/testing-tuning.mdx @@ -83,6 +83,12 @@ by PostgreSQL and or any possible extensions, including the BDR extension. It's responsibility to suppress them by setting appropriate variables, such as `client_min_messages`, `bdr.camo_enable_client_warnings`, and so on. +- `pgd_bench` does not automatically initiate SQL transactions for custom scripts. +Scripts which are intended to run in an SQL transaction need to include the transaction +start and end commands. If `pgd_bench` is executed with the `-m`/`--mode` option set +to `camo`, any custom scripts provided must wrap the SQL commands in a transaction, +otherwise CAMO functionality will not work as expected. + ## Performance testing and tuning PGD allows you to issue write transactions onto multiple nodes. Bringing From 8501b33fdd176269296af140cfaea90103a6f0ef Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Mon, 12 May 2025 07:15:56 +0100 Subject: [PATCH 059/145] Update compatibility with a matrix Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/compatibility.mdx | 43 ++++++++--------------- 1 file changed, 14 insertions(+), 29 deletions(-) diff --git a/product_docs/docs/pgd/6/compatibility.mdx b/product_docs/docs/pgd/6/compatibility.mdx index 46f5d0e7c8a..12730c1c54f 100644 --- a/product_docs/docs/pgd/6/compatibility.mdx +++ b/product_docs/docs/pgd/6/compatibility.mdx @@ -19,37 +19,22 @@ The following table shows the major versions of PostgreSQL that EDB Postgres Dis EDB recommends that you use the latest minor version of any Postgres major version with a supported PGD. ## PGD compatibility with operating systems and architectures - +    The following tables show the versions of EDB Postgres Distributed and their compatibility with various operating systems and architectures. -### Linux x86_64 (amd64) - -| Operating System | PGD 6 | -|------------------------------------|-------| -| RHEL 8 | Yes | -| RHEL 9 | Yes | -| Oracle Linux 8 | Yes | -| Oracle Linux 9 | Yes | -| Rocky Linux/AlmaLinux | Yes | -| SUSE Linux Enterprise Server 15SP6 | Yes | -| Ubuntu 22.04 | Yes | -| Ubuntu 24.04 | Yes | -| Debian 12 | Yes | - -### Linux ppc64le - -| Operating System | PGD 6 | -|------------------------------------|-------| -| RHEL 8 | Yes | -| RHEL 9 | Yes | -| SUSE Linux Enterprise Server 15SP6 | Yes | - -### Linux arm64/aarch64 - -| Operating System | PGD 6 | -|------------------|-------| -| Debian 12 | Yes | -| RHEL 9 | Yes | +### Linux + +| Operating System | :x86_64 (amd64): |:ppc64le: |:arm64/aarch64: | +|------------------------------------|----------------|---------|---------------| +| RHEL 8 | Yes | Yes | | +| RHEL 9 | Yes | Yes | Yes | +| Oracle Linux 8 | Yes | | | +| Oracle Linux 9 | Yes | | | +| Rocky Linux/AlmaLinux | Yes | | | +| SUSE Linux Enterprise Server 15SP6 | Yes | Yes | | +| Ubuntu 22.04 | Yes | | | +| Ubuntu 24.04 | Yes | | | +| Debian 12 | Yes | | Yes | !!! Note See [PGD 5 Compatibility](/pgd/5.8/compatibility) for previous versions of PGD. From dfe70f10dfadafb89ece06af1172ded81f9feb80 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Mon, 12 May 2025 07:32:12 +0100 Subject: [PATCH 060/145] Clarify what is evaluated in a commit scope group spec Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/reference/commit-scopes/commit-scope-rules.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/6/reference/commit-scopes/commit-scope-rules.mdx b/product_docs/docs/pgd/6/reference/commit-scopes/commit-scope-rules.mdx index 893541f5c21..ec4327ab9f5 100644 --- a/product_docs/docs/pgd/6/reference/commit-scopes/commit-scope-rules.mdx +++ b/product_docs/docs/pgd/6/reference/commit-scopes/commit-scope-rules.mdx @@ -28,7 +28,7 @@ The last part of this operation is the commit scope kind, which in this example ## The commit scope group -There are three kinds of commit scope groups: `ANY`, `ALL`, and `MAJORITY`. They're all followed by a list of one or more groups in parentheses. This list of groups combines to make a pool of nodes this operation applies to. This list can be preceded by `NOT`, which inverts the pool to be all other groups that aren't in the list. Witness nodes aren't eligible to be included in this pool, as they don't replicate data. +There are three kinds of commit scope groups: `ANY`, `ALL`, and `MAJORITY`. They're all followed by a list of one or more groups in parentheses. This list of groups combines to make a pool of nodes this operation applies to. This list can be preceded by `NOT`, which inverts the pool to be all other groups that aren't in the list. - `ANY n` is followed by an integer value, `n`. It translates to any `n` nodes in the listed groups' nodes. - `ALL` is followed by the groups and translates to all nodes in the listed groups' nodes. @@ -37,6 +37,7 @@ There are three kinds of commit scope groups: `ANY`, `ALL`, and `MAJORITY`. They - `ALL NOT` is followed by the groups and translates to all nodes that aren't in the listed groups' nodes. - `MAJORITY NOT` is followed by the groups and translates to requiring a half, plus one, of the nodes that aren't in the listed groups' nodes to confirm, to give a majority. +All of the above expressions only consider data nodes in the groups in their evaluation. Witness nodes and other non-data nodes are ignored. ## The confirmation level From 41baabdd239e9596603c7125a3a8ea7fceaa1d36 Mon Sep 17 00:00:00 2001 From: Ian Barwick Date: Fri, 9 May 2025 15:29:01 +0900 Subject: [PATCH 061/145] pgd: clarify that "transaction_id" is not accessible in SQL. Also add a missing heading for the unrelated function references which follow immediately after. DOCS-1528. --- .../pgd/6/reference/tables-views-functions/functions.mdx | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx index bc53ec43db8..d60563c275f 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx @@ -70,9 +70,12 @@ becomes remotely visible. If a CAMO transaction is in progress, `transaction_id` is updated to show the assigned transaction id. You can query this parameter only by using -using `PQparameterStatus` or equivalent. See [Application use](../commit-scopes/camo#application-use) +using `PQparameterStatus` or equivalent, and it is not accessible in SQL. +See [Application use](../commit-scopes/camo#application-use) for a usage example. +## Node status functions + ### `bdr.is_node_connected` #### Synopsis From b26d5fc55494d5b7997d4f27e0de93d8cea27c34 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Mon, 12 May 2025 07:57:00 +0100 Subject: [PATCH 062/145] Merge updated reference page Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/reference/tables-views-functions/index.mdx | 1 + 1 file changed, 1 insertion(+) diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx index c2651fe2f39..70afb2f8b86 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx @@ -121,6 +121,7 @@ The reference section is a definitive listing of all functions, views, and comma * [`bdr.local_node_id`](functions#bdrlocal_node_id) * [`bdr.last_committed_lsn`](functions#bdrlast_committed_lsn) * [`transaction_id`](functions#transaction_id) +### [Node status functions](functions#node-status-functions) * [`bdr.is_node_connected`](functions#bdris_node_connected) * [`bdr.is_node_ready`](functions#bdris_node_ready) ### [Consensus function](functions#consensus-function) From 9637c01473ed934993d9d51f6d4ac7ecaddc8f3b Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Mon, 12 May 2025 09:17:03 +0100 Subject: [PATCH 063/145] Corrected text to sync with ticket Signed-off-by: Dj Walker-Morgan --- .../nodes-management-interfaces.mdx | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/nodes-management-interfaces.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/nodes-management-interfaces.mdx index 626a9d02184..9c52930f5dd 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/nodes-management-interfaces.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/nodes-management-interfaces.mdx @@ -321,12 +321,11 @@ This function passes a request to the group consensus mechanism by way of the no that the `join_target_dsn` connection string points to. The changes made are replicated globally by the consensus mechanism. -The function isn't transactional. The joining process happens in the -background and you can't roll it back. The changes are visible only -to the local transaction if `wait_for_completion` was set to `true` or by calling -`bdr.wait_for_join_completion` later. +The function isn't transactional, and will emit an ERROR if executed in a transaction. +The joining process happens in the background and you can't roll it back. +The changes are visible only to the local session if `wait_for_completion` is set to `true` or by calling `bdr.wait_for_join_completion` later. -Node can be part of only a single group, so you can call this function only once +A node can be part of only a single group, so you can call this function only once on each node. Node join doesn't hold any locks in the PGD group. From ae3e9865e8e15195c8216e1a1520e62a6dcd7e02 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Mon, 12 May 2025 12:16:50 +0100 Subject: [PATCH 064/145] Updated command handling Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/reference/ddl/ddl-command-handling.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/ddl/ddl-command-handling.mdx b/product_docs/docs/pgd/6/reference/ddl/ddl-command-handling.mdx index ed2aa7fa368..db9f95d100b 100644 --- a/product_docs/docs/pgd/6/reference/ddl/ddl-command-handling.mdx +++ b/product_docs/docs/pgd/6/reference/ddl/ddl-command-handling.mdx @@ -57,7 +57,7 @@ under the following table. | ALTER SYNONYM | Y | Y | DDL | | ALTER SYSTEM | Y | N | N | | ALTER TABLE | [Details](#bdr_ddl_allowed_AlterTableStmt) | Y | [Details](#bdr_ddl_lock_relation_AlterTableStmt) | -| ALTER TABLESPACE | Y | N | N | +| ALTER TABLESPACE | Y | Y | DDL | | ALTER TEXT SEARCH CONFIGURATION | Y | Y | DDL | | ALTER TEXT SEARCH DICTIONARY | Y | Y | DDL | | ALTER TEXT SEARCH PARSER | Y | Y | DDL | @@ -120,7 +120,7 @@ under the following table. | CREATE SYNONYM | Y | Y | DDL | | CREATE TABLE | Y | Y | DDL | | CREATE TABLE AS | [Details](#bdr_ddl_allowed_CreateTableAsStmt) | Y | DDL | -| CREATE TABLESPACE | Y | N | N | +| CREATE TABLESPACE | Y | Y | DDL | | CREATE TEXT SEARCH CONFIGURATION | Y | Y | DDL | | CREATE TEXT SEARCH DICTIONARY | Y | Y | DDL | | CREATE TEXT SEARCH PARSER | Y | Y | DDL | @@ -182,7 +182,7 @@ under the following table. | DROP SUBSCRIPTION | Y | Y | DDL | | DROP SYNONYM | Y | Y | DDL | | DROP TABLE | Y | Y | DML | -| DROP TABLESPACE | Y | N | N | +| DROP TABLESPACE | Y | Y | DDL | | DROP TEXT SEARCH CONFIGURATION | Y | Y | DDL | | DROP TEXT SEARCH DICTIONARY | Y | Y | DDL | | DROP TEXT SEARCH PARSER | Y | Y | DDL | From 362d2e9e8bf4e5aab0c8e8df9d90e59492bbfa81 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Mon, 12 May 2025 11:18:56 +0100 Subject: [PATCH 065/145] Updates and regenerated indexes Signed-off-by: Dj Walker-Morgan --- .../catalogs-visible.mdx | 18 ++++++++++++++++++ .../tables-views-functions/index.json | 1 + .../tables-views-functions/index.mdx | 1 + .../nodes-management-interfaces.mdx | 19 +++++++++++++------ .../tables-views-functions/nodes.mdx | 1 + 5 files changed, 34 insertions(+), 6 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx index 362db71ded8..8fa4d04698f 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx @@ -762,6 +762,24 @@ node. | node_group_id | oid | OID of the PGD node group | | node_kind_name | oid | Node kind name | +### `bdr.parted_origin_catchup_info` + +This table records relevant catchup information on each node related to parted orgins. + +#### `bdr.parted_origin_catchup_info` columns + +| Name | Type | Description | +|----------------------|--------|----------------------------------------------------------------------------------------------------| +| parting_peer_node_id | oid | ID of the parted node | +| node_id | oid | ID of the node | +| node_group_id | oid | ID of the node group | +| origin_catchup_lsn | pg_lsn | The LSN which the node will wait for its group slot to catch up to and then move its state to DONE | +| origin_catchup_state | oid | Status code of the parted origin catchup | + +A node(`node_id`) waits for its group slot to catch up with the recorded LSN, (`origin_catchup_lsn`). This is to ensure it’s group slot is caught up with all the transactions originating from PARTED node (`parting_peer_node_id`). + +The records in this table persists until the parting node (`parting_peer_node_id`) is automatically removed. + ### `bdr.queue` This table stores the historical record of replicated DDL statements. diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/index.json b/product_docs/docs/pgd/6/reference/tables-views-functions/index.json index d6e8e8b4ee0..50478c8bbf3 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/index.json +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/index.json @@ -37,6 +37,7 @@ "bdrnode_replication_rates": "/pgd/6/reference/tables-views-functions/catalogs-visible#bdrnode_replication_rates", "bdrnode_slots": "/pgd/6/reference/tables-views-functions/catalogs-visible#bdrnode_slots", "bdrnode_summary": "/pgd/6/reference/tables-views-functions/catalogs-visible#bdrnode_summary", + "bdrparted_origin_catchup_info": "/pgd/6/reference/tables-views-functions/catalogs-visible#bdrparted_origin_catchup_info", "bdrqueue": "/pgd/6/reference/tables-views-functions/catalogs-visible#bdrqueue", "bdrreplication_set": "/pgd/6/reference/tables-views-functions/catalogs-visible#bdrreplication_set", "bdrreplication_set_table": "/pgd/6/reference/tables-views-functions/catalogs-visible#bdrreplication_set_table", diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx index 70afb2f8b86..a3111613fc1 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx @@ -71,6 +71,7 @@ The reference section is a definitive listing of all functions, views, and comma * [`bdr.node_replication_rates`](catalogs-visible#bdrnode_replication_rates) * [`bdr.node_slots`](catalogs-visible#bdrnode_slots) * [`bdr.node_summary`](catalogs-visible#bdrnode_summary) + * [`bdr.parted_origin_catchup_info`](catalogs-visible#bdrparted_origin_catchup_info) * [`bdr.queue`](catalogs-visible#bdrqueue) * [`bdr.replication_set`](catalogs-visible#bdrreplication_set) * [`bdr.replication_set_table`](catalogs-visible#bdrreplication_set_table) diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/nodes-management-interfaces.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/nodes-management-interfaces.mdx index 9c52930f5dd..9d70c7326b3 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/nodes-management-interfaces.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/nodes-management-interfaces.mdx @@ -332,8 +332,12 @@ Node join doesn't hold any locks in the PGD group. ## `bdr.part_node` -Removes (parts) the node from the PGD group but doesn't remove data -from the node. +Removes (parts) the node from the PGD group and eventually removes the parted node’s metadata automatically from all nodes in the cluster. + +* For the local node, it will remove all the node metadata, including information about remote nodes. +* For remote nodes, it removes only the metadata for that specific node. + +This operation does not remove data from the node. You can call the function from any active node in the PGD group, including the node that you're removing. @@ -392,11 +396,14 @@ roll it back. If the function is called on a node that's already in process of parting with `force` set to `true`, it also marks the given node as parted locally and exits. This is useful only when the consensus can't be reached on the cluster (that is, the majority of the nodes are down) or if the -parting process is stuck. But it's important to take into +parting process is stuck. + +But it's important to take into account that when the parting node that was receiving writes, the parting process -can take a long time without being stuck. The other nodes need to resynchronize -any missing data from the given node. The force parting completely skips this -resynchronization and can leave the other nodes in an inconsistent state. +can take a long time without actually being stuck. The other nodes need to resynchronize +any missing data from the given node. The other nodes need to wait till group slots of all nodes are caught up to all the transactions originating from the PARTED node. + +A forced parting completely skips this resynchronization and can leave the other nodes in an inconsistent state. The parting process doesn't hold any locks. diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/nodes.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/nodes.mdx index b7a7bcade24..cbff1f371cd 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/nodes.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/nodes.mdx @@ -21,6 +21,7 @@ deepToC: true | `PART_START` | Node was `ACTIVE` or `STANDBY` and `bdr.part_node` was just called to remove the node from the EDB Postgres Distributed cluster. | | `PARTING` | Node disconnects from other nodes and plays no further part in consensus or replication. | | `PART_CATCHUP` | Nonparting nodes synchronize any missing data from the recently parted node. | +| `PART_CLEANUP` | Non-parting nodes wait until the group slots of all nodes are caught up with all the transactions that originated form the PARTED node. | | `PARTED` | Node parting operation is now complete on all nodes. | Only one node at a time can be in either of the states PROMOTE or PROMOTING. From 452b81a8bc856aa025b1681b2d6856ab06f8339f Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Mon, 12 May 2025 14:24:39 +0100 Subject: [PATCH 066/145] Add bdr.parted_origin_catchup_info_details (BDR-6468) Signed-off-by: Dj Walker-Morgan --- .../catalogs-visible.mdx | 21 +++++++++++++++++++ .../tables-views-functions/index.json | 1 + .../tables-views-functions/index.mdx | 1 + 3 files changed, 23 insertions(+) diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx index 8fa4d04698f..90b4ac1df6a 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx @@ -780,6 +780,27 @@ A node(`node_id`) waits for its group slot to catch up with the recorded LSN, (` The records in this table persists until the parting node (`parting_peer_node_id`) is automatically removed. +### `bdr.parted_origin_catchup_info_details` + +This table is a friendly view of `bdr.parted_origin_catchup_info` with relevant catchup information on each node related to parted orgins, in this case in text form. + +#### `bdr.parted_origin_catchup_info_details` columns + +| Name | Type | Description | +|-----------------------|--------|----------------------------------------------------------------------------------------------------| +| target_node_id | oid | ID of the target node | +| target_node_name | text | Name of the target node | +| parting_node_id | oid | ID of the parted node | +| parting_node_name | text | Name of the parted node | +| node_group_id | oid | ID of the node group | +| node_group_name | text | Name of the node group | +| parting_catchup_lsn | pg_lsn | The LSN which the node will wait for its group slot to catch up to and then move its state to DONE | +| parting_catchup_state | text | Status text for the parted origin's catchup | + +A node(`target_node_id`) waits for its group slot to catch up with the recorded LSN, (`parting_catchup_lsn`). This is to ensure it’s group slot is caught up with all the transactions originating from PARTED node (`parting_node_id`). + +The records in this table persists until the parting node (`parting_node_id`) is automatically removed. + ### `bdr.queue` This table stores the historical record of replicated DDL statements. diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/index.json b/product_docs/docs/pgd/6/reference/tables-views-functions/index.json index 50478c8bbf3..34ff3ed6608 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/index.json +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/index.json @@ -38,6 +38,7 @@ "bdrnode_slots": "/pgd/6/reference/tables-views-functions/catalogs-visible#bdrnode_slots", "bdrnode_summary": "/pgd/6/reference/tables-views-functions/catalogs-visible#bdrnode_summary", "bdrparted_origin_catchup_info": "/pgd/6/reference/tables-views-functions/catalogs-visible#bdrparted_origin_catchup_info", + "bdrparted_origin_catchup_info_details": "/pgd/6/reference/tables-views-functions/catalogs-visible#bdrparted_origin_catchup_info_details", "bdrqueue": "/pgd/6/reference/tables-views-functions/catalogs-visible#bdrqueue", "bdrreplication_set": "/pgd/6/reference/tables-views-functions/catalogs-visible#bdrreplication_set", "bdrreplication_set_table": "/pgd/6/reference/tables-views-functions/catalogs-visible#bdrreplication_set_table", diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx index a3111613fc1..25aef405bb9 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/index.mdx @@ -72,6 +72,7 @@ The reference section is a definitive listing of all functions, views, and comma * [`bdr.node_slots`](catalogs-visible#bdrnode_slots) * [`bdr.node_summary`](catalogs-visible#bdrnode_summary) * [`bdr.parted_origin_catchup_info`](catalogs-visible#bdrparted_origin_catchup_info) + * [`bdr.parted_origin_catchup_info_details`](catalogs-visible#bdrparted_origin_catchup_info_details) * [`bdr.queue`](catalogs-visible#bdrqueue) * [`bdr.replication_set`](catalogs-visible#bdrreplication_set) * [`bdr.replication_set_table`](catalogs-visible#bdrreplication_set_table) From 48af4a9f285dbefdfb42be6ac87d2bc66413ed9b Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan <126472455+djw-m@users.noreply.github.com> Date: Tue, 13 May 2025 05:16:41 +0100 Subject: [PATCH 067/145] Apply correction --- .../6/reference/tables-views-functions/catalogs-visible.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx index 90b4ac1df6a..8f9bc500b1c 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx @@ -795,7 +795,8 @@ This table is a friendly view of `bdr.parted_origin_catchup_info` with relevant | node_group_id | oid | ID of the node group | | node_group_name | text | Name of the node group | | parting_catchup_lsn | pg_lsn | The LSN which the node will wait for its group slot to catch up to and then move its state to DONE | -| parting_catchup_state | text | Status text for the parted origin's catchup | +| parting_catchup_state | oid | Parted origin's catchup status code | +| parting_catchup_state_name | text | Parted origin's catchup status text | A node(`target_node_id`) waits for its group slot to catch up with the recorded LSN, (`parting_catchup_lsn`). This is to ensure it’s group slot is caught up with all the transactions originating from PARTED node (`parting_node_id`). From 8aa6d4f66e5dd11c482f5467747f41679f3010ff Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Tue, 13 May 2025 08:16:05 +0100 Subject: [PATCH 068/145] Added automatic sequence conversion section. Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/reference/sequences.mdx | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/sequences.mdx b/product_docs/docs/pgd/6/reference/sequences.mdx index 8e671997cec..18d7c9d89da 100644 --- a/product_docs/docs/pgd/6/reference/sequences.mdx +++ b/product_docs/docs/pgd/6/reference/sequences.mdx @@ -86,7 +86,13 @@ command is executed or when a `serial`, `bigserial`, or The [`bdr.sequences`](/pgd/latest/reference/catalogs-visible/#bdrsequences) view shows information about individual sequence kinds. -`currval()` and `lastval()` work correctly for all types of global sequence. +The `currval()` and `lastval()` functions work correctly for all types of global sequences. + +## Automatic sequence conversion + +In PGD 6.0 and later, the act of joining a node to a PGD group or creating a new group will also trigger an automatic conversion of any local sequences into global sequences. The [`bdr.default_sequence_kind`](/pgd/latest/reference/pgd-settings/#bdrdefault_sequence_kind) is used to determine the kind of sequence to convert the sequences into. If this is set to `local`, the sequences are left as local sequences. If it is set to `galloc`, `snowflakeid`, or `timeshard`, the sequences are converted to that sequence kind. Conversion to `galloc` is performed in a way that ensures that the sequence will not conflict with any other sequences in the group. + +If you decide to start with local sequences and later switch to galloc sequences, you can do so by setting the `bdr.default_sequence_kind` to `galloc` and then running the `bdr.alter_sequence_set_kind()` function on each sequence you want to convert. Do be aware though that you will need to manually set the starting values of the sequences to ensure that they do not conflict with any existing values in the table. See [converting a local sequence to a galloc sequence](#converting-a-local-sequence-to-a-galloc-sequence) for more information about this in general and specifically [how to set a new start value for a sequence](#2-set-a-new-start-value-for-the-sequence). ### SnowflakeId sequences @@ -227,7 +233,7 @@ to or more than the above ranges assigned for each sequence datatype. `setval()` doesn't reset the global state for `galloc` sequences. Don't use it. A few limitations apply to `galloc` sequences. PGD tracks `galloc` sequences in a -special PGD catalog [bdr.sequence_alloc](/pgd/latest/reference/catalogs-visible/#bdrsequence_alloc). This +special PGD catalog [bdr.sequence_alloc](/pgd/latest/reference/tables-views-functions/catalogs-visible/#bdrsequence_alloc). This catalog is required to track the currently allocated chunks for the `galloc` sequences. The sequence name and namespace is stored in this catalog. The sequence chunk allocation is managed by Raft, whereas any changes to the From e0599b3494c356a346ea4fe32cc3af5c957576dc Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Tue, 13 May 2025 09:28:18 +0100 Subject: [PATCH 069/145] Updated from review Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/reference/sequences.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/6/reference/sequences.mdx b/product_docs/docs/pgd/6/reference/sequences.mdx index 18d7c9d89da..d66ea2bf350 100644 --- a/product_docs/docs/pgd/6/reference/sequences.mdx +++ b/product_docs/docs/pgd/6/reference/sequences.mdx @@ -90,7 +90,7 @@ The `currval()` and `lastval()` functions work correctly for all types of global ## Automatic sequence conversion -In PGD 6.0 and later, the act of joining a node to a PGD group or creating a new group will also trigger an automatic conversion of any local sequences into global sequences. The [`bdr.default_sequence_kind`](/pgd/latest/reference/pgd-settings/#bdrdefault_sequence_kind) is used to determine the kind of sequence to convert the sequences into. If this is set to `local`, the sequences are left as local sequences. If it is set to `galloc`, `snowflakeid`, or `timeshard`, the sequences are converted to that sequence kind. Conversion to `galloc` is performed in a way that ensures that the sequence will not conflict with any other sequences in the group. +In PGD 6.0 and later, the act of joining a node to a PGD group or creating a new group will also trigger an automatic conversion of any local sequences into global sequences. The [`bdr.default_sequence_kind`](/pgd/latest/reference/pgd-settings/#bdrdefault_sequence_kind) should be set to `distributed`. This will then select the best kind of sequence to convert the local sequences into. If `bdr.default_sequence_kind` is set to `local`, the sequences are left as local sequences. Conversions to `galloc` is performed in a way that ensures that the sequence will not conflict with any other sequences in the group. If you decide to start with local sequences and later switch to galloc sequences, you can do so by setting the `bdr.default_sequence_kind` to `galloc` and then running the `bdr.alter_sequence_set_kind()` function on each sequence you want to convert. Do be aware though that you will need to manually set the starting values of the sequences to ensure that they do not conflict with any existing values in the table. See [converting a local sequence to a galloc sequence](#converting-a-local-sequence-to-a-galloc-sequence) for more information about this in general and specifically [how to set a new start value for a sequence](#2-set-a-new-start-value-for-the-sequence). From 9a1366ca0e41c33060c9ca6ebf17567127ac3e6e Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Tue, 13 May 2025 10:25:35 +0100 Subject: [PATCH 070/145] Now clear of 3.6 and 3.7 references Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/reference/monitoring/sql.mdx | 3 +- .../heterogeneous_clusters.mdx | 32 ------------------- .../pgd/6/reference/node_management/index.mdx | 4 --- 3 files changed, 1 insertion(+), 38 deletions(-) delete mode 100644 product_docs/docs/pgd/6/reference/node_management/heterogeneous_clusters.mdx diff --git a/product_docs/docs/pgd/6/reference/monitoring/sql.mdx b/product_docs/docs/pgd/6/reference/monitoring/sql.mdx index 2aa91953e0e..85824c53184 100644 --- a/product_docs/docs/pgd/6/reference/monitoring/sql.mdx +++ b/product_docs/docs/pgd/6/reference/monitoring/sql.mdx @@ -624,8 +624,7 @@ other or network latency is high, the default value of `bdr.raft_global_election_timeout` (6 seconds) might not be enough. If Raft consensus is still not working even after making sure everything is correct, consider increasing `bdr.raft_global_election_timeout` to 30 -seconds on all nodes. For PGD 3.6.11 and later, setting -`bdr.raft_global_election_timeout` requires only a server reload. +seconds on all nodes. Given how Raft consensus affects cluster operational tasks, and also as Raft consensus is directly responsible for advancing the group slot, diff --git a/product_docs/docs/pgd/6/reference/node_management/heterogeneous_clusters.mdx b/product_docs/docs/pgd/6/reference/node_management/heterogeneous_clusters.mdx deleted file mode 100644 index 98247d9b4e2..00000000000 --- a/product_docs/docs/pgd/6/reference/node_management/heterogeneous_clusters.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Joining a heterogeneous cluster ---- - - -A PGD 4.0 node can join an EDB Postgres Distributed cluster running 3.7.x at a specific -minimum maintenance release (such as 3.7.6) or a mix of 3.7 and 4.0 nodes. -This procedure is useful when you want to upgrade not just the PGD -major version but also the underlying PostgreSQL major -version. You can achieve this by joining a 3.7 node running on -PostgreSQL 12 or 13 to an EDB Postgres Distributed cluster running 3.6.x on -PostgreSQL 11. The new node can also -run on the same PostgreSQL major release as all of the nodes in the -existing cluster. - -PGD ensures that the replication works correctly in all directions -even when some nodes are running 3.6 on one PostgreSQL major release and -other nodes are running 3.7 on another PostgreSQL major release. However, -we recommend that you quickly bring the cluster into a -homogenous state by parting the older nodes once enough new nodes -join the cluster. Don't run any DDLs that might -not be available on the older versions and vice versa. - -A node joining with a different major PostgreSQL release can't use -physical backup taken with [`bdr_init_physical`](/pgd/latest/reference/tables-views-functions/nodes#bdr_init_physical), and the node must join -using the logical join method. Using this method is necessary because the major -PostgreSQL releases aren't on-disk compatible with each other. - -When a 3.7 node joins the cluster using a 3.6 node as a -source, certain configurations, such as conflict resolution, -aren't copied from the source node. The node must be configured -after it joins the cluster. \ No newline at end of file diff --git a/product_docs/docs/pgd/6/reference/node_management/index.mdx b/product_docs/docs/pgd/6/reference/node_management/index.mdx index 49bb760ef69..6bcc9bbbd1b 100644 --- a/product_docs/docs/pgd/6/reference/node_management/index.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/index.mdx @@ -8,7 +8,6 @@ navigation: - creating_and_joining - viewing_topology - removing_nodes_and_groups - - heterogeneous_clusters - connections_dsns_and_ssl - replication_slots - node_recovery @@ -39,9 +38,6 @@ with nodes and subgroups. * [Removing nodes and groups](removing_nodes_and_groups) shows the process to follow to safely remove a node from a group or a group from a cluster. -* [Heterogeneous clusters](heterogeneous_clusters) looks at how your PGD cluster - can interoperate with PGD nodes from earlier editions of PGD. - * [Connection DSNs](connections_dsns_and_ssl) introduces the DSNs or connection strings needed to connect directly to a node in a PGD cluster. It also covers how to use SSL/TLS certificates to provide authentication and encryption From b584c6d3e6b200b0adf384fc5b1870c0f48b18b4 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Tue, 13 May 2025 15:57:01 +0100 Subject: [PATCH 071/145] First draft of uuid docs Signed-off-by: Dj Walker-Morgan --- .../pgd/6/reference/node_management/index.mdx | 15 +- .../maintainance_with_proxies.mdx | 168 ------------------ .../reference/node_management/node_uuids.mdx | 31 ++++ .../node_management/replication_slots.mdx | 117 ++++++------ .../catalogs-visible.mdx | 41 +++-- 5 files changed, 118 insertions(+), 254 deletions(-) delete mode 100644 product_docs/docs/pgd/6/reference/node_management/maintainance_with_proxies.mdx create mode 100644 product_docs/docs/pgd/6/reference/node_management/node_uuids.mdx diff --git a/product_docs/docs/pgd/6/reference/node_management/index.mdx b/product_docs/docs/pgd/6/reference/node_management/index.mdx index 6bcc9bbbd1b..cf5f132c045 100644 --- a/product_docs/docs/pgd/6/reference/node_management/index.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/index.mdx @@ -9,9 +9,10 @@ navigation: - viewing_topology - removing_nodes_and_groups - connections_dsns_and_ssl - - replication_slots - node_recovery - automatic_sync + - node_uuids + - replication_slots --- @@ -41,10 +42,7 @@ with nodes and subgroups. * [Connection DSNs](connections_dsns_and_ssl) introduces the DSNs or connection strings needed to connect directly to a node in a PGD cluster. It also covers how to use SSL/TLS certificates to provide authentication and encryption - between servers and between clients. - -* [Replication slots](replication_slots) examines how the Postgres replication - slots are consumed when PGD is operating. + between servers and between clients. * [Node recovery](node_recovery) details the steps needed to bring a node back into service after a failure or scheduled downtime and the impact it has on @@ -53,5 +51,8 @@ with nodes and subgroups. * [Automatic Sync](automatic_sync) looks at how the automatic sync feature works in PGD and how it can be used to keep nodes in sync with each other. -* [Maintenance commands through proxies](maintainance_with_proxies) shows how to send maintenance commands to - nodes that you can't directly access, such as those behind a proxy. +* [Node UUIDs](node_uuids) explains how the UUIDs of nodes are used in PGD and + how they are generated. + +* [Replication slots](replication_slots) examines how the Postgres replication + slots are consumed when PGD is operating. diff --git a/product_docs/docs/pgd/6/reference/node_management/maintainance_with_proxies.mdx b/product_docs/docs/pgd/6/reference/node_management/maintainance_with_proxies.mdx deleted file mode 100644 index 10d9205f1e4..00000000000 --- a/product_docs/docs/pgd/6/reference/node_management/maintainance_with_proxies.mdx +++ /dev/null @@ -1,168 +0,0 @@ ---- -title: Maintenance commands through proxies ---- - -## Maintenance and performance - -As a general rule, you should never perform maintenance operations on a cluster's write leader. -Maintenance operations such as `VACUUM` can be quite disruptive to the smooth running of a busy server and often detrimental to workload performance. -Therefore, it's best to run maintenance commands on any node in a group that isn't the write leader. -Generally, this requires you to connect directly and issue the maintenance commands on the non-write-leader nodes. -But in some situations, this isn't possible. - -## Maintenance and proxies - -Proxies, by design, always connect to and send commands to the current write leader. -This usually means that you must not connect by way of a proxy to perform maintenance. -PGD clusters nodes can present a direct connection for psql and PGD CLI clients that you can use to issue maintenance commands to the server on those nodes. -But there are environment in which the PGD cluster is deployed where a proxy is the only way to access the cluster. - -For example, in EDB Cloud Service, PGD clusters are locked down such that the only access to the database is through an instance of PGD Proxy. -This configuration reduces the footprint of the cluster and makes it more secure. However, it requires that you use a different way of sending maintenance requests to the cluster's nodes. - -The technique outlined here is generally useful for despatching commands to specific nodes without being directly connected to that node's server. - -## Maintenance commands - -The term *maintenance commands* refers to: - -* `VACUUM` -* Non-replicated DDL commands (which you might want to manually replicate) - - -## A note on node names - -The servers in the cluster are referred to by their PGD cluster node names. To get a list of node names in your cluster, use: - -```SQL -select node_name from bdr.node; -``` - -!!! Tip -For more details, see the [`bdr.node`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrnode) table. -!!! - -This command lists just the node names. If you need to know the group they are a member of, use: - -``` -select node_name, node_group_name from bdr.node_summary; -``` - -!!! Tip -For more details, see the [`bdr.node_summary`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrnode_summary) table. -!!! - -## Finding the write leader - -If you're connected through the proxy, then you're connected to the write leader. -Run `select node_name from bdr.local_node_summary` to see the name of the node: - -``` -select node_name from bdr.local_node_summary; -__OUTPUT__ - node_name ------------------- -node-two -(1 row) -``` - -This is the node you do **not** want to run your maintenance tasks on. - -``` -select * from bdr.node_group_routing_summary; -__OUTPUT__ - node_group_name | write_lead | previous_write_lead | read_nodes ------------------+------------------+---------------------+------------------------- - dc1 | node-two | node-one | {node-one,node-three} -``` - -Where the `write_lead` is the node determined earlier (node-two), you can also see the two `read_nodes` (node-one and node-three). -It's on these nodes that you can safely perform maintenance. - - -!!! Tip -You can perform that operation with a single query: -```SQL -select read_nodes from bdr.node_group_routing_summary where write_lead = (select node_name from bdr.local_node_summary); -``` -!!! - -## Using `bdr.run_on_nodes()` -PGD has the ability to run specific commands on specific nodes using the `bdr.run_on_nodes()` function. This function takes two parameters: an array of node names and the command you want to run on those nodes. For example: - -```SQL -SELECT bdr.run_on_nodes(ARRAY['node-one','node-three'],'vacuum full foo'); -__OUTPUT__ - - run_on_nodes ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ - [{"dsn": "host=host-one port=5444 dbname=bdrdb", "node_id": "807899305", "response": {"command_status": "VACUUM"}, "node_name": "node-one", "query_send_time": "2024-01-16 16:24:35.418323+00"}, {"dsn": "host=host-three port=5432 dbname=bdrdb", "node_id": "199017004", "response": {"command_status": "VACUUM"}, "node_name": "node", "query_send_time": "2024-01-16 16:24:35.4542+00"}] -``` - -This command runs the `vacuum full foo` command on the node-one and node-three nodes. -The node names are passed to the function in an array. - -The `bdr.run_on_nodes` function reports its results as JSONB. -The results include the name of the node and the response (or error message) resulting from running the command. -Other fields included might be include and might not be relevant. - -The results also appear as a single string that's hard to read. By applying some formatting to this string, it can become more readable. - -## Formatting `bdr.run_on_nodes()` output - -Using Postgres's JSON expressions, you can reduce the output to just the columns you're interested in. The following command is functionally equivalent to the previous example but lists only the node and response as its results: - -```SQL -select q->>'node_name' as node, q->>'response' as response FROM jsonb_array_elements(bdr.run_on_nodes(ARRAY['node-one','node-three'], 'VACUUM FULL foo')) q; -__OUTPUT__ - node | response -------------------+------------------------------ - node-one | {"command_status": "VACUUM"} - node-three | {"command_status": "VACUUM"} -``` - -If an error occurs, the `command_status` field is set to error. An additional `error_message` value is included in the response. For example: - -```SQL -select q->>'node_name' as node, q->>'response' as response FROM jsonb_array_elements(bdr.run_on_nodes(ARRAY['node-one','node-three'], 'VACUUM FULL fool')) q; -__OUTPUT__ - node | response -------------------+-------------------------------------------------------------------------------------------- - node-one | {"error_message": "ERROR: relation \"fool\" does not exist\n", "command_status": "ERROR"} - node-three | {"error_message": "ERROR: relation \"fool\" does not exist\n", "command_status": "ERROR"} -(2 rows) -``` - -## Defining a function for maintenance - -If you find yourself regularly issuing maintenance commands to one node at a time, you can define a function to simplify things: - -```SQL -create or replace function runmaint(nodename varchar, command varchar) returns TABLE(node text,response jsonb) as $$ -begin -return query -select (q->>'node_name')::text, (q->'response') from jsonb_array_elements(bdr.run_on_nodes(ARRAY [nodename], command)) as q; -end; -$$ language 'plpgsql'; -``` - -This function takes a node name and a command and runs the command on that node, returning the results as shown in this interaction: - -```SQL -select runmaint('node-one','VACUUM FULL foo'); -__OUTPUT__ - runmaint -------------------------------------------------------- - (node-one,"{""command_status"": ""VACUUM""}") -``` - -You can break up the response by using `select * from`: - -```SQL -select * from runmaint('node-one','VACUUM FULL foo'); -__OUTPUT__ - node | response -------------------+------------------------------ - node-one | {"command_status": "VACUUM"} -(1 row) -``` diff --git a/product_docs/docs/pgd/6/reference/node_management/node_uuids.mdx b/product_docs/docs/pgd/6/reference/node_management/node_uuids.mdx new file mode 100644 index 00000000000..28a1e510be6 --- /dev/null +++ b/product_docs/docs/pgd/6/reference/node_management/node_uuids.mdx @@ -0,0 +1,31 @@ +--- +title: Node UUIDs +navTitle: Node UUIDs +description: Node UUIDs in PGD +--- + +In PGD 6, each node now has a UUID that is used to identify the node in the cluster. This UUID is generated when the node is created and is unique to that node. The UUID can be found in various places in PGD, including: + +* The `bdr.node` table, which contains information about each node in the cluster. +* The `bdr.node_summary` view, which provides a human readable view of the nodes in the cluster. +* The `bdr.local_node` table, which contains information about the local node. +* The uuid values also appear in the naming of the replication slots that are created for each node. + +Although used throughour PGD's node management, the use of UUIDs should not impact any existing functionality or features in PGD. The UUIDs are used internally to identify nodes and groups, and do not change the way that users interact with PGD. + +### Why UUIDs? + +UUIDs are used in PGD to provide a unique identifier for each node in the cluster. Previous versions of PGD used the node name as an identifier which could lead to conflicts if two nodes had the same name. By using UUIDs, PGD can ensure that each node has a unique identifier that will not change over time. This is especially important in a distributed system like PGD where nodes may be added or removed from the cluster frequently. The UUID ensures that although a new node may have the same name as an existing node, it will have a different UUID and will not conflict with the existing node. + +### How are UUIDs generated? + +When a new node is created, a UUID is generated for that node. This UUID is created using a combination of the current timestamp and a strong random number generator. This ensures that the UUID is unique and cannot be easily guessed. The generated UUID is then stored in the `bdr.node` table and is used to identify the node in the cluster. + +### What happens if a node is removed and a replacement added? + +If a node is removed from the cluster and a replacement node is added, the replacement node will be assigned a new UUID. This ensures that the replacement node is treated as a separate entity in the cluster and will not conflict with the existing nodes. But, PGD will require that the old node be fully parted from the cluster before it accepts the new node. The UUID of the replacement node will then be used in the same way as the UUIDs of the other nodes in the cluster. + +### UUID related changes in PGD 6 + +* The `generation` field in the `bdr.node` table, which was previously used to differntiate between nodes is no longer used. It will remain at 0 for all nodes. +* the `node_uuid` field in the `bdr.node` table is will never be null on PGD6. It may be null in the future with a mixed version cluster. diff --git a/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx b/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx index d371c7059a8..a34927d9ed6 100644 --- a/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx @@ -2,58 +2,59 @@ title: Replication slots created by PGD --- -On a PGD master node, the following replication slots are -created by PGD: +In previous versions of PGD, replication slots had human-readable names. With PGD 6, that has switched over to using UUIDs for nodes and groups +to ensure better identification. -- One *group slot*, named `bdr__` -- N-1 *node slots*, named `bdr___`, where N is the total number of PGD nodes in the cluster, - including direct logical standbys, if any +Replication slots are used by PostgreSQL to track the progress of replication. They are used to ensure that the data being replicated +is not lost and that the replication process is consistent. In PGD, replication slots are used to track the progress of replication +between nodes in a cluster. Each node in a PGD cluster has its own replication slots, which are used to track the progress of replication +to and from that node. Replication slots are also used to track the progress of replication between groups in a PGD cluster. Each group +in a PGD cluster has its own replication slots, which are used to track the progress of replication to and from that group. -!!! Warning - Don't drop those slots. PGD creates and manages them and drops them when or if necessary. +- One group slot, named `bdr__` +- N-1 node slots named `bdr_node__`, where N is the total number of nodes in the cluster, including direct logical standbys, if any. + +Where `topgroupuuid` is the UUID of the top-level group and `dbhash` is a hash of the database name. You can obtain the UUID of the top-level group using + +```sql +select node_group_uuid from bdr.node_group where node_group_parent_id=0; +``` -On the other hand, you can create or drop replication slots required by software like Barman -or logical replication using the appropriate commands -for the software without any effect on PGD. -Don't start slot names used by other software with the -prefix `bdr_`. +And `dbhash` is a hash of the database name. You can obtain the hash using: -For example, in a cluster composed of the three nodes `alpha`, `beta`, and -`gamma`, where PGD is used to replicate the `mydb` database and the -PGD group is called `mygroup`: +```sql +select to_hex(hashtext('pgddb')); +``` + +And the `targetnodeuuid` is the UUID of the target node. You can obtain the UUID of the target node using: -- Node `alpha` has three slots: - - One group slot named `bdr_mydb_mygroup` - - Two node slots named `bdr_mydb_mygroup_beta` and - `bdr_mydb_mygroup_gamma` -- Node `beta` has three slots: - - One group slot named `bdr_mydb_mygroup` - - Two node slots named `bdr_mydb_mygroup_alpha` and - `bdr_mydb_mygroup_gamma` -- Node `gamma` has three slots: - - One group slot named `bdr_mydb_mygroup` - - Two node slots named `bdr_mydb_mygroup_alpha` and - `bdr_mydb_mygroup_beta` +```sql +select node_uuid from bdr.node where node_name=''; +``` -## Group replication slot +The complete group slot name is returned by the function [`bdr.local_group_slot_name()`](/pgd/latest/reference/tables-views-functions/functions#bdrlocal_group_slot_name). -The group slot is an internal slot used by PGD primarily to track the -oldest safe position that any node in the PGD group (including all logical -standbys) has caught up to, for any outbound replication from this node. +!!! Warning + Don't drop those slots. PGD creates and manages them and drops them when or if necessary. + * Avoid touching slots prefixed with `bdr_` slots directly. + * And do not start slot names with the prefix `bdr_`. -The group slot name is given by the function [`bdr.local_group_slot_name()`](/pgd/latest/reference/tables-views-functions/functions#bdrlocal_group_slot_name). +## Group slot -The group slot can: +The group slot is used to track the progress of +replication between groups in a PGD cluster. Each group in a PGD +cluster has its own group slot, which is used to track the progress of -- Join new nodes to the PGD group without having all existing nodes +The group slot is used to: + +- Join new nodes to the PGD group without having all existing nodes up and running (although the majority of nodes should be up). This process doesn't incur data loss in case the node that was down during join starts replicating again. -- Part nodes from the cluster consistently, even if some nodes haven't +- Part nodes from the cluster consistently, even if some nodes haven't caught up fully with the parted node. -- Hold back the freeze point to avoid missing some conflicts. -- Keep the historical snapshot for timestamp-based snapshots. +- Hold back the freeze point to avoid missing some conflicts. +- Keep the historical snapshot for timestamp-based snapshots. The group slot is usually inactive and is fast forwarded only periodically in response to Raft progress messages from other nodes. @@ -61,26 +62,22 @@ in response to Raft progress messages from other nodes. !!! Warning Don't drop the group slot. Although usually inactive, it's still vital to the proper operation of the EDB Postgres Distributed cluster. If you drop it, - then some or all of the features can stop working or have - incorrect outcomes. - -## Hashing long identifiers - -The name of a replication slot, like any other PostgreSQL -identifier, can't be longer than 63 bytes. PGD handles this by -shortening the database name, the PGD group name, and the name of the -node in case the resulting slot name is too long for that limit. -Shortening an identifier is carried out by replacing the final section -of the string with a hash of the string itself. - -For example, consider a cluster that replicates a database -named `db20xxxxxxxxxxxxxxxx` (20 bytes long) using a PGD group named -`group20xxxxxxxxxxxxx` (20 bytes long). The logical replication slot -associated to node `a30xxxxxxxxxxxxxxxxxxxxxxxxxxx` (30 bytes long) -is called since `3597186`, `be9cbd0`, and `7f304a2` are respectively the hashes -of `db20xxxxxxxxxxxxxxxx`, `group20xxxxxxxxxxxxx`, and -`a30xxxxxxxxxxxxxxxxxxxxxxxxxx`. + then some or all of PGD's features can stop working or have incorrect outcomes. + +## Other slot names + +Other functionality within PGD makes use of replication slots. + +For example, when a node is added to a group, a slot is created for that node to track its progress in the replication process. + +This slot is named `bdr_node___tmp`. + +There are also slots created for the analytics and decoding features of PGD. +These slots are named: + +| Slot type | Slot name | +|----------------------------------------|----------------------------------------------------| +| Forwarding slot, leader-to-leader slot | `bdr_node___` | +| Analytics slot | `bdr_analytics__` | +| Decoding slot | `bdr_decoder__` | -``` -bdr_db20xxxx3597186_group20xbe9cbd0_a30xxxxxxxxxxxxx7f304a2 -``` diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx index 8f9bc500b1c..dd830f8b063 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/catalogs-visible.mdx @@ -448,10 +448,11 @@ This table identifies the local node in the current database of the current Post #### `bdr.local_node` columns | Name | Type | Description | -| ----------- | ------- | --------------------------- | +|-------------|---------|-----------------------------| | node_id | oid | ID of the node | | pub_repsets | text\[] | Published replication sets | | sub_repsets | text\[] | Subscribed replication sets | +| node_uuid | uuid | UUID of the node | ### `bdr.local_node_summary` @@ -481,22 +482,23 @@ The view [`bdr.node_summary`](#bdrnode_summary) provides a human-readable versio #### `bdr.node` columns -| Name | Type | Description | -| --------------------- | -------- | ----------------------------------------------------------------------------- | -| node_id | oid | ID of the node | -| node_name | name | Name of the node | -| node_group_id | oid | ID of the node group | -| source_node_id | oid | ID of the source node | -| synchronize_structure | "char" | Schema synchronization done during the join | -| node_state | oid | Consistent state of the node | -| target_state | oid | State that the node is trying to reach (during join or promotion) | -| seq_id | int4 | Sequence identifier of the node used for generating unique sequence numbers | -| dbname | name | Database name of the node | -| node_dsn | char | Connection string for the node | -| proto_version_ranges | int\[] | Supported protocol version ranges by the node | +| Name | Type | Description | +|-----------------------|----------|-----------------------------------------------------------------------------| +| node_id | oid | ID of the node | +| node_name | name | Name of the node | +| node_group_id | oid | ID of the node group | +| source_node_id | oid | ID of the source node | +| synchronize_structure | "char" | Schema synchronization done during the join | +| node_state | oid | Consistent state of the node | +| target_state | oid | State that the node is trying to reach (during join or promotion) | +| seq_id | int4 | Sequence identifier of the node used for generating unique sequence numbers | +| dbname | name | Database name of the node | +| node_dsn | char | Connection string for the node | +| proto_version_ranges | int\[] | Supported protocol version ranges by the node | | generation | smallint | Counter incremented when a node joins with the same name as a previous node | -| node_kind | oid | ID of the node kind | -| node_join_finished | boolean | Check if the join is finished | +| node_kind | oid | ID of the node kind | +| node_join_finished | boolean | Check if the join is finished | +| node_uuid | uuid | UUID of the node (UNIQUE) | ### `bdr.node_catchup_info` @@ -750,7 +752,7 @@ node. #### `bdr.node_summary` columns | Name | Type | Description | -| ---------------------- | ---- | --------------------------------------------------------------------------- | +|------------------------|------|-----------------------------------------------------------------------------| | node_name | name | Name of the node | | node_group_name | name | Name of the PGD group the node is part of | | interface_connstr | text | Connection string to the node | @@ -758,9 +760,10 @@ node. | peer_target_state_name | text | State that the node is trying to reach (during join or promotion) | | node_seq_id | int4 | Sequence identifier of the node used for generating unique sequence numbers | | node_local_dbname | name | Database name of the node | -| node_id | oid | OID of the node | -| node_group_id | oid | OID of the PGD node group | +| node_id | oid | OID of the node | +| node_group_id | oid | OID of the PGD node group | | node_kind_name | oid | Node kind name | +| node_uuid | uuid | UUID of the node | ### `bdr.parted_origin_catchup_info` From 759a212c226e294c99ef7365fe7e048720233a65 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Wed, 14 May 2025 07:20:04 +0100 Subject: [PATCH 072/145] Fix from review Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/reference/node_management/node_uuids.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/node_management/node_uuids.mdx b/product_docs/docs/pgd/6/reference/node_management/node_uuids.mdx index 28a1e510be6..9281f75325a 100644 --- a/product_docs/docs/pgd/6/reference/node_management/node_uuids.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/node_uuids.mdx @@ -19,7 +19,7 @@ UUIDs are used in PGD to provide a unique identifier for each node in the cluste ### How are UUIDs generated? -When a new node is created, a UUID is generated for that node. This UUID is created using a combination of the current timestamp and a strong random number generator. This ensures that the UUID is unique and cannot be easily guessed. The generated UUID is then stored in the `bdr.node` table and is used to identify the node in the cluster. +When a new node is created, a UUID is generated for that node. This UUID is created using the kernel's strong random number generator and guaranteed to be uniformly random. This ensures that the UUID is unique and cannot be easily guessed. The generated UUID is then stored in the `bdr.node` table and is used to identify the node in the cluster. ### What happens if a node is removed and a replacement added? @@ -27,5 +27,5 @@ If a node is removed from the cluster and a replacement node is added, the repla ### UUID related changes in PGD 6 -* The `generation` field in the `bdr.node` table, which was previously used to differntiate between nodes is no longer used. It will remain at 0 for all nodes. +* The `generation` field in the `bdr.node` table, which was previously used to differentiate between nodes is no longer used. It will remain at 0 for all nodes. * the `node_uuid` field in the `bdr.node` table is will never be null on PGD6. It may be null in the future with a mixed version cluster. From f34a86400dd0b050b096b4ddf6edba454a746be3 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan <126472455+djw-m@users.noreply.github.com> Date: Wed, 14 May 2025 02:29:54 -0400 Subject: [PATCH 073/145] DOCS-1532-pgd-6-0-release-notes (#6766) * First draft Signed-off-by: Dj Walker-Morgan * Fixups on list Signed-off-by: Dj Walker-Morgan * Add the release notes for PGD CLI changes * update generated release notes * Add the release note for sorted output for cli * update generated release notes * Address review comments * update generated release notes * Add missing relnotes These had not yet been carried over from the BDR source. * update generated release notes * Add BDR-5401 Signed-off-by: Dj Walker-Morgan * update generated release notes * Vadim's notes added Signed-off-by: Dj Walker-Morgan --------- Signed-off-by: Dj Walker-Morgan Co-authored-by: Jagdish Kewat Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Ian Barwick --- product_docs/docs/pgd/6/rel_notes/index.mdx | 2 +- .../pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx | 133 ++++++- .../pgd/6/rel_notes/src/relnote_6.0.0.yml | 343 +++++++++++++++++- 3 files changed, 463 insertions(+), 15 deletions(-) diff --git a/product_docs/docs/pgd/6/rel_notes/index.mdx b/product_docs/docs/pgd/6/rel_notes/index.mdx index 85172d6be08..810b7015e9e 100644 --- a/product_docs/docs/pgd/6/rel_notes/index.mdx +++ b/product_docs/docs/pgd/6/rel_notes/index.mdx @@ -15,4 +15,4 @@ The EDB Postgres Distributed documentation describes the latest version of EDB P | Release Date | EDB Postgres Distributed | |---|---| -| 15 May 2025 | [6.0.0](./pgd_6.0.0_rel_notes) | +| 22 May 2025 | [6.0.0](./pgd_6.0.0_rel_notes) | diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx index 29bdecdab1a..58250e9d4d8 100644 --- a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx +++ b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx @@ -5,18 +5,61 @@ originalFilePath: product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml editTarget: originalFilePath --- -Released: 15 May 2025 +Released: 22 May 2025 EDB Postgres Distributed 6.0.0 is a major update to PGD and sees the introduction on Essential and Extended editions. ## Highlights -- Connection Manager replaces PGD Proxy. +- New built-in Connection Manager. +- New CLI command for cluster setup. ## Features
Group
Commit		CAMO Lag
Control 		Synchronous
Commit 		Group
Commit		CAMO Lag
Control 		Synchronous
Commit
Group Commit Group Commit ⛔︎ ❌ ✅ ✅
CAMO CAMO ❌ ⛔︎ ✅ ❌
Lag Control Lag Control ✅ ✅ ⛔︎ ✅
Synchronous Commit Synchronous Commit ✅ ❌ ✅
- + + + + + + + + + + + +
DescriptionAddresses
Connection Manager replaces PGD Proxy

The connection manager is a new component that replaces the PGD Proxy. It is responsible for managing connections to the database and routing them to the appropriate nodes in the cluster. The connection manager provides improved performance, scalability, and reliability compared to the previous PGD Proxy.

+
Built-in connection manager

New built-in connection manager which handles routing of connections automatically and allows enforcing of read-only connections to non-leader.

+
CLI cluster setup

The PGD CLI now allows initial cluster setup as well as adding nodes from command-line using pgd node setup command.

+
Set sequence kind on group create/join

Transform the sequences in distributed based on the bdr.default_sequence_kind GUC when creating/joining a bdr group instead of when creating the node as done in older versions.

+
Set startvalue for distributed sequences automatically

Set the startvalue for galloc sequences to the following valid number after the last used by the local sequence. With this change, when creating distributed sequences and specifically galloc, there is no need to adjust the startvalue based on what might be already used.

+
Enabling of automatic sync and reconciliation

Link to a detailed google doc is provided below

+
Add node_uuid column to bdr.node and bdr.local_node

The node_uuid uniquely identifies instance of a node of a given name. Random node_uuid is generated when node is created and remains constant for the lifetime of the node. The node_id column is now derived from node_uuid instead of node name.

+

For the time being a node needs to be fully parted before before node of the same name can be rejoined, this may be relaxed in future releases to permit rejoin as soon as part_node process for the old instance has commenced and before it completed.

+

For the time being upgrades from older PGD versions and mixed-version operation in clusters with older PGD nodes are not supported. This limitation will be addressed in future releases.

+
Change replication origin and slot naming scheme

Replication origin and slot names now use node uuid and thus correspond to particular incarnation of a node of a given name. Similarly node group uuid is used instead of group name. Hash of database name is used in lieu of database name.

+

Please note that origin and node names should be treated as opaque identifiers from user's perspective, one shouldn't rely on the structure of these names nor expect these to be particularly meaningful to a human operator.

+

The new naming scheme is as follows:

+

Slots Naming Convention

+
    +
  • normal slot to a node => bdr_node_<targetuuid>_<dbhash>
    • +
  • join slot for node => bdr_node_<targetuuid>_<dbhash>_tmp
    • +
  • group slot for a topgroup => bdr_group_<topgroupuuid>_<dbhash>
    • +
  • slot for any forwarding + lead to lead => bdr_node_<targetuuid>_<originidhex>_<dbhash>
    • +
  • analytics slot => bdr_analytics_<groupuuid>_<dbhash>
    • +
  • decoding slot => bdr_decoder_<topgroupuuid>_<dbhash>
    • +
+

Origins Naming Convention:

+
    +
  • normal origin to a node => bdr_<originuuid>_<dbhash>
    • +
  • fwd origin to a source node => bdr_<originuuid>_<sourceoidhex>_<dbhash>
    • +
+
Limit on the number of node groups allowed in the system for PGD Essential.

Ensure that no more than three node groups (one top group and two subgroups) can exist at any given time. If the limit is exceeded, an error is raised.

+
Enforced PGD Essential limits - data node count

Don't allow PGD Essential clusters to join more than 4 data nodes.

+
Added bdr.wait_node_confirm_lsn() function which waits until a given reaches a given LSN

bdr.wait_node_confirm_lsn() will look at the confirmed_flush_lsn of the given node when available, otherwise it will query pg_replication_origin_progress() of that node, and wait for the specified LSN to be reached by said node.

+
Subscriber-only nodes can now be added to data node groups

So far subscriber-only nodes could only be added to node groups of type "subscriber-only". But now a subscriber-only node can be added to a data node group too. Only node_kind='subscriber_only' needs to be specified while doing a create_node as before. the join_node_group can be done on a data node group.

+
Add bdr.local_analytics_slot_name() SQL function.

Returns name of analytics slot. This merely produces the correct name irrespective of whether analytics feature is in use.

+
Add node_uuid column to bdr.node_summary view.

Added to complement the addition of the node_uuid column to bdr.node and bdr.local_node

@@ -24,6 +67,24 @@ EDB Postgres Distributed 6.0.0 is a major update to PGD and sees the introductio ## Enhancements + + + + + + + + + + + + + + + + + +
DescriptionAddresses
Multiple conflicting rows resolution

Both pk_exists and multiple_unique_conflicts conflict types can now resolve more than one conflicting row by removing any old rows that are part of the conflict. The multiple_unique_conflicts now defaults to update_if_newer resolver, so it does not throw error by default anymore.

+
Improved bdr.stat_activity view

The backend_type now shows consistent worker type for PGD workers without the extra process identification. The wait_event_type and wait_event include more wait events now, instead of showing "extension" for some events. Also, connection management related columns are added to show real client address/port and whether the session is read-only.

+
The PARTED node is removed automatically from all nodes in the cluster.

From PGD 6.0.0, bdr.part_node functionality is enhanced to remove the parted node’s metadata automatically from all nodes in the cluster.

+
    +
  • For local node, it will remove all the node metadata, including information about remote nodes.
    • +
  • For remote node, it removes only metadata for that specific node. +Hence with this release
    • +
  • A node will remain in PART_CLEANUP state till group slots of all nodes are caught up to all the transactions originating from the PARTED node
    • +
  • A node will not remain in PARTED state as the node is removed as soon as it moves to PARTED state.
    • +
+
The --summary and --options flags for pgd node show CLI command.

Add the --summary and --options flags to pgd node show command to filter the output of the pgd node show command. +This also maintains symmetry with other show commands.

+
More GUCs verfied in pgd cluster verify CLI command.

Add the bdr.lock_table_locking and bdr.truncate_locking GUCs to list of GUCs verfied in pgd cluster verify command.

+
Table rewriting ALTER TABLE... ALTER COLUMN calls are now supported.

Changing a column's type command which causes the whole table to be rewritten and the change isn't binary coercible is now supported:

CREATE TABLE foo (c1 int,c2 int, c3 int, c4 box, UNIQUE(c1, c2) INCLUDE(c3,c4));
 ALTER TABLE foo ALTER c1 TYPE bigint; – results into table rewrite
@@ -36,6 +97,72 @@ ALTER TABLE foo ALTER data TYPE BYTEA USING data::bytea;
Restrictions on non-immutable ALTER TABLE... ADD COLUMN calls have been removed.

The restrictions on non-immutable ALTER TABLE... ADD COLUMN calls have been removed.

Introduce bdr.node_group_config_summary view

The new bdr.node_group_config_summary view contains detailed information about group options, including effective value, source of the effective value, default value, whether the value can be inherited, etc. This is in similar spirit to pg_settings

+
Leader DML lock

New lock type leader DML lock is used by default for locking DDL statements that need to block DML. This lock locks on write-leaders only, no requiring all nodes to participate in the locking operation. Old behavior can be restored by adjusting bdr.ddl_locking configuration parameter.

+
Disabling bdr.xact_replication in run_on_* functions

Functions run_on_nodes, run_on_all_nodes and run_on_group now sets bdr.xact_replication to off by default.

+
Replica Identity full by default

The auto value for bdr.default_replica_identity changed to +REPLICA IDENTITY FULL. This setting prevents some edge cases in +conflict detection between inserts, updates and deletes across node +crashes and recovery.

+

When the PGD group is created and the database of the initial PGD node is not empty (i.e. has some tables with data) the REPLICA IDENTITY of all tables will be set according to bdr.default_replica_identity.

+
Tablespace replication as a DDL operation is supported.

Tablespace operations CREATE/ALTER/DROP TABLESPACE are now replicated as a DDL operation. Where users are +running a configuration with multiple nodes on the same machine, you will need to enable the developer option allow_in_place_tablespace.

+
Improve the CLI debug messages.

Improve the formating of the log messages to be more readable and symmetrical with Postgres log messages.

+
New column for pgd cluster verify --settings CLI command output.

Add the recommended_value column to the result of the pgd cluster verify --settings command. +The column will not be displayed in tabular output but will be displayed in JSON output.

+
Display sorted output for CLI.

The output for the commands with tabular output will be sorted by the resource name. +The commands that display more than one resource, the output will be sorted by each resource column in order.

+
Subscriber-only nodes replication.

Subscriber-only nodes now receive data only after it has been replicated to majority of data nodes. This does not require any special configuration. Subsequently bdr.standby_slot_names and bdr.standby_slots_min_confirmed options are removed as similar physical standby functionality is provided in pg_failover_slots extension and in PG17+.

+
Remove the deprecated legacy CLI commands.

Remove the old (PGD 5 and below) CLI commands, which were deprecated but supported for backward compatibility.

+
Commit scope logic is now only run on data nodes.

Previously, non-data nodes would attempt to handle, but not process commit scope logic, which could lead to confusing, albeit harmless log messages.

+
Explicitly log the start and stop of dump and restore operations.

This provides greater visibility into the node cloning process and assists with debugging possible issues.

+
+ + +## Changes + + + + + + +
DescriptionAddresses
Routing is now enabled by default on subgroups

Routing (and by extension raft) is now enabled by default on data-groups (subgroups with data nodes).

+
Function bdr.join_node_group may no longer be executed in a transaction.

As it is not possible to roll back a group join, it can not form part of an idempotent transaction.

+
Deprecated pause_in_standby parameter removed from function bdr.join_node_group().

pause_in_standby has been deprecated since PGD 5.0.0. Logical standby nodes should be specified as such when executing bdr.create_node()

+
BDR global sequences can no longer created as or set to UNLOGGED

Unlogged BDR sequences may display unexpected behaviour following a server crash. Existing unlogged BDR sequences may be converted to logged ones.

+
+ + +## Bug Fixes + + + + + + + +
DescriptionAddresses
Fix the CLI pgd cluster show command issues on a degraded cluster.

The pgd cluster show command failed with error for clock drift if only one node is up and running in a N node cluster. +The command is fixed to return valid output for other components viz., health and summary while reporting a valid error for clock-drift.

+
Fix the CLI pgd node show command issue if a non-existent node is specified.

The pgd node show command crashed if a non-existent node is specified to the command. +The command is fixed to fail gracefully with appropriate error message.

+
Fixed issue where parting node may belong to a non-existing group

When parting a given node, that same node may have subscriptions whose +origin was already parted and the group dropped. Previously this would break PGD, and has since been fixed.

+
num_writers should be positive or -1

The num_writers option, used in bdr.alter_node_group_option() and bdr.alter_node_group_config() should be positive or -1.

+
Fixed deadlock issue in bdr_init_physical.

Fixed deadlock between bdr_init_physical cleaning unwanted node data and concurrent monitoring queries.

+
46952
Fixed new cluster node consistency issue.

Fixed an issue when new node joining the cluster finishes CATCHUP phase before getting its replication progress against all data nodes. This may cause new node being out of sync with the cluster.

+
diff --git a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml index 8030da50d64..2fb1016fab2 100644 --- a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml +++ b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml @@ -1,20 +1,14 @@ # yaml-language-server: $schema=https://raw.githubusercontent.com/EnterpriseDB/docs/refs/heads/develop/tools/automation/generators/relgen/relnote-schema.json product: EDB Postgres Distributed version: 6.0.0 -date: 15 May 2025 +date: 22 May 2025 intro: | EDB Postgres Distributed 6.0.0 is a major update to PGD and sees the introduction on Essential and Extended editions. highlights: | - - Connection Manager replaces PGD Proxy. + - New built-in Connection Manager. + - New CLI command for cluster setup. relnotes: -- relnote: Connection Manager replaces PGD Proxy - details: | - The connection manager is a new component that replaces the PGD Proxy. It is responsible for managing connections to the database and routing them to the appropriate nodes in the cluster. The connection manager provides improved performance, scalability, and reliability compared to the previous PGD Proxy. - jira: BDR-5123 - addresses: "" - type: Feature - impact: High -- relnote: Table rewriting `ALTER TABLE... ALTER COLUMN` calls are now supported. +- relnote: Table rewriting `ALTER TABLE... ALTER COLUMN` calls are now supported. details: | Changing a column's type command which causes the whole table to be rewritten and the change isn't binary coercible is now supported: ```sql @@ -26,11 +20,12 @@ relnotes: CREATE TABLE foo (id serial primary key,data text); ALTER TABLE foo ALTER data TYPE BYTEA USING data::bytea; ``` - Table rewrites can hold an AccessExclusiveLock for extended periods on larger tables. + Table rewrites can hold an AccessExclusiveLock for extended periods on larger tables. jira: BDR-5724 addresses: "" type: Enhancement impact: Medium + - relnote: Restrictions on non-immutable `ALTER TABLE... ADD COLUMN` calls have been removed. details: | The restrictions on non-immutable `ALTER TABLE... ADD COLUMN` calls have been removed. @@ -38,3 +33,329 @@ relnotes: addresses: "" type: Enhancement impact: Medium + +- relnote: Set sequence kind on group create/join + details: | + Transform the sequences in distributed based on the `bdr.default_sequence_kind` GUC when creating/joining a bdr group instead of when creating the node as done in older versions. + jira: BDR-5972 + type: Feature + impact: High +- relnote: Set startvalue for distributed sequences automatically + details: | + Set the startvalue for galloc sequences to the following valid number after the last used by the local sequence. With this change, when creating distributed sequences and specifically galloc, there is no need to adjust the startvalue based on what might be already used. + jira: BDR-5972 + type: Feature + impact: High + +- relnote: Limit on the number of node groups allowed in the system for PGD Essential. + details: | + Ensure that no more than three node groups (one top group and two subgroups) can exist at any given time. If the limit is exceeded, an error is raised. + jira: BDR-6215 + type: Feature + impact: Medium + +- relnote: Enforced PGD Essential limits - data node count + details: | + Don't allow PGD Essential clusters to join more than 4 data nodes. + jira: BDR-6213 + type: Feature + impact: Medium + +- relnote: Routing is now enabled by default on subgroups + details: | + Routing (and by extension raft) is now enabled by default on data-groups (subgroups with data nodes). + jira: BDR-4956 + type: Change + impact: Medium + +- relnote: Fixed issue where parting node may belong to a non-existing group + details: | + When parting a given node, that same node may have subscriptions whose + origin was already parted and the group dropped. Previously this would break PGD, and has since been fixed. + jira: BDR-5461 + type: Bug fix + impact: Medium + +- relnote: Multiple conflicting rows resolution + details: | + Both `pk_exists` and `multiple_unique_conflicts` conflict types can now resolve more than one conflicting row by removing any old rows that are part of the conflict. The `multiple_unique_conflicts` now defaults to `update_if_newer` resolver, so it does not throw error by default anymore. + jira: BDR-6336 + type: Enhancement + impact: Highest + +- relnote: num_writers should be positive or -1 + details: | + The num_writers option, used in bdr.alter_node_group_option() and bdr.alter_node_group_config() should be positive or -1. + jira: BDR-6294 + type: Bug fix + impact: Medium + +- relnote: Introduce `bdr.node_group_config_summary` view + details: | + The new `bdr.node_group_config_summary` view contains detailed information about group options, including effective value, source of the effective value, default value, whether the value can be inherited, etc. This is in similar spirit to `pg_settings` + jira: BDR-4696 + type: Enhancement + impact: Medium + +- relnote: Added `bdr.wait_node_confirm_lsn()` function which waits until a given reaches a given LSN + details: | + `bdr.wait_node_confirm_lsn(`) will look at the confirmed_flush_lsn of the given node when available, otherwise it will query `pg_replication_origin_progress()` of that node, and wait for the specified LSN to be reached by said node. + jira: BDR-5200 + type: Feature + impact: Medium + +- relnote: Improved `bdr.stat_activity` view + details: | + The `backend_type` now shows consistent worker type for PGD workers without the extra process identification. The `wait_event_type` and `wait_event` include more wait events now, instead of showing "extension" for some events. Also, connection management related columns are added to show real client address/port and whether the session is read-only. + jira: BDR-4833, BDR-743 + type: Enhancement + impact: Highest + +- relnote: Leader DML lock + details: | + New lock type leader DML lock is used by default for locking DDL statements that need to block DML. This lock locks on write-leaders only, no requiring all nodes to participate in the locking operation. Old behavior can be restored by adjusting `bdr.ddl_locking` configuration parameter. + jira: BDR-6216 + type: Enhancement + impact: Medium + +- relnote: Built-in connection manager + details: | + New built-in connection manager which handles routing of connections automatically and allows enforcing of read-only connections to non-leader. + jira: BDR-6260 + type: Feature + impact: Highest + +- relnote: CLI cluster setup + details: | + The PGD CLI now allows initial cluster setup as well as adding nodes from command-line using `pgd node setup` command. + jira: BDR-5727 + type: Feature + impact: Highest + +- relnote: Disabling bdr.xact_replication in run_on_* functions + details: | + Functions `run_on_nodes`, `run_on_all_nodes` and `run_on_group` now sets `bdr.xact_replication` to `off` by default. + jira: BDR-1331 + type: Enhancement + impact: Medium + +- relnote: Replica Identity full by default + details: | + The `auto` value for `bdr.default_replica_identity` changed to + REPLICA IDENTITY FULL. This setting prevents some edge cases in + conflict detection between inserts, updates and deletes across node + crashes and recovery. + + When the PGD group is created and the database of the initial PGD node is not empty (i.e. has some tables with data) the REPLICA IDENTITY of all tables will be set according to `bdr.default_replica_identity`. + jira: BDR-5977 + type: Enhancement + impact: Medium + +- relnote: The PARTED node is removed automatically from all nodes in the cluster. + details: | + From PGD 6.0.0, bdr.part_node functionality is enhanced to remove the parted node’s metadata automatically from all nodes in the cluster. + - For local node, it will remove all the node metadata, including information about remote nodes. + - For remote node, it removes only metadata for that specific node. + Hence with this release + - A node will remain in PART_CLEANUP state till group slots of all nodes are caught up to all the transactions originating from the PARTED node + - A node will not remain in PARTED state as the node is removed as soon as it moves to PARTED state. + + jira: BDR-5975 + type: Enhancement + impact: High + +- relnote: Enabling of automatic sync and reconciliation + details: | + Link to a detailed google doc is provided below + jira: BDR-4798 + type: Feature + impact: High + +- relnote: Subscriber-only nodes can now be added to data node groups + details: | + So far subscriber-only nodes could only be added to node groups of type "subscriber-only". But now a subscriber-only node can be added to a data node group too. Only node_kind='subscriber_only' needs to be specified while doing a create_node as before. the join_node_group can be done on a data node group. + jira: BDR-6106 + type: Feature + impact: Medium + +- relnote: Add node_uuid column to bdr.node and bdr.local_node + details: | + The node_uuid uniquely identifies instance of a node of a given name. Random node_uuid is generated when node is created and remains constant for the lifetime of the node. The node_id column is now derived from node_uuid instead of node name. + + For the time being a node needs to be fully parted before before node of the same name can be rejoined, this may be relaxed in future releases to permit rejoin as soon as part_node process for the old instance has commenced and before it completed. + + For the time being upgrades from older PGD versions and mixed-version operation in clusters with older PGD nodes are not supported. This limitation will be addressed in future releases. + jira: BDR-6222 + type: Feature + impact: High + +- relnote: Change replication origin and slot naming scheme + details: | + Replication origin and slot names now use node uuid and thus correspond to particular incarnation of a node of a given name. Similarly node group uuid is used instead of group name. Hash of database name is used in lieu of database name. + + Please note that origin and node names should be treated as opaque identifiers from user's perspective, one shouldn't rely on the structure of these names nor expect these to be particularly meaningful to a human operator. + + The new naming scheme is as follows: + + #### Slots Naming Convention + + * normal slot to a node => `bdr_node__` + * join slot for node => `bdr_node___tmp` + * group slot for a topgroup => `bdr_group__` + * slot for any forwarding + lead to lead => `bdr_node___` + * analytics slot => `bdr_analytics__` + * decoding slot => `bdr_decoder__` + + #### Origins Naming Convention: + + * normal origin to a node => `bdr__` + * fwd origin to a source node => `bdr___` + jira: BDR-6157 + type: Feature + impact: High + +- relnote: Add `bdr.local_analytics_slot_name()` SQL function. + details: | + Returns name of analytics slot. This merely produces the correct name irrespective of whether analytics feature is in use. + jira: BDR-6469 + type: Feature + impact: Low + +- relnote: Add node_uuid column to `bdr.node_summary` view. + details: | + Added to complement the addition of the node_uuid column to bdr.node and bdr.local_node + jira: BDR-6478 + type: Feature + impact: Low + +- relnote: Tablespace replication as a DDL operation is supported. + details: | + Tablespace operations `CREATE/ALTER/DROP TABLESPACE` are now replicated as a DDL operation. Where users are + running a configuration with multiple nodes on the same machine, you will need to enable the developer option [`allow_in_place_tablespace`](https://www.postgresql.org/docs/current/runtime-config-developer.html#GUC-ALLOW-IN-PLACE-TABLESPACES). + jira: BDR-5401 + type: Enhancement + impact: Medium + +- relnote: Remove the deprecated legacy CLI commands. + details: | + Remove the old (PGD 5 and below) CLI commands, which were deprecated but supported for backward compatibility. + jira: BDR-6333 + type: Enhancement + impact: Low + +- relnote: Improve the CLI debug messages. + details: | + Improve the formating of the log messages to be more readable and symmetrical with Postgres log messages. + jira: BDR-6101 + type: Enhancement + impact: Medium + +- relnote: The `--summary` and `--options` flags for `pgd node show` CLI command. + details: | + Add the `--summary` and `--options` flags to `pgd node show` command to filter the output of the `pgd node show` command. + This also maintains symmetry with other `show` commands. + jira: BDR-6145 + type: Enhancement + impact: High + +- relnote: More GUCs verfied in `pgd cluster verify` CLI command. + details: | + Add the `bdr.lock_table_locking` and `bdr.truncate_locking` GUCs to list of GUCs verfied in `pgd cluster verify` command. + jira: BDR-5308 + type: Enhancement + impact: High + +- relnote: New column for `pgd cluster verify --settings` CLI command output. + details: | + Add the `recommended_value` column to the result of the `pgd cluster verify --settings` command. + The column will not be displayed in tabular output but will be displayed in JSON output. + jira: BDR-5308 + type: Enhancement + impact: Medium + +- relnote: Display sorted output for CLI. + details: | + The output for the commands with tabular output will be sorted by the resource name. + The commands that display more than one resource, the output will be sorted by each resource column in order. + jira: BDR-6094 + type: Enhancement + impact: Medium + +- relnote: Fix the CLI `pgd cluster show` command issues on a degraded cluster. + details: | + The `pgd cluster show` command failed with error for clock drift if only one node is up and running in a N node cluster. + The command is fixed to return valid output for other components viz., `health` and `summary` while reporting a valid error for `clock-drift`. + jira: BDR-6135 + type: Bug Fix + impact: High + +- relnote: Fix the CLI `pgd node show` command issue if a non-existent node is specified. + details: | + The `pgd node show` command crashed if a non-existent node is specified to the command. + The command is fixed to fail gracefully with appropriate error message. + jira: BDR-6292 + type: Bug Fix + impact: High + +- relnote: Commit scope logic is now only run on data nodes. + details: | + Previously, non-data nodes would attempt to handle, but not process commit scope logic, which could lead to confusing, albeit harmless log messages. + jira: BDR-6325 + type: Enhancement + impact: Low + +- relnote: Explicitly log the start and stop of dump and restore operations. + details: | + This provides greater visibility into the node cloning process and assists with debugging possible issues. + jira: BDR-4501 + type: Enhancement + impact: Low + +- relnote: Function `bdr.join_node_group` may no longer be executed in a transaction. + details: | + As it is not possible to roll back a group join, it can not form part of an idempotent transaction. + jira: BDR-6337 + type: Change + impact: Low + +- relnote: Deprecated `pause_in_standby` parameter removed from function `bdr.join_node_group()`. + details: | + `pause_in_standby` has been deprecated since PGD 5.0.0. Logical standby nodes should be specified as such when executing `bdr.create_node()` + jira: BDR-6385 + type: Change + impact: Low + +- relnote: BDR global sequences can no longer created as or set to `UNLOGGED` + details: | + Unlogged BDR sequences may display unexpected behaviour following a server crash. Existing unlogged BDR sequences may be converted to logged ones. + jira: BDR-6103 + type: Change + impact: Low + +- relnote: Subscriber-only nodes replication. + component: BDR + details: | + Subscriber-only nodes now receive data only after it has been replicated to majority of data nodes. This does not require any special configuration. Subsequently bdr.standby_slot_names and bdr.standby_slots_min_confirmed options are removed as similar physical standby functionality is provided in pg_failover_slots extension and in PG17+. + jira: BDR-5961 + addresses: "" + type: Enhancement + impact: Medium + +- relnote: Fixed deadlock issue in bdr_init_physical. + component: BDR + details: | + Fixed deadlock between bdr_init_physical cleaning unwanted node data and concurrent monitoring queries. + jira: BDR-6313 + addresses: 46952 + type: Bug Fix + impact: Low + +- relnote: Fixed new cluster node consistency issue. + component: BDR + details: | + Fixed an issue when new node joining the cluster finishes CATCHUP phase before getting its replication progress against all data nodes. This may cause new node being out of sync with the cluster. + jira: BDR-5961 + addresses: "" + type: Bug Fix + impact: Low + From 4a0961229a52b70078012791c3d9420d74cd960f Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Wed, 14 May 2025 08:27:33 +0100 Subject: [PATCH 074/145] Review fixes regroups Signed-off-by: Dj Walker-Morgan --- .../node_management/replication_slots.mdx | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx b/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx index a34927d9ed6..47b0f7fc4d3 100644 --- a/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx @@ -35,15 +35,17 @@ select node_uuid from bdr.node where node_name=''; The complete group slot name is returned by the function [`bdr.local_group_slot_name()`](/pgd/latest/reference/tables-views-functions/functions#bdrlocal_group_slot_name). !!! Warning - Don't drop those slots. PGD creates and manages them and drops them when or if necessary. - * Avoid touching slots prefixed with `bdr_` slots directly. - * And do not start slot names with the prefix `bdr_`. +Don't drop those slots. PGD creates and manages them and drops them when or if necessary. + +- Avoid touching slots prefixed with `bdr_` slots directly. +- And do not start slot names with the prefix `bdr_`. +!!! + ## Group slot -The group slot is used to track the progress of -replication between groups in a PGD cluster. Each group in a PGD -cluster has its own group slot, which is used to track the progress of +The group slot is used to track the progress of replication of the nodes in a PGD cluster that are replicating from the node. +Each node in a PGD cluster has its own group slot, which is used to track the progress of replication to and from that node. The group slot is used to: @@ -56,8 +58,7 @@ The group slot is used to: - Hold back the freeze point to avoid missing some conflicts. - Keep the historical snapshot for timestamp-based snapshots. -The group slot is usually inactive and is fast forwarded only periodically -in response to Raft progress messages from other nodes. +The group slot is usually inactive and is fast forwarded only periodically in response to Raft progress messages from other nodes. !!! Warning Don't drop the group slot. Although usually inactive, it's From 8a1ef06cd84c7ff6c29280e5d76e84ac2b32155c Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Wed, 14 May 2025 08:28:43 +0100 Subject: [PATCH 075/145] Tidy essential architecture languages Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/essential-how-to/architectures/index.mdx | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx index 9b123e8f5b7..777d0998f25 100644 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx @@ -24,14 +24,12 @@ The Essential standard architecture has been created to be easy to deploy and ma ## Near/far architecture - Ideal for disaster recovery -The Near/Far architecture is designed for a single location which needs to be reasonably highly available, but also needs to be able to recover from a disaster. It does this by having a two data node cluster in the primary location and a single data node in a secondary location. +The Near/Far architecture is designed for a single location which needs to be reasonably highly available, but also needs to be able to recover from a disaster. It does this by having a two data node cluster in the primary location and a single data node in a secondary location. The two data nodes in the primary location are configured in a multi-master replication configuration, just like the standard architecture. The single data node in the secondary location is configured as a subscriber to the primary location. This means that all changes made to the data in the primary location are replicated to the secondary location. In the event of a partial failure at the primary location, the system will switch to the other data node, also with a complete replica of the data, and continue to operate. It will also continue replication to the secondary location. When the failed node at the primary location comes back, it will rejoin and begin replicating data from the node that is currently primary. -In the event of a complete failure in the primary location, the secondary location's database has a complete replica of the data. The connection manager in the primary location will automatically failover to the secondary location and all writes will be directed to that node. When the primary location comes back online, it will automatically rejoin the cluster and begin replicating data from the secondary location. - - +In the event of a complete failure in the primary location, the secondary location's database has a complete replica of the data. Applications should be configured to automatically failover to the secondary location and all writes will be directed to that node. When the primary location comes back online, it will automatically rejoin the cluster and begin replicating data from the secondary location. From 0c35731bd9efe5cfa021ffd5ed4f02ac663fdd67 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Wed, 14 May 2025 08:29:19 +0100 Subject: [PATCH 076/145] SOP placeholders Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/essential-how-to/sop/install.mdx | 3 ++- .../pgd/6/essential-how-to/sop/monitoring.mdx | 2 ++ .../docs/pgd/6/essential-how-to/sop/upgrade.mdx | 15 +++++++++++++-- 3 files changed, 17 insertions(+), 3 deletions(-) diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/install.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/install.mdx index ffcf47f09f6..ca25cb9e47c 100644 --- a/product_docs/docs/pgd/6/essential-how-to/sop/install.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/sop/install.mdx @@ -3,5 +3,6 @@ title: Installation SOPs navTitle: Installation --- -Part of the nature of a distributed system like PGD is that new nodes can be added (and removed) at any time. This means that you do need to know how to install PGD on a fresh node, how to configure it, and how to add it to an existing cluster. This section covers the essential SOPs for installing PGD on a new node, configuring it, and adding it to an existing cluster. +This SOP covers the essential SOPs for installing PGD on a new node, configuring it, and adding it to an existing cluster. +Part of the nature of a distributed system like PGD is that new nodes can be added (and removed) at any time. This means that you do need to know how to install PGD on a fresh node, how to configure it, and how to add it to an existing cluster. diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/monitoring.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/monitoring.mdx index 993b94b8aea..07b4c337813 100644 --- a/product_docs/docs/pgd/6/essential-how-to/sop/monitoring.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/sop/monitoring.mdx @@ -3,3 +3,5 @@ title: Monitoring SOPs navTitle: Monitoring --- +This SOP covers the process of monitoring the Postgres database servers running on the nodes in a PGD cluster. It includes best practices for monitoring, tools to use, and common issues that may arise during the monitoring process. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx index 973efd341ea..618f2e22690 100644 --- a/product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx @@ -1,5 +1,16 @@ --- -title: Upgrading -navTitle: Upgrade +title: Upgrading Postgres +navTitle: Upgrades +redirects: + - /pgd/latest/upgrades --- +This SOP covers the process of upgrading the Postgres database servers running on the nodes in a PGD cluster. There are two main upgrade paths: minor and major upgrades. Minor upgrades are typically performed to apply security patches or bug fixes, while major upgrades involve significant changes to the database engine and may require more extensive testing and planning. + +## Minor Upgrades + +## Major Upgrades + +## Upgrading to EDB Postgres Distributed 6 + +See the [reference documentation](../reference/upgrade) for more information on upgrading to EDB Postgres Distributed 6.0.0. From 73dd19bd197ab1fe15ec7ccdebf422d2a1e1d975 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Wed, 14 May 2025 08:29:52 +0100 Subject: [PATCH 077/145] Reference fixes and explanded intro Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/expanded-how-to/index.mdx | 18 ++++++++++++++++++ .../pgd/6/reference/nodes/witness_nodes.mdx | 5 ++++- product_docs/docs/pgd/6/reference/upgrade.mdx | 10 ++++++++++ 3 files changed, 32 insertions(+), 1 deletion(-) create mode 100644 product_docs/docs/pgd/6/reference/upgrade.mdx diff --git a/product_docs/docs/pgd/6/expanded-how-to/index.mdx b/product_docs/docs/pgd/6/expanded-how-to/index.mdx index 2b2c42e7f70..8a31427e7c4 100644 --- a/product_docs/docs/pgd/6/expanded-how-to/index.mdx +++ b/product_docs/docs/pgd/6/expanded-how-to/index.mdx @@ -3,3 +3,21 @@ title: Expanded How-to navTitle: Expanded How-to --- +## Overview + +PGD Expanded offers the full PGD capability set to users; where PGD Essential is a best practice, controlled and simplified version of PGD. The expanded version is for users who want to take advantage of the full set of features and capabilities of PGD, including advanced architectures, custom configurations, and more complex use cases. + +PGD Expanded is designed for users who need the highest level of flexibility and control over their database environments. It provides a comprehensive set of tools and features that allow users to customize their deployments and optimize their performance. + +## Expanded Features + +The following features are enabled in PGD Expanded: + +- **Multi-master replication**: PGD Expanded supports multi-master replication, allowing users to create a highly available and fault-tolerant database environment. This feature enables users to write to any node in the cluster, providing maximum flexibility and scalability. + +- **Conflict resolution**: PGD Expanded's support for multi-master replication includes advanced conflict resolution capabilities, allowing users to handle conflicts that may arise during replication. This feature ensures that data consistency is maintained across all nodes in the cluster. + +- **Advanced durability**: PGD Expanded opens up the full set of durability options in PGD with customizable commit scopes offering flexibility beyond PGD Essentials pre-defined commit scopes. This feature allows users to optimize their database performance and durability based on their specific needs. + +- **Custom configurations**: PGD Expanded allows users to customize their database configurations to meet their specific needs. Where PGD Essential supports two basic architectures with limited numbers of nodes and groups, there are no restrictions on the number of nodes, node types, or replication configurations that can be used in a PGD Expanded deployment. + diff --git a/product_docs/docs/pgd/6/reference/nodes/witness_nodes.mdx b/product_docs/docs/pgd/6/reference/nodes/witness_nodes.mdx index 2ae84ad7e78..78a2a0e5dc7 100644 --- a/product_docs/docs/pgd/6/reference/nodes/witness_nodes.mdx +++ b/product_docs/docs/pgd/6/reference/nodes/witness_nodes.mdx @@ -2,6 +2,8 @@ title: Witness nodes navTitle: Witness description: Used to enable consensus in PGD clusters, both within clusters and outside regions +redirects: + - /pgd/latest/nodes/witness_nodes --- A witness node is a lightweight node that functions as a data node but that @@ -33,4 +35,5 @@ now only three nodes out of six are available, which isn't enough for a consensus. To avoid this scenario, you can deploy a witness node in a third region as part of the PGD cluster. This witness node will allow a consensus to be achieved for most operational requirements of the PGD cluster while a region -is unavailable. +is unavailable. + diff --git a/product_docs/docs/pgd/6/reference/upgrade.mdx b/product_docs/docs/pgd/6/reference/upgrade.mdx new file mode 100644 index 00000000000..8f947f90acf --- /dev/null +++ b/product_docs/docs/pgd/6/reference/upgrade.mdx @@ -0,0 +1,10 @@ +--- +title: Upgrading +navTitle: Upgrades +redirects: + - /pgd/latest/upgrades +--- + +## Upgrading to EDB Postgres Distributed 6 + +You cannot upgrade to EDB Postgres Distributed 6.0.0 from any earlier version of EDB Postgres Distributed 5.x or earlier. This will be possible in a future release. \ No newline at end of file From bb0a17bd0998b0eb33978120d3dbcbb5588c6133 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan <126472455+djw-m@users.noreply.github.com> Date: Wed, 14 May 2025 05:00:25 -0400 Subject: [PATCH 078/145] Docs 1464 pgd installation updates (#6800) * Reorganise and genericise Signed-off-by: Dj Walker-Morgan * Added essential durability Signed-off-by: Dj Walker-Morgan * misc fixes Signed-off-by: Dj Walker-Morgan * Tidy up Signed-off-by: Dj Walker-Morgan * First draft of uuid docs Signed-off-by: Dj Walker-Morgan * Fix from review Signed-off-by: Dj Walker-Morgan * DOCS-1532-pgd-6-0-release-notes (#6766) * First draft Signed-off-by: Dj Walker-Morgan * Fixups on list Signed-off-by: Dj Walker-Morgan * Add the release notes for PGD CLI changes * update generated release notes * Add the release note for sorted output for cli * update generated release notes * Address review comments * update generated release notes * Add missing relnotes These had not yet been carried over from the BDR source. * update generated release notes * Add BDR-5401 Signed-off-by: Dj Walker-Morgan * update generated release notes * Vadim's notes added Signed-off-by: Dj Walker-Morgan --------- Signed-off-by: Dj Walker-Morgan Co-authored-by: Jagdish Kewat Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Ian Barwick * Review fixes regroups Signed-off-by: Dj Walker-Morgan * Tidy essential architecture languages Signed-off-by: Dj Walker-Morgan * SOP placeholders Signed-off-by: Dj Walker-Morgan * Reference fixes and explanded intro Signed-off-by: Dj Walker-Morgan * Reorganise and genericise Signed-off-by: Dj Walker-Morgan * First draft of uuid docs Signed-off-by: Dj Walker-Morgan * SOP placeholders Signed-off-by: Dj Walker-Morgan * Reorganise and genericise Signed-off-by: Dj Walker-Morgan --------- Signed-off-by: Dj Walker-Morgan Co-authored-by: Jagdish Kewat Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Ian Barwick --- .../architectures/standard/index.mdx | 6 +- .../pgd/6/essential-how-to/durability.mdx | 76 ++++++++++++ .../6/essential-how-to/durability/index.mdx | 5 - .../docs/pgd/6/essential-how-to/index.mdx | 3 +- .../install/01-prerequisites.mdx | 2 +- .../install/02-configure-repositories.mdx | 81 +++++++++++++ ...mdx => 03-installing-database-and-pgd.mdx} | 113 ++++++------------ ...cluster.mdx => 04-configuring-cluster.mdx} | 83 +++++++++---- ...check-cluster.mdx => 05-check-cluster.mdx} | 95 ++++++++------- .../pgd/6/essential-how-to/install/index.mdx | 8 +- .../05-using-pgd-cli.mdx => pgd-cli.mdx} | 43 ++++--- .../{sop => sops}/backup-restore.mdx | 0 .../{sop => sops}/configure.mdx | 0 .../{sop => sops}/how-to-use-sops.mdx | 0 .../essential-how-to/{sop => sops}/index.mdx | 0 .../{sop => sops}/install.mdx | 0 .../6/essential-how-to/sops/monitoring.mdx | 7 ++ .../{sop => sops}/troubleshooting.mdx | 0 .../pgd/6/essential-how-to/sops/upgrade.mdx | 16 +++ .../pgd/6/expanded-how-to/architectures.mdx | 4 +- .../predefined-commit-scopes.mdx | 18 +-- .../node_management/replication_slots.mdx | 4 +- 22 files changed, 378 insertions(+), 186 deletions(-) create mode 100644 product_docs/docs/pgd/6/essential-how-to/durability.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/durability/index.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/install/02-configure-repositories.mdx rename product_docs/docs/pgd/6/essential-how-to/install/{02-installing-database-and-pgd.mdx => 03-installing-database-and-pgd.mdx} (51%) rename product_docs/docs/pgd/6/essential-how-to/install/{03-configuring-cluster.mdx => 04-configuring-cluster.mdx} (56%) rename product_docs/docs/pgd/6/essential-how-to/install/{04-check-cluster.mdx => 05-check-cluster.mdx} (56%) rename product_docs/docs/pgd/6/essential-how-to/{install/05-using-pgd-cli.mdx => pgd-cli.mdx} (89%) rename product_docs/docs/pgd/6/essential-how-to/{sop => sops}/backup-restore.mdx (100%) rename product_docs/docs/pgd/6/essential-how-to/{sop => sops}/configure.mdx (100%) rename product_docs/docs/pgd/6/essential-how-to/{sop => sops}/how-to-use-sops.mdx (100%) rename product_docs/docs/pgd/6/essential-how-to/{sop => sops}/index.mdx (100%) rename product_docs/docs/pgd/6/essential-how-to/{sop => sops}/install.mdx (100%) create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/monitoring.mdx rename product_docs/docs/pgd/6/essential-how-to/{sop => sops}/troubleshooting.mdx (100%) create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/upgrade.mdx diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/standard/index.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/standard/index.mdx index aaf86db74d4..dd5d2170f66 100644 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/standard/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/architectures/standard/index.mdx @@ -1,9 +1,9 @@ --- -title: Standard PGD Architectures -navTitle: Standard Architectures +title: Standard PGD Architecture +navTitle: Standard Architecture navigation: -- manual-deployments --- + diff --git a/product_docs/docs/pgd/6/essential-how-to/durability.mdx b/product_docs/docs/pgd/6/essential-how-to/durability.mdx new file mode 100644 index 00000000000..24ec03ffd4f --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/durability.mdx @@ -0,0 +1,76 @@ +--- +title: Durability in PGD Essential +navTitle: Durability +--- + +By default PGD Essential uses asynchronous replication between its nodes, but it can be configured to use synchronous replication as well. This allows for a high degree of flexibility in terms of data durability and availability. Asynchronous replication offers lower latency and higher throughput, while synchronous replication provides stronger consistency guarantees at the cost of performance. PGD Essential allows you to choose the replication strategy through the use of commit scopes. + +## Commit Scopes + +Commit scopes are a powerful feature of PGD Essential that allow you to control the durability and availability of your data. They enable you to specify the level of durability required for each transaction, allowing you to balance performance and consistency based on your application's needs. PGD Essential has four pre-defined commit scopes that you can use to control the durability of your transactions, among other things. + +- local protect +- lag protect +- majority protect +- adaptive protect + +The predefined commit scopes in PGD Essential are designed to provide a balance between performance and data safety. You cannot add, remove or modify a PGD Essential commit scope. In PGD Expanded, you can create and manage your own commit scopes, allowing for more flexibility and control over the durability guarantees. + +### `local protect` + +This is the default commit scope for PGD Essential. It provides asynchronous commit with no durability guarantees. This means that transactions are considered committed as soon as they are written to the local node's WAL, without waiting for any confirmation from other nodes in the cluster. + +### `lag protect` + +This commit scope ensures that transactions are considered committed only when the lag time is within a specified limit (30 seconds in this case) and the commit delay is also within a specified limit (10 seconds in this case). This helps to prevent data loss in case of network issues or node failures. + +### `majority protect` + +This commit scope provides a durability guarantee based on the majority origin group. It ensures that transactions are considered committed only when they are confirmed by the majority of nodes in the origin group. This helps to ensure data consistency and durability in case of node failures or network issues. + +### `adaptive protect` + +This commit scope provides a more flexible durability guarantee. It allows transactions to be considered committed based on the majority origin group synchronous commit, but it can degrade to asynchronous commit if the transaction cannot be confirmed within a specified timeout (10 seconds in this case). This is useful in scenarios where network latency or node failures may cause delays in confirming transactions. + +For more information on commit scopes, see the [Commit Scopes](/pgd/latest/reference/commit-scopes/) reference section and the [Predefined Commit Scopes](/pgd/latest/reference/commit-scopes/predefined-commit-scopes/) reference page. + +## Using Commit Scopes + +To use commit scopes in PGD Essential, you can specify the desired commit scope when executing a transaction. This allows you to control the durability and availability of your data based on your application's needs. For example, you can use the `lag protect` commit scope for transactions that require a higher level of durability, while using the `local protect` commit scope for transactions that prioritize performance over durability. + +### Within a transaction + +You can specify the commit scope for a transaction using the `SET LOCAL` command. For example, to use the `lag protect` commit scope for a transaction, you can execute the following commands: + +```sql +BEGIN; +SET LOCAL bdr.commit_scope = 'lag protect'; +-- Your transaction statements here +COMMIT; +``` + +This will ensure that the transaction is committed with the specified commit scope, providing the desired level of durability and availability. + +### For a session + +You can also set the commit scope for the entire session using the `SET` command. For example, to set the `majority protect` commit scope for the entire session, you can execute the following command: + +```sql +SET bdr.commit_scope = 'majority protect'; +``` + +This will ensure that all transactions executed in the session will use the specified commit scope, providing the desired level of durability and availability. + +### For a group + +You can also set the default commit scope for a PGD group using the bdr.alter_node_group_option()` function. For example, to set the `adaptive protect` commit scope for a PGD group, you can execute the following command: + +```sql +SELECT bdr.alter_node_group_option( + node_group_name:='mygroup', + config_key:='default_commit_scope', + config_value:='adaptive protect'); +``` + +This will ensure that all transactions executed in the specified PGD group will use the specified commit scope, providing the desired level of durability and availability, unless overridden by a session or transaction-level setting. + diff --git a/product_docs/docs/pgd/6/essential-how-to/durability/index.mdx b/product_docs/docs/pgd/6/essential-how-to/durability/index.mdx deleted file mode 100644 index d63a00aa6fa..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/durability/index.mdx +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Durability and PGD Essential -navTitle: Durability ---- - diff --git a/product_docs/docs/pgd/6/essential-how-to/index.mdx b/product_docs/docs/pgd/6/essential-how-to/index.mdx index 5bc1db439f1..028528a8ccd 100644 --- a/product_docs/docs/pgd/6/essential-how-to/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/index.mdx @@ -4,10 +4,11 @@ navTitle: Essential How-To navigation: - architectures - install +- pgd-cli - durability - autopartition - production-best-practices -- sop +- standard-operating-procedures description: Essential how-to guides for deploying and managing your PGD cluster. --- diff --git a/product_docs/docs/pgd/6/essential-how-to/install/01-prerequisites.mdx b/product_docs/docs/pgd/6/essential-how-to/install/01-prerequisites.mdx index 8a94e812f03..e18b249bb43 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/01-prerequisites.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/01-prerequisites.mdx @@ -1,5 +1,5 @@ --- -title: Prerequisites for manual deployment +title: 1 - Prerequisites for installation navTitle: Prerequisites --- diff --git a/product_docs/docs/pgd/6/essential-how-to/install/02-configure-repositories.mdx b/product_docs/docs/pgd/6/essential-how-to/install/02-configure-repositories.mdx new file mode 100644 index 00000000000..51657a66fc0 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/install/02-configure-repositories.mdx @@ -0,0 +1,81 @@ +--- +title: Step 2 - Configure repositories +navTitle: Configure repositories +description: Configuring the repositories for the database and pgd software on each host. +deepToC: true +--- + +On each host which you want to use as a PGD data node, you need to install the database and the PGD software. + +## Configure repositories + +Set the following environment variables: + +### `EDB_SUBSCRIPTION_TOKEN` + +This is the token you received when you registered for the EDB subscription. It is used to authenticate your access to the EDB repository. + +```bash +export EDB_SUBSCRIPTION_TOKEN= +``` + +### `EDB_SUBSCRIPTION_PLAN` + +This is the plan you subscribed to. It is used to determine which packages are available for installation. This is typically either `standard` or `enterprise`. + +```bash +# Set the EDB subscription plan +export EDB_SUBSCRIPTION_PLAN= +``` + +### `EDB_REPO_TYPE` + +This is the type of package manager you use, which informs the installer which type of package you need. This can be `deb` for Ubuntu/Debian or `rpm` for CentOS/RHEL. + +```bash +export EDB_REPO_TYPE= +``` + +## Install the repository/repositories + +For PGD Essential, there is just one repository to install. For PGD Extended, there are two repositories to install. + + + + + +Run the following command to install the EDB repository. This will add the EDB repository to your system's package manager, allowing you to install EDB packages. + +```bash +curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +``` + + + + + +```bash +curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/postgres_distributed/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +``` + + + + + +This command will download and run a script that configures your package manager to use the EDB repository. It will also install any necessary dependencies. + + +## Worked example + +In this example, we will configure the repositories on a CentOS/RHEL system that will allow us to install EDB Postgres Extended Server 17 with PGD Essential using an enterprise subscription. + +### Set the environment variables + +```bash +export EDB_SUBSCRIPTION_TOKEN=XXXXXXXXXXXXXX +export EDB_SUBSCRIPTION_PLAN=enterprise +export EDB_REPO_TYPE=rpm +curl -1sSLf " https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +``` + diff --git a/product_docs/docs/pgd/6/essential-how-to/install/02-installing-database-and-pgd.mdx b/product_docs/docs/pgd/6/essential-how-to/install/03-installing-database-and-pgd.mdx similarity index 51% rename from product_docs/docs/pgd/6/essential-how-to/install/02-installing-database-and-pgd.mdx rename to product_docs/docs/pgd/6/essential-how-to/install/03-installing-database-and-pgd.mdx index 5b49e62b7ae..9fb9c22b843 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/02-installing-database-and-pgd.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/03-installing-database-and-pgd.mdx @@ -1,5 +1,5 @@ --- -title: Installing the database and pgd +title: Step 3 - Installing the database and pgd navTitle: Installing description: Installing the database and pgd software on each host. deepToC: true @@ -7,55 +7,9 @@ deepToC: true On each host which you want to use as a PGD data node, you need to install the database and the PGD software. -## Configure repositories +After you have [configured the EDB repository](02-configure-repository), you can install the database and PGD software using your package manager. -Set the following environment variables: - -### `EDB_SUBSCRIPTION_TOKEN` - -This is the token you received when you registered for the EDB subscription. It is used to authenticate your access to the EDB repository. - -```bash -export EDB_SUBSCRIPTION_TOKEN= -``` - -### `EDB_SUBSCRIPTION_PLAN` - -This is the plan you subscribed to. It is used to determine which packages are available for installation. This is typically either `standard` or `enterprise`. - -```bash -# Set the EDB subscription plan -export EDB_SUBSCRIPTION_PLAN= -``` - -### `EDB_REPO_TYPE` - -This is the type of package manager you use, which informs the installer which type of package you need. This can be `deb` for Ubuntu/Debian or `rpm` for CentOS/RHEL. - -```bash -export EDB_REPO_TYPE= -``` - -## Install the repository - -Run the following command to install the EDB repository. This will add the EDB repository to your system's package manager, allowing you to install EDB packages. - -```bash -curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/setup.$EDB_REPO_TYPE.sh" | sudo -E bash -``` - -Or for dev: - -```bash -curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/dev/setup.$EDB_REPO_TYPE.sh" | sudo -E bash -curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/dev_postgres_distributed/setup.$EDB_REPO_TYPE.sh" | sudo -E bash -``` - -This command will download and run a script that configures your package manager to use the EDB repository. It will also install any necessary dependencies. - -## Install the database and PGD - -After you have installed the EDB repository, you can install the database and PGD software using your package manager. +## Install the database and PGD software ### Set the Postgres version @@ -75,33 +29,41 @@ export PGD_EDITION=essential ### Set the package names -#### EDB Postgres Advanced Server +Set an environment variable to specify the package names for the database and PGD software. The package names will vary depending on the database you are using and the platform you are on. + + -
+ +


+ +#### EDB Postgres Advanced Server - ```bash - export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-$PGD_EDITION-epas$PG_VERSION" - ``` +```shell +export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-$PGD_EDITION-epas$PG_VERSION" +``` - ```bash - export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-$PGD_EDITION-epas$PG_VERSION" - ``` +```shell +export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-$PGD_EDITION-epas$PG_VERSION" +``` + + + +


+ #### EDB Postgres Extended -
- @@ -120,12 +82,12 @@ export PGD_EDITION=essential + -#### Community PostgreSQL - - -
+ +


+#### Community PostgreSQL @@ -143,19 +105,27 @@ export PGD_EDITION=essential ``` - !!! Note Only PGD Expanded is available for Community PostgreSQL. !!! -### Install the database and PGD packages + + + + + + +


+ +### Run the installation command +Run the installation command appropriate for your platform. -```bash +```shell sudo apt install -y $EDB_PACKAGES ``` @@ -163,7 +133,7 @@ sudo apt install -y $EDB_PACKAGES -```bash +```shell sudo dnf install -y $EDB_PACKAGES ``` @@ -176,18 +146,11 @@ This command will install the specified packages and any dependencies they requi ## Worked example -In this example, we will install EDB Postgres Extended Server 17 with PGD Essential on a CentOS/RHEL system using an enterprise subscription. - -### Set the environment variables +In this example, we will install EDB Postgres Extended Server 17 with PGD Essential on a CentOS/RHEL system using an enterprise subscription using the repository confiuguration we set up in the [previous step's worked example](02-configure-repository#worked-example). ```bash -export EDB_SUBSCRIPTION_TOKEN=XXXXXXXXXXXXXX -export EDB_SUBSCRIPTION_PLAN=enterprise -export EDB_REPO_TYPE=rpm export PG_VERSION=17 export PGD_EDITION=essential export EDB_PACKAGES="edb-as$PG_VERSION edb-pgd6-$PGD_EDITION-epas$PG_VERSION" -curl -1sSLf " https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/setup.$EDB_REPO_TYPE.sh" | sudo -E bash sudo dnf install -y $EDB_PACKAGES ``` - diff --git a/product_docs/docs/pgd/6/essential-how-to/install/03-configuring-cluster.mdx b/product_docs/docs/pgd/6/essential-how-to/install/04-configuring-cluster.mdx similarity index 56% rename from product_docs/docs/pgd/6/essential-how-to/install/03-configuring-cluster.mdx rename to product_docs/docs/pgd/6/essential-how-to/install/04-configuring-cluster.mdx index a9e23738257..91312c516eb 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/03-configuring-cluster.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/04-configuring-cluster.mdx @@ -1,5 +1,5 @@ --- -title: Configuring the cluster +title: Step 4 - Configuring the cluster navTitle: Configuring deepToC: true --- @@ -12,16 +12,18 @@ This involves logging into each host and running the `pgd` command to create the These steps will vary according to which platform you are using and which version of Postgres you are using. -## Cluster names +## Cluster name -You will need to choose a name for your cluster. This is the name that will be used to identify the cluster in the PGD CLI and in the database. It will be referred to as `` in the examples. +You will need to choose a name for your cluster. This is the name that will be used to identify the cluster in the PGD CLI and in the database. It will be referred to as `` in the examples. If not specified, the default name is `pgd`. ## Group names You will also need to choose a name for the group. This is the name that will be used to identify the group in the PGD CLI and in the database. It will be referred to as `` in the examples. + The group name must be unique within the cluster. ## Node names + You will also need to choose a name for each node. This is the name that will be used to identify the node in the PGD CLI and in the database. It will be referred to as `` in the examples. This is separate from the host name, which is the name of the machine on which the node is running. The node name must be unique within the group and within the cluster. @@ -30,41 +32,78 @@ The node name must be unique within the group and within the cluster. The paths and users used in the examples will vary according to which version of Postgres you are using and which platform you are using. -### For EDB Postgres Advanced Server + + + You will use the system's `enterprisedb` user to run the `pgd` command. The database port is 5444. -#### On CentOS/RHEL + + -Postgres executable files are installed in `/usr/edb/as$PG_VERSION/bin/` and the data directory is in `/var/lib/edb/as$PG_VERSION/data/`. +| | | +|---------------------------|-------------------------------------| +| Postgres Executable files | `/usr/lib/edb-as/$PG_VERSION/bin/` | +| Postgres Data Directory | `/var/lib/edb-as/$PG_VERSION/main/` | -#### On Debian/Ubuntu + + -Postgres executable files are installed in `/usr/lib/edb-as/$PG_VERSION/bin/` and the data directory is in `/var/lib/edb-as/$PG_VERSION/main/`. +| | | +|---------------------------|------------------------------------| +| Postgres Executable files | `/usr/edb/as$PG_VERSION/bin/` | +| Postgres Data Directory | `/var/lib/edb/as$PG_VERSION/data/` | -### For EDB Postgres Extended + + + + You will use the system's `postgres` user to run the `pgd` command. The database port is 5432 -#### On CentOS/RHEL + + -Postgres Extended executable files are installed in `/usr/edb/pge$PG_VERSION/bin/` and the data directory is in `/var/lib/edb-pge/$PG_VERSION/data/`. +| | | +|---------------------------|--------------------------------------| +| Postgres Executable files | `/usr/lib/edb-pge/$PG_VERSION/bin/` | +| Postgres Data Directory | `/var/lib/edb-pge/$PG_VERSION/main/` | -#### On Debian/Ubuntu + + -Postgres Extended executable files are installed in `/usr/lib/edb-pge/$PG_VERSION/bin/` and the data directory is in `/var/lib/edb-pge/$PG_VERSION/main/`. +| | | +|---------------------------|--------------------------------------| +| Postgres Executable files | `/usr/edb/pge$PG_VERSION/bin/` | +| Postgres Data Directory | `/var/lib/edb-pge/$PG_VERSION/data/` | -### For Community PostgreSQL + + + + You will use the system's `postgres` user to run the `pgd` command. The database port is 5432. -#### On CentOS/RHEL + + + +| | | +|---------------------------|-----------------------------------------| +| Postgres Executable files | `/usr/lib/postgresql/$PG_VERSION/bin/` | +| Postgres Data Directory | `/var/lib/postgresql/$PG_VERSION/main/` | -Postgres executable files are installed in `/usr/pgsql-$PG_VERSION/bin/` and the data directory is in `/var/lib/pgsql/$PG_VERSION/data/`. + + -#### On Debian/Ubuntu +| | | +|---------------------------|------------------------------------| +| Postgres Executable files | `/usr/pgsql-$PG_VERSION/bin/` | +| Postgres Data Directory | `/var/lib/pgsql/$PG_VERSION/data/` | -Postgres executable files are installed in `/usr/lib/postgresql/$PG_VERSION/bin/` and the data directory is in `/var/lib/postgresql/$PG_VERSION/main/`. + + + + ## On each host @@ -87,7 +126,7 @@ export PATH=$PATH: On the first host, run the following command to create the cluster: ```bash -pgd node setup "host= user= port= dbname=bdrdb" --pgdata --group-name --cluster-name --create-group +pgd node setup --dsn "host= user= port= dbname=pgddb" --pgdata --group-name --cluster-name --create-group ``` This command will create the cluster and the group on the first host. It will also create the data directory and initialize the database. @@ -97,7 +136,7 @@ This command will create the cluster and the group on the first host. It will al On the second host, run the following command to create the cluster: ```bash -pgd node setup "host= user= port= dbname=bdrdb" --pgdata --cluster-dsn "host= user=pos tgres port= dbname=bdrdb" +pgd node setup --dsn "host= user= port= dbname=pgddb" --pgdata --cluster-dsn "host= user= port= dbname=pgddb" ``` This command will create the node on the second host, and then join the cluster using the cluster-dsn setting to connect to the first host. @@ -107,14 +146,14 @@ This command will create the node on the second host, and then join the cluster On the third host, run the following command to create the cluster: ```bash -pgd node setup "host= user= port= dbname=bdrdb" --pgdata --cluster-dsn "host= user= port= dbname=bdrdb" +pgd node setup --dsn "host= user= port= dbname=pgddb" --pgdata --cluster-dsn "host= user= port= dbname=pgddb" ``` This command will create the node on the third host, and then join the cluster using the cluster-dsn setting to connect to the first host. ## Worked example -In this example, we will configure the PGD Essential cluster with EDB Postgres Extended Server 17 on a CentOS/RHEL system using an enterprise subscription that we installed in the [previous worked example](02-installing-database-and-pgd). +In this example, we will configure the PGD Essential cluster with EDB Postgres Extended Server 17 on a CentOS/RHEL system using an enterprise subscription that we [configured](02-configure-repository) and [installed](03-installing-database-and-pgd) in the previous steps. We will now create a cluster called `pgd` with three nodes called `node1`, `node2`, and `node3`. diff --git a/product_docs/docs/pgd/6/essential-how-to/install/04-check-cluster.mdx b/product_docs/docs/pgd/6/essential-how-to/install/05-check-cluster.mdx similarity index 56% rename from product_docs/docs/pgd/6/essential-how-to/install/04-check-cluster.mdx rename to product_docs/docs/pgd/6/essential-how-to/install/05-check-cluster.mdx index 3db88ceac36..1bdea4aaee2 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/04-check-cluster.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/05-check-cluster.mdx @@ -1,10 +1,7 @@ --- -title: Step 4 - Checking the cluster +title: Step 5 - Checking the cluster navTitle: Checking the cluster deepToC: true -redirects: - - /pgd/latest/install-admin/admin-manual/installing/06-check-cluster/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-manual/installing/06-check-cluster/ #generated for pgd deploy-config-planning reorg --- ## Checking the cluster @@ -14,58 +11,65 @@ With the cluster up and running, it's worthwhile to run some basic checks to see The following example shows one quick way to do this, but you must ensure that any testing you perform is appropriate for your use case. +On any of the installed and configured nodes, log in and run `psql` to connect to the database. If you are using EDB Postgres Advanced Server, use the `enterprisedb` user, otherwise use `postgres`. If you configured the cluster with the previous steps you can use the pgddb database and pgdadmin user: + +```bash +sudo -iu postgres psql "host=host-1 port=5432 username=pgdadmin dbname=pgddb" +``` + * **Preparation** * Ensure the cluster is ready: - * Log in to the database on host-one/node-one. + * Log in to the database on host-1/node-1. * Run `select bdr.wait_slot_confirm_lsn(NULL, NULL);`. * When the query returns, the cluster is ready. * **Create data** The simplest way to test that the cluster is replicating is to log in to one node, create a table, and populate it. - * On node-one, create a table: + * On node-1, create a table: ```sql CREATE TABLE quicktest ( id SERIAL PRIMARY KEY, value INT ); ``` - * On node-one, populate the table: + * On node-1, populate the table: ```sql INSERT INTO quicktest (value) SELECT random()*10000 FROM generate_series(1,10000); ``` - * On node-one, monitor performance: + * On node-1, monitor performance: ```sql select * from bdr.node_replication_rates; ``` - * On node-one, get a sum of the value column (for checking): + * On node-1, get a sum of the value column (for checking): ```sql select COUNT(*),SUM(value) from quicktest; ``` * **Check data** - * Log in to node-two. - Log in to the database on host-two/node-two. - * On node-two, get a sum of the value column (for checking): + * Log in to node-2. + Log in to the database on host-2/node-2. + * On node-2, get a sum of the value column (for checking): ```sql select COUNT(*),SUM(value) from quicktest; ``` - * Compare with the result from node-one. - * Log in to node-three. - Log in to the database on host-three/node-three. - * On node-three, get a sum of the value column (for checking): + * Compare with the result from node-1. + * Log in to node-3. + Log in to the database on host-3/node-3. + * On node-3, get a sum of the value column (for checking): ```sql select COUNT(*),SUM(value) from quicktest; ``` - * Compare with the result from node-one and node-two. + * Compare with the result from node-1 and node-2. ## Worked example ### Preparation -Log in to host-one's Postgres server. -``` -ssh admin@host-one -sudo -iu enterprisedb psql bdrdb +Log in to host-1's Postgres server. + +```shell +ssh admin@host-1 +sudo -iu postgres psql "host=host-1 port=5432 username=pgdadmin dbname=pgddb" ``` -This is your connection to PGD's node-one. +This is your connection to PGD's node-1. #### Ensure the cluster is ready @@ -77,16 +81,16 @@ select bdr.wait_slot_confirm_lsn(NULL, NULL) This query blocks while the cluster is busy initializing and returns when the cluster is ready. -In another window, log in to host-two's Postgres server: +In another window, log in to host-2's Postgres server: ``` -ssh admin@host-two -sudo -iu enterprisedb psql bdrdb +ssh admin@host-2 +sudo -iu postgres psql "host=host-2 port=5432 username=pgdadmin dbname=pgddb" ``` ### Create data -#### On node-one, create a table +#### On node-1, create a table Run: @@ -94,15 +98,15 @@ Run: CREATE TABLE quicktest ( id SERIAL PRIMARY KEY, value INT ); ``` -#### On node-one, populate the table +#### On node-1, populate the table ``` INSERT INTO quicktest (value) SELECT random()*10000 FROM generate_series(1,10000); ``` -This command generates a table of 10000 rows of random values. +This command generates a table of 10000 rows of random values. -#### On node-one, monitor performance +#### On node-1, monitor performance As soon as possible, run: @@ -118,14 +122,14 @@ bdrdb=# select * from bdr.node_replication_rates; al --------------+-------------+-----------+------------+------------+------------------+-----------------+------------+--------------- --- - 1954860017 | node-three | 0/DDAA908 | 0/DDAA908 | 00:00:00 | 0 | 0 bytes | 13682 | 00:00:00 - 2299992455 | node-two | 0/DDAA908 | 0/DDAA908 | 00:00:00 | 0 | 0 bytes | 13763 | 00:00:00 + 1954860017 | node-3 | 0/DDAA908 | 0/DDAA908 | 00:00:00 | 0 | 0 bytes | 13682 | 00:00:00 + 2299992455 | node-2 | 0/DDAA908 | 0/DDAA908 | 00:00:00 | 0 | 0 bytes | 13763 | 00:00:00 (2 rows) ``` And it's already replicated. -#### On node-one get a checksum +#### On node-1 get a checksum Run: @@ -146,15 +150,15 @@ __OUTPUT__ ### Check data -#### Log in to host-two's Postgres server +#### Log in to host-2's Postgres server ``` -ssh admin@host-two -sudo -iu enterprisedb psql bdrdb +ssh admin@host-2 +sudo -iu postgres psql "host=host-2 port=5432 username=pgdadmin dbname=pgddb" ``` -This is your connection to PGD's node-two. +This is your connection to PGD's node-2. -#### On node-two, get a checksum +#### On node-2, get a checksum Run: @@ -162,7 +166,7 @@ Run: select COUNT(*),SUM(value) from quicktest; ``` -This command gets node-two's values for the generated data: +This command gets node-2's values for the generated data: ```sql bdrdb=# select COUNT(*),SUM(value) from quicktest; @@ -177,17 +181,18 @@ __OUTPUT__ The values are identical. -You can repeat the process with node-three or generate new data on any node and see it replicate to the other nodes. +You can repeat the process with node-3 or generate new data on any node and see it replicate to the other nodes. -#### Log in to host-three's Postgres server -``` -ssh admin@host-two +#### Log in to host-3's Postgres server + +```shell +ssh admin@host-3 sudo -iu enterprisedb psql bdrdb ``` -This is your connection to PGD's node-three. +This is your connection to PGD's node-3. -#### On node-three, get a checksum +#### On node-3, get a checksum Run: @@ -195,7 +200,7 @@ Run: select COUNT(*),SUM(value) from quicktest; ``` -This command gets node-three's values for the generated data: +This command gets node-3's values for the generated data: ```sql bdrdb=# select COUNT(*),SUM(value) from quicktest; diff --git a/product_docs/docs/pgd/6/essential-how-to/install/index.mdx b/product_docs/docs/pgd/6/essential-how-to/install/index.mdx index beabb962d7d..4c0e98c77a2 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/index.mdx @@ -6,7 +6,7 @@ navTitle: Installing and configuring This section covers how to manually deploy and configure EDB Postgres Distributed 6. * [Provisioning hosts](01-prerequisites.mdx) -* [Installing the database and PGD software](02-installing-database-and-pgd.mdx) -* [Creating the cluster](03-configuring-cluster.mdx) -* [Checking the cluster](04-check-cluster.mdx) -* [Using PGD CLI](05-using-pgd-cli.mdx) +* [Configuring the EDB repository](02-configure-repository.mdx) +* [Installing the database and PGD software](03-installing-database-and-pgd.mdx) +* [Configuring the cluster](04-configuring-cluster.mdx) +* [Checking the cluster](05check-cluster.mdx) diff --git a/product_docs/docs/pgd/6/essential-how-to/install/05-using-pgd-cli.mdx b/product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx similarity index 89% rename from product_docs/docs/pgd/6/essential-how-to/install/05-using-pgd-cli.mdx rename to product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx index d9f0365fd6d..8c5bdc34e15 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/05-using-pgd-cli.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx @@ -1,14 +1,22 @@ --- -title: Step 5 - Using PGD CLI -navTitle: Using PGD CLI +title: Using PGD CLI +navTitle: PGD CLI deepToC: true redirects: - - /pgd/latest/install-admin/admin-manual/installing/08-using-pgd-cli/ #generated for pgd deploy-config-planning reorg - - /pgd/latest/admin-manual/installing/08-using-pgd-cli/ #generated for pgd deploy-config-planning reorg + --- -## Using PGD CLI +The PGD CLI is a powerful command line interface for managing your PGD cluster. It can be used to perform a variety of tasks, including: + +- Checking the health of the cluster +- Listing the nodes in the cluster +- Listing the groups in the cluster +- Setting group options +- Switching the write leader + +If you have used the [installation guide](install) to install PGD, you will have already installed PGD CLI and used it to create the cluster. +## Using PGD CLI The PGD CLI command uses a configuration file to work out the hosts to connect to. There are [options](/pgd/latest/reference/cli/using_cli) that allow you to override this to use alternative configuration files or explicitly point at a server. But, by default, PGD CLI looks for a configuration file in preset locations. @@ -17,9 +25,9 @@ The connection to the database is authenticated in the same way as other command Unlike other commands, PGD CLI doesn't interactively prompt for your password. Therefore, you must pass your password using one of the following methods: - - Adding an entry to your [`.pgpass` password file](https://www.postgresql.org/docs/current/libpq-pgpass.html), which includes the host, port, database name, user name, and password - - Setting the password in the `PGPASSWORD` environment variable - - Including the password in the connection string +- Adding an entry to your [`.pgpass` password file](https://www.postgresql.org/docs/current/libpq-pgpass.html), which includes the host, port, database name, user name, and password +- Setting the password in the `PGPASSWORD` environment variable +- Including the password in the connection string We recommend the first option, as the other options don't scale well with multiple database clusters, or they compromise password confidentiality. @@ -27,7 +35,7 @@ We recommend the first option, as the other options don't scale well with multip - Ensure PGD CLI is installed. - If PGD CLI was already installed, move to the next step. - - For any system, repeat the [configure repositories](02-installing-database-and-pgd#configure_repositories) step on that system. + - For any system, repeat the [configure repositories](install/02-configure-repositories) step on that system. - Then run the package installation command appropriate for that platform. - RHEL and derivatives: `sudo dnf install edb-pgd6-cli` - Debian, Ubuntu, and derivatives: `sudo apt-get install edb-pgd6-cli` @@ -90,7 +98,7 @@ Then, write the configuration to the `pgd-cli-config.yml` file in the `/etc/edb/ For this example, you can run this on host-one to create the file: -``` +```shell cat < No - if 2 PGD data nodes | Yes - if 3 PGD data nodes
No - if 2 PGD data nodes | Yes - if 3 PGD data nodes
No - if 2 PGD data nodes | Yes - if 3 PGD data nodes
No - if 2 PGD data nodes | -| Data protection in case of location failure | No (unless offsite backup) | Yes | Yes | Yes | +| Data protection in case of location failure | No (unless offsite backup) | Yes | Yes | Yes | | Global consensus in case of location failure | N/A | No | Yes | Yes | | Data restore required after location failure | Yes | No | No | No | | Immediate failover in case of location failure | No - requires data restore from backup | Yes - alternate Location | Yes - alternate Location | Yes - alternate Location | diff --git a/product_docs/docs/pgd/6/reference/commit-scopes/predefined-commit-scopes.mdx b/product_docs/docs/pgd/6/reference/commit-scopes/predefined-commit-scopes.mdx index 77c625fd041..1ed4c461ba6 100644 --- a/product_docs/docs/pgd/6/reference/commit-scopes/predefined-commit-scopes.mdx +++ b/product_docs/docs/pgd/6/reference/commit-scopes/predefined-commit-scopes.mdx @@ -13,11 +13,11 @@ The difference between the two editions is that PGD Essential has a limited set ASYNCHRONOUS COMMIT ``` -The `local protect` commit scope is the default commit scope for PGD Essential. -It provides asynchronous commit with no durability guarantees. +The `local protect` commit scope is the default commit scope for PGD Essential. +It provides asynchronous commit with no durability guarantees. This means that transactions are considered committed as soon as they are written to the local node's WAL, without waiting for any confirmation from other nodes in the cluster. -This commit scope is suitable for scenarios where high availability and low latency are more important than data durability. +This commit scope is suitable for scenarios where high availability and low latency are more important than data durability. However, it does not provide any guarantees against data loss in case of node failures or network issues. ## `lag protect` @@ -27,10 +27,10 @@ MAJORITY ORIGIN GROUP LAG CONTROL (max_lag_time = 30s, max_commit_delay = 10s) ``` The `lag protect` commit scope provides a durability guarantee based on the lag time of the majority origin group. -It ensures that transactions are considered committed only when the lag time is within a specified limit (30 seconds in this case) and the commit delay is also within a specified limit (10 seconds in this case). +It ensures that transactions are considered committed only when the lag time is within a specified limit (30 seconds in this case) and the commit delay is also within a specified limit (10 seconds in this case). This helps to prevent data loss in case of network issues or node failures. -This commit scope is useful in scenarios where data consistency and durability are important, but some latency is acceptable. +This commit scope is useful in scenarios where data consistency and durability are important, but some latency is acceptable. It allows for a balance between performance and data safety by ensuring that transactions are not considered committed until they have been confirmed by the majority of nodes in the origin group within the specified lag and commit delay limits. ## `majority protect` @@ -39,8 +39,8 @@ It allows for a balance between performance and data safety by ensuring that tra MAJORITY ORIGIN GROUP SYNCHRONOUS COMMIT ``` -The `majority protect` commit scope provides a durability guarantee based on the majority origin group. -It ensures that transactions are considered committed only when they are confirmed by the majority of nodes in the origin group. +The `majority protect` commit scope provides a durability guarantee based on the majority origin group. +It ensures that transactions are considered committed only when they are confirmed by the majority of nodes in the origin group. This helps to ensure data consistency and durability in case of node failures or network issues. This commit scope is suitable for scenarios where data consistency and durability are critical, and it provides a higher level of protection against data loss compared to the `local protect` commit scope. @@ -52,8 +52,8 @@ However, it may introduce some latency due to the need for confirmation from mul MAJORITY ORIGIN GROUP SYNCHRONOUS COMMIT DEGRADE ON (timeout = 10s, require_write_lead = true) TO ASYNCHRONOUS COMMIT ``` -The `adaptive protect` commit scope provides a more flexible durability guarantee. -It allows transactions to be considered committed based on the majority origin group synchronous commit, but it can degrade to asynchronous commit if the transaction cannot be confirmed within a specified timeout (10 seconds in this case). +The `adaptive protect` commit scope provides a more flexible durability guarantee. +It allows transactions to be considered committed based on the majority origin group synchronous commit, but it can degrade to asynchronous commit if the transaction cannot be confirmed within a specified timeout (10 seconds in this case). This is useful in scenarios where network latency or node failures may cause delays in confirming transactions. This commit scope is suitable for scenarios where data consistency and durability are important, but some flexibility is needed to handle potential delays. diff --git a/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx b/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx index 47b0f7fc4d3..6f7d507425f 100644 --- a/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx @@ -44,8 +44,8 @@ Don't drop those slots. PGD creates and manages them and drops them when or if n ## Group slot -The group slot is used to track the progress of replication of the nodes in a PGD cluster that are replicating from the node. -Each node in a PGD cluster has its own group slot, which is used to track the progress of replication to and from that node. +The group slot is used to track the progress of replication of the nodes in a PGD cluster that are replicating from the node. +Each node in a PGD cluster has its own group slot, which is used to track the progress of replication from that node. The group slot is used to: From 5a51b9d0de541eb588d9fe28183adc98db1359bd Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Wed, 14 May 2025 10:57:10 +0100 Subject: [PATCH 079/145] Review comments applied Signed-off-by: Dj Walker-Morgan --- .../6/reference/node_management/replication_slots.mdx | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx b/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx index 6f7d507425f..f4d06f555cd 100644 --- a/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/replication_slots.mdx @@ -7,14 +7,13 @@ to ensure better identification. Replication slots are used by PostgreSQL to track the progress of replication. They are used to ensure that the data being replicated is not lost and that the replication process is consistent. In PGD, replication slots are used to track the progress of replication -between nodes in a cluster. Each node in a PGD cluster has its own replication slots, which are used to track the progress of replication -to and from that node. Replication slots are also used to track the progress of replication between groups in a PGD cluster. Each group -in a PGD cluster has its own replication slots, which are used to track the progress of replication to and from that group. +from that node. There is one slot per downstream node. Ther is also a special replication slot used for tracking replication progress from a given +node globally across all downstream nodes. - One group slot, named `bdr__` - N-1 node slots named `bdr_node__`, where N is the total number of nodes in the cluster, including direct logical standbys, if any. -Where `topgroupuuid` is the UUID of the top-level group and `dbhash` is a hash of the database name. You can obtain the UUID of the top-level group using +Where `topgroupuuid` is the string representation of the top level-group's UUID (less the `-` characters) and `dbhash` is a hash of the database name. You can obtain the UUID of the top-level group using ```sql select node_group_uuid from bdr.node_group where node_group_parent_id=0; @@ -26,7 +25,7 @@ And `dbhash` is a hash of the database name. You can obtain the hash using: select to_hex(hashtext('pgddb')); ``` -And the `targetnodeuuid` is the UUID of the target node. You can obtain the UUID of the target node using: +And the `targetnodeuuid` is the string representation of the target node's UUID (less the `-` characters). You can obtain the UUID of the target node using: ```sql select node_uuid from bdr.node where node_name=''; From 837d8b8b75d87550aa9bdc65a88d72dd187d24a4 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan <126472455+djw-m@users.noreply.github.com> Date: Wed, 14 May 2025 13:45:37 +0100 Subject: [PATCH 080/145] Update product_docs/docs/pgd/6/get-started/index.mdx --- product_docs/docs/pgd/6/get-started/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/6/get-started/index.mdx b/product_docs/docs/pgd/6/get-started/index.mdx index e0d7ec01239..57c0ba61566 100644 --- a/product_docs/docs/pgd/6/get-started/index.mdx +++ b/product_docs/docs/pgd/6/get-started/index.mdx @@ -9,5 +9,5 @@ navigation: - expanded-examples --- -To begin using any edition of EDB Postgres Distributed, we recommend you first try our local installation and configuration guide. This guide will help you set up a Docker-compose cluster on your local machine, which is ideal for testing and learning purposes. +To begin using any edition of EDB Postgres Distributed, we recommend you first try our local installation and configuration guide. This guide will help you set up a Docker Compose cluster on your local machine, which is ideal for testing and learning purposes. From 6610e65f0cba32c8741d2418471ad4ef9d83a7b7 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 15 May 2025 12:56:33 +0100 Subject: [PATCH 081/145] Updated node-setup and other fill out fixes Signed-off-by: Dj Walker-Morgan --- .../6/concepts/advanced-concepts/index.mdx | 6 -- product_docs/docs/pgd/6/concepts/index.mdx | 6 +- .../essential-how-to/architectures/index.mdx | 21 ++--- .../architectures/near-far/index.mdx | 47 ++++++++++ .../near-far/manual-deployments/index.mdx | 5 -- .../near-far/manually-deploying-near-far.mdx | 44 ++++++++++ .../architectures/standard/index.mdx | 4 + .../standard/manual-deployments/index.mdx | 4 - .../standard/manually-deploying-standard.mdx | 79 +++++++++++++++++ .../pgd/6/essential-how-to/autopartition.mdx | 2 +- .../pgd/6/essential-how-to/connections.mdx | 34 ++++++++ .../docs/pgd/6/essential-how-to/index.mdx | 3 +- .../docs/pgd/6/essential-how-to/pgd-cli.mdx | 14 ++- .../pgd/6/essential-how-to/sop/monitoring.mdx | 7 -- .../pgd/6/essential-how-to/sop/upgrade.mdx | 16 ---- .../essential-how-to/sops/backup-restore.mdx | 20 ++--- .../docs/pgd/6/expanded-how-to/index.mdx | 1 + .../get-started/essential-near-far/index.mdx | 5 -- product_docs/docs/pgd/6/index.mdx | 7 +- .../reference/cli/command_ref/node/setup.mdx | 86 ++++++++++++------- product_docs/docs/pgd/6/reference/index.mdx | 55 +++++++++--- 21 files changed, 343 insertions(+), 123 deletions(-) delete mode 100644 product_docs/docs/pgd/6/concepts/advanced-concepts/index.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/architectures/near-far/manual-deployments/index.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/architectures/near-far/manually-deploying-near-far.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/architectures/standard/manual-deployments/index.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/architectures/standard/manually-deploying-standard.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/connections.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/monitoring.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx delete mode 100644 product_docs/docs/pgd/6/get-started/essential-near-far/index.mdx diff --git a/product_docs/docs/pgd/6/concepts/advanced-concepts/index.mdx b/product_docs/docs/pgd/6/concepts/advanced-concepts/index.mdx deleted file mode 100644 index b86d9fc676f..00000000000 --- a/product_docs/docs/pgd/6/concepts/advanced-concepts/index.mdx +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Advanced PGD Concepts -navTitle: Advanced -description: Advanced concepts for EDB Postgres Distributed (PGD) including commit scopes, deployment configurations, and more. ---- - diff --git a/product_docs/docs/pgd/6/concepts/index.mdx b/product_docs/docs/pgd/6/concepts/index.mdx index 184da4f9944..4cbc6c045dc 100644 --- a/product_docs/docs/pgd/6/concepts/index.mdx +++ b/product_docs/docs/pgd/6/concepts/index.mdx @@ -1,6 +1,7 @@ --- title: PGD Concepts Explained navTitle: PGD Explained +description: The concepts behind EDB Postgres Distributed (PGD) 6.0 and how they work in practice. navigation: --- @@ -17,4 +18,7 @@ navigation: * Commit scopes * Geo-distributed clusters - +* Advanced durability +* Custom configurations +* Conflict management +* Replication sets diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx index 777d0998f25..37b363b1058 100644 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx @@ -4,6 +4,7 @@ navTitle: Architectures navigation: - standard - near-far +description: PGD Essential architectures for high availability and disaster recovery and how to implement them. --- ## Choosing an architecture @@ -14,22 +15,16 @@ They are standard and near/far. ## Standard architecture - Ideal for a highly available single location -The standard, or one-location, architecture is designed for a single location which needs to be highly available. Built around three data nodes, the Essential standard architecture ensures that data is replicated across all three nodes and that, in the event of a failure, the system can continue to operate without data loss. +The standard, or one-location, architecture is designed for a single location that needs to be highly available. Built around three data nodes, the Essential standard architecture ensures that data is replicated across all three nodes and that, in the event of a failure, the system can continue to operate without data loss. -Using core PGD capabilites, the standard architecture configures the three nodes in a multi-master replication configuration. That is, each node operates as a master node and logically replicates its data to the other nodes. Now, while PGD is capable of handling conflicts between data changes on nodes, the Essential standard architecture use PGD's integrated connection manager to ensure that all writes are directed to a single node, the write leader. Conflicts are avoided by allowing that singular leader to handle all updates to the data. Changes are then replicated to the other nodes in the cluster. - -If the write leader fails, the remaining nodes in the cluster will elect a new write leader and the connection managers in those nodes will then automatically failover to send writes to the new leader. When the failed node comes back online, it will automatically rejoin the cluster and begin replicating data from the new write leader. - -The Essential standard architecture has been created to be easy to deploy and manage, based on user experience. Unlike other high availability solutions, because Essential is built on PGD, moving to a more complex architecture is simple and straightforward; move to Expanded PGD and then add new data groups to the cluster as needed. +Learn more about the [Standard architecture](standard). ## Near/far architecture - Ideal for disaster recovery -The Near/Far architecture is designed for a single location which needs to be reasonably highly available, but also needs to be able to recover from a disaster. It does this by having a two data node cluster in the primary location and a single data node in a secondary location. - -The two data nodes in the primary location are configured in a multi-master replication configuration, just like the standard architecture. The single data node in the secondary location is configured as a subscriber to the primary location. This means that all changes made to the data in the primary location are replicated to the secondary location. - -In the event of a partial failure at the primary location, the system will switch to the other data node, also with a complete replica of the data, and continue to operate. It will also continue replication to the secondary location. When the failed node at the primary location comes back, it will rejoin and begin replicating data from the node that is currently primary. - -In the event of a complete failure in the primary location, the secondary location's database has a complete replica of the data. Applications should be configured to automatically failover to the secondary location and all writes will be directed to that node. When the primary location comes back online, it will automatically rejoin the cluster and begin replicating data from the secondary location. +The Near/Far architecture is designed for a single location which needs to be reasonably highly available, and needs to be able to recover from a disaster. It does this by having a two data node cluster in the primary location and a single data node in a secondary location. +Learn more about the [Near/Far architecture](near-far). +!!!Note For multi-region deployments + For multi-region deployments, geo-distributed architectures are available in [PGD Expanded](/pgd/latest/expanded-how-to/architectures/). These architectures are designed for use cases that require data to be distributed across multiple regions or data centers. They provide advanced features such as conflict resolution, data distribution, and support for large-scale deployments. + For more information on PGD Expanded, see the [Expanded How-to](expanded-how-to). diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/index.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/index.mdx index c0fe87cc3d5..6ab95f935e2 100644 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/index.mdx @@ -5,3 +5,50 @@ navigation: - manual-deployments --- +In the near/far architecture, there are two data nodes in the primary location and one data node in a secondary location. The primary location is where the majority of the data is stored and where most of the client connections are made. The secondary location is used for disaster recovery and is not used for client connections by default. + +The data nodes are all configured in a multi-master replication configuration, just like the standard architecture, but the difference is that the node at the secondary location is fenced off from the other nodes in the cluster and does not receive client connections by default. In this configuration, the secondary location node has a complete replica of the data in the primary location. + +Using a PGD commit scope, the data nodes in the primary location will be configured to synchronously replicate data to the other node in the primary location and to the node in the secondary location. This ensures that the data is replicated to all nodes before it is committed to on the primary location. In the case of a node going down, the commit scope rule will detect the situation and degrade the replication to asynchronous replication. This will allow the system to continue to operate. + +In the event of a partial failure at the primary location, the system will switch to the other data node, also with a complete replica of the data, and continue to operate. It will also continue replication to the secondary location. When the failed node at the primary location comes back, it will rejoin and begin replicating data from the node that is currently primary. + +In the event of a complete failure in the primary location, the secondary location's database has a complete replica of the data. Depending on the failure, options for recovery include restoring the primary location from the secondary location, or restoring the primary location from a backup of the secondary location. The secondary location could be configured to accept client connections, but this is not the default configuration and would require some additional reconfiguration. + +## Synchronous Replication in Near-Far Architecture + +For best results the near-far architecture should be configured with synchronous replication. +This ensures that the data is replicated to the secondary location before it is committed to the primary location. + +## PGD Configuration + +The primary location is configured with two data nodes, in their own group "active". This location will be where the majority of the client connections will be made. + +The secondary location is configured with one data node, in its own group "dr". + +They are all members of the same cluster. + +Once created with pgd-cli, the routing and fencing of the nodes needs to be configured. + +First, we disable the routing on both the "active" and "dr" groups. + +```shell +pgd group dr set-option enable_routing off --dsn "host=localhost port=5432 dbname=pgddb user=pgdadmin" +pgd group active set-option enable_routing off --dsn "host=localhost port=5432 dbname=pgddb user=pgdadmin" +``` + +Then we should enable the routing on the "pgd" top-level group. + +```shell +pgd group pgd set-option enable_routing on --dsn "host=localhost port=5432 dbname=pgddb user=pgdadmin" +``` + +Finally, we would enable the fencing on the "dr" group. + +```shell +pgd group dr set-option enable_fencing on --dsn "host=localhost port=5432 dbname=pgddb user=pgdadmin" +``` + +This will ensure that the "dr" group is fenced off from the other nodes in the cluster and does not receive client connections by default. +The "active" group will continue to operate normally and will continue to replicate data to the "dr" group. + diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/manual-deployments/index.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/manual-deployments/index.mdx deleted file mode 100644 index c0a6f52d9aa..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/manual-deployments/index.mdx +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "Manual Deployments" ---- -# Manual Deployments - diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/manually-deploying-near-far.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/manually-deploying-near-far.mdx new file mode 100644 index 00000000000..3b192d05e20 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/architectures/near-far/manually-deploying-near-far.mdx @@ -0,0 +1,44 @@ +--- +title: "Manually Deploying PGD Essential Near-Far Architecture" +navTitle: Manual Near-Far Deployments +description: How to manually deploy the PGD Essential Near-Far Architecture. +--- + +The following instructions describe how to manually deploy the PGD Essential Near-Far architecture. This architecture is designed for a single location that needs to be reasonably highly available and needs to be able to recover from a disaster. It does this by having a two data node cluster in the primary location and a single data node in a secondary location. + +In this guide, we will use the `pgd` command line tool to create the cluster and configure the nodes. The instructions assume that you have already installed PGD Essential and have access to the `pgd` command line tool. + +We will refer to the primary location as the `active` location and the secondary location as the `dr` location. + +## PGD Configuration + +The primary location is configured with two data nodes, in their own group "active". This location will be where the majority of the client connections will be made. + +The secondary location is configured with one data node, in its own group "dr". + +They are all members of the same cluster. + +Once created with pgd-cli, the routing and fencing of the nodes needs to be configured. + +First, we disable the routing on both the "active" and "dr" groups. + +```shell +pgd group dr set-option enable_routing off --dsn "host=localhost port=5432 dbname=pgddb user=pgdadmin" +pgd group active set-option enable_routing off --dsn "host=localhost port=5432 dbname=pgddb user=pgdadmin" +``` + +Then we should enable the routing on the "pgd" top-level group. + +```shell +pgd group pgd set-option enable_routing on --dsn "host=localhost port=5432 dbname=pgddb user=pgdadmin" +``` + +Finally, we enable the fencing on the "dr" group. + +```shell +pgd group dr set-option enable_fencing on --dsn "host=localhost port=5432 dbname=pgddb user=pgdadmin" +``` + +This will ensure that the "dr" group is fenced off from the other nodes in the cluster and does not receive client connections by default. +The "active" group will continue to operate normally and will continue to replicate data to the "dr" group. + diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/standard/index.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/standard/index.mdx index dd5d2170f66..e1c83f29c9a 100644 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/standard/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/architectures/standard/index.mdx @@ -6,4 +6,8 @@ navigation: +Using core PGD capabilites, the standard architecture configures the three nodes in a multi-master replication configuration. That is, each node operates as a master node and logically replicates its data to the other nodes. Now, while PGD is capable of handling conflicts between data changes on nodes, the Essential standard architecture use PGD's integrated connection manager to ensure that all writes are directed to a single node, the write leader. Conflicts are avoided by allowing that singular leader to handle all updates to the data. Changes are then replicated to the other nodes in the cluster. +If the write leader fails, the remaining nodes in the cluster will elect a new write leader and the connection managers in those nodes will then automatically failover to send writes to the new leader. When the failed node comes back online, it will automatically rejoin the cluster and begin replicating data from the new write leader. + +The Essential standard architecture has been created to be easy to deploy and manage, based on user experience. Unlike other high availability solutions, because Essential is built on PGD, moving to a more complex architecture is simple and straightforward; move to Expanded PGD and then add new data groups to the cluster as needed. diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/standard/manual-deployments/index.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/standard/manual-deployments/index.mdx deleted file mode 100644 index 840e5c24933..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/standard/manual-deployments/index.mdx +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: "Manual Deployments" ---- - diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/standard/manually-deploying-standard.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/standard/manually-deploying-standard.mdx new file mode 100644 index 00000000000..a3dc101f5a8 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/architectures/standard/manually-deploying-standard.mdx @@ -0,0 +1,79 @@ +--- +title: "Manually Deploying PGD Essential Standard Architecture" +navTitle: Manual Standard Deployments +description: How to manually deploy the PGD Essential Standard Architecture. +--- + +Manually deploying the PGD Essential Standard architecture is a straightforward process. This architecture is designed for a single location that needs to be highly available and can recover from a disaster. It does this by having three data nodes in a multi-master replication configuration, with one node acting as the write leader. + +## PGD Configuration + +Install PGD on each of the three nodes using the instructions in the Essentials install guide. Specifically: + +* [Configure Repositories](/pgd/latest/essential-how-to/install/02-configuring-repositories/) to enable installation of the PGD packages. +* [Install PGD and the Postgres](/pgd/latest/essential-how-to/install/03-installing-pgd/) to install the PGD packages. +* [Configure the PGD Cluster](/pgd/latest/essential-how-to/install/04-configuring-pgd/) to configure the PGD cluster. + +## Worked Example + +In this example, we will create a three-node cluster with the following nodes: + +* The first node is called `node1` and is located on `host-1`. +* The second node is called `node2` and is located on `host-2`. +* The third node is called `node3` and is located on `host-3`. +* the cluster name is `pgd` (the default name). +* The group name is `group1`. +* The Postgres version is `17`. +* The Postgres edition is `essential`. +* The Postgres data directory is `/var/lib/edb-pge/17/main/`. +* The Postgres executable files are in `/usr/edb/pge17/bin/`. +* The Postgres database user is `postgres`. +* The Postgres database port is `5432`. +* The Postgres database name is `bdrdb`. + +### For the first node + +This is the common setup for all three nodes, installing the software itself. + +```bash +export EDB_SUBSCRIPTION_TOKEN=XXXXXXXXXXXXXX +export EDB_SUBSCRIPTION_PLAN=enterprise +export EDB_REPO_TYPE=rpm +curl -1sSLf " https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +export PG_VERSION=17 +export PGD_EDITION=essential +export EDB_PACKAGES="edb-as$PG_VERSION edb-pgd6-$PGD_EDITION-epas$PG_VERSION" +sudo dnf install -y $EDB_PACKAGES +``` + +On the first node, the following command creates the cluster and the group. It also creates the data directory and initializes the database. + +```bash +sudo su - postgres +export PATH=$PATH:/usr/edb/pge17/bin/ +pgd node node1 setup "host=host-1 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --group-name group1 --cluster-name pgd --create-group --initial-node-count 3 +``` + +### For the second node + +Repeat the software installation steps on the second node. + +Then run the following command to initialize the node and join the cluster and group. + +```bash +sudo su - postgres +export PATH=$PATH:/usr/edb/pge17/bin/ +pgd node node2 setup "host=host-2 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --cluster-dsn "host=host-1 user=postgres port=5432 dbname=bdrdb" +``` + +### For the third node + +Repeat the software installation steps on the third node. + +The command to initialize the node and join the cluster and group is similar to the second node, but with a different host and node name. + +```bash +sudo su - postgres +export PATH=$PATH:/usr/edb/pge17/bin/ +pgd node node3 setup "host=host-3 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --cluster-dsn "host=host-1 user=postgres port=5432 dbname=bdrdb" +``` diff --git a/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx b/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx index 0931b4db2fb..75a36c3d95d 100644 --- a/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx @@ -1,6 +1,6 @@ --- title: Auto Partitioning navTitle: Auto Partitioning -description: A guide on how to use auto partitioning in PGD. +description: A guide on how to use auto partitioning in PGD Essential. --- diff --git a/product_docs/docs/pgd/6/essential-how-to/connections.mdx b/product_docs/docs/pgd/6/essential-how-to/connections.mdx new file mode 100644 index 00000000000..a83171b000b --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/connections.mdx @@ -0,0 +1,34 @@ +--- +title: Connections +navTitle: Connections +description: A guide on how to connect to your PGD cluster. +--- + +PGD Essential uses the same connection methods as Postgres. The difference is that most of your connections to the cluster should go through the connection manager that is built into every data node in the cluster. + +Although you can connect directly to the data nodes, it is not recommended for anything other than maintenance when you want to work on a particular node's database instance. + +For PGD Essential, it is required that you connect to the cluster through the connection manager. PGD Essential is designed to be simple to deploy and manage and that means the cluster has a write leader node which handles all the writes to the cluster. The connection manager is then responsible for directing your read-write connections to the write leader. All your client or application needs to do is to use the connection manager's port and the connection manager will handle the rest. + +The connection manager is responsible for directing your writes to the write leader and ensuring that your reads are directed to the correct node in the cluster. If you connect directly to a data node, you may not be able to take advantage of these features. For applications that only need to read data, the connection manager can direct your reads to a node which isn't the write leader. This can help to balance the load on the cluster and improve performance. + +## Connecting through the Connection Manager + +Postgres is very flexible for configuring ports and connections, so for simplicity, we will use the default port settings for Postgres and the connection manager. The default port for Postgres is 5432, and the default port for the connection manager is 6432. + +You can use that port in your connection strings to connect to the cluster. So for example, if you are using the `psql` command line tool, you can connect to the cluster like this: + +```bash +psql -h host-1 -p 6432 -U pgdadmin -d pgddb +``` + +Where `host-1` is the hostname of the node you are connecting to. The connection manager will then direct your connection to the write leader node in the cluster. + +## Connecting Directly to a Data Node + +You can connect directly to a data node in the cluster, but it is not recommended. If you do need to connect directly to a data node, you can use the following command: + +```bash +psql -h host-1 -p 5432 -U pgdadmin -d pgddb +``` + diff --git a/product_docs/docs/pgd/6/essential-how-to/index.mdx b/product_docs/docs/pgd/6/essential-how-to/index.mdx index 028528a8ccd..216e5f0a8b4 100644 --- a/product_docs/docs/pgd/6/essential-how-to/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/index.mdx @@ -4,11 +4,12 @@ navTitle: Essential How-To navigation: - architectures - install +- connections - pgd-cli - durability - autopartition - production-best-practices -- standard-operating-procedures +- sops description: Essential how-to guides for deploying and managing your PGD cluster. --- diff --git a/product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx b/product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx index 8c5bdc34e15..7308dd96d5d 100644 --- a/product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx @@ -65,7 +65,7 @@ Also consult the [PGD CLI documentation](/pgd/latest/reference/cli/) for details In this worked example, you configure and use PGD CLI on host-one, where you've already installed Postgres and PGD. You don't need to install PGD CLI again. -### Create a configuration file +### (Optionally) Create a configuration file The PGD CLI configuration file is a YAML file that contains a cluster object. This has two properties: @@ -77,20 +77,18 @@ This has two properties: cluster: name: pgd endpoints: - - host=host-one dbname=bdrdb port=5444 - - host=host-two dbname=bdrdb port=5444 - - host=host-three dbname=bdrdb port=5444 + - host=host-1 dbname=bdrdb port=5444 + - host=host-2 dbname=bdrdb port=5444 + - host=host-3 dbname=bdrdb port=5444 ``` Note that the endpoints in this example specify `port=5444`. This is necessary for EDB Postgres Advanced Server instances. For EDB Postgres Extended and community PostgreSQL, you can omit this. -### Install the configuration file - Create the PGD CLI configuration directory: -``` +```shell sudo mkdir -p /etc/edb/pgd-cli ``` @@ -111,7 +109,7 @@ EOF You can repeat this process on any system where you need to use PGD CLI. -### Run PGD CLI +### Running PGD CLI With the configuration file in place, and logged in as the enterprisedb system user, you can run pgd-cli. For example, you can use the `nodes list` command to list the nodes in your cluster and their status: diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/monitoring.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/monitoring.mdx deleted file mode 100644 index 07b4c337813..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sop/monitoring.mdx +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Monitoring SOPs -navTitle: Monitoring ---- - -This SOP covers the process of monitoring the Postgres database servers running on the nodes in a PGD cluster. It includes best practices for monitoring, tools to use, and common issues that may arise during the monitoring process. - diff --git a/product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx b/product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx deleted file mode 100644 index 618f2e22690..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sop/upgrade.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Upgrading Postgres -navTitle: Upgrades -redirects: - - /pgd/latest/upgrades ---- - -This SOP covers the process of upgrading the Postgres database servers running on the nodes in a PGD cluster. There are two main upgrade paths: minor and major upgrades. Minor upgrades are typically performed to apply security patches or bug fixes, while major upgrades involve significant changes to the database engine and may require more extensive testing and planning. - -## Minor Upgrades - -## Major Upgrades - -## Upgrading to EDB Postgres Distributed 6 - -See the [reference documentation](../reference/upgrade) for more information on upgrading to EDB Postgres Distributed 6.0.0. diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/backup-restore.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/backup-restore.mdx index 34e87d2dfcd..7b28fa13769 100644 --- a/product_docs/docs/pgd/6/essential-how-to/sops/backup-restore.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/sops/backup-restore.mdx @@ -8,8 +8,6 @@ redirects: --- -**TODO**: Split? - PGD is designed to be a distributed, highly available system. If one or more nodes of a cluster are lost, the best way to replace them is to clone new nodes directly from the remaining nodes. @@ -17,8 +15,8 @@ is to clone new nodes directly from the remaining nodes. The role of backup and recovery in PGD is to provide for disaster recovery (DR), such as in the following situations: -- Loss of all nodes in the cluster -- Significant, uncorrectable data corruption across multiple nodes +- Loss of all nodes in the cluster +- Significant, uncorrectable data corruption across multiple nodes as a result of data corruption, application error, or security breach @@ -65,18 +63,18 @@ PostgreSQL node running the BDR extension. Consider these specific points when applying PostgreSQL backup techniques to PGD: -- PGD operates at the level of a single database, while a physical +- PGD operates at the level of a single database, while a physical backup includes all the databases in the instance. Plan your databases to allow them to be easily backed up and restored. -- Backups make a copy of just one node. In the simplest case, +- Backups make a copy of just one node. In the simplest case, every node has a copy of all data, so you need to back up only one node to capture all data. However, the goal of PGD isn't met if the site containing that single copy goes down, so the minimum is at least one node backup per site (with many copies, and so on). -- However, each node might have unreplicated local data, or the +- However, each node might have unreplicated local data, or the definition of replication sets might be complex so that all nodes don't subscribe to all replication sets. In these cases, backup planning must also include plans for how to back up any unreplicated @@ -131,7 +129,7 @@ replication origin. With PostgreSQL PITR, you can use the standard syntax: -``` +```text recovery_target_time = T1 ``` @@ -170,7 +168,7 @@ by `T1`, even though they weren't applied on `N1` until later. To request multi-origin PITR, use the standard syntax in the `postgresql.conf` file: -``` +```text recovery_target_time = T1 ``` @@ -178,13 +176,13 @@ You need to specify the list of replication origins that are restored to `T1` in You can use a separate `multi_recovery.conf` file by way of a new parameter, `recovery_target_origins`: -``` +```text recovery_target_origins = '*' ``` Or you can specify the origin subset as a list in `recovery_target_origins`: -``` +```text recovery_target_origins = '1,3' ``` diff --git a/product_docs/docs/pgd/6/expanded-how-to/index.mdx b/product_docs/docs/pgd/6/expanded-how-to/index.mdx index 8a31427e7c4..fc8e947f063 100644 --- a/product_docs/docs/pgd/6/expanded-how-to/index.mdx +++ b/product_docs/docs/pgd/6/expanded-how-to/index.mdx @@ -1,6 +1,7 @@ --- title: Expanded How-to navTitle: Expanded How-to +description: How to use PGD Expanded's advanced features and capabilities. --- ## Overview diff --git a/product_docs/docs/pgd/6/get-started/essential-near-far/index.mdx b/product_docs/docs/pgd/6/get-started/essential-near-far/index.mdx deleted file mode 100644 index 7ceaa173542..00000000000 --- a/product_docs/docs/pgd/6/get-started/essential-near-far/index.mdx +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: PGD Essential Near-Far -navTitle: Near-Far ---- - diff --git a/product_docs/docs/pgd/6/index.mdx b/product_docs/docs/pgd/6/index.mdx index 70aa669c29b..f32ca586aa4 100644 --- a/product_docs/docs/pgd/6/index.mdx +++ b/product_docs/docs/pgd/6/index.mdx @@ -2,17 +2,20 @@ title: "EDB Postgres Distributed (PGD)" navTitle: EDB Postgres Distributed description: EDB Postgres Distributed (PGD) provides multi-master replication and data distribution with advanced conflict management, data-loss protection, and throughput up to 5X faster than native logical replication. -indexCards: full +indexCards: simple redirects: - /edb-postgres-ai/migration-etl/pgd/ navigation: - get-started + - "#How To..." - essential-how-to - expanded-how-to + - "#In Depth" - concepts + - "#Reference" - reference - - "#Appendix" - terminology + - "#Appendix" - compatibility - rel_notes - known_issues diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx index 8902c65ae4f..6b9c9ecb97e 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx @@ -21,38 +21,35 @@ If the local node is up and running and remote node dsn is not provided, `pgd no ## Syntax ```plaintext -pgd node setup [OPTIONS] -D +pgd node setup [OPTIONS] -D ``` ## Arguments -### +- The name of the node to be created. This is the name that will be used to identify the node in the cluster. It must be unique within the cluster. -DSN of the local node. This is the connection string to the local node. It is used to connect to the local node and perform the setup operation. -This is a mandatory argument and should be in the format `host=localhost port=5432 user=postgres dbname=bdrdb`. +- The data directory for the node. This is where the Postgres data files will be stored. It must be a valid directory and must be writable by the user running the command. ## Options -| Option                                              | Description | -|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------| -| -D, --pgdata | Uses as the data directory of the node. (Also set with environment variable `PGDATA`) | -| --listen-address | Sets listen address the new node should listen to (defaults to `localhost`) | -| --initial-node-count | Number of nodes in the cluster (or planned to be in the cluster). Used to calculate various resource settings for the node. Default is 3. | -| --bindir | Specifies the directory where the binaries are located. Defaults to the directory where the running pgd binary is located. | -| --superuser | The superuser to use for the connection. | -| --node-kind | Specifies the kind of node to be created. Applies to first node only. Default is `data`.Possible values are `data`, `witness`, `subscriber-only`. | -| --group-name | Node group name. If not provided, the node will be added to the group of the active node. It is a mandatory argument for the first node of a group. | -| --create-group | Set this flag to create the given group, if it is not already present. This will be true by default for the first node. | -| --cluster-name | Name of the cluster to join the node to. Defaults to `pgd` | -| --cluster-dsn | A DSN which belongs to the active PGD cluster. When configuring the first node of a cluster, should point to the DSN for the first node. | -| --postgresql-conf | Optional path of the postgresql.conf file to be used for the node. | -| --postgresql-auto-conf     | Optional path of the postgresql.auto.conf file to be used for the node. | -| --hba-conf | Optional path of the pg_hba.conf file to be used for the node. | -| --update-pgpass | If set, the pgpass file for the new nodes password will be stored in the current user's `.pgpass` file. | -| --debug | Print debug messages, useful while troubleshooting. | -| --verbose | Print verbose messages. | -| --log-file | Log file to write the log messages to. Records log messages for any external commands executed. Default is to write a file in the current directory named `postgres-.log` where the port value | - +| Option                                              | Description | +|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `--listen-addr ` | The address that the configured node will listen on for incoming connections, and the address that other nodes will use to connect to this node. This is typically set to at least `localhost`, but can be set to any valid address. The default is `localhost`. | +| `--initial-node-count ` | Number of nodes in the cluster (or planned to be in the cluster). Used to calculate various resource settings for the node. Default is 3. | +| `--bindir ` | Specifies the directory where the binaries are located. Defaults to the directory where the running pgd binary is located. | +| `--log-file ` | Log file to write the log messages to. Records log messages for any external commands executed. Default is to write a file in the current directory named `postgres-.log` where the port value | +| `-D`, `--pgdata ` | Uses as the data directory of the node. (Also set with environment variable `PGDATA`) | +| `--superuser ` | The superuser to use for the connection. | +| `--node-kind ` | Specifies the kind of node to be created. Applies to first node only. Default is `data`.Possible values are `data`, `witness`, `subscriber-only`. | +| `--group-name ` | Node group name. If not provided, the node will be added to the group of the active node. It is a mandatory argument for the first node of a group. | +| `--create-group` | Set this flag to create the given group, if it is not already present. This will be true by default for the first node. | +| `--cluster-name ` | Name of the cluster to join the node to. Defaults to `pgd` | +| `--cluster-dsn ` | A DSN which belongs to the active PGD cluster. When configuring the first node of a cluster, should point to the DSN for the first node. | +| `--postgresql-conf ` | Optional path of the `postgresql.conf` file to be used for the node. | +| `--postgresql-auto-conf ` | Optional path of the `postgresql.auto.conf` file to be used for the node. | +| `--hba-conf ` | Optional path of the `pg_hba.conf` file to be used for the node. | +| `--update-pgpass` | If set, the pgpass file for the new nodes password will be stored in the current user's `.pgpass` file. | +| `--verbose` | Print verbose messages. | See also [Global Options](/pgd/latest/cli/command_ref/#global-options). ## Examples @@ -60,27 +57,50 @@ See also [Global Options](/pgd/latest/cli/command_ref/#global-options). In these examples, we will set up a cluster with on three hosts, `host-1`, `host-2` and `host-3`, to create three nodes: `node-one`, `node-two`, and `node-three`. The three nodes will be data nodes, and part of a cluster named `dc1-cluster` with the group name `dc1`. +We recommend that you export the PGPASSWORD environment variable to avoid having to enter the password for the `pgdadmin` user each time you run a command. You can do this with the following command: + +```shell +export PGPASSWORD=pgdsecret +``` + ### Configuring the first node ```shell -pgd node node-one setup ---group-name dc1 --cluster-name dc1-cluster --create-group \ ---cluster-dsn "host=localhost port=5432 user=postgres dbname=bdrdb" \ ---pgdata /var/lib/edb-pge/17/main +pgd node node-one setup --dsn "host=host-1 port=5432 user=pgdadmin dbname=pgddb" \ +--listen-addr "localhost,host-1" \ +--group-name group-1 --cluster-name pgd \ +-D /var/lib/edb-pge/17/main ``` -Stepping through the command, we are setting up "node-one". This is the first node in the cluster, so we set the group name to `dc1` and the cluster name to `dc1-cluster`. The `--create-group` option indicates that this is the first node in the group, so it will create the group as well. +Stepping through the command, we are setting up "node-one". The first option is the `--dsn` option, which is the connection string for the node. This is typically set to `host=hostname port=5432 user=pgdadmin dbname=pgd`, which is a typical connection string for a local Postgres instance. + +The `--listen-address` option is used to specify the address that the node will listen on for incoming connections. In this case, we are setting it to `localhost,host-1`, which means that the node will listen on both the localhost and the host-1 address. -We also need to provide the `--cluster-dsn` option, which is the connection string for the first node. This is typically set to `host=localhost port=5432 user=postgres dbname=bdrdb`, which is a typical connection string for a local Postgres instance. +This is the first node in the cluster, so we set the group name to `group-1` and the cluster name to `pgd` (which is actually the default). As this is the first node in the cluster, the `--create-group` option is automatically set. -Finally, we set the data directory for the node with the `--pgdata` option; this is where the Postgres data files will be stored. In this example, we are using `/var/lib/edb-pge/17/main` as the data directory. +Finally, we set the data directory for the node with the `-D` option; this is where the Postgres data files will be stored. In this example, we are using `/var/lib/edb-pge/17/main` as the data directory. The command will create the data directory and initialize the database correctly for PGD. It will then start the node and make it available for new connections, including the other nodes joining the cluster. -### Configuring the second node +### Configuring a second node + +```shell +pgd node node-two setup --dsn "host=host-2 port=5432 user=pgdadmin dbname=pgddb" \ +--listen-addr "localhost,host-2" \ +-D /var/lib/edb-pge/17/main +--cluster-dsn "host=host-1 port=5432 user=pgdadmin dbname=pgd" +``` + +This command is similar to the first node, but we are setting up "node-two". The `--dsn` option is the connection string for the node, which is typically set to `host=hostname port=5432 user=pgdadmin dbname=pgd`. The `--cluster-dsn` option is the connection string for the first node in the cluster, which is used to join the cluster. In this case, we are setting it to `host=host-1 port=5432 user=pgdadmin dbname=pgd`, which is the connection string for the first node in the cluster. + +### Configuring a third node ```shell -pgd node node-two setup --pgdata /var/lib/edb-pge/17/main --group-name dc1 --cluster-name dc1-cluster --cluster-dsn "host= port=5444 user=postgres dbname=bdrdb" --create-group +pgd node node-three setup --dsn "host=host-3 port=5432 user=pgdadmin dbname=pgddb" \ +--listen-addr "localhost,host-3" \ +--cluster-dsn "host=host-1 port=5432 user=pgdadmin dbname=pgd" \ +-D /var/lib/edb-pge/17/main ``` +This command is similar to the second node, but we are setting up "node-three". The `--dsn` option is the connection string for the node, which is typically set to `host=hostname port=5432 user=pgdadmin dbname=pgd`. The `--cluster-dsn` option is the connection string for the first node in the cluster, which is used to join the cluster. In this case, we are setting it to `host=host-1 port=5432 user=pgdadmin dbname=pgd`, which is the connection string for the first node in the cluster. diff --git a/product_docs/docs/pgd/6/reference/index.mdx b/product_docs/docs/pgd/6/reference/index.mdx index 2261ca6a46d..e17b4c9efec 100644 --- a/product_docs/docs/pgd/6/reference/index.mdx +++ b/product_docs/docs/pgd/6/reference/index.mdx @@ -2,31 +2,66 @@ title: PGD Reference navTitle: Reference navigation: +- "#Functions and Commands" - tables-views-functions -- appusage -- autopartition -- architectures -- cdc-failover - cli +- "#Configuration and Management" +- architectures +- nodes +- node-management +- connection-manager +- postgres-configuration +- autopartition - commit-scopes - conflict-management -- connection-manager +- testing-tuning +- "# Guidance for developers" +- appusage +- "# Advanced functionality" - ddl - decoding-worker -- nodes -- node-management +- cdc-failover - parallelapply -- postgres-configuration - repsets - security - sequences - striggers -- testing-tuning - transaction-streaming - tssnapshots - twophase +description: Reference documentation for EDB Postgres Distributed (PGD) 6.0. --- - The PGD Reference section provides detailed information about PGD's features. +## Functions and Commands + +* [Tables, Views, and Functions](/pgd/latest/reference/tables-views-functions) +* [Command Line Interface (CLI)](/pgd/latest/reference/cli) + +## Configuration and Management + +* [Architectures](/pgd/latest/reference/architectures) +* [Nodes](/pgd/latest/reference/nodes) +* [Node Management](/pgd/latest/reference/node-management) +* [Connection Manager](/pgd/latest/reference/connection-manager) +* [Postgres Configuration](/pgd/latest/reference/postgres-configuration) +* [Autopartition](/pgd/latest/reference/autopartition) +* [Commit Scopes](/pgd/latest/reference/commit-scopes) +* [Conflict Management](/pgd/latest/reference/conflict-management) +* [Testing and Tuning](/pgd/latest/reference/testing-tuning) + +## Advanced Functionality +* [Application Usage](/pgd/latest/reference/appusage) + Guidance for developers wanting to use PGD's advanced functionality in their applications. +* [DDL](/pgd/latest/reference/ddl) +* [Decoding Worker](/pgd/latest/reference/decoding-worker) +* [CDC Failover](/pgd/latest/reference/cdc-failover) +* [Parallel Apply](/pgd/latest/reference/parallelapply) +* [Replication Sets](/pgd/latest/reference/repsets) +* [Security](/pgd/latest/reference/security) +* [Sequences](/pgd/latest/reference/sequences) +* [Triggers](/pgd/latest/reference/triggers) +* [Transaction Streaming](/pgd/latest/reference/transaction-streaming) +* [TSSnapshots](/pgd/latest/reference/tssnapshots) +* [Two-Phase Commit](/pgd/latest/reference/twophase) From 4a5aa50a5a6d081d139a9a481c7957e0d669faca Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Mon, 19 May 2025 08:19:07 +0100 Subject: [PATCH 082/145] relnote updates, upgrade corrections Signed-off-by: Dj Walker-Morgan --- .../pgd/6/essential-how-to/sops/upgrade.mdx | 2 +- .../get-started/essential-standard/index.mdx | 5 +-- product_docs/docs/pgd/6/reference/upgrade.mdx | 2 +- .../pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx | 22 +++++++-- .../pgd/6/rel_notes/src/relnote_6.0.0.yml | 45 +++++++++++++++++-- 5 files changed, 63 insertions(+), 13 deletions(-) diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/upgrade.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/upgrade.mdx index 618f2e22690..2a0427f5877 100644 --- a/product_docs/docs/pgd/6/essential-how-to/sops/upgrade.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/sops/upgrade.mdx @@ -13,4 +13,4 @@ This SOP covers the process of upgrading the Postgres database servers running o ## Upgrading to EDB Postgres Distributed 6 -See the [reference documentation](../reference/upgrade) for more information on upgrading to EDB Postgres Distributed 6.0.0. +See the [reference documentation](/pgd/latest/reference/upgrade) for more information on upgrading to EDB Postgres Distributed 6.0.0. diff --git a/product_docs/docs/pgd/6/get-started/essential-standard/index.mdx b/product_docs/docs/pgd/6/get-started/essential-standard/index.mdx index 92b62e23c91..a51a4ae6ce7 100644 --- a/product_docs/docs/pgd/6/get-started/essential-standard/index.mdx +++ b/product_docs/docs/pgd/6/get-started/essential-standard/index.mdx @@ -3,13 +3,12 @@ title: PGD Essential Standard/One-location Architecture navTitle: Standard Architecture --- -The standard architecture is the basic building block for EDB Postgres Distributed. It is most commonly used on a single location where the nodes are in the same data center, and it is also called the one-location architecture. +The standard architecture is the basic building block for EDB Postgres Distributed. It is most commonly used on a single location where the nodes are in the same data center, and it is also called the one-location architecture. ## Standard/One-location architecture The one-location architecture consists of a single PGD cluster with three nodes. The nodes are located in the same data center or availability zone. The nodes are connected to each other using a high-speed network. -The nodes are configured as a data sub-group which means that they replicate data to each other within the same group. In PGD Essential, the group also uses the same write leader node, one node selected by the nodes in the group. The write leader node is responsible for accepting write transactions and replicating them to the other nodes in the group. If the write leade node fails, the other nodes in the group will elect a new write leader node. +The nodes are configured as a data sub-group which means that they replicate data to each other within the same group. In PGD Essential, the group also uses a write leader node, one node selected by the nodes in the group to handle all the writes. The write leader node is responsible for accepting write transactions and replicating them to the other nodes in the group. If the write leader node fails, the other nodes in the group will elect a new write leader node. Applications can connect to any node in the cluster using PGD's connection manager which runs on every data node. It will automatically route read and write transactions to the write leader. It can also route read only transactions to the other nodes in the group. - diff --git a/product_docs/docs/pgd/6/reference/upgrade.mdx b/product_docs/docs/pgd/6/reference/upgrade.mdx index 8f947f90acf..78c2cb15483 100644 --- a/product_docs/docs/pgd/6/reference/upgrade.mdx +++ b/product_docs/docs/pgd/6/reference/upgrade.mdx @@ -7,4 +7,4 @@ redirects: ## Upgrading to EDB Postgres Distributed 6 -You cannot upgrade to EDB Postgres Distributed 6.0.0 from any earlier version of EDB Postgres Distributed 5.x or earlier. This will be possible in a future release. \ No newline at end of file +You cannot upgrade to EDB Postgres Distributed 6.0.0 from any earlier version of EDB Postgres Distributed 5.x or earlier. This will be possible in a future release. diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx index 58250e9d4d8..a92d367faf0 100644 --- a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx +++ b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx @@ -97,6 +97,12 @@ ALTER TABLE foo ALTER data TYPE BYTEA USING data::bytea;
Restrictions on non-immutable ALTER TABLE... ADD COLUMN calls have been removed.

The restrictions on non-immutable ALTER TABLE... ADD COLUMN calls have been removed.

+
Synchronize roles and tablespaces during logical join

Roles and tablespaces are now synchronized before the schema is restored from +the join source node. If there are already existing roles or tablespaces (or EPAS +profiles, they will be updated to have the same settings, passwords etc. as the +ones from the join source node. +System roles (i.e. the ones created by initdb) are not synchronized.

+
Introduce bdr.node_group_config_summary view

The new bdr.node_group_config_summary view contains detailed information about group options, including effective value, source of the effective value, default value, whether the value can be inherited, etc. This is in similar spirit to pg_settings

Leader DML lock

New lock type leader DML lock is used by default for locking DDL statements that need to block DML. This lock locks on write-leaders only, no requiring all nodes to participate in the locking operation. Old behavior can be restored by adjusting bdr.ddl_locking configuration parameter.

@@ -117,8 +123,8 @@ running a configuration with multiple nodes on the same machine, you will need t
New column for pgd cluster verify --settings CLI command output.

Add the recommended_value column to the result of the pgd cluster verify --settings command. The column will not be displayed in tabular output but will be displayed in JSON output.

-
Display sorted output for CLI.

The output for the commands with tabular output will be sorted by the resource name. -The commands that display more than one resource, the output will be sorted by each resource column in order.

+
Display sorted output for CLI.

The output for the commands with tabular output are now sorted by the resource name. +Commands that display more than one resource will sort output by each resource column in order.

Subscriber-only nodes replication.

Subscriber-only nodes now receive data only after it has been replicated to majority of data nodes. This does not require any special configuration. Subsequently bdr.standby_slot_names and bdr.standby_slots_min_confirmed options are removed as similar physical standby functionality is provided in pg_failover_slots extension and in PG17+.

@@ -148,21 +154,29 @@ The commands that display more than one resource, the output will be sorted by e ## Bug Fixes - + + +
DescriptionAddresses
Fix the CLI pgd cluster show command issues on a degraded cluster.

The pgd cluster show command failed with error for clock drift if only one node is up and running in a N node cluster. -The command is fixed to return valid output for other components viz., health and summary while reporting a valid error for clock-drift.

+
Fix the CLI pgd cluster show command issues on a degraded cluster.

The pgd cluster show command failed with an error for clock drift if only one node was up and running in a N node cluster. +The command now returns valid output for the other components, health and summary, while reporting an appropriate error for clock-drift.

Fix the CLI pgd node show command issue if a non-existent node is specified.

The pgd node show command crashed if a non-existent node is specified to the command. The command is fixed to fail gracefully with appropriate error message.

Fixed the timestamp parsing issue for pgd replication show CLI command.

The pgd replication show command previously crashed when formatting EPAS timestamps.

+
Fixed issue where parting node may belong to a non-existing group

When parting a given node, that same node may have subscriptions whose origin was already parted and the group dropped. Previously this would break PGD, and has since been fixed.

num_writers should be positive or -1

The num_writers option, used in bdr.alter_node_group_option() and bdr.alter_node_group_config() should be positive or -1.

Fix replication breakage with updates to non-unique indexes

Fixes the case where an update to a table with non-unique indexes results in the ERROR +concurrent INSERT when looking for delete rows, which breaks replication.

+
43523,43802,45244,47815
Fixed deadlock issue in bdr_init_physical.

Fixed deadlock between bdr_init_physical cleaning unwanted node data and concurrent monitoring queries.

46952
Fixed new cluster node consistency issue.

Fixed an issue when new node joining the cluster finishes CATCHUP phase before getting its replication progress against all data nodes. This may cause new node being out of sync with the cluster.

Ensure correct sequence type is displayed in CREATE SEQUENCE warnings

In some cases, warning messages referred to timeshard when the sequence +was actually snowflakeid.

+
diff --git a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml index 2fb1016fab2..1f007da54cb 100644 --- a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml +++ b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml @@ -47,6 +47,17 @@ relnotes: type: Feature impact: High +- relnote: Synchronize roles and tablespaces during logical join + details: | + Roles and tablespaces are now synchronized before the schema is restored from + the join source node. If there are already existing roles or tablespaces (or EPAS + profiles, they will be updated to have the same settings, passwords etc. as the + ones from the join source node. + System roles (i.e. the ones created by initdb) are not synchronized. + jira: BDR-5976 + type: Enhancement + impact: Medium + - relnote: Limit on the number of node groups allowed in the system for PGD Essential. details: | Ensure that no more than three node groups (one top group and two subgroups) can exist at any given time. If the limit is exceeded, an error is raised. @@ -275,16 +286,16 @@ relnotes: - relnote: Display sorted output for CLI. details: | - The output for the commands with tabular output will be sorted by the resource name. - The commands that display more than one resource, the output will be sorted by each resource column in order. + The output for the commands with tabular output are now sorted by the resource name. + Commands that display more than one resource will sort output by each resource column in order. jira: BDR-6094 type: Enhancement impact: Medium - relnote: Fix the CLI `pgd cluster show` command issues on a degraded cluster. details: | - The `pgd cluster show` command failed with error for clock drift if only one node is up and running in a N node cluster. - The command is fixed to return valid output for other components viz., `health` and `summary` while reporting a valid error for `clock-drift`. + The `pgd cluster show` command failed with an error for clock drift if only one node was up and running in a N node cluster. + The command now returns valid output for the other components, `health` and `summary`, while reporting an appropriate error for `clock-drift`. jira: BDR-6135 type: Bug Fix impact: High @@ -359,3 +370,29 @@ relnotes: type: Bug Fix impact: Low +- relnote: Fixed the timestamp parsing issue for `pgd replication show` CLI command. + details: | + The `pgd replication show` command previously crashed when formatting EPAS timestamps. + jira: BDR-6347 + type: Bug Fix + impact: High + +- relnote: Fix replication breakage with updates to non-unique indexes + component: BDR + details: | + Fixes the case where an update to a table with non-unique indexes results in the ERROR + `concurrent INSERT when looking for delete rows`, which breaks replication. + jira: BDR-5811 + addresses: "43523,43802,45244,47815" + type: Bug Fix + impact: Medium + +- relnote: Ensure correct sequence type is displayed in CREATE SEQUENCE warnings + component: BDR + details: | + In some cases, warning messages referred to `timeshard` when the sequence + was actually `snowflakeid`. + jira: BDR-6266 + addresses: "" + type: Bug Fix + impact: Low \ No newline at end of file From f6dc11dd9e516a67b0248781a90b76f264689d60 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Mon, 19 May 2025 08:34:38 +0100 Subject: [PATCH 083/145] Missing release note and fix for node-management Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/reference/index.mdx | 4 ++-- .../docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx | 2 ++ .../docs/pgd/6/rel_notes/src/relnote_6.0.0.yml | 13 ++++++++++++- 3 files changed, 16 insertions(+), 3 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/index.mdx b/product_docs/docs/pgd/6/reference/index.mdx index e17b4c9efec..c2b045d215e 100644 --- a/product_docs/docs/pgd/6/reference/index.mdx +++ b/product_docs/docs/pgd/6/reference/index.mdx @@ -8,7 +8,7 @@ navigation: - "#Configuration and Management" - architectures - nodes -- node-management +- node_management - connection-manager - postgres-configuration - autopartition @@ -43,7 +43,7 @@ The PGD Reference section provides detailed information about PGD's features. * [Architectures](/pgd/latest/reference/architectures) * [Nodes](/pgd/latest/reference/nodes) -* [Node Management](/pgd/latest/reference/node-management) +* [Node Management](/pgd/latest/reference/node_management) * [Connection Manager](/pgd/latest/reference/connection-manager) * [Postgres Configuration](/pgd/latest/reference/postgres-configuration) * [Autopartition](/pgd/latest/reference/autopartition) diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx index a92d367faf0..bf6673534aa 100644 --- a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx +++ b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx @@ -170,6 +170,8 @@ origin was already parted and the group dropped. Previously this would break PGD
Fix replication breakage with updates to non-unique indexes

Fixes the case where an update to a table with non-unique indexes results in the ERROR concurrent INSERT when looking for delete rows, which breaks replication.

43523,43802,45244,47815 +
Fixed issue where manually disabled subscriptions were automatically re-enabled

Fixed an issue where manually disabled subscriptions to a subscriber-only node were re-enabled by the manager.

+
46519
Fixed deadlock issue in bdr_init_physical.

Fixed deadlock between bdr_init_physical cleaning unwanted node data and concurrent monitoring queries.

46952
Fixed new cluster node consistency issue.

Fixed an issue when new node joining the cluster finishes CATCHUP phase before getting its replication progress against all data nodes. This may cause new node being out of sync with the cluster.

diff --git a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml index 1f007da54cb..fe5d06f3000 100644 --- a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml +++ b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml @@ -395,4 +395,15 @@ relnotes: jira: BDR-6266 addresses: "" type: Bug Fix - impact: Low \ No newline at end of file + impact: Low + +- relnote: Fixed issue where manually disabled subscriptions were automatically re-enabled + component: BDR + details: | + Fixed an issue where manually disabled subscriptions to a subscriber-only node were re-enabled by the manager. + jira: BDR-6314 + addresses: "46519" + type: Bug Fix + impact: Medium + + \ No newline at end of file From 805a13d3c0619675091148995e17bcb1985768f6 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Mon, 19 May 2025 08:45:02 +0100 Subject: [PATCH 084/145] release note fix Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx | 2 +- product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx index bf6673534aa..aac0d81e7a9 100644 --- a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx +++ b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx @@ -55,7 +55,7 @@ EDB Postgres Distributed 6.0.0 is a major update to PGD and sees the introductio
Added bdr.wait_node_confirm_lsn() function which waits until a given reaches a given LSN

bdr.wait_node_confirm_lsn() will look at the confirmed_flush_lsn of the given node when available, otherwise it will query pg_replication_origin_progress() of that node, and wait for the specified LSN to be reached by said node.

-
Subscriber-only nodes can now be added to data node groups

So far subscriber-only nodes could only be added to node groups of type "subscriber-only". But now a subscriber-only node can be added to a data node group too. Only node_kind='subscriber_only' needs to be specified while doing a create_node as before. the join_node_group can be done on a data node group.

+
Subscriber-only nodes can now be added to data node groups

In previous versions, subscriber-only nodes could only be added to node groups of type "subscriber-only". In PGD 6, a subscriber-only node can be also be added to a data node group by specifying node_kind='subscriber_only' when using create_node. The join_node_group can then be done using a data node group.

Add bdr.local_analytics_slot_name() SQL function.

Returns name of analytics slot. This merely produces the correct name irrespective of whether analytics feature is in use.

diff --git a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml index fe5d06f3000..60de2255a55 100644 --- a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml +++ b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml @@ -184,7 +184,7 @@ relnotes: - relnote: Subscriber-only nodes can now be added to data node groups details: | - So far subscriber-only nodes could only be added to node groups of type "subscriber-only". But now a subscriber-only node can be added to a data node group too. Only node_kind='subscriber_only' needs to be specified while doing a create_node as before. the join_node_group can be done on a data node group. + In previous versions, subscriber-only nodes could only be added to node groups of type "subscriber-only". In PGD 6, a subscriber-only node can be also be added to a data node group by specifying node_kind='subscriber_only' when using create_node. The join_node_group can then be done using a data node group. jira: BDR-6106 type: Feature impact: Medium From 733fa7e11656728458c2c814c5ea3618f1f77861 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Mon, 19 May 2025 08:54:13 +0100 Subject: [PATCH 085/145] Remove dupes Signed-off-by: Dj Walker-Morgan --- .../pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx | 7 ++++++- .../pgd/6/rel_notes/src/relnote_6.0.0.yml | 19 +++++++++++++++---- 2 files changed, 21 insertions(+), 5 deletions(-) diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx index aac0d81e7a9..366b84b9048 100644 --- a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx +++ b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx @@ -170,7 +170,12 @@ origin was already parted and the group dropped. Previously this would break PGD
Fix replication breakage with updates to non-unique indexes

Fixes the case where an update to a table with non-unique indexes results in the ERROR concurrent INSERT when looking for delete rows, which breaks replication.

43523,43802,45244,47815 -
Fixed issue where manually disabled subscriptions were automatically re-enabled

Fixed an issue where manually disabled subscriptions to a subscriber-only node were re-enabled by the manager.

+
Fix Raft leader election timeout/failure after upgrade

Ensure that any custom value set in the deprecated GUC bdr.raft_election_timeout +is applied to the replacement bdr.raft_global_election_timeout

+
+
Ensure that disables subscriptions on subscriber-only nodes are not re-enabled

During subscription reconfiguration, if there is no change required to a subscription, +do not enable it since it could have been disabled explicitly by the user. +Skip reconfiguring subscriptions if there are no leadership changes.

46519
Fixed deadlock issue in bdr_init_physical.

Fixed deadlock between bdr_init_physical cleaning unwanted node data and concurrent monitoring queries.

46952 diff --git a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml index 60de2255a55..fc399727089 100644 --- a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml +++ b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml @@ -397,13 +397,24 @@ relnotes: type: Bug Fix impact: Low -- relnote: Fixed issue where manually disabled subscriptions were automatically re-enabled +- relnote: Fix Raft leader election timeout/failure after upgrade component: BDR details: | - Fixed an issue where manually disabled subscriptions to a subscriber-only node were re-enabled by the manager. - jira: BDR-6314 - addresses: "46519" + Ensure that any custom value set in the deprecated GUC `bdr.raft_election_timeout` + is applied to the replacement `bdr.raft_global_election_timeout` + jira: BDR-6068 + addresses: "" type: Bug Fix impact: Medium +- relnote: Ensure that disables subscriptions on subscriber-only nodes are not re-enabled + component: BDR + details: | + During subscription reconfiguration, if there is no change required to a subscription, + do not enable it since it could have been disabled explicitly by the user. + Skip reconfiguring subscriptions if there are no leadership changes. + jira: BDR-6270 + addresses: "46519" + type: Bug Fix + impact: Medium \ No newline at end of file From ee8a0d0dbb5effbfb29890ddf6e89405fbb4b930 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Tue, 20 May 2025 10:36:30 +0100 Subject: [PATCH 086/145] Users and roles opening Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/reference/cli/command_ref/node/setup.mdx | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx index 6b9c9ecb97e..62846fd14ed 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx @@ -18,6 +18,12 @@ If the local node is up and running and remote node also is reachable, `pgd node If the local node is up and running and remote node dsn is not provided, `pgd node setup` will do a node group switch if node not part of the given group. +### Users and roles + +The `pgd node setup` command requires a superuser role to run. The superuser role is used to create the data directory and initialize the database. The superuser role must have the `CREATEDB` privilege to create the database. + +The user specified in the `--dsn` option will be created if it does not exist. It will only be granted the `bdr_superuser` role which will allow it to administer PGD functionality. It will not, though have any other privileges on the database. + ## Syntax ```plaintext From 40f9ba2be71fdeb92eec8d88ea5c2a4eb118b678 Mon Sep 17 00:00:00 2001 From: Jagdish Kewat Date: Tue, 20 May 2025 20:19:40 +0530 Subject: [PATCH 087/145] BDR-6300 - Update docs for 'pgd node setup'. Add the section for joining a parted and dropped node to the cluster. --- .../reference/cli/command_ref/node/setup.mdx | 53 ++++++++++++------- 1 file changed, 33 insertions(+), 20 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx index 62846fd14ed..f642fd89944 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/node/setup.mdx @@ -10,7 +10,7 @@ The `pgd node setup` command is used to configure PGD data nodes in a cluster. I The behavior of the command depends on the state of the local node and the remote node specified in the command. -If this is the first node in the cluster, `pgd node setup` will perform initdb and setup PGD node. +If this is the first node in the cluster, `pgd node setup` will perform `initdb` and setup PGD node. If this is not the first node, but the local node is not up and running, `pgd node setup` will perform a physical join of the node to the cluster. This will copy the data from the remote node to the local node as part of the initialization process, then join the local node to the cluster. This is the fastest way to load data into a new node. @@ -34,23 +34,22 @@ pgd node setup [OPTIONS] -D - The name of the node to be created. This is the name that will be used to identify the node in the cluster. It must be unique within the cluster. -- The data directory for the node. This is where the Postgres data files will be stored. It must be a valid directory and must be writable by the user running the command. ## Options | Option                                              | Description | |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `--listen-addr ` | The address that the configured node will listen on for incoming connections, and the address that other nodes will use to connect to this node. This is typically set to at least `localhost`, but can be set to any valid address. The default is `localhost`. | +| `--listen-addr ` | The address that the configured node will listen on for incoming connections, and the address that other nodes will use to connect to this node. This is typically set to at least `localhost`, but can be set to any valid address. The default is `localhost`. The `host` value from the `--dsn` will also be appended to this list. | | `--initial-node-count ` | Number of nodes in the cluster (or planned to be in the cluster). Used to calculate various resource settings for the node. Default is 3. | | `--bindir ` | Specifies the directory where the binaries are located. Defaults to the directory where the running pgd binary is located. | -| `--log-file ` | Log file to write the log messages to. Records log messages for any external commands executed. Default is to write a file in the current directory named `postgres-.log` where the port value | -| `-D`, `--pgdata ` | Uses as the data directory of the node. (Also set with environment variable `PGDATA`) | -| `--superuser ` | The superuser to use for the connection. | -| `--node-kind ` | Specifies the kind of node to be created. Applies to first node only. Default is `data`.Possible values are `data`, `witness`, `subscriber-only`. | +| `--log-file ` | Path to log file, used for postgres startup logs. Default is to write to a file in the current directory named `postgres-.log` where the port value is fetched from the `port` attribute of `--dsn` option. | +| `-D`, `--pgdata ` | Uses as the data directory of the node. (Also set with environment variable `PGDATA`). It must be a valid directory and must be writable by the user running the command. | +| `--superuser ` | Superuser name for `initdb`. Default is `postgres`. | +| `--node-kind ` | Specifies the kind of node to be created. Default is `data`. Possible values are `data`, `witness`, `subscriber-only`. | | `--group-name ` | Node group name. If not provided, the node will be added to the group of the active node. It is a mandatory argument for the first node of a group. | | `--create-group` | Set this flag to create the given group, if it is not already present. This will be true by default for the first node. | -| `--cluster-name ` | Name of the cluster to join the node to. Defaults to `pgd` | -| `--cluster-dsn ` | A DSN which belongs to the active PGD cluster. When configuring the first node of a cluster, should point to the DSN for the first node. | +| `--cluster-name ` | Name of the cluster to join the node to. When setting up cluster for the first time this will be used to create the `parent node group`. Defaults to `pgd` if not specified. | +| `--cluster-dsn ` | A DSN which belongs to the active PGD cluster. This is not required when configuring the first node of a cluster, however is mandatory for subsequent nodes. Should point to the DSN of an existing active node. | | `--postgresql-conf ` | Optional path of the `postgresql.conf` file to be used for the node. | | `--postgresql-auto-conf ` | Optional path of the `postgresql.auto.conf` file to be used for the node. | | `--hba-conf ` | Optional path of the `pg_hba.conf` file to be used for the node. | @@ -60,8 +59,8 @@ See also [Global Options](/pgd/latest/cli/command_ref/#global-options). ## Examples -In these examples, we will set up a cluster with on three hosts, `host-1`, `host-2` and `host-3`, to create three nodes: `node-one`, `node-two`, and `node-three`. -The three nodes will be data nodes, and part of a cluster named `dc1-cluster` with the group name `dc1`. +In these examples, we will set up a cluster with on three hosts, `host-1`, `host-2` and `host-3`, to create three nodes: `node-1`, `node-2`, and `node-3`. +The three nodes will be data nodes, and part of a cluster named `pgd` with the group name `group-1`. We recommend that you export the PGPASSWORD environment variable to avoid having to enter the password for the `pgdadmin` user each time you run a command. You can do this with the following command: @@ -72,15 +71,15 @@ export PGPASSWORD=pgdsecret ### Configuring the first node ```shell -pgd node node-one setup --dsn "host=host-1 port=5432 user=pgdadmin dbname=pgddb" \ +pgd node node-1 setup --dsn "host=host-1 port=5432 user=pgdadmin dbname=pgddb" \ --listen-addr "localhost,host-1" \ --group-name group-1 --cluster-name pgd \ -D /var/lib/edb-pge/17/main ``` -Stepping through the command, we are setting up "node-one". The first option is the `--dsn` option, which is the connection string for the node. This is typically set to `host=hostname port=5432 user=pgdadmin dbname=pgd`, which is a typical connection string for a local Postgres instance. +Stepping through the command, we are setting up `node-1`. The first option is the `--dsn` option, which is the connection string for the node. This is typically set to `host=hostname port=5432 user=pgdadmin dbname=pgd`, which is a typical connection string for a local Postgres instance. -The `--listen-address` option is used to specify the address that the node will listen on for incoming connections. In this case, we are setting it to `localhost,host-1`, which means that the node will listen on both the localhost and the host-1 address. +The `--listen-address` option is used to specify the address that the node will listen on for incoming connections. In this case, we are setting it to `localhost,host-1`, which means that the node will listen on both the localhost and the `host-1` address. This is the first node in the cluster, so we set the group name to `group-1` and the cluster name to `pgd` (which is actually the default). As this is the first node in the cluster, the `--create-group` option is automatically set. @@ -92,21 +91,35 @@ The command will create the data directory and initialize the database correctly ### Configuring a second node ```shell -pgd node node-two setup --dsn "host=host-2 port=5432 user=pgdadmin dbname=pgddb" \ +pgd node node-2 setup --dsn "host=host-2 port=5432 user=pgdadmin dbname=pgddb" \ --listen-addr "localhost,host-2" \ -D /var/lib/edb-pge/17/main ---cluster-dsn "host=host-1 port=5432 user=pgdadmin dbname=pgd" +--cluster-dsn "host=host-1 port=5432 user=pgdadmin dbname=pgddb" ``` -This command is similar to the first node, but we are setting up "node-two". The `--dsn` option is the connection string for the node, which is typically set to `host=hostname port=5432 user=pgdadmin dbname=pgd`. The `--cluster-dsn` option is the connection string for the first node in the cluster, which is used to join the cluster. In this case, we are setting it to `host=host-1 port=5432 user=pgdadmin dbname=pgd`, which is the connection string for the first node in the cluster. +This command is similar to the first node, but we are setting up `node-2`. The `--dsn` option is the connection string for the node, which is typically set to `host=hostname port=5432 user=pgdadmin dbname=pgd`. The `cluster-dsn` must point to an active node, it can point to connection manager, or proxy endpoint etc., CLI will get the real DSN of the node behind it. In this case, we are setting it to `host=host-1 port=5432 user=pgdadmin dbname=pgd`, which is the connection string for the first node in the cluster. ### Configuring a third node ```shell -pgd node node-three setup --dsn "host=host-3 port=5432 user=pgdadmin dbname=pgddb" \ +pgd node node-3 setup --dsn "host=host-3 port=5432 user=pgdadmin dbname=pgddb" \ --listen-addr "localhost,host-3" \ ---cluster-dsn "host=host-1 port=5432 user=pgdadmin dbname=pgd" \ +--cluster-dsn "host=host-1 port=5432 user=pgdadmin dbname=pgddb" \ -D /var/lib/edb-pge/17/main ``` -This command is similar to the second node, but we are setting up "node-three". The `--dsn` option is the connection string for the node, which is typically set to `host=hostname port=5432 user=pgdadmin dbname=pgd`. The `--cluster-dsn` option is the connection string for the first node in the cluster, which is used to join the cluster. In this case, we are setting it to `host=host-1 port=5432 user=pgdadmin dbname=pgd`, which is the connection string for the first node in the cluster. +This command is similar to the second node, but we are setting up `node-3`. The `--dsn` option is the connection string for the node, which is typically set to `host=hostname port=5432 user=pgdadmin dbname=pgd`. The `cluster-dsn` must point to an active node, it can point to connection manager, or proxy endpoint etc., CLI will get the real DSN of the node behind it. In this case, we are setting it to `host=host-1 port=5432 user=pgdadmin dbname=pgd`, which is the connection string for the first node in the cluster. + +### Joining a parted and dropped node to the cluster + +```shell +pgd node node-2 setup --dsn "host=host-2 port=5432 user=pgdadmin dbname=pgddb" \ +--listen-addr "localhost,host-2" \ +--cluster-dsn "host=host-1 port=5432 user=pgdadmin dbname=pgddb" \ +-D /var/lib/edb-pge/17/main +``` + +This command is similar to the setting up the subsequent nodes, but we are setting up `node-2` again. The `--dsn` option is the connection string for the node, which is typically set to `host=hostname port=5432 user=pgdadmin dbname=pgd`. The `cluster-dsn` must point to an active node, it can point to connection manager, or proxy endpoint etc., CLI will get the real DSN of the node behind it. In this case, we are setting it to `host=host-1 port=5432 user=pgdadmin dbname=pgd`, which is the connection string for the first node in the cluster. + +This is useful when a node has been `parted` and `dropped` from the cluster for some activity like maintenance and needs to be rejoined to the cluster. The command will perform a logical join of the node to the cluster, which will create a new node in the cluster and start streaming replication from the remote node. + From a28a3bb8ed5cef2901148cee461a29353642fe28 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Tue, 20 May 2025 13:05:58 +0100 Subject: [PATCH 088/145] DDL for 6.0 on SO update Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/6/rel_notes/src/relnote_6.0.0.yml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml index fc399727089..a9ecd8963a8 100644 --- a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml +++ b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml @@ -417,4 +417,12 @@ relnotes: addresses: "46519" type: Bug Fix impact: Medium - \ No newline at end of file + +- relnote: Subscriber-only nodes will not take a lock when running DDL + details: | + Subscriber-only nodes will no longer attempt to take a lock when running DDL. The DDL will be executed locally and not replicated to other nodes. + component: BDR + jira: BDR-3767 + addresses: "47233" + type: Bug Fix + impact: Medium \ No newline at end of file From a7a34c81abc1f91b3072c30f56a59f29b79493f9 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Tue, 20 May 2025 12:07:37 +0000 Subject: [PATCH 089/145] update generated release notes --- product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx | 2 ++ 1 file changed, 2 insertions(+) diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx index 366b84b9048..ba62699be4e 100644 --- a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx +++ b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx @@ -177,6 +177,8 @@ is applied to the replacement bdr.raft_global_election_timeout

do not enable it since it could have been disabled explicitly by the user. Skip reconfiguring subscriptions if there are no leadership changes.

46519 +
Subscriber-only nodes will not take a lock when running DDL

Subscriber-only nodes will no longer attempt to take a lock when running DDL. The DDL will be executed locally and not replicated to other nodes.

+
47233
Fixed deadlock issue in bdr_init_physical.

Fixed deadlock between bdr_init_physical cleaning unwanted node data and concurrent monitoring queries.

46952
Fixed new cluster node consistency issue.

Fixed an issue when new node joining the cluster finishes CATCHUP phase before getting its replication progress against all data nodes. This may cause new node being out of sync with the cluster.

From 4e3d0d1fc8846cd9095c1c1ed1d923fd9a579893 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan <126472455+djw-m@users.noreply.github.com> Date: Wed, 21 May 2025 09:45:48 +0100 Subject: [PATCH 090/145] Update product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml --- product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml index a9ecd8963a8..6dc828e1c8d 100644 --- a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml +++ b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml @@ -420,7 +420,7 @@ relnotes: - relnote: Subscriber-only nodes will not take a lock when running DDL details: | - Subscriber-only nodes will no longer attempt to take a lock when running DDL. The DDL will be executed locally and not replicated to other nodes. + Subscriber-only nodes will no longer attempt to take a lock on the cluster when running DDL. The DDL will be executed locally and not replicated to other nodes. component: BDR jira: BDR-3767 addresses: "47233" From d289d6ba6e947ec822c284826d51b541b73a2ca2 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 21 May 2025 08:46:52 +0000 Subject: [PATCH 091/145] update generated release notes --- product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx index ba62699be4e..f49f11ae546 100644 --- a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx +++ b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx @@ -177,7 +177,7 @@ is applied to the replacement bdr.raft_global_election_timeout

do not enable it since it could have been disabled explicitly by the user. Skip reconfiguring subscriptions if there are no leadership changes.

46519 -
Subscriber-only nodes will not take a lock when running DDL

Subscriber-only nodes will no longer attempt to take a lock when running DDL. The DDL will be executed locally and not replicated to other nodes.

+
Subscriber-only nodes will not take a lock when running DDL

Subscriber-only nodes will no longer attempt to take a lock on the cluster when running DDL. The DDL will be executed locally and not replicated to other nodes.

47233
Fixed deadlock issue in bdr_init_physical.

Fixed deadlock between bdr_init_physical cleaning unwanted node data and concurrent monitoring queries.

46952 From dcb49ab25b72268bde393e3fa0097d499ec7bced Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 22 May 2025 11:38:05 +0100 Subject: [PATCH 092/145] Various work and the installer split for going forward Signed-off-by: Dj Walker-Morgan --- .../install/01-prerequisites.mdx | 22 +- .../install/02-configure-repositories.mdx | 39 +-- .../03-installing-database-and-pgd.mdx | 48 +--- .../install/04-configuring-cluster.mdx | 129 ++++++---- .../install/05-check-cluster.mdx | 14 +- .../install/images/edbrepos2.0.png | 4 +- .../pgd/6/essential-how-to/install/index.mdx | 10 +- .../docs/pgd/6/essential-how-to/pgd-cli.mdx | 44 ++-- .../advanced-architectures/index.mdx | 5 - .../{ => architectures}/architectures.mdx | 0 .../6/expanded-how-to/architectures/index.mdx | 11 + .../install/01-prerequisites.mdx | 72 ++++++ .../install/02-configure-repositories.mdx | 59 +++++ .../03-installing-database-and-pgd.mdx | 143 +++++++++++ .../install/04-configuring-cluster.mdx | 237 ++++++++++++++++++ .../install/05-check-cluster.mdx | 222 ++++++++++++++++ .../install/images/edbrepos2.0.png | 3 + .../pgd/6/expanded-how-to/install/index.mdx | 12 + .../index.mdx => essential-standard.mdx} | 0 .../pgd/6/get-started/expanded-examples.mdx | 5 +- .../index.mdx => first-cluster.mdx} | 0 product_docs/docs/pgd/6/get-started/index.mdx | 20 +- .../6/reference/connection-manager/index.mdx | 8 +- .../node_management/automatic_sync.mdx | 40 +-- .../node_management/images/autosyncstates.svg | 1 + 25 files changed, 964 insertions(+), 184 deletions(-) delete mode 100644 product_docs/docs/pgd/6/expanded-how-to/advanced-architectures/index.mdx rename product_docs/docs/pgd/6/expanded-how-to/{ => architectures}/architectures.mdx (100%) create mode 100644 product_docs/docs/pgd/6/expanded-how-to/architectures/index.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/install/01-prerequisites.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/install/02-configure-repositories.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/install/03-installing-database-and-pgd.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/install/04-configuring-cluster.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/install/05-check-cluster.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/install/images/edbrepos2.0.png create mode 100644 product_docs/docs/pgd/6/expanded-how-to/install/index.mdx rename product_docs/docs/pgd/6/get-started/{essential-standard/index.mdx => essential-standard.mdx} (100%) rename product_docs/docs/pgd/6/get-started/{first-cluster/index.mdx => first-cluster.mdx} (100%) create mode 100644 product_docs/docs/pgd/6/reference/node_management/images/autosyncstates.svg diff --git a/product_docs/docs/pgd/6/essential-how-to/install/01-prerequisites.mdx b/product_docs/docs/pgd/6/essential-how-to/install/01-prerequisites.mdx index e18b249bb43..50e7de97ffb 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/01-prerequisites.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/01-prerequisites.mdx @@ -1,8 +1,16 @@ --- -title: 1 - Prerequisites for installation +title: 1 - Prerequisites for Essential installation navTitle: Prerequisites --- +This guide takes you through the steps to install EDB Postgres Distributed (PGD) Essential on your systems. + +If you want to install a learning/test environment, we recommend using the [PGD Essential Quickstart](/pgd/latest/quickstart). + +!!! Note +If you want to install EDB Postgres Distributed (PGD) Expanded, consult the [Expanded installation guide](/pgd/latest/expanded-how-to/install/01-prerequisites). +!!! + ## Provisioning hosts The first step in the process of deploying PGD is to provision and configure hosts. @@ -41,10 +49,9 @@ We also recommend that the admin user be configured for passwordless SSH access With the admin user created, ensure that each machine can communicate with the other machines you're provisioning. -In particular, the PostgreSQL TCP/IP port (5444 for EDB Postgres Advanced -Server, 5432 for EDB Postgres Extended and community PostgreSQL) must be open -to all machines in the cluster. The PGD Connection Manager must also be -accessible to all nodes in the cluster. By default, the Connection Manager uses port 6432 (or 6444 for EDB Postgres Advanced Server). +In particular, the PostgreSQL TCP/IP port (5444 for EDB Postgres Advanced Server, 5432 for EDB Postgres Extended and community PostgreSQL) must be open +to all machines in the cluster. +The PGD Connection Manager must also be accessible to all nodes in the cluster. By default, the Connection Manager uses port 6432 (or 6444 for EDB Postgres Advanced Server). ## Worked example @@ -69,3 +76,8 @@ For the example cluster, `/etc/hosts` was also edited to use those private IP ad 192.168.254.247 host-2 192.168.254.135 host-3 ``` + +In production environments, you should use DNS to resolve hostnames to IP addresses. + + + diff --git a/product_docs/docs/pgd/6/essential-how-to/install/02-configure-repositories.mdx b/product_docs/docs/pgd/6/essential-how-to/install/02-configure-repositories.mdx index 51657a66fc0..2d5c2f7fb22 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/02-configure-repositories.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/02-configure-repositories.mdx @@ -19,15 +19,6 @@ This is the token you received when you registered for the EDB subscription. It export EDB_SUBSCRIPTION_TOKEN= ``` -### `EDB_SUBSCRIPTION_PLAN` - -This is the plan you subscribed to. It is used to determine which packages are available for installation. This is typically either `standard` or `enterprise`. - -```bash -# Set the EDB subscription plan -export EDB_SUBSCRIPTION_PLAN= -``` - ### `EDB_REPO_TYPE` This is the type of package manager you use, which informs the installer which type of package you need. This can be `deb` for Ubuntu/Debian or `rpm` for CentOS/RHEL. @@ -38,44 +29,22 @@ export EDB_REPO_TYPE= ## Install the repository/repositories -For PGD Essential, there is just one repository to install. For PGD Extended, there are two repositories to install. - - - - - -Run the following command to install the EDB repository. This will add the EDB repository to your system's package manager, allowing you to install EDB packages. +For PGD Essential, there is just one repository to install. ```bash -curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/standard/setup.$EDB_REPO_TYPE.sh" | sudo -E bash ``` - - - - -```bash -curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/setup.$EDB_REPO_TYPE.sh" | sudo -E bash -curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/postgres_distributed/setup.$EDB_REPO_TYPE.sh" | sudo -E bash -``` - - - - - This command will download and run a script that configures your package manager to use the EDB repository. It will also install any necessary dependencies. - ## Worked example -In this example, we will configure the repositories on a CentOS/RHEL system that will allow us to install EDB Postgres Extended Server 17 with PGD Essential using an enterprise subscription. +In this example, we will configure the repositories on a CentOS/RHEL system that will allow us to install EDB Postgres Extended Server 17 with PGD Essential with a standard subscription. ### Set the environment variables ```bash export EDB_SUBSCRIPTION_TOKEN=XXXXXXXXXXXXXX -export EDB_SUBSCRIPTION_PLAN=enterprise export EDB_REPO_TYPE=rpm -curl -1sSLf " https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +curl -1sSLf " https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/standard/setup.$EDB_REPO_TYPE.sh" | sudo -E bash ``` - diff --git a/product_docs/docs/pgd/6/essential-how-to/install/03-installing-database-and-pgd.mdx b/product_docs/docs/pgd/6/essential-how-to/install/03-installing-database-and-pgd.mdx index 9fb9c22b843..e8208f13db3 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/03-installing-database-and-pgd.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/03-installing-database-and-pgd.mdx @@ -19,14 +19,6 @@ Set an environment variable to specify the version of Postgres you want to insta export PG_VERSION=17 ``` -### Set the PGD edition - -Set an environment variable to specify the edition of Postgres you want to install. This can be `essential` for PGD Essential or `expanded` for PGD Expanded. - -```bash -export PGD_EDITION=essential -``` - ### Set the package names Set an environment variable to specify the package names for the database and PGD software. The package names will vary depending on the database you are using and the platform you are on. @@ -34,16 +26,13 @@ Set an environment variable to specify the package names for the database and PG -


- -#### EDB Postgres Advanced Server ```shell -export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-$PGD_EDITION-epas$PG_VERSION" +export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-essential-epas$PG_VERSION" ``` @@ -51,7 +40,7 @@ export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-$PGD_EDITION-epas$PG_VERS ```shell -export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-$PGD_EDITION-epas$PG_VERSION" +export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-essential-epas$PG_VERSION" ``` @@ -60,16 +49,13 @@ export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-$PGD_EDITION-epas$PG_VERS -


- -#### EDB Postgres Extended ```bash - export EDB_PACKAGES="edb-postgresextended-$PG_VERSION edb-pgd6-$PGD_EDITION-pgextended$PG_VERSION" + export EDB_PACKAGES="edb-postgresextended-$PG_VERSION edb-pgd6-essential-pgextended$PG_VERSION" ``` @@ -77,7 +63,7 @@ export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-$PGD_EDITION-epas$PG_VERS ```bash - export EDB_PACKAGES="edb-postgresextended$PG_VERSION-server edb-postgresextended$PG_VERSION-contrib edb-pgd6-$PGD_EDITION-pgextended$PG_VERSION" + export EDB_PACKAGES="edb-postgresextended$PG_VERSION-server edb-postgresextended$PG_VERSION-contrib edb-pgd6-essential-pgextended$PG_VERSION" ``` @@ -85,33 +71,18 @@ export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-$PGD_EDITION-epas$PG_VERS -


- -#### Community PostgreSQL - +!!! note Not available - +
- ```bash - export EDB_PACKAGES="postgresql-$PG_VERSION edb-pgd6-$PGD_EDITION-pg$PG_VERSION" - ``` +Community PostgreSQL is only operable with PGD Expanded. - - +
- ```bash - export EDB_PACKAGES="postgresql$PG_VERSION-server postgresql$PG_VERSION-contrib edb-pgd6-$PGD_EDITION-pg$PG_VERSION" - ``` - - -!!! Note -Only PGD Expanded is available for Community PostgreSQL. !!! - - @@ -150,7 +121,6 @@ In this example, we will install EDB Postgres Extended Server 17 with PGD Essent ```bash export PG_VERSION=17 -export PGD_EDITION=essential -export EDB_PACKAGES="edb-as$PG_VERSION edb-pgd6-$PGD_EDITION-epas$PG_VERSION" +export EDB_PACKAGES="edb-as$PG_VERSION edb-pgd6-essential-epas$PG_VERSION" sudo dnf install -y $EDB_PACKAGES ``` diff --git a/product_docs/docs/pgd/6/essential-how-to/install/04-configuring-cluster.mdx b/product_docs/docs/pgd/6/essential-how-to/install/04-configuring-cluster.mdx index 91312c516eb..fdfdeabdb93 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/04-configuring-cluster.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/04-configuring-cluster.mdx @@ -36,107 +36,136 @@ The paths and users used in the examples will vary according to which version of -You will use the system's `enterprisedb` user to run the `pgd` command. The database port is 5444. | | | |---------------------------|-------------------------------------| +| Postgres User | `enterprisedb` | +| Postgres Port | `5444` | | Postgres Executable files | `/usr/lib/edb-as/$PG_VERSION/bin/` | | Postgres Data Directory | `/var/lib/edb-as/$PG_VERSION/main/` | +```shell +sudo --preserve-env=PG_VERSION -iu enterprisedb +export PATH=$PATH:/usr/lib/edb-as/$PG_VERSION/bin/ +export PGDATA=/var/lib/edb-as/$PG_VERSION/main/ +export PGPORT=5444 +``` + | | | |---------------------------|------------------------------------| +| Postgres User | `enterprisedb` | +| Postgres Port | `5444` | | Postgres Executable files | `/usr/edb/as$PG_VERSION/bin/` | | Postgres Data Directory | `/var/lib/edb/as$PG_VERSION/data/` | +```shell +sudo --preserve-env=PG_VERSION -iu enterprisedb +export PATH=$PATH:/usr/edb/as$PG_VERSION/bin/ +export PGDATA=/var/lib/edb/as$PG_VERSION/data/ +export PGPORT=5444 +``` + -You will use the system's `postgres` user to run the `pgd` command. The database port is 5432 | | | |---------------------------|--------------------------------------| +| Postgres User | `postgres` | +| Postgres Port | `5432` | | Postgres Executable files | `/usr/lib/edb-pge/$PG_VERSION/bin/` | | Postgres Data Directory | `/var/lib/edb-pge/$PG_VERSION/main/` | +```shell +sudo --preserve-env=PG_VERSION -iu postgres +export PATH=$PATH:/usr/lib/edb-pge/$PG_VERSION/bin/ +export PGDATA=/var/lib/edb-pge/$PG_VERSION/main/ +export PGPORT=5432 +``` + | | | |---------------------------|--------------------------------------| +| Postgres User | `postgres` | +| Postgres Port | `5432` | | Postgres Executable files | `/usr/edb/pge$PG_VERSION/bin/` | | Postgres Data Directory | `/var/lib/edb-pge/$PG_VERSION/data/` | +```shell +sudo --preserve-env=PG_VERSION -iu postgres +export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ +export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ +export PGPORT=5432 +``` + +


-You will use the system's `postgres` user to run the `pgd` command. The database port is 5432. - - +!!! note Not available -| | | -|---------------------------|-----------------------------------------| -| Postgres Executable files | `/usr/lib/postgresql/$PG_VERSION/bin/` | -| Postgres Data Directory | `/var/lib/postgresql/$PG_VERSION/main/` | +

- - -| | | -|---------------------------|------------------------------------| -| Postgres Executable files | `/usr/pgsql-$PG_VERSION/bin/` | -| Postgres Data Directory | `/var/lib/pgsql/$PG_VERSION/data/` | +Community PostgreSQL is only operable with PGD Expanded. - - +

+ + +!!! + +



 ## On each host -1. Log in as the database user. +1. Log in as the database user and set the environment variables. Copy and paste the scripts above to login and set required environment variables. In the scripts above: + - The `PG_VERSION` variable is set to the version of Postgres you are using (we assume you have set this in the previous step and use the `--preserve-env` option of sudo to preserve its setting when switching users.). + - The `PGPORT` variable is set to the port number for the database. + - The `PGDATA` variable is set to the data directory for the database. The `PATH` variable is set to include the Postgres executable files. -```bash -sudo su - -``` - -2. Add the Postgres executable files to your path. - -```bash -export PATH=$PATH: -``` +2. Set the `PGPASSWORD` environment variable to the password for the database user. This is required for the `pgd` command to connect to the database. + ```bash + export PGPASSWORD= + ``` + This is the password for the database user. In the examples, the password is `secret`. -3. Run the pgd node setup command +1. Run the pgd node setup command ### On the first host +The first host in the cluster is also the first node and will be where we begin the cluster creation. On the first host, run the following command to create the cluster: ```bash -pgd node setup --dsn "host= user= port= dbname=pgddb" --pgdata --group-name --cluster-name --create-group +pgd node setup --dsn "host= user= port= dbname=" --group-name ``` -This command will create the cluster and the group on the first host. It will also create the data directory and initialize the database. +This command will create the data directory and initialize the database, then will create the cluster and the group on the first node. ### On the second host On the second host, run the following command to create the cluster: ```bash -pgd node setup --dsn "host= user= port= dbname=pgddb" --pgdata --cluster-dsn "host= user= port= dbname=pgddb" +pgd node setup --dsn "host= user= port= dbname=" --cluster-dsn "host= user= port= dbname=" ``` This command will create the node on the second host, and then join the cluster using the cluster-dsn setting to connect to the first host. @@ -146,44 +175,54 @@ This command will create the node on the second host, and then join the cluster On the third host, run the following command to create the cluster: ```bash -pgd node setup --dsn "host= user= port= dbname=pgddb" --pgdata --cluster-dsn "host= user= port= dbname=pgddb" +pgd node setup --dsn "host= user= port= dbname=" --cluster-dsn "host= user= port= dbname=" ``` This command will create the node on the third host, and then join the cluster using the cluster-dsn setting to connect to the first host. ## Worked example -In this example, we will configure the PGD Essential cluster with EDB Postgres Extended Server 17 on a CentOS/RHEL system using an enterprise subscription that we [configured](02-configure-repository) and [installed](03-installing-database-and-pgd) in the previous steps. +In this example, we will configure the PGD Essential cluster with EDB Postgres Extended Server 17 on a CentOS/RHEL system that we [configured](02-configure-repository) and [installed](03-installing-database-and-pgd) in the previous steps. -We will now create a cluster called `pgd` with three nodes called `node1`, `node2`, and `node3`. +We will now create a cluster called `pgd` with three nodes called `node-1`, `node-2`, and `node-3`. -* The group name will be `group1`. The hosts are `host-1`, `host-2`, and `host-3`. +* The group name will be `group-1`. The hosts are `host-1`, `host-2`, and `host-3`. * The Postgres version is 17. -* The database user is `postgres`. +* The database user is `postgres`. * The database port is 5432. +* The database name is `pgddb`. * The Postgres executable files are in `/usr/edb/pge17/bin/`. * The Postgres data directory is in `/var/lib/edb-pge/17/main/`. +* The Postgres password is `secret`. + +(Note that we assume the Postgres version environment variable PG_VERSION is set to `17` from the previous step, and that we are preserving the environment variable when switching users.) #### On the first host ```bash -sudo su - postgres -export PATH=$PATH:/usr/edb/pge17/bin/ -pgd node node1 setup "host=host-1 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --group-name group1 --cluster-name pgd --create-group --initial-node-count 3 +sudo --preserve-env=PG_VERSION -iu postgres +export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ +export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ +export PGPASSWORD=secret +pgd node node-1 setup "host=host-1 user=postgres port=5432 dbname=pgddb" --group-name group-1 ``` #### On the second host ```bash -sudo su - postgres -export PATH=$PATH:/usr/edb/pge17/bin/ -pgd node node2 setup "host=host-2 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --cluster-dsn "host=host-1 user=postgres port=5432 dbname=bdrdb" --initial-node-count 3 +sudo --preserve-env=PG_VERSION -iu postgres +export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ +export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ +export PGPASSWORD=secret +pgd node node-2 setup "host=host-2 user=postgres port=5432 dbname=pgddb" --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" ``` #### On the third host ```bash -sudo su - postgres -export PATH=$PATH:/usr/edb/pge17/bin/ -pgd node node3 setup "host=host-3 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --cluster-dsn "host=host-1 user=postgres port=5432 dbname=bdrdb" --initial-node-count 3 +sudo --preserve-env=PG_VERSION -iu postgres +export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ +export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ +export PGPASSWORD=secret +pgd node node-3 setup "host=host-3 user=postgres port=5432 dbname=pgddb" --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" ``` diff --git a/product_docs/docs/pgd/6/essential-how-to/install/05-check-cluster.mdx b/product_docs/docs/pgd/6/essential-how-to/install/05-check-cluster.mdx index 1bdea4aaee2..7b4cb663852 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/05-check-cluster.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/05-check-cluster.mdx @@ -11,10 +11,10 @@ With the cluster up and running, it's worthwhile to run some basic checks to see The following example shows one quick way to do this, but you must ensure that any testing you perform is appropriate for your use case. -On any of the installed and configured nodes, log in and run `psql` to connect to the database. If you are using EDB Postgres Advanced Server, use the `enterprisedb` user, otherwise use `postgres`. If you configured the cluster with the previous steps you can use the pgddb database and pgdadmin user: +On any of the installed and configured nodes, log in and run `psql` to connect to the database. If you are using EDB Postgres Advanced Server, use the `enterprisedb` user, otherwise use `postgres`: ```bash -sudo -iu postgres psql "host=host-1 port=5432 username=pgdadmin dbname=pgddb" +sudo -iu postgres psql "host=host-1 port=5432 username=postgres dbname=pgddb" ``` * **Preparation** @@ -66,7 +66,7 @@ Log in to host-1's Postgres server. ```shell ssh admin@host-1 -sudo -iu postgres psql "host=host-1 port=5432 username=pgdadmin dbname=pgddb" +sudo -iu postgres psql "host=host-1 port=5432 username=postgres dbname=pgddb" ``` This is your connection to PGD's node-1. @@ -75,7 +75,7 @@ This is your connection to PGD's node-1. To ensure that the cluster is ready to go, run: -``` +```sql select bdr.wait_slot_confirm_lsn(NULL, NULL) ``` @@ -83,9 +83,9 @@ This query blocks while the cluster is busy initializing and returns when the cl In another window, log in to host-2's Postgres server: -``` +```shell ssh admin@host-2 -sudo -iu postgres psql "host=host-2 port=5432 username=pgdadmin dbname=pgddb" +sudo -iu postgres psql "host=host-2 port=5432 username=postgres dbname=pgddb" ``` ### Create data @@ -153,7 +153,7 @@ __OUTPUT__ #### Log in to host-2's Postgres server ``` ssh admin@host-2 -sudo -iu postgres psql "host=host-2 port=5432 username=pgdadmin dbname=pgddb" +sudo -iu postgres psql "host=host-2 port=5432 username=postgres dbname=pgddb" ``` This is your connection to PGD's node-2. diff --git a/product_docs/docs/pgd/6/essential-how-to/install/images/edbrepos2.0.png b/product_docs/docs/pgd/6/essential-how-to/install/images/edbrepos2.0.png index a34e4aac568..e2b61730574 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/images/edbrepos2.0.png +++ b/product_docs/docs/pgd/6/essential-how-to/install/images/edbrepos2.0.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:8992e9fcc472dd7ef8b01eea8a92d021089cc4a41623f5a462da09ce304cf2b7 -size 251304 +oid sha256:a1900876939036491c2604939cc7173fa347d5ee218656ef4e0f2d984c262231 +size 278800 diff --git a/product_docs/docs/pgd/6/essential-how-to/install/index.mdx b/product_docs/docs/pgd/6/essential-how-to/install/index.mdx index 4c0e98c77a2..4e139a07e6e 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/index.mdx @@ -5,8 +5,8 @@ navTitle: Installing and configuring This section covers how to manually deploy and configure EDB Postgres Distributed 6. -* [Provisioning hosts](01-prerequisites.mdx) -* [Configuring the EDB repository](02-configure-repository.mdx) -* [Installing the database and PGD software](03-installing-database-and-pgd.mdx) -* [Configuring the cluster](04-configuring-cluster.mdx) -* [Checking the cluster](05check-cluster.mdx) +* [Provisioning hosts](01-prerequisites) +* [Configuring the EDB repository](02-configure-repositories) +* [Installing the database and PGD software](03-installing-database-and-pgd) +* [Configuring the cluster](04-configuring-cluster) +* [Checking the cluster](05-check-cluster) diff --git a/product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx b/product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx index 7308dd96d5d..ebe754224b2 100644 --- a/product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx @@ -62,7 +62,7 @@ Also consult the [PGD CLI documentation](/pgd/latest/reference/cli/) for details ### Ensure PGD CLI is installed -In this worked example, you configure and use PGD CLI on host-one, where you've already installed Postgres and PGD. +In this worked example, you configure and use PGD CLI on host-1, where you've already installed Postgres and PGD. You don't need to install PGD CLI again. ### (Optionally) Create a configuration file @@ -94,16 +94,16 @@ sudo mkdir -p /etc/edb/pgd-cli Then, write the configuration to the `pgd-cli-config.yml` file in the `/etc/edb/pgd-cli` directory. -For this example, you can run this on host-one to create the file: +For this example, you can run this on host-1 to create the file: ```shell cat < +``` + +### `EDB_REPO_TYPE` + +This is the type of package manager you use, which informs the installer which type of package you need. This can be `deb` for Ubuntu/Debian or `rpm` for CentOS/RHEL. + +```bash +export EDB_REPO_TYPE= +``` + +## Install the repository/repositories + +For PGD Essential, there is just one repository to install. For PGD Extended, there are two repositories to install. + + +```bash +curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/postgres_distributed/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +``` + +This command will download and run a script that configures your package manager to use the EDB repository. It will also install any necessary dependencies. + +## Worked example + +In this example, we will configure the repositories on a CentOS/RHEL system that will allow us to install EDB Postgres Extended Server 17 with PGD Expanded using an enterprise subscription. + +### Set the environment variables + +```bash +export EDB_SUBSCRIPTION_TOKEN=XXXXXXXXXXXXXX +export EDB_REPO_TYPE=rpm +``` + +### Install the repositories + +```bash +# For PGD Expanded, there are two repositories to install. +curl -1sSLf " https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/enterprise/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +curl -1sSLf " https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/postgres_distributed/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +``` diff --git a/product_docs/docs/pgd/6/expanded-how-to/install/03-installing-database-and-pgd.mdx b/product_docs/docs/pgd/6/expanded-how-to/install/03-installing-database-and-pgd.mdx new file mode 100644 index 00000000000..b26b2075a01 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/install/03-installing-database-and-pgd.mdx @@ -0,0 +1,143 @@ +--- +title: Step 3 - Installing the database and pgd +navTitle: Installing +description: Installing the database and pgd software on each host. +deepToC: true +--- + +On each host which you want to use as a PGD data node, you need to install the database and the PGD software. + +After you have [configured the EDB repository](02-configure-repository), you can install the database and PGD software using your package manager. + +## Install the database and PGD software + +### Set the Postgres version + +Set an environment variable to specify the version of Postgres you want to install. This is typically `17` for Postgres 17. + +```bash +export PG_VERSION=17 +``` + +### Set the package names + +Set an environment variable to specify the package names for the database and PGD software. The package names will vary depending on the database you are using and the platform you are on. + + + + +


+ +#### EDB Postgres Advanced Server + + + + + +```shell +export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-expanded-epas$PG_VERSION" +``` + + + + + +```shell +export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-expanded-epas$PG_VERSION" +``` + + + + + + + +


+ +#### EDB Postgres Extended + + + + + + ```bash + export EDB_PACKAGES="edb-postgresextended-$PG_VERSION edb-pgd6-expanded-pgextended$PG_VERSION" + ``` + + + + + + ```bash + export EDB_PACKAGES="edb-postgresextended$PG_VERSION-server edb-postgresextended$PG_VERSION-contrib edb-pgd6-expanded-pgextended$PG_VERSION" + ``` + + + + + + +


+ +#### Community PostgreSQL + + + + + + ```bash + export EDB_PACKAGES="postgresql-$PG_VERSION edb-pgd6-expanded-pg$PG_VERSION" + ``` + + + + + ```bash + export EDB_PACKAGES="postgresql$PG_VERSION-server postgresql$PG_VERSION-contrib edb-pgd6-expanded-pg$PG_VERSION" + ``` + + + + + + + + + +


+ +### Run the installation command +Run the installation command appropriate for your platform. + + + + + +```shell +sudo apt install -y $EDB_PACKAGES +``` + + + + + +```shell +sudo dnf install -y $EDB_PACKAGES +``` + + + + + +This command will install the specified packages and any dependencies they require. Once the installation is complete, you will have the database and PGD software installed on your system. + + +## Worked example + +In this example, we will install EDB Postgres Extended Server 17 with PGD Expanded on a CentOS/RHEL system using the repository configuration we set up in the [previous step's worked example](02-configure-repository#worked-example). + +```bash +export PG_VERSION=17 +export EDB_PACKAGES="edb-as$PG_VERSION edb-pgd6-expanded-epas$PG_VERSION" +sudo dnf install -y $EDB_PACKAGES +``` diff --git a/product_docs/docs/pgd/6/expanded-how-to/install/04-configuring-cluster.mdx b/product_docs/docs/pgd/6/expanded-how-to/install/04-configuring-cluster.mdx new file mode 100644 index 00000000000..1fc08a90434 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/install/04-configuring-cluster.mdx @@ -0,0 +1,237 @@ +--- +title: Step 4 - Configuring the cluster +navTitle: Configuring +deepToC: true +--- + +## Configuring the cluster + +The next step in the process is to configure the database and the cluster. + +This involves logging into each host and running the `pgd` command to create the cluster as the database user. + +These steps will vary according to which platform you are using and which version of Postgres you are using. + +## Cluster name + +You will need to choose a name for your cluster. This is the name that will be used to identify the cluster in the PGD CLI and in the database. It will be referred to as `` in the examples. If not specified, the default name is `pgd`. + +## Group names + +You will also need to choose a name for the group. This is the name that will be used to identify the group in the PGD CLI and in the database. It will be referred to as `` in the examples. + +The group name must be unique within the cluster. + +## Node names + +You will also need to choose a name for each node. This is the name that will be used to identify the node in the PGD CLI and in the database. It will be referred to as `` in the examples. This is separate from the host name, which is the name of the machine on which the node is running. + +The node name must be unique within the group and within the cluster. + +## Paths and users + +The paths and users used in the examples will vary according to which version of Postgres you are using and which platform you are using. + + + + + +You will use the system's `enterprisedb` user to run the `pgd` command. The database port is 5444. + + + + +| | | +|---------------------------|-------------------------------------| +| Postgres Executable files | `/usr/lib/edb-as/$PG_VERSION/bin/` | +| Postgres Data Directory | `/var/lib/edb-as/$PG_VERSION/main/` | + +```shell +sudo --preserve-env=PG_VERSION -iu enterprisedb +export PATH=$PATH:/usr/lib/edb-as/$PG_VERSION/bin/ +export PGDATA=/var/lib/edb-as/$PG_VERSION/main/ +``` + + + + +| | | +|---------------------------|------------------------------------| +| Postgres Executable files | `/usr/edb/as$PG_VERSION/bin/` | +| Postgres Data Directory | `/var/lib/edb/as$PG_VERSION/data/` | + +```shell +sudo --preserve-env=PG_VERSION -iu enterprisedb +export PATH=$PATH:/usr/edb/as$PG_VERSION/bin/ +export PGDATA=/var/lib/edb/as$PG_VERSION/data/ +``` + + + + + + +You will use the system's `postgres` user to run the `pgd` command. The database port is 5432 + + + + +| | | +|---------------------------|--------------------------------------| +| Postgres Executable files | `/usr/lib/edb-pge/$PG_VERSION/bin/` | +| Postgres Data Directory | `/var/lib/edb-pge/$PG_VERSION/main/` | + +```shell +sudo --preserve-env=PG_VERSION -iu postgres +export PATH=$PATH:/usr/lib/edb-pge/$PG_VERSION/bin/ +export PGDATA=/var/lib/edb-pge/$PG_VERSION/main/ +``` + + + + +| | | +|---------------------------|--------------------------------------| +| Postgres Executable files | `/usr/edb/pge$PG_VERSION/bin/` | +| Postgres Data Directory | `/var/lib/edb-pge/$PG_VERSION/data/` | + +```shell +sudo --preserve-env=PG_VERSION -iu postgres +export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ +export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ +``` + + + + + + +You will use the system's `postgres` user to run the `pgd` command. The database port is 5432. + + + + +| | | +|---------------------------|-----------------------------------------| +| Postgres Executable files | `/usr/lib/postgresql/$PG_VERSION/bin/` | +| Postgres Data Directory | `/var/lib/postgresql/$PG_VERSION/main/` | + +```shell +sudo --preserve-env=PG_VERSION -iu postgres +export PATH=$PATH:/usr/lib/postgresql/$PG_VERSION/bin/ +export PGDATA=/var/lib/postgresql/$PG_VERSION/main/ +``` + + + + +| | | +|---------------------------|------------------------------------| +| Postgres Executable files | `/usr/pgsql-$PG_VERSION/bin/` | +| Postgres Data Directory | `/var/lib/pgsql/$PG_VERSION/data/` | + +```shell +sudo --preserve-env=PG_VERSION -iu postgres +export PATH=$PATH:/usr/pgsql-$PG_VERSION/bin/ +export PGDATA=/var/lib/pgsql/$PG_VERSION/data/ +``` + + + + + + +## On each host + +1. Using the appropriate user, log in as the database user. + +```bash +sudo su - +``` + +2. Add the Postgres executable files to your path. + +```bash +export PATH=$PATH: +``` + +3. Run the pgd node setup command + +### On the first host + +On the first host, run the following command to create the cluster: + +```bash +pgd node setup --dsn "host= user= port= dbname=" --group-name --create-group +``` + +This command will create the cluster and the group on the first host. It will also create the data directory and initialize the database. + +### On the second host + +On the second host, run the following command to create the cluster: + +```bash +pgd node setup --dsn "host= user= port= dbname=" --cluster-dsn "host= user= port= dbname=" +``` + +This command will create the node on the second host, and then join the cluster using the cluster-dsn setting to connect to the first host. + +### On the third host + +On the third host, run the following command to create the cluster: + +```bash +pgd node setup --dsn "host= user= port= dbname=" --cluster-dsn "host= user= port= dbname=" +``` + +This command will create the node on the third host, and then join the cluster using the cluster-dsn setting to connect to the first host. + +## Worked example + +In this example, we will configure the PGD Expanded cluster with EDB Postgres Extended Server 17 on a CentOS/RHEL system using an enterprise subscription that we [configured](02-configure-repository) and [installed](03-installing-database-and-pgd) in the previous steps. + +We will now create a cluster called `pgd` with three nodes called `node1`, `node2`, and `node3`. + +* The group name will be `group1`. The hosts are `host-1`, `host-2`, and `host-3`. +* The Postgres version is 17. +* The database user is `postgres`. +* The database port is 5432. +* The Postgres executable files are in `/usr/edb/pge17/bin/`. +* The Postgres data directory is in `/var/lib/edb-pge/17/data/`. +* We will use the `pgddb` database. +* The Postgres password is `secret`. + + +#### On the first host + +```bash +sudo -iu postgres +export PG_VERSION=17 +export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ +export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ +export PGPASSWORD=secret +pgd node node-1 setup "host=host-1 user=postgres port=5432 dbname=pgddb" --group-name group1 --update-pgpass +``` + +#### On the second host + +```bash +sudo -iu postgres +export PG_VERSION=17 +export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ +export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ +export PGPASSWORD=secret +pgd node node-2 setup "host=host-2 user=postgres port=5432 dbname=pgddb" --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" +``` + +#### On the third host + +```bash +sudo -iu postgres +export PG_VERSION=17 +export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ +export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ +export PGPASSWORD=secret +pgd node node-3 setup "host=host-3 user=postgres port=5432 dbname=pgddb" --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" +``` diff --git a/product_docs/docs/pgd/6/expanded-how-to/install/05-check-cluster.mdx b/product_docs/docs/pgd/6/expanded-how-to/install/05-check-cluster.mdx new file mode 100644 index 00000000000..b8640c97504 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/install/05-check-cluster.mdx @@ -0,0 +1,222 @@ +--- +title: Step 5 - Checking the cluster +navTitle: Checking the cluster +deepToC: true +--- + +## Checking the cluster + + +With the cluster up and running, it's worthwhile to run some basic checks to see how effectively it's replicating. + +The following example shows one quick way to do this, but you must ensure that any testing you perform is appropriate for your use case. + +On any of the installed and configured nodes, log in and run `psql` to connect to the database. If you are using EDB Postgres Advanced Server, use the `enterprisedb` user, otherwise use `postgres`: + +```bash +sudo -iu postgres psql pgddb +``` + +This command connects you *directly* to the database on host-1/node-1. + +### Quick test + +* **Preparation** + * Ensure the cluster is ready: + * Log in to the database on host-1/node-1. + * Run `select bdr.wait_slot_confirm_lsn(NULL, NULL);`. + * When the query returns, the cluster is ready. + + +* **Create data** + The simplest way to test that the cluster is replicating is to log in to one node, create a table, and populate it. + * On node-1, create a table: + ```sql + CREATE TABLE quicktest ( id SERIAL PRIMARY KEY, value INT ); + ``` + * On node-1, populate the table: + ```sql + INSERT INTO quicktest (value) SELECT random()*10000 FROM generate_series(1,10000); + ``` + * On node-1, monitor performance: + ```sql + select * from bdr.node_replication_rates; + ``` + * On node-1, get a sum of the value column (for checking): + ```sql + select COUNT(*),SUM(value) from quicktest; + ``` +* **Check data** + * Log in to node-2. + Log in to the database on host-2/node-2. + * On node-2, get a sum of the value column (for checking): + ```sql + select COUNT(*),SUM(value) from quicktest; + ``` + * Compare with the result from node-1. + * Log in to node-3. + Log in to the database on host-3/node-3. + * On node-3, get a sum of the value column (for checking): + ```sql + select COUNT(*),SUM(value) from quicktest; + ``` + * Compare with the result from node-1 and node-2. + +## Worked example + +### Preparation + +Log in to host-1's Postgres server. + +```shell +ssh admin@host-1 +sudo -iu postgres psql "host=host-1 port=5432 username=postgres dbname=pgddb" +``` + +This is your connection to PGD's node-1. + +#### Ensure the cluster is ready + +To ensure that the cluster is ready to go, run: + +```sql +select bdr.wait_slot_confirm_lsn(NULL, NULL) +``` + +This query blocks while the cluster is busy initializing and returns when the cluster is ready. + +In another window, log in to host-2's Postgres server: + +```shell +ssh admin@host-2 +sudo -iu postgres psql "host=host-2 port=5432 username=postgres dbname=pgddb" +``` + +### Create data + +#### On node-1, create a table + +Run: + +```sql +CREATE TABLE quicktest ( id SERIAL PRIMARY KEY, value INT ); +``` + +#### On node-1, populate the table + +```sql +INSERT INTO quicktest (value) SELECT random()*10000 FROM generate_series(1,10000); +``` + +This command generates a table of 10000 rows of random values. + +#### On node-1, monitor performance + +As soon as possible, run: + +```sql +select * from bdr.node_replication_rates; +``` + +The command shows statistics about how quickly that data was replicated to the other two nodes: + +```console +bdrdb=# select * from bdr.node_replication_rates; +__OUTPUT__ + peer_node_id | target_name | sent_lsn | replay_lsn | replay_lag | replay_lag_bytes | replay_lag_size | apply_rate | catchup_interv +al +--------------+-------------+-----------+------------+------------+------------------+-----------------+------------+--------------- +--- + 1954860017 | node-3 | 0/DDAA908 | 0/DDAA908 | 00:00:00 | 0 | 0 bytes | 13682 | 00:00:00 + 2299992455 | node-2 | 0/DDAA908 | 0/DDAA908 | 00:00:00 | 0 | 0 bytes | 13763 | 00:00:00 +(2 rows) +``` + +And it's already replicated. + +#### On node-1 get a checksum + +Run: + +```sql +select COUNT(*),SUM(value) from quicktest; +``` + +This command gets some values from the generated data: + +```sql +bdrdb=# select COUNT(*),SUM(value) from quicktest; +__OUTPUT__ + count | sum +--------+----------- + 100000 | 498884606 +(1 row) +``` + +### Check data + +#### Log in to host-2's Postgres server + +```shell +ssh admin@host-2 +sudo -iu postgres psql "host=host-2 port=5432 username=postgres dbname=pgddb" +``` + +This is your connection to PGD's node-2. + +#### On node-2, get a checksum + +Run: + +```sql +select COUNT(*),SUM(value) from quicktest; +``` + +This command gets node-2's values for the generated data: + +```sql +bdrdb=# select COUNT(*),SUM(value) from quicktest; +__OUTPUT__ + count | sum +--------+----------- + 100000 | 498884606 +(1 row) +``` + +#### Compare with the result from node-one + +The values are identical. + +You can repeat the process with node-3 or generate new data on any node and see it replicate to the other nodes. + +#### Log in to host-3's Postgres server + +```shell +ssh admin@host-3 +sudo -iu enterprisedb psql bdrdb +``` + +This is your connection to PGD's node-3. + +#### On node-3, get a checksum + +Run: + +```sql +select COUNT(*),SUM(value) from quicktest; +``` + +This command gets node-3's values for the generated data: + +```sql +bdrdb=# select COUNT(*),SUM(value) from quicktest; +__OUTPUT__ + count | sum +--------+----------- + 100000 | 498884606 +(1 row) +``` + +#### Compare with the result from node-one and node-two + +The values are identical. diff --git a/product_docs/docs/pgd/6/expanded-how-to/install/images/edbrepos2.0.png b/product_docs/docs/pgd/6/expanded-how-to/install/images/edbrepos2.0.png new file mode 100644 index 00000000000..e2b61730574 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/install/images/edbrepos2.0.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:a1900876939036491c2604939cc7173fa347d5ee218656ef4e0f2d984c262231 +size 278800 diff --git a/product_docs/docs/pgd/6/expanded-how-to/install/index.mdx b/product_docs/docs/pgd/6/expanded-how-to/install/index.mdx new file mode 100644 index 00000000000..4e139a07e6e --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/install/index.mdx @@ -0,0 +1,12 @@ +--- +title: Installing and configuring EDB Postgres Distributed 6 +navTitle: Installing and configuring +--- + +This section covers how to manually deploy and configure EDB Postgres Distributed 6. + +* [Provisioning hosts](01-prerequisites) +* [Configuring the EDB repository](02-configure-repositories) +* [Installing the database and PGD software](03-installing-database-and-pgd) +* [Configuring the cluster](04-configuring-cluster) +* [Checking the cluster](05-check-cluster) diff --git a/product_docs/docs/pgd/6/get-started/essential-standard/index.mdx b/product_docs/docs/pgd/6/get-started/essential-standard.mdx similarity index 100% rename from product_docs/docs/pgd/6/get-started/essential-standard/index.mdx rename to product_docs/docs/pgd/6/get-started/essential-standard.mdx diff --git a/product_docs/docs/pgd/6/get-started/expanded-examples.mdx b/product_docs/docs/pgd/6/get-started/expanded-examples.mdx index 60c799cdf3a..7167ed77147 100644 --- a/product_docs/docs/pgd/6/get-started/expanded-examples.mdx +++ b/product_docs/docs/pgd/6/get-started/expanded-examples.mdx @@ -15,12 +15,13 @@ With PGD Expanded, you can send your requests to any node in the cluster, and PG ### Use Case 2: Data Distribution -PGD Expanded allows you to distribute your data across multiple nodes in the cluster. The nodes can be located in +PGD Expanded allows you to distribute your data across multiple nodes in the cluster, including subscriber-only read-only nodes. These nodes can be located in multiple data centers or availability zones. This allows you to scale your database's read capacity horizontally, adding more nodes to the cluster as needed. ### Use Case 3: Geo-Distribution -PGD Expanded allows you to distribute your data across multiple regions, replicating data to all the nodes in the cluster. Multiple Data groups can be located in different locations to ensure high availability and resiliance in that location. +PGD Expanded allows you to distribute your data across multiple regions, replicating data to all the nodes in the cluster. Multiple Data groups can be located in different locations to ensure high availability and resilience in that location. ### Use Case 4: Tiered Tables An optional element of PGD Expanded is the ability to create tiered tables. These tables can be used to tier data between hot data, being replicated within the cluster and cold data being written to a Iceberg/Delta tables data lake. The cold data remains queryable as Tiered Tables uses PGAA which allows you to query the data lake as if it were a table in the database. + diff --git a/product_docs/docs/pgd/6/get-started/first-cluster/index.mdx b/product_docs/docs/pgd/6/get-started/first-cluster.mdx similarity index 100% rename from product_docs/docs/pgd/6/get-started/first-cluster/index.mdx rename to product_docs/docs/pgd/6/get-started/first-cluster.mdx diff --git a/product_docs/docs/pgd/6/get-started/index.mdx b/product_docs/docs/pgd/6/get-started/index.mdx index 57c0ba61566..505aa838710 100644 --- a/product_docs/docs/pgd/6/get-started/index.mdx +++ b/product_docs/docs/pgd/6/get-started/index.mdx @@ -9,5 +9,23 @@ navigation: - expanded-examples --- -To begin using any edition of EDB Postgres Distributed, we recommend you first try our local installation and configuration guide. This guide will help you set up a Docker Compose cluster on your local machine, which is ideal for testing and learning purposes. +To begin using any edition of EDB Postgres Distributed, we recommend you first try our local installation and configuration guide. + +This guide will help you install and configure the software, and create your first cluster. + +## What is EDB Postgres Distributed? + +EDB Postgres Distributed (PGD) is a distributed database solution that provides high availability, scalability, and fault tolerance for PostgreSQL databases. It allows you to create clusters of PostgreSQL instances that can work together to provide a single, unified database system. + +## What is EDB Postgres Distributed Essential? + +EDB Postgres Distributed Essential is a streamlined version of PGD that focuses on delivering core distributed database functionality with minimal complexity. It is designed for users who need basic high availability and disaster recovery features without the advanced capabilities offered by PGD Expanded, the full version. + +## What is the PGD Essential Standard architecture + +Get to know what EDB Postgres Distributed Essential is all about in [Essential Standard](essential-standard). + +## Create your first PGD Essential cluster with Docker Compose + +Use the [Docker Compose](https://docs.docker.com/compose/) file to [create your first PGD Essential cluster](first-cluster) with three nodes. This is a great way to get started with PGD Essential and see how it works in a real-world scenario and a stepping stone to deploying a production cluster with PGD Essential or PGD Expanded. diff --git a/product_docs/docs/pgd/6/reference/connection-manager/index.mdx b/product_docs/docs/pgd/6/reference/connection-manager/index.mdx index 77b43c4da4f..76e2dccee49 100644 --- a/product_docs/docs/pgd/6/reference/connection-manager/index.mdx +++ b/product_docs/docs/pgd/6/reference/connection-manager/index.mdx @@ -6,9 +6,15 @@ navigation: - overview - authentication - configuring -- health-checks - load-balancing +- monitoring --- PGD 6.0 introduces a new Connection Manager which replaces the PGD 5's proxy solution with a tightly integrated approach using a background worker to expose read-write, read-only and http-status network interfaces in PGD. +* [Overview](overview) covers the new features and benefits of the Connection Manager. +* [Authentication](authentication) covers how authentication works with the Connection Manager. +* [Configuration](configuring) details the configuration options available and how to set them. +* [Load Balancing](load-balancing) how to use load balancing with the Connection Manager. +* [Monitoring](monitoring) covers the tables and HTTP endpoints available for monitoring. + diff --git a/product_docs/docs/pgd/6/reference/node_management/automatic_sync.mdx b/product_docs/docs/pgd/6/reference/node_management/automatic_sync.mdx index 4e8c99b8199..6ce9afb4c35 100644 --- a/product_docs/docs/pgd/6/reference/node_management/automatic_sync.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/automatic_sync.mdx @@ -12,13 +12,14 @@ Nodes are checked for their closeness to each other. If all nodes are equally ca The view [`bdr.sync_node_requests_summary`](/pgd/latest/reference/tables-views-functions/catalogs-internal#bdrsync_node_requests_summary) tracks the sync requests. -Origin: origin node is the down node -Source: source node is the node furthest ahead from origin -Target: each of the other nodes that’s behind the source with respect to the origin -Sync_start_lsn: Highest LSN received by the target from origin when sync started -Sync_end_lsn: Target LSN of the target node from the origin when the sync ended -Sync_status: status of the sync -Sync_start_ts: Time when sync started +- `Origin`: origin node is the down node. +- `Source`: source node is the node furthest ahead from origin. +- `Target`: each of the other nodes that’s behind the source with respect to the origin. +- `Sync_start_lsn`: Highest LSN received by the target from origin when sync started. +- `Sync_end_lsn`: Target LSN of the target node from the origin when the sync ended. +- `Sync_status`: status of the sync. +- `Sync_start_ts`: Time when sync started. + Once a sync request is entered in the catalog, it is carried forward to completion. ## Cancellation @@ -35,19 +36,28 @@ This cancels all sync node requests for all targets that have the given origin a ## Sync Request Life Cycle -A single sync request has an origin, source, target and a sync_end_lsn to reach. The sync request goes through various states and each state executes on a different node. -**setup**: Executes on the write lead. It sets up the fields of the sync, except sync_end_lsn -**setup_source**: Executes on the source. It populates sync_end_lsn and creates a slot for the sync subscription -**setup_target**: This executes on the target node. In this state, the original subscription to origin is disabled. A sync subscription is set up on the target which forwards origin’s changes from source node to target. -**start**: This executes on the target. It monitors the progress of the target to see if sync_end_lsn is reached and if reached moves to synced state. -**synced**: subscription has synced to sync_end_lsn. In this state the slot is dropped +A single sync request has an origin, source, target and a sync_end_lsn to reach. The sync request goes through various states and each state executes on a different node. + +
+ +![Autosync Request Life Cycle](images/autosyncstates.svg) + +
+ +The states are as follows: +**setup**: Executes on the write lead. It sets up the fields of the sync, except `sync_end_lsn`. +**setup_source**: Executes on the source. It populates `sync_end_lsn` and creates a slot for the sync subscription. +**setup_target**: This executes on the target node. In this state, the original subscription to the origin is disabled. A sync subscription is set up on the target which forwards the origin’s changes from the source node to the target. +**start**: This executes on the target. It monitors the progress of the target to see if `sync_end_lsn` is reached and if reached moves to synced state. +**synced**: subscription has synced to `sync_end_lsn`. In this state the slot is dropped. **complete**: This state executes on the target. In this state, sync subscription is dropped on the target and original subscription is enabled. It then moves to to done state. **done**: This means sync is successful. **cancel start**: This executes on the target node. In this state, the sync subscription is disabled, in preparation for a drop later, and the original subscription to the origin is re-enabled. **cancel continue**: This executes on the target node. In this state, the sync subscription is dropped. **cancel done**: This executes on the source node. In this state, the slot is dropped. -**failed**: A sync ends-up in this state if a cancellation happens and all cleanup is done. This means the sync could not happen and needs to be retried. -A cancellation of sync can happen too automatically if the chosen source node is found to be down. During cancellation the subscription and slot needs to be cleaned up, and the original subscription enabled. A sync request can be stalled if the source or target nodes are down. +**failed**: A sync ends-up in this state if a cancellation happens and all cleanup is done. This means the sync could not happen and needs to be retried. + +A cancellation of sync can also happen automatically if the chosen source node is found to be down. During cancellation the subscription and slot needs to be cleaned up, and the original subscription enabled. A sync request can be stalled if the source or target nodes are down. ## GUC diff --git a/product_docs/docs/pgd/6/reference/node_management/images/autosyncstates.svg b/product_docs/docs/pgd/6/reference/node_management/images/autosyncstates.svg new file mode 100644 index 00000000000..ef892e59172 --- /dev/null +++ b/product_docs/docs/pgd/6/reference/node_management/images/autosyncstates.svg @@ -0,0 +1 @@ + \ No newline at end of file From de4e53f5939206dce31a5cda0a5495a09e842bc2 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Tue, 27 May 2025 07:36:26 +0100 Subject: [PATCH 093/145] comments from feedback resolved Signed-off-by: Dj Walker-Morgan --- .../connection-manager/monitoring.mdx | 35 ++++++++++++++++--- .../nodes/subscriber_only/overview.mdx | 11 +++--- .../pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx | 8 +++++ .../pgd/6/rel_notes/src/relnote_6.0.0.yml | 10 +++++- 4 files changed, 54 insertions(+), 10 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/connection-manager/monitoring.mdx b/product_docs/docs/pgd/6/reference/connection-manager/monitoring.mdx index e82deaebc2b..3384319b6d5 100644 --- a/product_docs/docs/pgd/6/reference/connection-manager/monitoring.mdx +++ b/product_docs/docs/pgd/6/reference/connection-manager/monitoring.mdx @@ -4,8 +4,10 @@ navTitle: Monitoring description: Monitoring the Connection Manager through SQL and HTTP deepToC: true --- +You can view the status of the Connection Manager and its connections through SQL queries and HTTP endpoints. -## Available tables and views + +## Available SQL tables and views The Connection Manager provides a number of tables and views that can be used to monitor the status of the Connection Manager and its connections. These include: @@ -15,11 +17,36 @@ The Connection Manager provides a number of tables and views that can be used to - [`bdr.stat_connection_manager_node_stats`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_connection_manager_node_stats) — which is a view that provides statistics about the Connection Manager on each of the data nodes. - [`bdr.stat_connection_manager_hba_file_rules`](/pgd/latest/reference/tables-views-functions/catalogs-visible#bdrstat_connection_manager_hba_file_rules) — which is a view that shows which HBA file rules for the connection manager are being used on this node. -## Monitoring the Connection Manager +## Available HTTP/HTTPS endpoints + +The Connection Manager can be monitored through the HTTP API. + +Endpoints returning true/false will also return a 200 status code for true and a 503 status code for false. + +The following endpoints are available: + +| Endpoint | Description | +|------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| /connection/is-live | Is the connection manager live (listening), always returns “true”, if the manager is not running, the client will simply fail to open the connection/url | +| /connection/is-ready | Is the connection manager is ready, returns true(200)/false(503) | +| /node/is-read-write | Is this PGD node, not the connection manager but the PGD node itself, a read-write node (is it write leader), returns true(200)/false(503) | +| /node/is-read-only | Is this PGD node, not the connection manager but the PGD node itself, a read-only node (not the write leader), returns true(200)/false(503)node | +| /group/read-write-info | Returns information about the read-write pool on this instance of connection manager - a list of nodes in the pool in JSON format with node id, node name, node host, node port and node dbname. For the read-write pool, the pool only contains one entry. | +| /group/read-only-info | Returns information about the read-only pool on this instance of connection manager - a list of nodes in the pool in JSON format with node id, node name, node host, node port and node dbname. | -The Connection Manager can be monitored through the HTTP API. The following endpoints are available: +Below is an example of a response body from the `/group/read-write-info` endpoint: -**TODO** +```json +[ + { + "id": 683485707, + "name": "node-1", + "host": "host-1", + "port": 5432, + "dbname": "pgddb" + } +] +``` ## Logging diff --git a/product_docs/docs/pgd/6/reference/nodes/subscriber_only/overview.mdx b/product_docs/docs/pgd/6/reference/nodes/subscriber_only/overview.mdx index 02b980d4ddd..8211a14fb1a 100644 --- a/product_docs/docs/pgd/6/reference/nodes/subscriber_only/overview.mdx +++ b/product_docs/docs/pgd/6/reference/nodes/subscriber_only/overview.mdx @@ -11,22 +11,23 @@ Read scaling like this, by moving the read-only traffic away from active databas ## Subscriber-only nodes The basic idea of subscriber-only nodes is to provide a read-only node that you can use to offload read-only queries from the main cluster. -The default topology of a PGD cluster is what's called a full mesh topology, where every node connects to every other node. +The default topology of a PGD cluster is what's called a full mesh topology, where every node connects to every other node. This is the most robust and fault-tolerant way to connect nodes, but it can be inefficient for some use cases. -Each subscriber-only node has to be member of a subscriber-only group, which is a group of nodes that only replicate changes from the rest of the cluster. You can't have a subscriber-only node that's not part of a subscriber-only group. +Subscriber-only nodes can be a member of a subscriber-only group or, with PGD 6 and later, they can be part of a data group. ## Subscriber-only groups Subscriber-only groups in PGD gather together subscriber-only nodes. Each group can address different regions or different application demands. -Unlike data groups, a subscriber-only group has no raft consensus mechanism of its own and no proxies. This also means that a subscriber-only group can have as many subscriber-only nodes as your need. +Unlike data groups, a subscriber-only group has no raft consensus mechanism of its own. This also means that a subscriber-only group can have as many subscriber-only nodes as your need. -Previous to PGD 6, the existence of a subscriber-only group didn't change the replication topology. All nodes in the subscriber-only group independently received replicated changes from all other nodes in the cluster. +Previous to PGD 6, the existence of a subscriber-only group didn't change the replication topology. All nodes in the subscriber-only group, by default, independently receive replicated changes from all other nodes in the cluster. ## Optimizing subscriber-only groups -In PGD 6 and later, you can optionally optimize the topology of subscriber-only groups. +In PGD 6 and later, you can optionally optimize the topology of subscriber-only groups. + For clusters using proxies and raft-enabled groups for their data nodes, subscriber-only groups can use a more efficient model for receiving replicated changes. The optimized topology option creates a group leader in each subscriber-only group, similar to a write leader in PGD Proxies. The group leader receives all the changes from the cluster and then replicates them to the other nodes in its group. See [Optimizing subscriber-only groups](optimizing-so) for more information on this feature. diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx index f49f11ae546..a29882fa2d9 100644 --- a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx +++ b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx @@ -189,3 +189,11 @@ was actually snowflakeid.

+## Other + + + +
DescriptionAddresses
automatic node sync and reconciliation is enabled by default.

The GUC bdr.enable_auto_sync_reconcile was off by default, but is made on by default in 6.0. This GUC setting ensures that when a node is down for some time, all other nodes get caught up equally with respect to this node automatically. It also ensures that if there are any prepared transactions that are orphaned by the node going down, they are resolved, either aborted or committed as per the rules of the commit scope that created them.

+
+ + diff --git a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml index 6dc828e1c8d..96b744a2188 100644 --- a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml +++ b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml @@ -425,4 +425,12 @@ relnotes: jira: BDR-3767 addresses: "47233" type: Bug Fix - impact: Medium \ No newline at end of file + impact: Medium + +- relnote: automatic node sync and reconciliation is enabled by default. + details: | + The GUC [`bdr.enable_auto_sync_reconcile`](/pgd/latest/reference/tables-views-functions/pgd-settings#bdrenable_auto_sync_reconcile) was off by default, but is made on by default in 6.0. This GUC setting ensures that when a node is down for some time, all other nodes get caught up equally with respect to this node automatically. It also ensures that if there are any prepared transactions that are orphaned by the node going down, they are resolved, either aborted or committed as per the rules of the commit scope that created them. + component: BDR + jira: BDR-6115 + type: enhancement + impact: Medium From a29368c7995b93e354f1b93c6a7b1bd656586115 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 29 May 2025 12:28:14 +0100 Subject: [PATCH 094/145] Fixups Batch 1 Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/5.7/commit-scopes/camo.mdx | 2 +- .../5.7/commit-scopes/commit-scope-rules.mdx | 2 +- .../pgd/5.7/commit-scopes/group-commit.mdx | 2 +- .../5.7/commit-scopes/synchronous_commit.mdx | 2 +- .../5.7/ddl/ddl-pgd-functions-like-ddl.mdx | 22 ++--- .../node_management/creating_and_joining.mdx | 12 +-- .../heterogeneous_clusters.mdx | 2 +- product_docs/docs/pgd/5.7/scaling.mdx | 14 ++-- .../pgd/5.7/security/pgd-predefined-roles.mdx | 46 +++++----- .../docs/pgd/5.7/security/role-management.mdx | 4 +- .../essential-how-to/architectures/index.mdx | 2 +- .../standard/manually-deploying-standard.mdx | 19 ++--- .../install/02-configure-repositories.mdx | 13 ++- .../03-installing-database-and-pgd.mdx | 11 ++- .../install/04-configuring-cluster.mdx | 72 +++++++++++----- .../install/05-check-cluster.mdx | 13 +-- .../docs/pgd/6/essential-how-to/pgd-cli.mdx | 12 +-- .../{architectures.mdx => always-on.mdx} | 31 +++---- .../architectures/essential.mdx | 11 +++ .../architectures/geo-distributed.mdx | 7 ++ .../architectures/images/1x3-cluster.svg | 1 + .../architectures/images/2x3-cluster.svg | 1 + .../6/expanded-how-to/architectures/index.mdx | 12 ++- .../architectures/multi-location.mdx | 7 ++ .../install/02-configure-repositories.mdx | 26 ++++-- .../03-installing-database-and-pgd.mdx | 4 +- .../install/04-configuring-cluster.mdx | 83 ++++++++++++++----- .../install/05-check-cluster.mdx | 10 +-- .../6/get-started/assets/docker-compose.yml | 24 ++++++ .../pgd/6/get-started/essential-standard.mdx | 22 +++-- .../docs/pgd/6/get-started/first-cluster.mdx | 35 ++++++-- product_docs/docs/pgd/6/index.mdx | 3 + .../pgd/6/reference/cli/command_ref/index.mdx | 2 +- .../cli/command_ref/node/get-option.mdx | 4 +- .../cli/command_ref/node/set-option.mdx | 2 +- .../6/reference/cli/command_ref/node/show.mdx | 8 +- .../cli/command_ref/node/upgrade.mdx | 8 +- .../reference/cli/command_ref/nodes/list.mdx | 6 +- .../cli/command_ref/replication/show.mdx | 12 +-- .../pgd/6/reference/cli/configuring_cli.mdx | 8 +- .../6/reference/cli/discover_connections.mdx | 2 +- .../docs/pgd/6/reference/cli/using_cli.mdx | 8 +- .../conflicts/00_conflicts_overview.mdx | 2 +- .../6/reference/ddl/ddl-role-manipulation.mdx | 4 +- product_docs/docs/pgd/6/reference/index.mdx | 4 +- .../docs/pgd/6/reference/monitoring/sql.mdx | 20 ++--- .../node_management/creating_nodes.mdx | 6 +- .../reference/node_management/node_uuids.mdx | 2 +- .../nodes/subscriber_only/creating-so.mdx | 6 +- .../nodes/subscriber_only/joining-so.mdx | 8 +- .../docs/pgd/6/reference/parallelapply.mdx | 8 +- .../{striggers.mdx => stream-triggers.mdx} | 0 .../tables-views-functions/conflicts.mdx | 2 +- .../tables-views-functions/functions.mdx | 14 ++-- .../streamtriggers/index.mdx | 4 +- product_docs/docs/pgd/6/reference/upgrade.mdx | 2 - product_docs/docs/pgd/6/rel_notes/index.mdx | 4 +- ..._rel_notes.mdx => pgd_6.0.1_rel_notes.mdx} | 10 +-- .../{relnote_6.0.0.yml => relnote_6.0.1.yml} | 6 +- 59 files changed, 433 insertions(+), 256 deletions(-) rename product_docs/docs/pgd/6/expanded-how-to/architectures/{architectures.mdx => always-on.mdx} (87%) create mode 100644 product_docs/docs/pgd/6/expanded-how-to/architectures/essential.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/architectures/geo-distributed.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/architectures/images/1x3-cluster.svg create mode 100644 product_docs/docs/pgd/6/expanded-how-to/architectures/images/2x3-cluster.svg create mode 100644 product_docs/docs/pgd/6/expanded-how-to/architectures/multi-location.mdx create mode 100644 product_docs/docs/pgd/6/get-started/assets/docker-compose.yml rename product_docs/docs/pgd/6/reference/{striggers.mdx => stream-triggers.mdx} (100%) rename product_docs/docs/pgd/6/rel_notes/{pgd_6.0.0_rel_notes.mdx => pgd_6.0.1_rel_notes.mdx} (99%) rename product_docs/docs/pgd/6/rel_notes/src/{relnote_6.0.0.yml => relnote_6.0.1.yml} (99%) diff --git a/product_docs/docs/pgd/5.7/commit-scopes/camo.mdx b/product_docs/docs/pgd/5.7/commit-scopes/camo.mdx index 63db329783b..6fdccccc146 100644 --- a/product_docs/docs/pgd/5.7/commit-scopes/camo.mdx +++ b/product_docs/docs/pgd/5.7/commit-scopes/camo.mdx @@ -43,7 +43,7 @@ To use CAMO, an application must issue an explicit `COMMIT` message as a separat ## Configuration -See the[`CAMO`](/pgd/latest/reference/commit-scopes/#camo) commit scope reference for configuration parameters. +See the[`CAMO`](/pgd/5.7/reference/commit-scopes/#camo) commit scope reference for configuration parameters. ## Confirmation diff --git a/product_docs/docs/pgd/5.7/commit-scopes/commit-scope-rules.mdx b/product_docs/docs/pgd/5.7/commit-scopes/commit-scope-rules.mdx index e636ae25fbd..01243514714 100644 --- a/product_docs/docs/pgd/5.7/commit-scopes/commit-scope-rules.mdx +++ b/product_docs/docs/pgd/5.7/commit-scopes/commit-scope-rules.mdx @@ -12,7 +12,7 @@ Each operation is made up of two or three parts: the commit scope group, an opti commit_scope_group [ confirmation_level ] commit_scope_kind ``` -A full formal syntax diagram is available in the [Commit scopes](/pgd/latest/reference/commit-scopes/#commit-scope-syntax) reference. +A full formal syntax diagram is available in the [Commit scopes](/pgd/5.7/reference/commit-scopes/#commit-scope-syntax) reference. A typical commit scope rule, such as `ANY 2 (group) GROUP COMMIT`, can be broken down into its components. `ANY 2 (group)` is the commit scope group specifying, for the rule, which nodes need to respond and confirm they processed the transaction. In this example, any two nodes from the named group must confirm. diff --git a/product_docs/docs/pgd/5.7/commit-scopes/group-commit.mdx b/product_docs/docs/pgd/5.7/commit-scopes/group-commit.mdx index 470ba63294e..fa2aebebe4f 100644 --- a/product_docs/docs/pgd/5.7/commit-scopes/group-commit.mdx +++ b/product_docs/docs/pgd/5.7/commit-scopes/group-commit.mdx @@ -58,7 +58,7 @@ See the Group Commit section of [Limitations](limitations#group-commit). ## Configuration -`GROUP_COMMIT` supports optional `GROUP COMMIT` parameters, as well as `ABORT ON` and `DEGRADE ON` clauses. For a full description of configuration parameters, see the [GROUP_COMMIT](/pgd/latest/reference/commit-scopes/#group-commit) commit scope reference or for more regarding `DEGRADE ON` options in general, see the [Degrade options](degrading) section. +`GROUP_COMMIT` supports optional `GROUP COMMIT` parameters, as well as `ABORT ON` and `DEGRADE ON` clauses. For a full description of configuration parameters, see the [GROUP_COMMIT](/pgd/5.7/reference/commit-scopes/#group-commit) commit scope reference or for more regarding `DEGRADE ON` options in general, see the [Degrade options](degrading) section. ## Confirmation diff --git a/product_docs/docs/pgd/5.7/commit-scopes/synchronous_commit.mdx b/product_docs/docs/pgd/5.7/commit-scopes/synchronous_commit.mdx index 668c0a13808..26048a65994 100644 --- a/product_docs/docs/pgd/5.7/commit-scopes/synchronous_commit.mdx +++ b/product_docs/docs/pgd/5.7/commit-scopes/synchronous_commit.mdx @@ -26,7 +26,7 @@ SELECT bdr.create_commit_scope( ## Configuration -`SYNCHRONOUS COMMIT` supports the optional `DEGRADE ON` clause. See the [`SYNCHRONOUS COMMIT`](/pgd/latest/reference/commit-scopes/#synchronous-commit) commit scope reference for specific configuration parameters or see [this section](degrading) regarding Degrade on options. +`SYNCHRONOUS COMMIT` supports the optional `DEGRADE ON` clause. See the [`SYNCHRONOUS COMMIT`](/pgd/5.7/reference/commit-scopes/#synchronous-commit) commit scope reference for specific configuration parameters or see [this section](degrading) regarding Degrade on options. ## Confirmation diff --git a/product_docs/docs/pgd/5.7/ddl/ddl-pgd-functions-like-ddl.mdx b/product_docs/docs/pgd/5.7/ddl/ddl-pgd-functions-like-ddl.mdx index 0f9aa5d00e3..0b13a05e378 100644 --- a/product_docs/docs/pgd/5.7/ddl/ddl-pgd-functions-like-ddl.mdx +++ b/product_docs/docs/pgd/5.7/ddl/ddl-pgd-functions-like-ddl.mdx @@ -10,13 +10,13 @@ information, see the documentation for the individual functions. Replication set management: -- [`bdr.create_replication_set`](/pgd/latest/reference/repsets-management#bdrcreate_replication_set) -- [`bdr.alter_replication_set`](/pgd/latest/reference/repsets-management#bdralter_replication_set) -- [`bdr.drop_replication_set`](/pgd/latest/reference/repsets-management#bdrdrop_replication_set) -- [`bdr.replication_set_add_table`](/pgd/latest/reference/repsets-membership#bdrreplication_set_add_table) -- [`bdr.replication_set_remove_table`](/pgd/latest/reference/repsets-membership#bdrreplication_set_remove_table) -- [`bdr.replication_set_add_ddl_filter`](/pgd/latest/reference/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter) -- [`bdr.replication_set_remove_ddl_filter`](/pgd/latest/reference/repsets-ddl-filtering#bdrreplication_set_remove_ddl_filter) +- [`bdr.create_replication_set`](/pgd/5.7/reference/repsets-management#bdrcreate_replication_set) +- [`bdr.alter_replication_set`](/pgd/5.7/reference/repsets-management#bdralter_replication_set) +- [`bdr.drop_replication_set`](/pgd/5.7/reference/repsets-management#bdrdrop_replication_set) +- [`bdr.replication_set_add_table`](/pgd/5.7/reference/repsets-membership#bdrreplication_set_add_table) +- [`bdr.replication_set_remove_table`](/pgd/5.7/reference/repsets-membership#bdrreplication_set_remove_table) +- [`bdr.replication_set_add_ddl_filter`](/pgd/5.7/reference/repsets-ddl-filtering#bdrreplication_set_add_ddl_filter) +- [`bdr.replication_set_remove_ddl_filter`](/pgd/5.7/reference/repsets-ddl-filtering#bdrreplication_set_remove_ddl_filter) Conflict management: @@ -26,10 +26,10 @@ Conflict management: Sequence management: -- [`bdr.alter_sequence_set_kind`](/pgd/latest/reference/sequences#bdralter_sequence_set_kind) +- [`bdr.alter_sequence_set_kind`](/pgd/5.7/reference/sequences#bdralter_sequence_set_kind) Stream triggers: -- [`bdr.create_conflict_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrcreate_conflict_trigger) -- [`bdr.create_transform_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrcreate_transform_trigger) -- [`bdr.drop_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrdrop_trigger) +- [`bdr.create_conflict_trigger`](/pgd/5.7/reference/streamtriggers/interfaces#bdrcreate_conflict_trigger) +- [`bdr.create_transform_trigger`](/pgd/5.7/reference/streamtriggers/interfaces#bdrcreate_transform_trigger) +- [`bdr.drop_trigger`](/pgd/5.7/reference/streamtriggers/interfaces#bdrdrop_trigger) diff --git a/product_docs/docs/pgd/5.7/node_management/creating_and_joining.mdx b/product_docs/docs/pgd/5.7/node_management/creating_and_joining.mdx index 91d36338d36..b561bdaa43e 100644 --- a/product_docs/docs/pgd/5.7/node_management/creating_and_joining.mdx +++ b/product_docs/docs/pgd/5.7/node_management/creating_and_joining.mdx @@ -18,7 +18,7 @@ format, like `host=myhost port=5432 dbname=mydb`, or URI format, like `postgresql://myhost:5432/mydb`. The SQL function -[`bdr.create_node_group()`](/pgd/latest/reference/nodes-management-interfaces#bdrcreate_node_group) +[`bdr.create_node_group()`](/pgd/5.7/reference/nodes-management-interfaces#bdrcreate_node_group) creates the PGD group from the local node. Doing so activates PGD on that node and allows other nodes to join the PGD group, which consists of only one node at that point. At the time of creation, you must specify the connection string for @@ -26,11 +26,11 @@ other nodes to use to connect to this node. Once the node group is created, every further node can join the PGD group using the -[`bdr.join_node_group()`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) +[`bdr.join_node_group()`](/pgd/5.7/reference/nodes-management-interfaces#bdrjoin_node_group) function. Alternatively, use the command line utility -[bdr_init_physical](/pgd/latest/reference/nodes/#bdr_init_physical) to create a +[bdr_init_physical](/pgd/5.7/reference/nodes/#bdr_init_physical) to create a new node, using `pg_basebackup`. If using `pg_basebackup`, the bdr_init_physical utility can optionally specify the base backup of only the target database. The earlier behavior was to back up the entire database cluster. With this utility, @@ -62,7 +62,7 @@ more details, see [Connections and roles](../security/role-management#connection Optionally, you can skip the schema synchronization using the `synchronize_structure` parameter of the -[`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) +[`bdr.join_node_group`](/pgd/5.7/reference/nodes-management-interfaces#bdrjoin_node_group) function. In this case, the schema must already exist on the newly joining node. We recommend that you select the source node that has the best connection (logically close, ideally with low latency and high bandwidth) @@ -73,7 +73,7 @@ Coordinate the join procedure using the Raft consensus algorithm, which requires most existing nodes to be online and reachable. The logical join procedure (which uses the -[`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) +[`bdr.join_node_group`](/pgd/5.7/reference/nodes-management-interfaces#bdrjoin_node_group) function) performs data sync doing `COPY` operations and uses multiple writers (parallel apply) if those are enabled. @@ -99,6 +99,6 @@ If this is necessary, run LiveCompare on the newly joined node to correct any data divergence once all nodes are available and caught up. `pg_dump` can fail when there's concurrent DDL activity on the source node -because of cache-lookup failures. Since [`bdr.join_node_group`](/pgd/latest/reference/nodes-management-interfaces#bdrjoin_node_group) uses pg_dump +because of cache-lookup failures. Since [`bdr.join_node_group`](/pgd/5.7/reference/nodes-management-interfaces#bdrjoin_node_group) uses pg_dump internally, it might fail if there's concurrent DDL activity on the source node. Retrying the join works in that case. diff --git a/product_docs/docs/pgd/5.7/node_management/heterogeneous_clusters.mdx b/product_docs/docs/pgd/5.7/node_management/heterogeneous_clusters.mdx index 62a3feed9c2..174922a41d9 100644 --- a/product_docs/docs/pgd/5.7/node_management/heterogeneous_clusters.mdx +++ b/product_docs/docs/pgd/5.7/node_management/heterogeneous_clusters.mdx @@ -22,7 +22,7 @@ join the cluster. Don't run any DDLs that might not be available on the older versions and vice versa. A node joining with a different major PostgreSQL release can't use -physical backup taken with [`bdr_init_physical`](/pgd/latest/reference/nodes#bdr_init_physical), and the node must join +physical backup taken with [`bdr_init_physical`](/pgd/5.7/reference/nodes#bdr_init_physical), and the node must join using the logical join method. Using this method is necessary because the major PostgreSQL releases aren't on-disk compatible with each other. diff --git a/product_docs/docs/pgd/5.7/scaling.mdx b/product_docs/docs/pgd/5.7/scaling.mdx index 49bb625b580..ac6c9f015e2 100644 --- a/product_docs/docs/pgd/5.7/scaling.mdx +++ b/product_docs/docs/pgd/5.7/scaling.mdx @@ -19,7 +19,7 @@ your search_path, you need to schema qualify the name of each function. ## Auto creation of partitions -PGD AutoPartition uses the [`bdr.autopartition()`](/pgd/latest/reference/autopartition#bdrautopartition) +PGD AutoPartition uses the [`bdr.autopartition()`](/pgd/5.7/reference/autopartition#bdrautopartition) function to create or alter the definition of automatic range partitioning for a table. If no definition exists, it's created. Otherwise, later executions will alter the definition. @@ -145,7 +145,7 @@ upper bound. ## Stopping automatic creation of partitions Use -[`bdr.drop_autopartition()`](/pgd/latest/reference/autopartition#bdrdrop_autopartition) +[`bdr.drop_autopartition()`](/pgd/5.7/reference/autopartition#bdrdrop_autopartition) to drop the autopartitioning rule for the given relation. All pending work items for the relation are deleted, and no new work items are created. @@ -155,7 +155,7 @@ Partition creation is an asynchronous process. AutoPartition provides a set of functions to wait for the partition to be created, locally or on all nodes. Use -[`bdr.autopartition_wait_for_partitions()`](/pgd/latest/reference/autopartition#bdrautopartition_wait_for_partitions) +[`bdr.autopartition_wait_for_partitions()`](/pgd/5.7/reference/autopartition#bdrautopartition_wait_for_partitions) to wait for the creation of partitions on the local node. The function takes the partitioned table name and a partition key column value and waits until the partition that holds that value is created. @@ -164,14 +164,14 @@ The function waits only for the partitions to be created locally. It doesn't guarantee that the partitions also exist on the remote nodes. To wait for the partition to be created on all PGD nodes, use the -[`bdr.autopartition_wait_for_partitions_on_all_nodes()`](/pgd/latest/reference/autopartition#bdrautopartition_wait_for_partitions_on_all_nodes) +[`bdr.autopartition_wait_for_partitions_on_all_nodes()`](/pgd/5.7/reference/autopartition#bdrautopartition_wait_for_partitions_on_all_nodes) function. This function internally checks local as well as all remote nodes and waits until the partition is created everywhere. ## Finding a partition Use the -[`bdr.autopartition_find_partition()`](/pgd/latest/reference/autopartition#bdrautopartition_find_partition) +[`bdr.autopartition_find_partition()`](/pgd/5.7/reference/autopartition#bdrautopartition_find_partition) function to find the partition for the given partition key value. If a partition to hold that value doesn't exist, then the function returns NULL. Otherwise it returns the Oid of the partition. @@ -179,10 +179,10 @@ of the partition. ## Enabling or disabling autopartitioning Use -[`bdr.autopartition_enable()`](/pgd/latest/reference/autopartition#bdrautopartition_enable) +[`bdr.autopartition_enable()`](/pgd/5.7/reference/autopartition#bdrautopartition_enable) to enable autopartitioning on the given table. If autopartitioning is already enabled, then no action occurs. Similarly, use -[`bdr.autopartition_disable()`](/pgd/latest/reference/autopartition#bdrautopartition_disable) +[`bdr.autopartition_disable()`](/pgd/5.7/reference/autopartition#bdrautopartition_disable) to disable autopartitioning on the given table. ## Restrictions on EDB Postgres Advanced Server-native automatic partitioning diff --git a/product_docs/docs/pgd/5.7/security/pgd-predefined-roles.mdx b/product_docs/docs/pgd/5.7/security/pgd-predefined-roles.mdx index 97e74fae2a0..8327dc573f0 100644 --- a/product_docs/docs/pgd/5.7/security/pgd-predefined-roles.mdx +++ b/product_docs/docs/pgd/5.7/security/pgd-predefined-roles.mdx @@ -130,28 +130,28 @@ This role is designed for applications that require access to PGD features, obje - All functions for column_timestamps datatypes - All functions for CRDT datatypes -- [`bdr.alter_sequence_set_kind`](/pgd/latest/reference/sequences#bdralter_sequence_set_kind) -- [`bdr.create_conflict_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrcreate_conflict_trigger) -- [`bdr.create_transform_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrcreate_transform_trigger) -- [`bdr.drop_trigger`](/pgd/latest/reference/streamtriggers/interfaces#bdrdrop_trigger) -- [`bdr.get_configured_camo_partner`](/pgd/latest/reference/functions#bdrget_configured_camo_partner) -- [`bdr.global_lock_table`](/pgd/latest/reference/functions#bdrglobal_lock_table) -- [`bdr.is_camo_partner_connected`](/pgd/latest/reference/functions#bdris_camo_partner_connected) -- [`bdr.is_camo_partner_ready`](/pgd/latest/reference/functions#bdris_camo_partner_ready) -- [`bdr.logical_transaction_status`](/pgd/latest/reference/functions#bdrlogical_transaction_status) +- [`bdr.alter_sequence_set_kind`](/pgd/5.7/reference/sequences#bdralter_sequence_set_kind) +- [`bdr.create_conflict_trigger`](/pgd/5.7/reference/streamtriggers/interfaces#bdrcreate_conflict_trigger) +- [`bdr.create_transform_trigger`](/pgd/5.7/reference/streamtriggers/interfaces#bdrcreate_transform_trigger) +- [`bdr.drop_trigger`](/pgd/5.7/reference/streamtriggers/interfaces#bdrdrop_trigger) +- [`bdr.get_configured_camo_partner`](/pgd/5.7/reference/functions#bdrget_configured_camo_partner) +- [`bdr.global_lock_table`](/pgd/5.7/reference/functions#bdrglobal_lock_table) +- [`bdr.is_camo_partner_connected`](/pgd/5.7/reference/functions#bdris_camo_partner_connected) +- [`bdr.is_camo_partner_ready`](/pgd/5.7/reference/functions#bdris_camo_partner_ready) +- [`bdr.logical_transaction_status`](/pgd/5.7/reference/functions#bdrlogical_transaction_status) - `bdr.ri_fkey_trigger` -- [`bdr.seq_nextval`](/pgd/latest/reference/functions-internal#bdrseq_nextval) -- [`bdr.seq_currval`](/pgd/latest/reference/functions-internal#bdrseq_currval) -- [`bdr.seq_lastval`](/pgd/latest/reference/functions-internal#bdrseq_lastval) -- [`bdr.trigger_get_committs`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_committs) -- [`bdr.trigger_get_conflict_type`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_conflict_type) -- [`bdr.trigger_get_origin_node_id`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_origin_node_id) -- [`bdr.trigger_get_row`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_row) -- [`bdr.trigger_get_type`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_type) -- [`bdr.trigger_get_xid`](/pgd/latest/reference/streamtriggers/rowfunctions#bdrtrigger_get_xid) -- [`bdr.wait_for_camo_partner_queue`](/pgd/latest/reference/functions#bdrwait_for_camo_partner_queue) -- [`bdr.wait_slot_confirm_lsn`](/pgd/latest/reference/functions#bdrwait_slot_confirm_lsn) -- [`bdr.wait_node_confirm_lsn`](/pgd/latest/reference/functions#bdrwait_node_confirm_lsn) +- [`bdr.seq_nextval`](/pgd/5.7/reference/functions-internal#bdrseq_nextval) +- [`bdr.seq_currval`](/pgd/5.7/reference/functions-internal#bdrseq_currval) +- [`bdr.seq_lastval`](/pgd/5.7/reference/functions-internal#bdrseq_lastval) +- [`bdr.trigger_get_committs`](/pgd/5.7/reference/streamtriggers/rowfunctions#bdrtrigger_get_committs) +- [`bdr.trigger_get_conflict_type`](/pgd/5.7/reference/streamtriggers/rowfunctions#bdrtrigger_get_conflict_type) +- [`bdr.trigger_get_origin_node_id`](/pgd/5.7/reference/streamtriggers/rowfunctions#bdrtrigger_get_origin_node_id) +- [`bdr.trigger_get_row`](/pgd/5.7/reference/streamtriggers/rowfunctions#bdrtrigger_get_row) +- [`bdr.trigger_get_type`](/pgd/5.7/reference/streamtriggers/rowfunctions#bdrtrigger_get_type) +- [`bdr.trigger_get_xid`](/pgd/5.7/reference/streamtriggers/rowfunctions#bdrtrigger_get_xid) +- [`bdr.wait_for_camo_partner_queue`](/pgd/5.7/reference/functions#bdrwait_for_camo_partner_queue) +- [`bdr.wait_slot_confirm_lsn`](/pgd/5.7/reference/functions#bdrwait_slot_confirm_lsn) +- [`bdr.wait_node_confirm_lsn`](/pgd/5.7/reference/functions#bdrwait_node_confirm_lsn) Many of these functions require additional privileges before you can use them. For example, you must be the table owner to successfully execute @@ -161,7 +161,7 @@ specific function. ### bdr_read_all_conflicts PGD logs conflicts into the -[`bdr.conflict_history`](/pgd/latest/reference/catalogs-visible#bdrconflict_history) +[`bdr.conflict_history`](/pgd/5.7/reference/catalogs-visible#bdrconflict_history) table. Conflicts are visible only to table owners, so no extra privileges are required for the owners to read the conflict history. @@ -170,4 +170,4 @@ you can optionally grant the role `bdr_read_all_conflicts` to that user. #### Privileges -An explicit policy is set on [`bdr.conflict_history`](/pgd/latest/reference/catalogs-visible#bdrconflict_history) that allows this role to read the `bdr.conflict_history` table. +An explicit policy is set on [`bdr.conflict_history`](/pgd/5.7/reference/catalogs-visible#bdrconflict_history) that allows this role to read the `bdr.conflict_history` table. diff --git a/product_docs/docs/pgd/5.7/security/role-management.mdx b/product_docs/docs/pgd/5.7/security/role-management.mdx index cc32a697155..f924495c4d8 100644 --- a/product_docs/docs/pgd/5.7/security/role-management.mdx +++ b/product_docs/docs/pgd/5.7/security/role-management.mdx @@ -12,12 +12,12 @@ Remember that a user in Postgres terms is simply a role with login privileges. If you do create a role or user in a non-PGD, unreplicated database, it's especially important that you do not make an object in the PGD-replicated database rely on that role. It will break the replication process, as PGD cannot replicate a role that is not in the PGD-replicated database. -You can disable this automatic replication behavior by turning off the [`bdr.role_replication`](https://www.enterprisedb.com/docs/pgd/latest/reference/pgd-settings/#bdrrole_replication) setting, but we don't recommend that. +You can disable this automatic replication behavior by turning off the [`bdr.role_replication`](https://www.enterprisedb.com/docs/pgd/5.7/reference/pgd-settings/#bdrrole_replication) setting, but we don't recommend that. ## Roles for new nodes -New PGD nodes that are added using [`bdr_init_physical`](https://www.enterprisedb.com/docs/pgd/latest/reference/nodes/#bdr_init_physical) will automatically replicate the roles from other nodes of the PGD cluster. +New PGD nodes that are added using [`bdr_init_physical`](https://www.enterprisedb.com/docs/pgd/5.7/reference/nodes/#bdr_init_physical) will automatically replicate the roles from other nodes of the PGD cluster. If a PGD node is joined to a PGD group manually, without using `bdr_init_physical`, existing roles aren't copied to the newly joined node. This is intentional behavior to ensure that access isn't accidentally granted. diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx index 37b363b1058..857ed654e9d 100644 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/architectures/index.mdx @@ -27,4 +27,4 @@ Learn more about the [Near/Far architecture](near-far). !!!Note For multi-region deployments For multi-region deployments, geo-distributed architectures are available in [PGD Expanded](/pgd/latest/expanded-how-to/architectures/). These architectures are designed for use cases that require data to be distributed across multiple regions or data centers. They provide advanced features such as conflict resolution, data distribution, and support for large-scale deployments. - For more information on PGD Expanded, see the [Expanded How-to](expanded-how-to). + For more information on PGD Expanded, see the [Expanded How-to](/pgd/latest/expanded-how-to). diff --git a/product_docs/docs/pgd/6/essential-how-to/architectures/standard/manually-deploying-standard.mdx b/product_docs/docs/pgd/6/essential-how-to/architectures/standard/manually-deploying-standard.mdx index a3dc101f5a8..6fe42e6ebf1 100644 --- a/product_docs/docs/pgd/6/essential-how-to/architectures/standard/manually-deploying-standard.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/architectures/standard/manually-deploying-standard.mdx @@ -10,13 +10,13 @@ Manually deploying the PGD Essential Standard architecture is a straightforward Install PGD on each of the three nodes using the instructions in the Essentials install guide. Specifically: -* [Configure Repositories](/pgd/latest/essential-how-to/install/02-configuring-repositories/) to enable installation of the PGD packages. -* [Install PGD and the Postgres](/pgd/latest/essential-how-to/install/03-installing-pgd/) to install the PGD packages. -* [Configure the PGD Cluster](/pgd/latest/essential-how-to/install/04-configuring-pgd/) to configure the PGD cluster. +* [Configure Repositories](/pgd/latest/essential-how-to/install/02-configure-repositories/) to enable installation of the PGD packages. +* [Install PGD and the Postgres](/pgd/latest/essential-how-to/install/03-installing-database-and-pgd/) to install the PGD packages. +* [Configure the PGD Cluster](/pgd/latest/essential-how-to/install/04-configuring-cluster/) to configure the PGD cluster. ## Worked Example -In this example, we will create a three-node cluster with the following nodes: +In this example, we will create a three-node RHEL cluster with EDB Postgres Extended Server, using the PGD Essential Standard architecture and the following parameters: * The first node is called `node1` and is located on `host-1`. * The second node is called `node2` and is located on `host-2`. @@ -24,12 +24,11 @@ In this example, we will create a three-node cluster with the following nodes: * the cluster name is `pgd` (the default name). * The group name is `group1`. * The Postgres version is `17`. -* The Postgres edition is `essential`. * The Postgres data directory is `/var/lib/edb-pge/17/main/`. * The Postgres executable files are in `/usr/edb/pge17/bin/`. * The Postgres database user is `postgres`. * The Postgres database port is `5432`. -* The Postgres database name is `bdrdb`. +* The Postgres database name is `pgddb`. ### For the first node @@ -42,7 +41,7 @@ export EDB_REPO_TYPE=rpm curl -1sSLf " https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/setup.$EDB_REPO_TYPE.sh" | sudo -E bash export PG_VERSION=17 export PGD_EDITION=essential -export EDB_PACKAGES="edb-as$PG_VERSION edb-pgd6-$PGD_EDITION-epas$PG_VERSION" +export EDB_PACKAGES="edb-as$PG_VERSION-server edb-pgd6-$PGD_EDITION-epas$PG_VERSION" sudo dnf install -y $EDB_PACKAGES ``` @@ -51,7 +50,7 @@ On the first node, the following command creates the cluster and the group. It a ```bash sudo su - postgres export PATH=$PATH:/usr/edb/pge17/bin/ -pgd node node1 setup "host=host-1 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --group-name group1 --cluster-name pgd --create-group --initial-node-count 3 +pgd node node1 setup "host=host-1 user=postgres port=5432 dbname=pgddb" --pgdata /var/lib/edb-pge/17/main/ --group-name group1 --cluster-name pgd --create-group --initial-node-count 3 ``` ### For the second node @@ -63,7 +62,7 @@ Then run the following command to initialize the node and join the cluster and g ```bash sudo su - postgres export PATH=$PATH:/usr/edb/pge17/bin/ -pgd node node2 setup "host=host-2 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --cluster-dsn "host=host-1 user=postgres port=5432 dbname=bdrdb" +pgd node node2 setup "host=host-2 user=postgres port=5432 dbname=pgddb" --pgdata /var/lib/edb-pge/17/main/ --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" ``` ### For the third node @@ -75,5 +74,5 @@ The command to initialize the node and join the cluster and group is similar to ```bash sudo su - postgres export PATH=$PATH:/usr/edb/pge17/bin/ -pgd node node3 setup "host=host-3 user=postgres port=5432 dbname=bdrdb" --pgdata /var/lib/edb-pge/17/main/ --cluster-dsn "host=host-1 user=postgres port=5432 dbname=bdrdb" +pgd node node3 setup "host=host-3 user=postgres port=5432 dbname=pgddb" --pgdata /var/lib/edb-pge/17/main/ --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" ``` diff --git a/product_docs/docs/pgd/6/essential-how-to/install/02-configure-repositories.mdx b/product_docs/docs/pgd/6/essential-how-to/install/02-configure-repositories.mdx index 2d5c2f7fb22..65cb237d6ea 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/02-configure-repositories.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/02-configure-repositories.mdx @@ -27,12 +27,14 @@ This is the type of package manager you use, which informs the installer which t export EDB_REPO_TYPE= ``` -## Install the repository/repositories +## Install the repositories -For PGD Essential, there is just one repository to install. +There are two repositories you need to configure: one for the database software and one for the PGD software. + +The following command will download and run a script that configures your package manager to use the EDB repository for databases. ```bash -curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/standard/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/enterprise/setup.$EDB_REPO_TYPE.sh" | sudo -E bash ``` This command will download and run a script that configures your package manager to use the EDB repository. It will also install any necessary dependencies. @@ -46,5 +48,8 @@ In this example, we will configure the repositories on a CentOS/RHEL system that ```bash export EDB_SUBSCRIPTION_TOKEN=XXXXXXXXXXXXXX export EDB_REPO_TYPE=rpm -curl -1sSLf " https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/standard/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +curl -1sSLf " https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/enterprise/setup.$EDB_REPO_TYPE.sh" | sudo -E bash ``` + +The next step is to [install the database and PGD software](03-installing-database-and-pgd/). + diff --git a/product_docs/docs/pgd/6/essential-how-to/install/03-installing-database-and-pgd.mdx b/product_docs/docs/pgd/6/essential-how-to/install/03-installing-database-and-pgd.mdx index e8208f13db3..45c07f3bf3f 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/03-installing-database-and-pgd.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/03-installing-database-and-pgd.mdx @@ -7,7 +7,7 @@ deepToC: true On each host which you want to use as a PGD data node, you need to install the database and the PGD software. -After you have [configured the EDB repository](02-configure-repository), you can install the database and PGD software using your package manager. +After you have [configured the EDB repository](02-configure-repositories), you can install the database and PGD software using your package manager. ## Install the database and PGD software @@ -117,10 +117,13 @@ This command will install the specified packages and any dependencies they requi ## Worked example -In this example, we will install EDB Postgres Extended Server 17 with PGD Essential on a CentOS/RHEL system using an enterprise subscription using the repository confiuguration we set up in the [previous step's worked example](02-configure-repository#worked-example). +In this example, we will install EDB Postgres Extended Server 17 with PGD Essential on a CentOS/RHEL system using an enterprise subscription using the repository confiuguration we set up in the [previous step's worked example](02-configure-repositories#worked-example). ```bash export PG_VERSION=17 -export EDB_PACKAGES="edb-as$PG_VERSION edb-pgd6-essential-epas$PG_VERSION" -sudo dnf install -y $EDB_PACKAGES + export EDB_PACKAGES="edb-postgresextended$PG_VERSION-server edb-postgresextended$PG_VERSION-contrib edb-pgd6-essential-pgextended$PG_VERSION" + sudo dnf install -y $EDB_PACKAGES ``` + +The next step is to [configure the cluster](04-configuring-cluster/). + diff --git a/product_docs/docs/pgd/6/essential-how-to/install/04-configuring-cluster.mdx b/product_docs/docs/pgd/6/essential-how-to/install/04-configuring-cluster.mdx index fdfdeabdb93..0dcb77c40f8 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/04-configuring-cluster.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/04-configuring-cluster.mdx @@ -48,7 +48,8 @@ The paths and users used in the examples will vary according to which version of | Postgres Data Directory | `/var/lib/edb-as/$PG_VERSION/main/` | ```shell -sudo --preserve-env=PG_VERSION -iu enterprisedb +sudo -iu enterprisedb +export PG_VERSION= export PATH=$PATH:/usr/lib/edb-as/$PG_VERSION/bin/ export PGDATA=/var/lib/edb-as/$PG_VERSION/main/ export PGPORT=5444 @@ -65,7 +66,8 @@ export PGPORT=5444 | Postgres Data Directory | `/var/lib/edb/as$PG_VERSION/data/` | ```shell -sudo --preserve-env=PG_VERSION -iu enterprisedb +sudo -iu enterprisedb +export PG_VERSION= export PATH=$PATH:/usr/edb/as$PG_VERSION/bin/ export PGDATA=/var/lib/edb/as$PG_VERSION/data/ export PGPORT=5444 @@ -88,7 +90,8 @@ export PGPORT=5444 | Postgres Data Directory | `/var/lib/edb-pge/$PG_VERSION/main/` | ```shell -sudo --preserve-env=PG_VERSION -iu postgres +sudo -iu postgres +export PG_VERSION= export PATH=$PATH:/usr/lib/edb-pge/$PG_VERSION/bin/ export PGDATA=/var/lib/edb-pge/$PG_VERSION/main/ export PGPORT=5432 @@ -105,7 +108,8 @@ export PGPORT=5432 | Postgres Data Directory | `/var/lib/edb-pge/$PG_VERSION/data/` | ```shell -sudo --preserve-env=PG_VERSION -iu postgres +sudo -iu postgres +export PG_VERSION= export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ export PGPORT=5432 @@ -127,7 +131,6 @@ Community PostgreSQL is only operable with PGD Expanded.

- !!!



@@ -136,18 +139,38 @@ Community PostgreSQL is only operable with PGD Expanded. ## On each host -1. Log in as the database user and set the environment variables. Copy and paste the scripts above to login and set required environment variables. In the scripts above: - - The `PG_VERSION` variable is set to the version of Postgres you are using (we assume you have set this in the previous step and use the `--preserve-env` option of sudo to preserve its setting when switching users.). - - The `PGPORT` variable is set to the port number for the database. - - The `PGDATA` variable is set to the data directory for the database. The `PATH` variable is set to include the Postgres executable files. +Run the commands from the script/settings above to set the environment variables and paths for the Postgres user on each host. +This will ensure that the `pgd` command can find the Postgres executable files and data directory. + +1. Using the appropriate user, log in as the database user. + +```bash +sudo -iu +``` + +1. Set the Postgres version environment variable. Don't forget to replace `` with the actual version number you are using, such as `17`. + +```bash +export PG_VERSION= +``` + +1. Add the Postgres executable files to your path. -2. Set the `PGPASSWORD` environment variable to the password for the database user. This is required for the `pgd` command to connect to the database. - ```bash - export PGPASSWORD= - ``` - This is the password for the database user. In the examples, the password is `secret`. +```bash +export PATH=$PATH: +``` + +1. Set the Postgres data directory environment variable. + +```bash +export PGDATA= +``` -1. Run the pgd node setup command +1. Set the Postgres password environment variable. Don't forget to replace `` with the actual password you want for the database user. + +```bash +export PGPASSWORD= +``` ### On the first host @@ -182,7 +205,7 @@ This command will create the node on the third host, and then join the cluster u ## Worked example -In this example, we will configure the PGD Essential cluster with EDB Postgres Extended Server 17 on a CentOS/RHEL system that we [configured](02-configure-repository) and [installed](03-installing-database-and-pgd) in the previous steps. +In this example, we will configure the PGD Essential cluster with EDB Postgres Extended Server 17 on a CentOS/RHEL system that we [configured](02-configure-repositories) and [installed](03-installing-database-and-pgd) in the previous steps. We will now create a cluster called `pgd` with three nodes called `node-1`, `node-2`, and `node-3`. @@ -200,29 +223,34 @@ We will now create a cluster called `pgd` with three nodes called `node-1`, `nod #### On the first host ```bash -sudo --preserve-env=PG_VERSION -iu postgres +sudo -iu postgres +export PG_VERSION=17 export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ export PGPASSWORD=secret -pgd node node-1 setup "host=host-1 user=postgres port=5432 dbname=pgddb" --group-name group-1 +pgd node node-1 setup --dsn "host=host-1 user=postgres port=5432 dbname=pgddb" --group-name group-1 ``` #### On the second host ```bash -sudo --preserve-env=PG_VERSION -iu postgres +sudo -iu postgres +export PG_VERSION=17 export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ export PGPASSWORD=secret -pgd node node-2 setup "host=host-2 user=postgres port=5432 dbname=pgddb" --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" +pgd node node-2 setup --dsn "host=host-2 user=postgres port=5432 dbname=pgddb" --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" ``` #### On the third host ```bash -sudo --preserve-env=PG_VERSION -iu postgres +sudo -iu postgres +export PG_VERSION=17 export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ export PGPASSWORD=secret -pgd node node-3 setup "host=host-3 user=postgres port=5432 dbname=pgddb" --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" +pgd node node-3 setup --dsn "host=host-3 user=postgres port=5432 dbname=pgddb" --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" ``` + +The next step is to [create the database](05-check-cluster). diff --git a/product_docs/docs/pgd/6/essential-how-to/install/05-check-cluster.mdx b/product_docs/docs/pgd/6/essential-how-to/install/05-check-cluster.mdx index 7b4cb663852..eab0c54edf5 100644 --- a/product_docs/docs/pgd/6/essential-how-to/install/05-check-cluster.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/install/05-check-cluster.mdx @@ -117,7 +117,7 @@ select * from bdr.node_replication_rates; The command shows statistics about how quickly that data was replicated to the other two nodes: ```console -bdrdb=# select * from bdr.node_replication_rates; +pgddb=# select * from bdr.node_replication_rates; peer_node_id | target_name | sent_lsn | replay_lsn | replay_lag | replay_lag_bytes | replay_lag_size | apply_rate | catchup_interv al --------------+-------------+-----------+------------+------------+------------------+-----------------+------------+--------------- @@ -140,7 +140,7 @@ select COUNT(*),SUM(value) from quicktest; This command gets some values from the generated data: ```sql -bdrdb=# select COUNT(*),SUM(value) from quicktest; +pgddb=# select COUNT(*),SUM(value) from quicktest; __OUTPUT__ count | sum --------+----------- @@ -151,7 +151,8 @@ __OUTPUT__ ### Check data #### Log in to host-2's Postgres server -``` + +```shell ssh admin@host-2 sudo -iu postgres psql "host=host-2 port=5432 username=postgres dbname=pgddb" ``` @@ -169,7 +170,7 @@ select COUNT(*),SUM(value) from quicktest; This command gets node-2's values for the generated data: ```sql -bdrdb=# select COUNT(*),SUM(value) from quicktest; +pgddb=# select COUNT(*),SUM(value) from quicktest; __OUTPUT__ count | sum --------+----------- @@ -187,7 +188,7 @@ You can repeat the process with node-3 or generate new data on any node and see ```shell ssh admin@host-3 -sudo -iu enterprisedb psql bdrdb +sudo -iu enterprisedb psql pgddb ``` This is your connection to PGD's node-3. @@ -203,7 +204,7 @@ select COUNT(*),SUM(value) from quicktest; This command gets node-3's values for the generated data: ```sql -bdrdb=# select COUNT(*),SUM(value) from quicktest; +pgddb=# select COUNT(*),SUM(value) from quicktest; __OUTPUT__ count | sum --------+----------- diff --git a/product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx b/product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx index ebe754224b2..4917d86d893 100644 --- a/product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/pgd-cli.mdx @@ -77,9 +77,9 @@ This has two properties: cluster: name: pgd endpoints: - - host=host-1 dbname=bdrdb port=5444 - - host=host-2 dbname=bdrdb port=5444 - - host=host-3 dbname=bdrdb port=5444 + - host=host-1 dbname=pgddb port=5444 + - host=host-2 dbname=pgddb port=5444 + - host=host-3 dbname=pgddb port=5444 ``` Note that the endpoints in this example specify `port=5444`. @@ -101,9 +101,9 @@ cat < \ No newline at end of file diff --git a/product_docs/docs/pgd/6/expanded-how-to/architectures/images/2x3-cluster.svg b/product_docs/docs/pgd/6/expanded-how-to/architectures/images/2x3-cluster.svg new file mode 100644 index 00000000000..ba14b6bed03 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/architectures/images/2x3-cluster.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/product_docs/docs/pgd/6/expanded-how-to/architectures/index.mdx b/product_docs/docs/pgd/6/expanded-how-to/architectures/index.mdx index 59d011c577b..3bf1011cbf8 100644 --- a/product_docs/docs/pgd/6/expanded-how-to/architectures/index.mdx +++ b/product_docs/docs/pgd/6/expanded-how-to/architectures/index.mdx @@ -1,11 +1,17 @@ --- title: PGD Architectures navTitle: Architectures +navigation: +- always-on +- essential +- multi-location +- geo-distributed --- With PGD 6 Expanded, you can deploy a cluster in a wide range of architectures. Unlike PGD 6 Essential, which is limited to two architectures made with a limited number of groups, PGD 6 Expanded supports multiple architectures with technically unlimited groups, including: -* **Standard/One-location architecture**: A single PGD cluster with three nodes in the same data center or availability zone; The PGD 6 Essential architecture. -* **Multi-location architecture**: A single PGD cluster with two or more groups in different data centers or availability zones. -* **Geo-distributed architecture**: A single PGD cluster with two or more groups in different regions. +* [**Always-on architecture**](always-on): A single PGD cluster with two or more groups in the same data center or availability zone. This architecture is designed for high availability and disaster recovery, ensuring that the database remains operational even if one group fails. +* [**Essentials's Standard/One-location architecture**](essential): A single PGD cluster with three nodes in the same data center or availability zone; The PGD 6 Essential architecture. +* [**Multi-location architecture**](multi-location): A single PGD cluster with two or more groups in different data centers or availability zones. +* [**Geo-distributed architecture**](geo-distributed): A single PGD cluster with two or more groups in different regions, like a multi-location architecture but with higher latency and potential network partitioning issues. diff --git a/product_docs/docs/pgd/6/expanded-how-to/architectures/multi-location.mdx b/product_docs/docs/pgd/6/expanded-how-to/architectures/multi-location.mdx new file mode 100644 index 00000000000..66dac43e59e --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/architectures/multi-location.mdx @@ -0,0 +1,7 @@ +--- +title: Multi-Location Architectures +navTitle: Multi-Location +--- + +PGD 6 Expanded inherently supports architectures that span multiple locations, such as data centers or availability zones. This is a key feature of the Expanded edition, allowing you to build robust and resilient distributed databases that can handle failures and maintain high availability across different geographic locations. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/install/02-configure-repositories.mdx b/product_docs/docs/pgd/6/expanded-how-to/install/02-configure-repositories.mdx index 4284dfa9470..46a6045a3bb 100644 --- a/product_docs/docs/pgd/6/expanded-how-to/install/02-configure-repositories.mdx +++ b/product_docs/docs/pgd/6/expanded-how-to/install/02-configure-repositories.mdx @@ -19,6 +19,14 @@ This is the token you received when you registered for the EDB subscription. It export EDB_SUBSCRIPTION_TOKEN= ``` +### `EDB_SUBSCRIPTION_PLAN` + +This is the type of subscription you have with EDB. It can be `standard`, `enterprise`, or `community`. + +```bash +export EDB_SUBSCRIPTION_PLAN= +``` + ### `EDB_REPO_TYPE` This is the type of package manager you use, which informs the installer which type of package you need. This can be `deb` for Ubuntu/Debian or `rpm` for CentOS/RHEL. @@ -29,24 +37,30 @@ export EDB_REPO_TYPE= ## Install the repository/repositories -For PGD Essential, there is just one repository to install. For PGD Extended, there are two repositories to install. +There are two repositories you need to configure: one for the database software and one for the PGD software. +The following command will download and run a script that configures your package manager to use the EDB repository for databases. ```bash curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/setup.$EDB_REPO_TYPE.sh" | sudo -E bash -curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/postgres_distributed/setup.$EDB_REPO_TYPE.sh" | sudo -E bash ``` -This command will download and run a script that configures your package manager to use the EDB repository. It will also install any necessary dependencies. +The following command will download and run a script that configures your package manager to use the EDB repository for PGD. + +```bash +curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/postgres_distributed/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +``` + ## Worked example -In this example, we will configure the repositories on a CentOS/RHEL system that will allow us to install EDB Postgres Extended Server 17 with PGD Expanded using an enterprise subscription. +In this example, we will configure the repositories on a CentOS/RHEL system that will allow us to install EDB Postgres Advanced Server 17 with PGD Expanded using an enterprise subscription. ### Set the environment variables ```bash export EDB_SUBSCRIPTION_TOKEN=XXXXXXXXXXXXXX +export EDB_SUBSCRIPTION_PLAN=enterprise export EDB_REPO_TYPE=rpm ``` @@ -54,6 +68,8 @@ export EDB_REPO_TYPE=rpm ```bash # For PGD Expanded, there are two repositories to install. -curl -1sSLf " https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/enterprise/setup.$EDB_REPO_TYPE.sh" | sudo -E bash +curl -1sSLf " https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/$EDB_SUBSCRIPTION_PLAN/setup.$EDB_REPO_TYPE.sh" | sudo -E bash curl -1sSLf " https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/postgres_distributed/setup.$EDB_REPO_TYPE.sh" | sudo -E bash ``` + +The next step is to [install the database and PGD software](03-installing-database-and-pgd/). \ No newline at end of file diff --git a/product_docs/docs/pgd/6/expanded-how-to/install/03-installing-database-and-pgd.mdx b/product_docs/docs/pgd/6/expanded-how-to/install/03-installing-database-and-pgd.mdx index b26b2075a01..941fa253b6b 100644 --- a/product_docs/docs/pgd/6/expanded-how-to/install/03-installing-database-and-pgd.mdx +++ b/product_docs/docs/pgd/6/expanded-how-to/install/03-installing-database-and-pgd.mdx @@ -7,7 +7,7 @@ deepToC: true On each host which you want to use as a PGD data node, you need to install the database and the PGD software. -After you have [configured the EDB repository](02-configure-repository), you can install the database and PGD software using your package manager. +After you have [configured the EDB repository](02-configure-repositories), you can install the database and PGD software using your package manager. ## Install the database and PGD software @@ -134,7 +134,7 @@ This command will install the specified packages and any dependencies they requi ## Worked example -In this example, we will install EDB Postgres Extended Server 17 with PGD Expanded on a CentOS/RHEL system using the repository configuration we set up in the [previous step's worked example](02-configure-repository#worked-example). +In this example, we will install EDB Postgres Extended Server 17 with PGD Expanded on a CentOS/RHEL system using the repository configuration we set up in the [previous step's worked example](02-configure-repositories#worked-example). ```bash export PG_VERSION=17 diff --git a/product_docs/docs/pgd/6/expanded-how-to/install/04-configuring-cluster.mdx b/product_docs/docs/pgd/6/expanded-how-to/install/04-configuring-cluster.mdx index 1fc08a90434..6744282c007 100644 --- a/product_docs/docs/pgd/6/expanded-how-to/install/04-configuring-cluster.mdx +++ b/product_docs/docs/pgd/6/expanded-how-to/install/04-configuring-cluster.mdx @@ -10,27 +10,27 @@ The next step in the process is to configure the database and the cluster. This involves logging into each host and running the `pgd` command to create the cluster as the database user. -These steps will vary according to which platform you are using and which version of Postgres you are using. +These steps vary according to which platform you are using and which version of Postgres you are using. Bute there are some common steps to follow and common variables to set. -## Cluster name +### Cluster name You will need to choose a name for your cluster. This is the name that will be used to identify the cluster in the PGD CLI and in the database. It will be referred to as `` in the examples. If not specified, the default name is `pgd`. -## Group names +### Group names You will also need to choose a name for the group. This is the name that will be used to identify the group in the PGD CLI and in the database. It will be referred to as `` in the examples. The group name must be unique within the cluster. -## Node names +### Node names You will also need to choose a name for each node. This is the name that will be used to identify the node in the PGD CLI and in the database. It will be referred to as `` in the examples. This is separate from the host name, which is the name of the machine on which the node is running. The node name must be unique within the group and within the cluster. -## Paths and users +### Paths and users -The paths and users used in the examples will vary according to which version of Postgres you are using and which platform you are using. +The paths, users and ports used in the examples will vary according to which version of Postgres you are using and which platform you are using. @@ -38,6 +38,13 @@ The paths and users used in the examples will vary according to which version of You will use the system's `enterprisedb` user to run the `pgd` command. The database port is 5444. +```shell +sudo -iu enterprisedb +export PG_VERSION= +export PATH=$PATH:/usr/lib/edb-as/$PG_VERSION/bin/ +export PGDATA=/var/lib/edb-as/$PG_VERSION/main/ +``` + @@ -47,7 +54,16 @@ You will use the system's `enterprisedb` user to run the `pgd` command. The data | Postgres Data Directory | `/var/lib/edb-as/$PG_VERSION/main/` | ```shell -sudo --preserve-env=PG_VERSION -iu enterprisedb +sudo -iu enterprisedb +export PG_VERSION= +export PATH=$PATH:/usr/lib/edb-as/$PG_VERSION/bin/ +export PGDATA=/var/lib/edb-as/$PG_VERSION/main/ +``` + + +```shell +sudo -iu enterprisedb +export PG_VERSION= export PATH=$PATH:/usr/lib/edb-as/$PG_VERSION/bin/ export PGDATA=/var/lib/edb-as/$PG_VERSION/main/ ``` @@ -61,7 +77,8 @@ export PGDATA=/var/lib/edb-as/$PG_VERSION/main/ | Postgres Data Directory | `/var/lib/edb/as$PG_VERSION/data/` | ```shell -sudo --preserve-env=PG_VERSION -iu enterprisedb +sudo -iu enterprisedb +export PG_VERSION= export PATH=$PATH:/usr/edb/as$PG_VERSION/bin/ export PGDATA=/var/lib/edb/as$PG_VERSION/data/ ``` @@ -82,7 +99,8 @@ You will use the system's `postgres` user to run the `pgd` command. The database | Postgres Data Directory | `/var/lib/edb-pge/$PG_VERSION/main/` | ```shell -sudo --preserve-env=PG_VERSION -iu postgres +sudo -iu postgres +export PG_VERSION= export PATH=$PATH:/usr/lib/edb-pge/$PG_VERSION/bin/ export PGDATA=/var/lib/edb-pge/$PG_VERSION/main/ ``` @@ -96,7 +114,8 @@ export PGDATA=/var/lib/edb-pge/$PG_VERSION/main/ | Postgres Data Directory | `/var/lib/edb-pge/$PG_VERSION/data/` | ```shell -sudo --preserve-env=PG_VERSION -iu postgres +sudo -iu postgres +export PG_VERSION= export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ ``` @@ -117,7 +136,8 @@ You will use the system's `postgres` user to run the `pgd` command. The database | Postgres Data Directory | `/var/lib/postgresql/$PG_VERSION/main/` | ```shell -sudo --preserve-env=PG_VERSION -iu postgres +sudo -iu postgres +export PG_VERSION= export PATH=$PATH:/usr/lib/postgresql/$PG_VERSION/bin/ export PGDATA=/var/lib/postgresql/$PG_VERSION/main/ ``` @@ -131,7 +151,8 @@ export PGDATA=/var/lib/postgresql/$PG_VERSION/main/ | Postgres Data Directory | `/var/lib/pgsql/$PG_VERSION/data/` | ```shell -sudo --preserve-env=PG_VERSION -iu postgres +sudo -iu postgres +export PG_VERSION= export PATH=$PATH:/usr/pgsql-$PG_VERSION/bin/ export PGDATA=/var/lib/pgsql/$PG_VERSION/data/ ``` @@ -146,16 +167,36 @@ export PGDATA=/var/lib/pgsql/$PG_VERSION/data/ 1. Using the appropriate user, log in as the database user. ```bash -sudo su - +sudo -iu ``` -2. Add the Postgres executable files to your path. +1. Set the Postgres version environment variable. + +```bash +export PG_VERSION= +``` + +1. Add the Postgres executable files to your path. ```bash export PATH=$PATH: ``` -3. Run the pgd node setup command +1. Set the Postgres data directory environment variable. + +```bash +export PGDATA= +``` + +1. Set the Postgres password environment variable. + +```bash +export PGPASSWORD= +``` + +This password is used by the `pgd` command to connect to the database, and when initializing the database. + +1. Run the pgd node setup command. ### On the first host @@ -189,11 +230,11 @@ This command will create the node on the third host, and then join the cluster u ## Worked example -In this example, we will configure the PGD Expanded cluster with EDB Postgres Extended Server 17 on a CentOS/RHEL system using an enterprise subscription that we [configured](02-configure-repository) and [installed](03-installing-database-and-pgd) in the previous steps. +In this example, we will configure the PGD Expanded cluster with EDB Postgres Extended Server 17 on a CentOS/RHEL system using an enterprise subscription that we [configured](02-configure-repositories) and [installed](03-installing-database-and-pgd) in the previous steps. We will now create a cluster called `pgd` with three nodes called `node1`, `node2`, and `node3`. -* The group name will be `group1`. The hosts are `host-1`, `host-2`, and `host-3`. +* The group name will be `group-1`. The hosts are `host-1`, `host-2`, and `host-3`. * The Postgres version is 17. * The database user is `postgres`. * The database port is 5432. @@ -211,7 +252,7 @@ export PG_VERSION=17 export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ export PGPASSWORD=secret -pgd node node-1 setup "host=host-1 user=postgres port=5432 dbname=pgddb" --group-name group1 --update-pgpass +pgd node node-1 setup --dsn "host=host-1 user=postgres port=5432 dbname=pgddb" --group-name group-1 --update-pgpass ``` #### On the second host @@ -222,7 +263,7 @@ export PG_VERSION=17 export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ export PGPASSWORD=secret -pgd node node-2 setup "host=host-2 user=postgres port=5432 dbname=pgddb" --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" +pgd node node-2 setup --dsn "host=host-2 user=postgres port=5432 dbname=pgddb" --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" ``` #### On the third host @@ -233,5 +274,7 @@ export PG_VERSION=17 export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ export PGPASSWORD=secret -pgd node node-3 setup "host=host-3 user=postgres port=5432 dbname=pgddb" --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" +pgd node node-3 setup --dsn "host=host-3 user=postgres port=5432 dbname=pgddb" --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" ``` + +Next, you can [check the cluster](05-check-cluster) to begin using it. diff --git a/product_docs/docs/pgd/6/expanded-how-to/install/05-check-cluster.mdx b/product_docs/docs/pgd/6/expanded-how-to/install/05-check-cluster.mdx index b8640c97504..a8ccbefb5f7 100644 --- a/product_docs/docs/pgd/6/expanded-how-to/install/05-check-cluster.mdx +++ b/product_docs/docs/pgd/6/expanded-how-to/install/05-check-cluster.mdx @@ -121,7 +121,7 @@ select * from bdr.node_replication_rates; The command shows statistics about how quickly that data was replicated to the other two nodes: ```console -bdrdb=# select * from bdr.node_replication_rates; +pgddb=# select * from bdr.node_replication_rates; __OUTPUT__ peer_node_id | target_name | sent_lsn | replay_lsn | replay_lag | replay_lag_bytes | replay_lag_size | apply_rate | catchup_interv al @@ -145,7 +145,7 @@ select COUNT(*),SUM(value) from quicktest; This command gets some values from the generated data: ```sql -bdrdb=# select COUNT(*),SUM(value) from quicktest; +pgddb=# select COUNT(*),SUM(value) from quicktest; __OUTPUT__ count | sum --------+----------- @@ -175,7 +175,7 @@ select COUNT(*),SUM(value) from quicktest; This command gets node-2's values for the generated data: ```sql -bdrdb=# select COUNT(*),SUM(value) from quicktest; +pgddb=# select COUNT(*),SUM(value) from quicktest; __OUTPUT__ count | sum --------+----------- @@ -193,7 +193,7 @@ You can repeat the process with node-3 or generate new data on any node and see ```shell ssh admin@host-3 -sudo -iu enterprisedb psql bdrdb +sudo -iu enterprisedb psql pgddb ``` This is your connection to PGD's node-3. @@ -209,7 +209,7 @@ select COUNT(*),SUM(value) from quicktest; This command gets node-3's values for the generated data: ```sql -bdrdb=# select COUNT(*),SUM(value) from quicktest; +pgddb=# select COUNT(*),SUM(value) from quicktest; __OUTPUT__ count | sum --------+----------- diff --git a/product_docs/docs/pgd/6/get-started/assets/docker-compose.yml b/product_docs/docs/pgd/6/get-started/assets/docker-compose.yml new file mode 100644 index 00000000000..bded4e6b65f --- /dev/null +++ b/product_docs/docs/pgd/6/get-started/assets/docker-compose.yml @@ -0,0 +1,24 @@ + +services: + host-1: + hostname: host-1 + image: pgd + environment: + PGPASSWORD: secret + PGD_JOIN_NODE_DSN: "port=5432 dbname=pgddb host=host-1 user=postgres" + restart: always + volumes: + - ./host-1-data:/var/lib/postgresql/data + + host-2: + hostname: host-2 + extends: host-1 + volumes: + - ./host-2-data:/var/lib/postgresql/data + + host-3: + hostname: host-3 + extends: host-1 + volumes: + - ./host-3-data:/var/lib/postgresql/data + diff --git a/product_docs/docs/pgd/6/get-started/essential-standard.mdx b/product_docs/docs/pgd/6/get-started/essential-standard.mdx index a51a4ae6ce7..e25c6d94ea2 100644 --- a/product_docs/docs/pgd/6/get-started/essential-standard.mdx +++ b/product_docs/docs/pgd/6/get-started/essential-standard.mdx @@ -1,14 +1,24 @@ --- -title: PGD Essential Standard/One-location Architecture -navTitle: Standard Architecture +title: An introduction to PGD Essential +navTitle: Introducing PGD Essential --- -The standard architecture is the basic building block for EDB Postgres Distributed. It is most commonly used on a single location where the nodes are in the same data center, and it is also called the one-location architecture. +EDB Postgres Distributed (PGD) Essential is a simplified version of PGD Expanded, designed to help you get started with distributed databases quickly and easily. It provides the core features of PGD, enabling high availability and disaster recovery without the complexity of advanced configurations. + +At the core of PGD are data nodes, Postgres databases that are part of a PGD cluster. PGD enables these databases to replicate data efficiently between nodes, ensuring that your data is always available and up-to-date. PGD Essential simplifies this process by providing a standard architecture that is easy to set up and manage. + +The standard architecture is built around a single data group, which is the basic architectural element for EDB Postgres Distributed systems. Within a group, nodes cooperate to select which nodes handle incoming write or read traffic, and identify when nodes are available or out of sync with the rest of the group. Groups are most commonly used on a single location where the nodes are in the same data center and where you have just the one group in the cluster, we also call it the one-location architecture. ## Standard/One-location architecture -The one-location architecture consists of a single PGD cluster with three nodes. The nodes are located in the same data center or availability zone. The nodes are connected to each other using a high-speed network. +The one-location architecture consists of a single PGD cluster with three nodes. The nodes are located in the same data center or region. Ideally they are in different availability zones, but that isn't required. The nodes are connected to each other using a high-speed network. + +The nodes are configured as a data group which means that they replicate data to each other within the same group. While PGD can handle multiple writers in a network, this requires more advanced conflict management and is not supported in PGD Essential. + +Therefore, in the standard architecture, one node is designated as the write leader node, which handles all write transactions. The other nodes in the group are read-only nodes that replicate data from the write leader. + + +The write leader node is one node selected by the nodes in the group to handle all the writes. It is responsible for accepting write transactions and replicating them to the other nodes in the group. If the write leader node fails, the other nodes in the group will elect a new write leader node. -The nodes are configured as a data sub-group which means that they replicate data to each other within the same group. In PGD Essential, the group also uses a write leader node, one node selected by the nodes in the group to handle all the writes. The write leader node is responsible for accepting write transactions and replicating them to the other nodes in the group. If the write leader node fails, the other nodes in the group will elect a new write leader node. +Applications can connect to any node in the cluster using PGD's Connection Manager ports which runs on every data node. It will automatically route read and write transactions to the write leader. It can also route read only transactions to the other nodes in the group. -Applications can connect to any node in the cluster using PGD's connection manager which runs on every data node. It will automatically route read and write transactions to the write leader. It can also route read only transactions to the other nodes in the group. diff --git a/product_docs/docs/pgd/6/get-started/first-cluster.mdx b/product_docs/docs/pgd/6/get-started/first-cluster.mdx index 2c4b0ddb95f..99f1be49684 100644 --- a/product_docs/docs/pgd/6/get-started/first-cluster.mdx +++ b/product_docs/docs/pgd/6/get-started/first-cluster.mdx @@ -12,22 +12,41 @@ This part of the Getting Started guide will help you create a local cluster usin ## Download the PGD Docker Compose kit -1. Download the Docker kit from the [EDB website](https://www.enterprisedb.com/downloads/postgres-distributed). -2. Extract the contents of the downloaded file to a directory on your local machine. -3. Navigate to the extracted directory. -4. Open a terminal window and run the following command to start the Docker containers: +1. Download the PGD Docker Compose file - [docker-compose.yml](/pgd/latest/get-started/assets/docker-compose.yml). +1. Move the downloaded file to a directory where you want to create your local cluster. +1. Run ```bash -make up +docker compose up ``` This command will start the Docker containers and create a local cluster with the default configuration. -5. Once the containers are up and running, you can access the PGD cluster using the following command: +1. Once the containers are up and running, you can access the PGD cluster using the following command: + +``` +docker compose exec host-1 psql pgddb +``` + +This command will connect you directly to the first node of the cluster using the `psql` command-line interface. This is how you could connect to the database for maintenance and management tasks. + +1. You can connect to the write leader node in the cluster using the following command: + +```bash +docker compose exec host-1 psql -h host-1 -p 6432 pgddb +``` + +1. To use the PGD CLI, you can run the following command: ```bash -make psql +docker compose exec host-1 pgd nodes list --dsn "host=host-1 port=6432 dbname=pgddb" +__OUTPUT__ + Node Name | Group Name | Node Kind | Join State | Node Status +-----------+------------+-----------+------------+------------- + node-1 | group-1 | data | ACTIVE | Up + node-2 | group-1 | data | ACTIVE | Up + node-3 | group-1 | data | ACTIVE | Up ``` -This command will connect you to the primary node of the cluster using the `psql` command-line interface. +This command will list the nodes in the cluster and their status. diff --git a/product_docs/docs/pgd/6/index.mdx b/product_docs/docs/pgd/6/index.mdx index f32ca586aa4..c59273b934e 100644 --- a/product_docs/docs/pgd/6/index.mdx +++ b/product_docs/docs/pgd/6/index.mdx @@ -6,6 +6,7 @@ indexCards: simple redirects: - /edb-postgres-ai/migration-etl/pgd/ navigation: + - "#Getting Started" - get-started - "#How To..." - essential-how-to @@ -45,3 +46,5 @@ PGD Essential is a simplified version of PGD Expanded. It is designed for users PGD Essential limits the number of nodes in a cluster to 4 and the number of groups to 2. It also limits the number of nodes in a group to 4. PGD Expanded does not have these limitations. +Learn more about PGD in [Get Started with PGD](/pgd/latest/get-started/). + diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/index.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/index.mdx index e0a6cc5ffea..330ec931ed4 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/index.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/index.mdx @@ -55,7 +55,7 @@ All commands accept the following global options: | Short | Long             | Description | |-------|------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------| | `-f` | `--config-file` | Name/Path to config file.
This is ignored if --dsn flag is present
Default "/etc/edb/pgd-cli/pgd-cli-config.yml" | -| | `--dsn` | Database connection string
For example "host=bdr-a1 port=5432 dbname=bdrdb user=postgres" | +| | `--dsn` | Database connection string
For example "host=bdr-a1 port=5432 dbname=pgddb user=postgres" | | `-h` | `--help` | Help for pgd - will show specific help for any command used | | `-o` | `--output` | Output format: `json`, `psql`, `modern`, `markdown`, `simple` (see [Output formats](#output-formats)) | diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/node/get-option.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/node/get-option.mdx index f28ab4522da..c60233c5645 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/node/get-option.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/node/get-option.mdx @@ -44,7 +44,7 @@ pgd node kaboom get-option __OUTPUT__ Option Name Option Value -------------- ------------------------------------------------- -route_dsn host=kaboom port=5444 dbname=bdrdb user=postgres +route_dsn host=kaboom port=5444 dbname=pgddb user=postgres route_fence false route_priority 100 route_reads true @@ -69,7 +69,7 @@ __OUTPUT__ [ { "option_name": "route_dsn", - "option_value": "host=kaboom port=5444 dbname=bdrdb user=postgres" + "option_value": "host=kaboom port=5444 dbname=pgddb user=postgres" }, { "option_name": "route_fence", diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/node/set-option.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/node/set-option.mdx index fefa99f7c80..66ab5181b09 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/node/set-option.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/node/set-option.mdx @@ -47,7 +47,7 @@ Command executed successfully ### Set a specific node option with a space in the value ```shell -pgd node kaboom set-option route_dsn "host=kaboom port=5444 dbname=bdrdb user=postgres" +pgd node kaboom set-option route_dsn "host=kaboom port=5444 dbname=pgddb user=postgres" __OUTPUT__ Command executed successfully ``` diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/node/show.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/node/show.mdx index df28181f8c7..7a310af166f 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/node/show.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/node/show.mdx @@ -37,12 +37,12 @@ Join State ACTIVE Node Status Up Node ID 2710197610 Snowflake SeqID 2 -Database bdrdb +Database pgddb # Options Option Name Option Value -------------- ------------------------------------------------- -route_dsn host=kaboom port=5444 dbname=bdrdb user=postgres +route_dsn host=kaboom port=5444 dbname=pgddb user=postgres route_fence false route_priority 100 route_reads true @@ -87,7 +87,7 @@ __OUTPUT__ }, { "info": "Database", - "value": "bdrdb" + "value": "pgddb" } ] }, @@ -95,7 +95,7 @@ __OUTPUT__ "Options": [ { "option_name": "route_dsn", - "option_value": "host=kaboom port=5444 dbname=bdrdb user=postgres " + "option_value": "host=kaboom port=5444 dbname=pgddb user=postgres " }, { "option_name": "route_fence", diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/node/upgrade.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/node/upgrade.mdx index a55f01586e0..f856a2011d5 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/node/upgrade.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/node/upgrade.mdx @@ -50,23 +50,23 @@ In the following examples, "kaolin" is the name of the node to upgrade, from the ### Upgrade the PostgreSQL version on a node ```shell -pgd node kaolin upgrade --old-bindir /usr/pgsql-16/bin --new-bindir /usr/pgsql-17/bin --old-datadir /var/lib/pgsql/16/data --new-datadir /var/lib/pgsql/17/data --database bdrdb --username enterprisedb +pgd node kaolin upgrade --old-bindir /usr/pgsql-16/bin --new-bindir /usr/pgsql-17/bin --old-datadir /var/lib/pgsql/16/data --new-datadir /var/lib/pgsql/17/data --database pgddb --username enterprisedb ``` ### Upgrade the PostgreSQL version on a node with hard links ```shell -pgd node kaolin upgrade --old-bindir /usr/pgsql-16/bin --new-bindir /usr/pgsql-17/bin --old-datadir /var/lib/pgsql/16/data --new-datadir /var/lib/pgsql/17/data --database bdrdb --username enterprisedb --link +pgd node kaolin upgrade --old-bindir /usr/pgsql-16/bin --new-bindir /usr/pgsql-17/bin --old-datadir /var/lib/pgsql/16/data --new-datadir /var/lib/pgsql/17/data --database pgddb --username enterprisedb --link ``` ### Upgrade the PostgreSQL version on a node with efficient file cloning ```shell -pgd node kaolin upgrade --old-bindir /usr/pgsql-16/bin --new-bindir /usr/pgsql-17/bin --old-datadir /var/lib/pgsql/16/data --new-datadir /var/lib/pgsql/17/data --database bdrdb --username enterprisedb --clone +pgd node kaolin upgrade --old-bindir /usr/pgsql-16/bin --new-bindir /usr/pgsql-17/bin --old-datadir /var/lib/pgsql/16/data --new-datadir /var/lib/pgsql/17/data --database pgddb --username enterprisedb --clone ``` ### Upgrade the PostgreSQL version on a node with a different port number ```shell -pgd node kaolin upgrade --old-bindir /usr/pgsql-16/bin --new-bindir /usr/pgsql-17/bin --old-datadir /var/lib/pgsql/16/data --new-datadir /var/lib/pgsql/17/data --database bdrdb --username enterprisedb --old-port 5433 --new-port 5434 +pgd node kaolin upgrade --old-bindir /usr/pgsql-16/bin --new-bindir /usr/pgsql-17/bin --old-datadir /var/lib/pgsql/16/data --new-datadir /var/lib/pgsql/17/data --database pgddb --username enterprisedb --old-port 5433 --new-port 5434 ``` diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/nodes/list.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/nodes/list.mdx index 048b5601a3e..c755d57adca 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/nodes/list.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/nodes/list.mdx @@ -47,9 +47,9 @@ pgd nodes list --verbose __OUTPUT__ Node Name Group Name Node Kind Join State Node Status Node ID Snowflake SeqID Database --------- ------------ --------- ---------- ----------- ---------- --------------- -------- -kaftan dc1_subgroup data ACTIVE Up 3490219809 1 bdrdb -kaboom dc1_subgroup data ACTIVE Up 2710197610 2 bdrdb -kaolin dc1_subgroup data ACTIVE Up 2111777360 3 bdrdb +kaftan dc1_subgroup data ACTIVE Up 3490219809 1 pgddb +kaboom dc1_subgroup data ACTIVE Up 2710197610 2 pgddb +kaolin dc1_subgroup data ACTIVE Up 2111777360 3 pgddb ``` ### List all nodes version information diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/replication/show.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/replication/show.mdx index 4564a2dacf3..515d6db92a5 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/replication/show.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/replication/show.mdx @@ -69,12 +69,12 @@ kaolin * * - # Replication Slots Group Name Origin Node Target Node Slot Name Active State Write Lag Replay Lag Sent Lag Bytes Write Lag Bytes Replay Lag Bytes ------------ ----------- ----------- ------------------------------ ------ --------- --------- ---------- -------------- --------------- ---------------- -dc1_subgroup kaboom kaftan bdr_bdrdb_democluster15_kaftan t streaming 00:00:00 00:00:00 0 0 0 -dc1_subgroup kaboom kaolin bdr_bdrdb_democluster15_kaolin t streaming 00:00:00 00:00:00 0 0 0 -dc1_subgroup kaftan kaboom bdr_bdrdb_democluster15_kaboom t streaming 00:00:00 00:00:00 0 0 0 -dc1_subgroup kaftan kaolin bdr_bdrdb_democluster15_kaolin t streaming 00:00:00 00:00:00 0 0 0 -dc1_subgroup kaolin kaboom bdr_bdrdb_democluster15_kaboom t streaming 00:00:00 00:00:00 0 0 0 -dc1_subgroup kaolin kaftan bdr_bdrdb_democluster15_kaftan t streaming 00:00:00 00:00:00 0 0 0 +dc1_subgroup kaboom kaftan bdr_pgddb_democluster15_kaftan t streaming 00:00:00 00:00:00 0 0 0 +dc1_subgroup kaboom kaolin bdr_pgddb_democluster15_kaolin t streaming 00:00:00 00:00:00 0 0 0 +dc1_subgroup kaftan kaboom bdr_pgddb_democluster15_kaboom t streaming 00:00:00 00:00:00 0 0 0 +dc1_subgroup kaftan kaolin bdr_pgddb_democluster15_kaolin t streaming 00:00:00 00:00:00 0 0 0 +dc1_subgroup kaolin kaboom bdr_pgddb_democluster15_kaboom t streaming 00:00:00 00:00:00 0 0 0 +dc1_subgroup kaolin kaftan bdr_pgddb_democluster15_kaftan t streaming 00:00:00 00:00:00 0 0 0 # Subscriptions Origin Node Target Node Last Applied Tx Timestamp Last Applied Tx Age Subscription Status diff --git a/product_docs/docs/pgd/6/reference/cli/configuring_cli.mdx b/product_docs/docs/pgd/6/reference/cli/configuring_cli.mdx index a710269e222..a574aa18c6c 100644 --- a/product_docs/docs/pgd/6/reference/cli/configuring_cli.mdx +++ b/product_docs/docs/pgd/6/reference/cli/configuring_cli.mdx @@ -35,7 +35,7 @@ PGD CLI takes its database connection information from either the PGD CLI config You can pass the connection string directly to `pgd` using the `--dsn` option. For details, see the [sample use case](using_cli/#passing-a-database-connection-string). For example: ```shell -pgd --dsn "host=kaboom port=5444 user=enterprisedb dbname=bdrdb" nodes show --versions +pgd --dsn "host=kaboom port=5444 user=enterprisedb dbname=pgddb" nodes show --versions ``` ### Using a configuration file @@ -48,9 +48,9 @@ For example: cluster: name: cluster-name endpoints: - - "host=bdr-a1 port=5444 dbname=bdrdb user=enterprisedb" - - "host=bdr-b1 port=5444 dbname=bdrdb user=enterprisedb" - - "host=bdr-c1 port=5444 dbname=bdrdb user=enterprisedb" + - "host=bdr-a1 port=5444 dbname=pgddb user=enterprisedb" + - "host=bdr-b1 port=5444 dbname=pgddb user=enterprisedb" + - "host=bdr-c1 port=5444 dbname=pgddb user=enterprisedb" ``` By default, `pgd-cli-config.yml` is located in the `/etc/edb/pgd-cli` directory. The PGD CLI searches for `pgd-cli-config.yml` in the following locations. Precedence order is high to low. diff --git a/product_docs/docs/pgd/6/reference/cli/discover_connections.mdx b/product_docs/docs/pgd/6/reference/cli/discover_connections.mdx index f8f9fa6ef60..4a68198390f 100644 --- a/product_docs/docs/pgd/6/reference/cli/discover_connections.mdx +++ b/product_docs/docs/pgd/6/reference/cli/discover_connections.mdx @@ -28,7 +28,7 @@ If you are using EDB CloudNative Postgres Global Cluster (CNPG-GC), the connecti Consult your configuration file to determine this information. -Establish a host name or IP address, port, database name, and username. The default database name is `bdrdb`. The default username is enterprisedb for EDB Postgres Advanced Server and postgres for PostgreSQL and EDB Postgres Extended Server. +Establish a host name or IP address, port, database name, and username. The default database name is `pgddb`. The default username is enterprisedb for EDB Postgres Advanced Server and postgres for PostgreSQL and EDB Postgres Extended Server. You can then assemble a connection string based on that information: diff --git a/product_docs/docs/pgd/6/reference/cli/using_cli.mdx b/product_docs/docs/pgd/6/reference/cli/using_cli.mdx index a17d624a48b..86104f73be0 100644 --- a/product_docs/docs/pgd/6/reference/cli/using_cli.mdx +++ b/product_docs/docs/pgd/6/reference/cli/using_cli.mdx @@ -27,7 +27,7 @@ Once you have [installed pgd-cli](installing), run the `pgd` command to access t Use the `--dsn` flag to pass a database connection string to the `pgd` command. When you pass the connection string with the `--dsn` flag, you don't need a configuration file. The flag takes precedence even if a configuration file is present. For example: ```sh -pgd nodes list --dsn "host=bdr-a1 port=5432 dbname=bdrdb user=enterprisedb" +pgd nodes list --dsn "host=bdr-a1 port=5432 dbname=pgddb user=enterprisedb" ``` See [PGD CLI Command reference](/pgd/latest/cli/command_ref/) for a description of the command options. @@ -63,7 +63,7 @@ pgd nodes list -o json "node_status": "Up", "node_id": 3490219809, "node_seq_id": 2, - "node_local_dbname": "bdrdb" + "node_local_dbname": "pgddb" }, { "node_name": "kaolin", @@ -73,7 +73,7 @@ pgd nodes list -o json "node_status": "Up", "node_id": 2111777360, "node_seq_id": 1, - "node_local_dbname": "bdrdb" + "node_local_dbname": "pgddb" }, { "node_name": "kaboom", @@ -83,7 +83,7 @@ pgd nodes list -o json "node_status": "Up", "node_id": 2710197610, "node_seq_id": 3, - "node_local_dbname": "bdrdb" + "node_local_dbname": "pgddb" } ] ``` diff --git a/product_docs/docs/pgd/6/reference/conflict-management/conflicts/00_conflicts_overview.mdx b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/00_conflicts_overview.mdx index 5af82599291..cf518c9bd86 100644 --- a/product_docs/docs/pgd/6/reference/conflict-management/conflicts/00_conflicts_overview.mdx +++ b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/00_conflicts_overview.mdx @@ -11,7 +11,7 @@ PGD to provide the application with a range of choices for how to resolve confli By default, conflicts are resolved at the row level. When changes from two nodes conflict, PGD picks either the local or remote tuple and the discards the other. For example, the commit timestamps might be compared for the two conflicting changes and the newer one kept. This approach ensures that all nodes converge to the same result and establishes commit-order-like semantics on the whole cluster. -Conflict handling is configurable, as described in [Conflict resolution](04_conflict_resolution). PGD can detect conflicts and handle them differently for each table using conflict triggers, described in [Stream triggers](../../striggers). +Conflict handling is configurable, as described in [Conflict resolution](04_conflict_resolution). PGD can detect conflicts and handle them differently for each table using conflict triggers, described in [Stream triggers](../../stream-triggers). Column-level conflict detection and resolution is available with PGD, as described in [CLCD](../column-level-conflicts). diff --git a/product_docs/docs/pgd/6/reference/ddl/ddl-role-manipulation.mdx b/product_docs/docs/pgd/6/reference/ddl/ddl-role-manipulation.mdx index 15b2c9a7f8a..db920735c45 100644 --- a/product_docs/docs/pgd/6/reference/ddl/ddl-role-manipulation.mdx +++ b/product_docs/docs/pgd/6/reference/ddl/ddl-role-manipulation.mdx @@ -50,6 +50,6 @@ stalls with an error until the role is created on the other nodes. !!! Note PGD with non-PGD-enabled databases PGD doesn't capture and replicate role management statements when they run on a non-PGD-enabled database in a PGD-enabled PostgreSQL instance. - For example, suppose you have databases `bdrdb` (bdr group member) and `postgres` (bare db), - and `bdr.role_replication = on`. A `CREATE USER` run in `bdrdb` is + For example, suppose you have databases `pgddb` (bdr group member) and `postgres` (bare db), + and `bdr.role_replication = on`. A `CREATE USER` run in `pgddb` is replicated, but a `CREATE USER` run in `postgres` isn't. diff --git a/product_docs/docs/pgd/6/reference/index.mdx b/product_docs/docs/pgd/6/reference/index.mdx index c2b045d215e..1ab523e0290 100644 --- a/product_docs/docs/pgd/6/reference/index.mdx +++ b/product_docs/docs/pgd/6/reference/index.mdx @@ -55,13 +55,13 @@ The PGD Reference section provides detailed information about PGD's features. * [Application Usage](/pgd/latest/reference/appusage) Guidance for developers wanting to use PGD's advanced functionality in their applications. * [DDL](/pgd/latest/reference/ddl) -* [Decoding Worker](/pgd/latest/reference/decoding-worker) +* [Decoding Worker](/pgd/latest/reference/decoding_worker) * [CDC Failover](/pgd/latest/reference/cdc-failover) * [Parallel Apply](/pgd/latest/reference/parallelapply) * [Replication Sets](/pgd/latest/reference/repsets) * [Security](/pgd/latest/reference/security) * [Sequences](/pgd/latest/reference/sequences) -* [Triggers](/pgd/latest/reference/triggers) +* [Stream Triggers](/pgd/latest/reference/stream-triggers) * [Transaction Streaming](/pgd/latest/reference/transaction-streaming) * [TSSnapshots](/pgd/latest/reference/tssnapshots) * [Two-Phase Commit](/pgd/latest/reference/twophase) diff --git a/product_docs/docs/pgd/6/reference/monitoring/sql.mdx b/product_docs/docs/pgd/6/reference/monitoring/sql.mdx index 85824c53184..82c7119615b 100644 --- a/product_docs/docs/pgd/6/reference/monitoring/sql.mdx +++ b/product_docs/docs/pgd/6/reference/monitoring/sql.mdx @@ -529,7 +529,7 @@ The view [`bdr.group_versions_details`](/pgd/latest/reference/tables-views-funct nodes at the same time. For example: ```sql -bdrdb=# SELECT node_name, postgres_version, bdr_version +pgddb=# SELECT node_name, postgres_version, bdr_version FROM bdr.group_versions_details; node_name | postgres_version | bdr_version -----------+------------------+------------- @@ -555,7 +555,7 @@ information returned from the view `bdr.group_version_details` to provide a cluster-wide version check. For example: ```sql -bdrdb=# SELECT * FROM bdr.monitor_group_versions(); +pgddb=# SELECT * FROM bdr.monitor_group_versions(); status | message --------+----------------------------------------- OK | All nodes are running same BDR versions @@ -582,7 +582,7 @@ The view [`bdr.group_raft_details`](/pgd/latest/reference/tables-views-functions consensus status from all nodes at the same time. For example: ```sql -bdrdb=# SELECT node_id, node_name, state, leader_id +pgddb=# SELECT node_id, node_name, state, leader_id FROM bdr.group_raft_details; node_id | node_name | node_group_name | state | leader_id ------------+-----------+-----------------+---------------+------------ @@ -649,7 +649,7 @@ information returned from the view [`bdr.group_raft_details`](/pgd/latest/refere to provide a cluster-wide Raft check. For example: ```sql -bdrdb=# SELECT * FROM bdr.monitor_group_raft(); +pgddb=# SELECT * FROM bdr.monitor_group_raft(); node_group_name | status | message ----------------|--------+------------------------------------- mygroup | OK | Raft Consensus is working correctly @@ -667,14 +667,14 @@ Each PGD node keeps: For example: ```sql -bdrdb=# SELECT slot_name, database, active, confirmed_flush_lsn +pgddb=# SELECT slot_name, database, active, confirmed_flush_lsn FROM pg_replication_slots ORDER BY slot_name; slot_name | database | active | confirmed_flush_lsn --------------------------+----------+--------+--------------------- - bdr_bdrdb_bdrgroup | bdrdb | f | 0/3110A08 - bdr_bdrdb_bdrgroup_node2 | bdrdb | t | 0/31F4670 - bdr_bdrdb_bdrgroup_node3 | bdrdb | t | 0/31F4670 - bdr_bdrdb_bdrgroup_node4 | bdrdb | t | 0/31F4670 + bdr_pgddb_bdrgroup | pgddb | f | 0/3110A08 + bdr_pgddb_bdrgroup_node2 | pgddb | t | 0/31F4670 + bdr_pgddb_bdrgroup_node3 | pgddb | t | 0/31F4670 + bdr_pgddb_bdrgroup_node4 | pgddb | t | 0/31F4670 ``` Peer slot names follow the convention `bdr___`, @@ -701,7 +701,7 @@ The function [`bdr.monitor_local_replslots()`](/pgd/latest/reference/tables-view PGD node replication slots are working as expected. This summary is also available on subscriber-only nodes that are operating as subscriber-only group leaders in a PGD cluster when [optimized topology](/pgd/latest/reference/nodes/subscriber_only/optimizing-so) is enabled. For example: ```sql -bdrdb=# SELECT * FROM bdr.monitor_local_replslots(); +pgddb=# SELECT * FROM bdr.monitor_local_replslots(); status | message --------+------------------------------------------------- OK | All BDR replication slots are working correctly diff --git a/product_docs/docs/pgd/6/reference/node_management/creating_nodes.mdx b/product_docs/docs/pgd/6/reference/node_management/creating_nodes.mdx index 10c089a079f..75c5fb505c1 100644 --- a/product_docs/docs/pgd/6/reference/node_management/creating_nodes.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/creating_nodes.mdx @@ -16,11 +16,11 @@ PGD is built on top of Postgres, so the distribution and version of Postgres you ## Installing Postgres -You must install your selected Postgres distribution on each node you are configuring. You can find installation instructions for each distribution in the [EDB Postgres Advanced Server documentation](/epas/latest/installing/), [EDB Postgres Extended Server documentation](/pge/latest/installing/), and the [Postgres installation documentation](/supported-open-source/postgresql/installing/). You can also refer to the [PGD manual installation guide](../deploy-config/deploy-manual/deploying/02-install-postgres) which covers the installation of Postgres. +You must install your selected Postgres distribution on each node you are configuring. You can find installation instructions for each distribution in the [EDB Postgres Advanced Server documentation](/epas/latest/installing/), [EDB Postgres Extended Server documentation](/pge/latest/installing/), and the [Postgres installation documentation](/supported-open-source/postgresql/installing/). You can also refer to the [PGD manual installation guide](/pgd/latest/essential-how-to/install/03-installing-database-and-pgd) which covers the installation of Postgres. ## Installing the BDR extension -The BDR extension is the key to PGD's distributed architecture. You need to install the BDR extension on each node in your PGD cluster. The BDR extension is available from the EDB Postgres Distributed repository. You need to add the `postgres_distributed` repository to your package management system on Linux and then install the `edb-bdr` package. You can find the repository configuration instructions in the [PGD manual installation guide](/pgd/latest/essential-how-to/install/02-configuring-repositories). +The BDR extension is the key to PGD's distributed architecture. You need to install the BDR extension on each node in your PGD cluster. The BDR extension is available from the EDB Postgres Distributed repository. You need to add the `postgres_distributed` repository to your package management system on Linux and then install the `edb-bdr` package. You can find the repository configuration instructions in the [PGD manual installation guide](/pgd/latest/essential-how-to/install/02-configure-repositories). Once the repository is configured, you can install the BDR package with your package manager. The package name is `edb-pgd6-` where `` is the version of Postgres you are using. For example, if you are using Postgres 14, the package name is `edb-pgd6-14`. @@ -58,7 +58,7 @@ This command creates the BDR extension. You also need to create a database within Postgres to use as PGD's replicated database. You can do this with the `CREATE DATABASE` command. -The created database should be the name of the database that other nodes in the PGD cluster replicate. The convention is to name the database `bdrdb`. +The created database should be the name of the database that other nodes in the PGD cluster replicate. The convention is to name the database `pgddb`. ## Next steps diff --git a/product_docs/docs/pgd/6/reference/node_management/node_uuids.mdx b/product_docs/docs/pgd/6/reference/node_management/node_uuids.mdx index 9281f75325a..168e3d34f47 100644 --- a/product_docs/docs/pgd/6/reference/node_management/node_uuids.mdx +++ b/product_docs/docs/pgd/6/reference/node_management/node_uuids.mdx @@ -28,4 +28,4 @@ If a node is removed from the cluster and a replacement node is added, the repla ### UUID related changes in PGD 6 * The `generation` field in the `bdr.node` table, which was previously used to differentiate between nodes is no longer used. It will remain at 0 for all nodes. -* the `node_uuid` field in the `bdr.node` table is will never be null on PGD6. It may be null in the future with a mixed version cluster. +* the `node_uuid` field in the `bdr.node` table will never be null on PGD6. It may be null in the future with a mixed version cluster. diff --git a/product_docs/docs/pgd/6/reference/nodes/subscriber_only/creating-so.mdx b/product_docs/docs/pgd/6/reference/nodes/subscriber_only/creating-so.mdx index b95a5b31985..3ae7adefc24 100644 --- a/product_docs/docs/pgd/6/reference/nodes/subscriber_only/creating-so.mdx +++ b/product_docs/docs/pgd/6/reference/nodes/subscriber_only/creating-so.mdx @@ -33,19 +33,19 @@ You can now initialize a new data node and then add it to the Subscriber-only gr You now have to create this new node as a `subscriber-only` node. To do this, log into the new node and run the following SQL command: ```sql -select bdr.create_node('so-node-1', 'host=so-host-1 dbname=bdrdb port=5444', 'subscriber-only'); +select bdr.create_node('so-node-1', 'host=so-host-1 dbname=pgddb port=5444', 'subscriber-only'); ``` Then, log into that new node and add it to the `sogroup` group with the following SQL command: ```sql - select bdr.join_node_group('host=host-one dbname=bdrdb port=5444','sogroup'); + select bdr.join_node_group('host=host-one dbname=pgddb port=5444','sogroup'); ``` or more explicitly with parameter names: ```sql -select bdr.join_node_group(dsn:='host=host-one dbname=bdrdb port=5444', +select bdr.join_node_group(dsn:='host=host-one dbname=pgddb port=5444', node_group_name:='sogroup'); ``` diff --git a/product_docs/docs/pgd/6/reference/nodes/subscriber_only/joining-so.mdx b/product_docs/docs/pgd/6/reference/nodes/subscriber_only/joining-so.mdx index fec659840e7..c1bd0be593c 100644 --- a/product_docs/docs/pgd/6/reference/nodes/subscriber_only/joining-so.mdx +++ b/product_docs/docs/pgd/6/reference/nodes/subscriber_only/joining-so.mdx @@ -13,14 +13,14 @@ Unlike joining a node to a [new subscriber-only group](creating-so), joining a n First create the new node as a subscriber-only node. Run the following SQL command on the new node: ```sql -select bdr.create_node('so-node-2', 'host=so-host-2 dbname=bdrdb port=5444', 'subscriber-only'); +select bdr.create_node('so-node-2', 'host=so-host-2 dbname=pgddb port=5444', 'subscriber-only'); ``` or more explicitly with parameter names: ```sql select bdr.create_node(node_name:='so-node-2', - dsn:='host=so-host-2 dbname=bdrdb port=5444', + dsn:='host=so-host-2 dbname=pgddb port=5444', node_type:='subscriber-only'); ``` @@ -35,13 +35,13 @@ In the [creating](creating-so) examples, they use `host-one` in the cluster's da You can use the following SQL command on `shost-2` to join it to the `sogroup` group: ```sql -select bdr.join_node_group('host=host-one dbname=bdrdb port=5444','sogroup'); +select bdr.join_node_group('host=host-one dbname=pgddb port=5444','sogroup'); ``` or more explicitly with parameter names: ```sql -select bdr.join_node_group(dsn:='host=host-one dbname=bdrdb port=5444', +select bdr.join_node_group(dsn:='host=host-one dbname=pgddb port=5444', node_group_name:='sogroup'); ``` diff --git a/product_docs/docs/pgd/6/reference/parallelapply.mdx b/product_docs/docs/pgd/6/reference/parallelapply.mdx index 8b6c48505a0..2278d03c20e 100644 --- a/product_docs/docs/pgd/6/reference/parallelapply.mdx +++ b/product_docs/docs/pgd/6/reference/parallelapply.mdx @@ -42,16 +42,16 @@ for a specific subscription without a restart by: First though, establish the name of the subscription using `select * from bdr.subscription`. For this example, the subscription name is -`bdr_bdrdb_bdrgroup_node2_node1`. +`bdr_pgddb_bdrgroup_node2_node1`. ```sql -SELECT bdr.alter_subscription_disable ('bdr_bdrdb_bdrgroup_node2_node1'); +SELECT bdr.alter_subscription_disable ('bdr_pgddb_bdrgroup_node2_node1'); UPDATE bdr.subscription SET num_writers = 4 -WHERE sub_name = 'bdr_bdrdb_bdrgroup_node2_node1'; +WHERE sub_name = 'bdr_pgddb_bdrgroup_node2_node1'; -SELECT bdr.alter_subscription_enable ('bdr_bdrdb_bdrgroup_node2_node1'); +SELECT bdr.alter_subscription_enable ('bdr_pgddb_bdrgroup_node2_node1'); ``` ### When to use Parallel Apply diff --git a/product_docs/docs/pgd/6/reference/striggers.mdx b/product_docs/docs/pgd/6/reference/stream-triggers.mdx similarity index 100% rename from product_docs/docs/pgd/6/reference/striggers.mdx rename to product_docs/docs/pgd/6/reference/stream-triggers.mdx diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/conflicts.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/conflicts.mdx index 238db9fa88f..989318d693b 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/conflicts.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/conflicts.mdx @@ -53,7 +53,7 @@ Several conflict resolvers are available in PGD, with differing coverages of the The `insert_exists`, `update_differing`, `update_origin_change`, `update_missing`, `multiple_unique_conflicts`, `update_recently_deleted`, `update_pkey_exists`, `delete_recently_updated`, and `delete_missing` conflict types can also be resolved by user-defined logic using -[Conflict triggers](../striggers). +[Conflict triggers](../stream-triggers). This matrix shows the conflict types each conflict resolver can handle. diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx index d60563c275f..a8afc3703b8 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/functions.mdx @@ -507,7 +507,7 @@ This query returns something like this on a two-node cluster: ``` [ { - "dsn": "host=node1 port=5432 dbname=bdrdb user=postgres ", + "dsn": "host=node1 port=5432 dbname=pgddb user=postgres ", "node_id": "2232128708", "response": { "command_status": "SELECT 1", @@ -515,7 +515,7 @@ This query returns something like this on a two-node cluster: { "origin_name": "node1", "target_name": "node2", - "local_slot_name": "bdr_bdrdb_bdrgroup_node2", + "local_slot_name": "bdr_pgddb_bdrgroup_node2", "replay_lag_size": "0 bytes" } ] @@ -523,7 +523,7 @@ This query returns something like this on a two-node cluster: "node_name": "node1" }, { - "dsn": "host=node2 port=5432 dbname=bdrdb user=postgres ", + "dsn": "host=node2 port=5432 dbname=pgddb user=postgres ", "node_id": "2058684375", "response": { "command_status": "SELECT 1", @@ -531,7 +531,7 @@ This query returns something like this on a two-node cluster: { "origin_name": "node2", "target_name": "node1", - "local_slot_name": "bdr_bdrdb_bdrgroup_node1", + "local_slot_name": "bdr_pgddb_bdrgroup_node1", "replay_lag_size": "0 bytes" } ] @@ -694,10 +694,10 @@ Returns the name of the group slot on the local node. #### Example ```sql -bdrdb=# SELECT bdr.local_group_slot_name(); +pgddb=# SELECT bdr.local_group_slot_name(); local_group_slot_name ----------------------- - bdr_bdrdb_bdrgroup + bdr_pgddb_bdrgroup ``` ### `bdr.node_group_type` @@ -710,7 +710,7 @@ when the group was created. #### Example ```sql -bdrdb=# SELECT bdr.node_group_type('bdrgroup'); +pgddb=# SELECT bdr.node_group_type('bdrgroup'); node_group_type ----------------- global diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/streamtriggers/index.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/streamtriggers/index.mdx index 304689b5811..515396ce578 100644 --- a/product_docs/docs/pgd/6/reference/tables-views-functions/streamtriggers/index.mdx +++ b/product_docs/docs/pgd/6/reference/tables-views-functions/streamtriggers/index.mdx @@ -8,10 +8,10 @@ navigation: --- !!! SeeAlso -[Stream Triggers](/pgd/latest/reference/striggers) for an introduction to Stream Triggers. +[Stream Triggers](/pgd/latest/reference/stream-triggers) for an introduction to Stream Triggers. !!! -Both [conflict triggers](/pgd/latest/reference/striggers/#conflict-triggers) and [transform triggers](/pgd/latest/reference/striggers/#transform-triggers) have access to information about +Both [conflict triggers](/pgd/latest/reference/stream-triggers/#conflict-triggers) and [transform triggers](/pgd/latest/reference/stream-triggers/#transform-triggers) have access to information about rows and metadata by way of the predefined variables provided by the trigger API and additional information functions provided by PGD. diff --git a/product_docs/docs/pgd/6/reference/upgrade.mdx b/product_docs/docs/pgd/6/reference/upgrade.mdx index 78c2cb15483..031d979c2d9 100644 --- a/product_docs/docs/pgd/6/reference/upgrade.mdx +++ b/product_docs/docs/pgd/6/reference/upgrade.mdx @@ -1,8 +1,6 @@ --- title: Upgrading navTitle: Upgrades -redirects: - - /pgd/latest/upgrades --- ## Upgrading to EDB Postgres Distributed 6 diff --git a/product_docs/docs/pgd/6/rel_notes/index.mdx b/product_docs/docs/pgd/6/rel_notes/index.mdx index 810b7015e9e..1875b0dec17 100644 --- a/product_docs/docs/pgd/6/rel_notes/index.mdx +++ b/product_docs/docs/pgd/6/rel_notes/index.mdx @@ -4,7 +4,7 @@ navTitle: Release notes description: Release notes for EDB Postgres Distributed 6 and later indexCards: none navigation: - - pgd_6.0.0_rel_notes + - pgd_6.0.1_rel_notes originalFilePath: product_docs/docs/pgd/6/rel_notes/src/meta.yml editTarget: originalFilePath --- @@ -15,4 +15,4 @@ The EDB Postgres Distributed documentation describes the latest version of EDB P | Release Date | EDB Postgres Distributed | |---|---| -| 22 May 2025 | [6.0.0](./pgd_6.0.0_rel_notes) | +| 02 Jun 2025 | [6.0.1](./pgd_6.0.1_rel_notes) | diff --git a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.1_rel_notes.mdx similarity index 99% rename from product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx rename to product_docs/docs/pgd/6/rel_notes/pgd_6.0.1_rel_notes.mdx index a29882fa2d9..286e48ba6b8 100644 --- a/product_docs/docs/pgd/6/rel_notes/pgd_6.0.0_rel_notes.mdx +++ b/product_docs/docs/pgd/6/rel_notes/pgd_6.0.1_rel_notes.mdx @@ -1,13 +1,13 @@ --- -title: EDB Postgres Distributed 6.0.0 release notes -navTitle: Version 6.0.0 -originalFilePath: product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml +title: EDB Postgres Distributed 6.0.1 release notes +navTitle: Version 6.0.1 +originalFilePath: product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.1.yml editTarget: originalFilePath --- -Released: 22 May 2025 +Released: 2 June 2025 -EDB Postgres Distributed 6.0.0 is a major update to PGD and sees the introduction on Essential and Extended editions. +EDB Postgres Distributed 6.0.1 is a major update to PGD and sees the introduction on Essential and Extended editions. ## Highlights diff --git a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.1.yml similarity index 99% rename from product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml rename to product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.1.yml index 96b744a2188..3140d542fc3 100644 --- a/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.0.yml +++ b/product_docs/docs/pgd/6/rel_notes/src/relnote_6.0.1.yml @@ -1,9 +1,9 @@ # yaml-language-server: $schema=https://raw.githubusercontent.com/EnterpriseDB/docs/refs/heads/develop/tools/automation/generators/relgen/relnote-schema.json product: EDB Postgres Distributed -version: 6.0.0 -date: 22 May 2025 +version: 6.0.1 +date: 2 June 2025 intro: | - EDB Postgres Distributed 6.0.0 is a major update to PGD and sees the introduction on Essential and Extended editions. + EDB Postgres Distributed 6.0.1 is a major update to PGD and sees the introduction on Essential and Extended editions. highlights: | - New built-in Connection Manager. - New CLI command for cluster setup. From c46635b5b3150bf97431f6dc21d0c1c2fb30f73e Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Thu, 29 May 2025 14:01:53 +0100 Subject: [PATCH 095/145] Fix for missing option in node upgrade Signed-off-by: Dj Walker-Morgan --- .../cli/command_ref/node/upgrade.mdx | 38 +++++++++---------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/node/upgrade.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/node/upgrade.mdx index f856a2011d5..dd44b15f4a7 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/node/upgrade.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/node/upgrade.mdx @@ -20,26 +20,26 @@ Where `` is the name of the node which you want to upgrade and ` Date: Thu, 29 May 2025 16:47:26 +0100 Subject: [PATCH 096/145] fix index version Signed-off-by: Dj Walker-Morgan --- product_docs/docs/pgd/6/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/6/index.mdx b/product_docs/docs/pgd/6/index.mdx index c59273b934e..0e3fd31fb38 100644 --- a/product_docs/docs/pgd/6/index.mdx +++ b/product_docs/docs/pgd/6/index.mdx @@ -25,7 +25,7 @@ categories: - /edb-postgres-ai/platforms-and-tools/high-availability/ pdf: true directoryDefaults: - version: "6.0.0" + version: "6.0.1" --- Welcome to the PGD 6.0 documentation. PGD 6.0 is now available in two editions, Essential and Expanded. From 3b85825c90359ee7b23f1b2c581ae09888048bf1 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Fri, 30 May 2025 12:50:30 +0100 Subject: [PATCH 097/145] Build out SOPs, autopartition work, tidy configs Signed-off-by: Dj Walker-Morgan --- .../pgd/6/essential-how-to/autopartition.mdx | 20 +++++ .../production-best-practices/index.mdx | 12 ++- .../production-best-practices/security.mdx | 5 ++ .../sops/backup-restore/barman.mdx | 33 +++++++ .../sops/backup-restore/index.mdx | 14 +++ .../sops/backup-restore/pg_dump.mdx | 33 +++++++ .../pgd/6/essential-how-to/sops/configure.mdx | 5 -- .../sops/data-movement/index.mdx | 14 +++ .../sops/data-movement/move-in.mdx | 33 +++++++ .../sops/data-movement/move-out.mdx | 33 +++++++ .../pgd/6/essential-how-to/sops/index.mdx | 31 ++++++- .../pgd/6/essential-how-to/sops/install.mdx | 8 -- .../sops/install/add-node.mdx | 33 +++++++ .../6/essential-how-to/sops/install/index.mdx | 15 ++++ .../sops/install/new-group.mdx | 33 +++++++ .../sops/install/new-node.mdx | 33 +++++++ .../sops/maintenence/index.mdx | 17 ++++ .../sops/maintenence/node-failures.mdx | 33 +++++++ .../sops/maintenence/online-vacuum.mdx | 33 +++++++ .../sops/maintenence/routine.mdx | 33 +++++++ .../6/essential-how-to/sops/monitoring.mdx | 7 -- .../sops/monitoring/index.mdx | 10 +++ .../essential-how-to/sops/monitoring/sql.mdx | 33 +++++++ .../pgd/6/essential-how-to/sops/template.txt | 33 +++++++ .../essential-how-to/sops/troubleshooting.mdx | 5 -- .../troubleshooting/cluster-operations.mdx | 33 +++++++ .../sops/troubleshooting/index.mdx | 10 +++ .../pgd/6/essential-how-to/sops/upgrade.mdx | 16 ---- .../6/essential-how-to/sops/upgrade/index.mdx | 19 ++++ .../6/essential-how-to/sops/upgrade/major.mdx | 33 +++++++ .../6/essential-how-to/sops/upgrade/minor.mdx | 33 +++++++ .../6/essential-how-to/sops/upgrade/pgd.mdx | 33 +++++++ .../install/04-configuring-cluster.mdx | 87 ++++++++++--------- .../sops/backup-restore/barman.mdx | 33 +++++++ .../sops/backup-restore/index.mdx | 14 +++ .../sops/backup-restore/pg_dump.mdx | 33 +++++++ .../sops/data-movement/index.mdx | 14 +++ .../sops/data-movement/move-in.mdx | 33 +++++++ .../sops/data-movement/move-out.mdx | 33 +++++++ .../expanded-how-to/sops/how-to-use-sops.mdx | 24 +++++ .../docs/pgd/6/expanded-how-to/sops/index.mdx | 49 +++++++++++ .../expanded-how-to/sops/install/add-node.mdx | 33 +++++++ .../6/expanded-how-to/sops/install/index.mdx | 15 ++++ .../sops/install/new-group.mdx | 33 +++++++ .../expanded-how-to/sops/install/new-node.mdx | 33 +++++++ .../sops/maintenence/index.mdx | 17 ++++ .../sops/maintenence/node-failures.mdx | 33 +++++++ .../sops/maintenence/online-vacuum.mdx | 33 +++++++ .../sops/maintenence/routine.mdx | 33 +++++++ .../expanded-how-to/sops/monitoring/index.mdx | 10 +++ .../6/expanded-how-to/sops/monitoring/sql.mdx | 33 +++++++ .../pgd/6/expanded-how-to/sops/template.txt | 33 +++++++ .../troubleshooting/cluster-operations.mdx | 33 +++++++ .../sops/troubleshooting/index.mdx | 10 +++ .../6/expanded-how-to/sops/upgrade/index.mdx | 19 ++++ .../6/expanded-how-to/sops/upgrade/major.mdx | 33 +++++++ .../6/expanded-how-to/sops/upgrade/minor.mdx | 33 +++++++ .../6/expanded-how-to/sops/upgrade/pgd.mdx | 33 +++++++ .../pgd/6/get-started/essential-standard.mdx | 2 +- .../sops => reference}/backup-restore.mdx | 0 .../cli/command_ref/group/get-option.mdx | 1 - .../cli/command_ref/group/set-option.mdx | 1 - product_docs/docs/pgd/6/reference/index.mdx | 1 + .../pgd/6/reference/nodes/witness_nodes.mdx | 3 +- 64 files changed, 1441 insertions(+), 90 deletions(-) create mode 100644 product_docs/docs/pgd/6/essential-how-to/production-best-practices/security.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/backup-restore/barman.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/backup-restore/index.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/backup-restore/pg_dump.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/configure.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/data-movement/index.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/data-movement/move-in.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/data-movement/move-out.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/install.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/install/add-node.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/install/index.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/install/new-group.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/install/new-node.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/maintenence/index.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/maintenence/node-failures.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/maintenence/online-vacuum.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/maintenence/routine.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/monitoring.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/monitoring/index.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/monitoring/sql.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/template.txt delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/troubleshooting.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/troubleshooting/cluster-operations.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/troubleshooting/index.mdx delete mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/upgrade.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/upgrade/index.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/upgrade/major.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/upgrade/minor.mdx create mode 100644 product_docs/docs/pgd/6/essential-how-to/sops/upgrade/pgd.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/backup-restore/barman.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/backup-restore/index.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/backup-restore/pg_dump.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/data-movement/index.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/data-movement/move-in.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/data-movement/move-out.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/how-to-use-sops.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/index.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/install/add-node.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/install/index.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/install/new-group.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/install/new-node.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/index.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/node-failures.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/online-vacuum.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/routine.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/monitoring/index.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/monitoring/sql.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/template.txt create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/troubleshooting/cluster-operations.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/troubleshooting/index.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/index.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/major.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/minor.mdx create mode 100644 product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/pgd.mdx rename product_docs/docs/pgd/6/{essential-how-to/sops => reference}/backup-restore.mdx (100%) diff --git a/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx b/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx index 75a36c3d95d..40b2b089ebe 100644 --- a/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/autopartition.mdx @@ -4,3 +4,23 @@ navTitle: Auto Partitioning description: A guide on how to use auto partitioning in PGD Essential. --- +Autopartitioning in PGD allows you to split tables automatically into several partitions, other tables, automatically creating and dropping those partitions are needed. Autopartitioning is useful for managing large tables that grow over time as it allows you to separate the data into manageable chunks. For example, you could archive older data into its own partition, and then archive, or drop the partition when the data is no longer needed. + +### Autopartitioning and replication + +PGD autopartitioning is managed, by default, locally through the `bdr.autopartition` functions. This function allows you to create or alter the definition of automatic range partitioning for a table. If no definition exists, it will create one; otherwise, it will alter the existing definition. + +!!! Note EPAS automatic partitioning is not supported in PGD +EDB Postgres Advanced Server (EPAS) has native automatic partitioning support, but this is not available in EDB Postgres Distributed (PGD). PGD autopartitioning is a separate feature that allows you to manage partitions locally. If PGD is active on an EPAS node, native automatic partitioning commands are rejected. See [Autoparition Reference](/pgd/latest/reference/autopartition) for more information. +!!! + +### RANGE partitioning + +PGD autopartitioning support RANGE partitioning. RANGE partitioning allows you to partition a table based on a range of values in a column. For example, you could partition a table by date, where each partition contains data for a specific date range. This is useful for managing large tables that grow over time, as it allows you to separate the data into manageable chunks. + + + +## Enabling PGD Autopartitioning + + + diff --git a/product_docs/docs/pgd/6/essential-how-to/production-best-practices/index.mdx b/product_docs/docs/pgd/6/essential-how-to/production-best-practices/index.mdx index ab1dfb9cbe4..a6cf4b372bb 100644 --- a/product_docs/docs/pgd/6/essential-how-to/production-best-practices/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/production-best-practices/index.mdx @@ -1,5 +1,15 @@ --- title: Production Best Practices -navTitle: Production Best Practices +navTitle: Best Practice +navigation: +- sizing +- time-and-pgd +- security --- +There are a number of best practices to follow when deploying Postgres Distributed (PGD) in production. These practices help ensure the reliability, performance, and security of your PGD clusters. This section outlines some of the key best practices to consider when deploying PGD in a production environment. + +* [Sizing and Scaling PGD Clusters](/pgd/latest/essential-how-to/production-best-practices/sizing) +* [Time and PGD Clusters](/pgd/latest/essential-how-to/production-best-practices/time-and-pgd) +* [Security Best Practices](/pgd/latest/essential-how-to/production-best-practices/security) + diff --git a/product_docs/docs/pgd/6/essential-how-to/production-best-practices/security.mdx b/product_docs/docs/pgd/6/essential-how-to/production-best-practices/security.mdx new file mode 100644 index 00000000000..e86a0aec45e --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/production-best-practices/security.mdx @@ -0,0 +1,5 @@ +--- +title: Security Best Practices +navTitle: Security +--- + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/backup-restore/barman.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/backup-restore/barman.mdx new file mode 100644 index 00000000000..97648a22836 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/backup-restore/barman.mdx @@ -0,0 +1,33 @@ +--- +title: Backup and Restore with Barman +navTitle: Barman +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/backup-restore/index.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/backup-restore/index.mdx new file mode 100644 index 00000000000..ca7519b56d6 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/backup-restore/index.mdx @@ -0,0 +1,14 @@ +--- +title: Backup and Restore SOPs +navTitle: Backup and Restore +navigation: +- pg_dump +- barman +--- +The SOPs in this section cover the process of backing up and restoring the Postgres database servers running on the nodes in a PGD cluster. It includes best practices for backup and restore, tools to use, and common issues that may arise during the backup and restore process. + +## SOPs + +- [Backup and Restore with pg_dump](/pgd/latest/essential-how-to/sops/backup-restore/pg_dump) +- [Backup and Restore with Barman](/pgd/latest/essential-how-to/sops/backup-restore/barman) + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/backup-restore/pg_dump.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/backup-restore/pg_dump.mdx new file mode 100644 index 00000000000..9307ca21037 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/backup-restore/pg_dump.mdx @@ -0,0 +1,33 @@ +--- +title: Backup and Restore with pg_dump +navTitle: pg_dump +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/configure.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/configure.mdx deleted file mode 100644 index 5a17d905b45..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sops/configure.mdx +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Configuration SOPs -navTitle: Configuration ---- - diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/data-movement/index.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/data-movement/index.mdx new file mode 100644 index 00000000000..3b9f315a9c3 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/data-movement/index.mdx @@ -0,0 +1,14 @@ +--- +title: Data Movement SOPs +navTitle: Data Movement +navigation: +- move-in +- move-out +--- + +This section covers how to move data in and out of a Postgres Distributed cluster as efficiently as possible. + +## SOPs + +- [Moving Data into a PGD Cluster](/pgd/latest/essential-how-to/sops/data-movement/move-in) +- [Moving Data out of a PGD Cluster](/pgd/latest/essential-how-to/sops/data-movement/move-out) diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/data-movement/move-in.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/data-movement/move-in.mdx new file mode 100644 index 00000000000..ca81d71a097 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/data-movement/move-in.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Moving Data into the Cluster +navTitle: Move In +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/data-movement/move-out.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/data-movement/move-out.mdx new file mode 100644 index 00000000000..498bce0fc32 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/data-movement/move-out.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Moving Data Out of the Cluster +navTitle: Move Out +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/index.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/index.mdx index cfb898f49b6..91839d4fb49 100644 --- a/product_docs/docs/pgd/6/essential-how-to/sops/index.mdx +++ b/product_docs/docs/pgd/6/essential-how-to/sops/index.mdx @@ -4,7 +4,8 @@ navTitle: Essential Standard Operating Procedures navigation: - how-to-use-sops - install -- configure +- data-movement +- monitoring - backup-restore - upgrade - monitoring @@ -15,10 +16,34 @@ navigation: Standard Operating Procedures (SOPs) are a set of procedures that are essential for the successful operation of EDB Postgres Distributed (PGD). These procedures cover various aspects of the system, including installation, configuration, backup and restore, upgrades, monitoring, and troubleshooting. +SOPs are designed to address the most common tasks around using and maintaining a PGD cluster. They provide a structured approach to performing these tasks, ensuring consistency and reliability in operations. Read more about the structure of SOPs in the [How to Use SOPs](/pgd/latest/essential-how-to/sops/how-to-use-sops). + This document provides an overview of the SOPs and links to detailed instructions for each procedure. +## [Installation and Configuration](/pgd/latest/essential-how-to/sops/install) + +The SOPs in this section cover the procedures for installing PGD, creating a new PGD cluster, adding a node to an existing cluster, and configuring PGD. + +## [Data Movement](/pgd/latest/essential-how-to/sops/data-movement) + +The SOPs in this section cover the procedures for moving data into or out of a PGD cluster. This include importing and exporting data efficiently. + +## [Monitoring](/pgd/latest/essential-how-to/sops/monitoring) + +The SOPs in this section cover the procedures for monitoring a Postgres Distributed (PGD) cluster. Monitoring is crucial for maintaining the health and performance of your database system. + +## [Maintenance](/pgd/latest/essential-how-to/sops/maintenance) + +The SOPs in this section cover the procedures for maintaining a Postgres Distributed (PGD) cluster. It covers routine maintenance tasks and how they should be performed when working with a PGD cluster. + +## [Backup and Restore](/pgd/latest/essential-how-to/sops/backup-restore) + +The SOPs in this section cover the process of backing up and restoring the Postgres database servers running on the nodes in a PGD cluster. + +## [Upgrade](/pgd/latest/essential-how-to/sops/upgrade) -## Backup and Restore +The SOPs in this section cover the process of upgrading the Postgres database servers running on the nodes in a PGD cluster and upgrade PGD itself. This includes minor and major upgrades of Postgres. -## Upgrades +## [Troubleshooting](/pgd/latest/essential-how-to/sops/troubleshooting) +The SOPs in this section cover the procedures for troubleshooting common issues that may arise in a Postgres Distributed (PGD) cluster. It includes steps to diagnose and resolve problems effectively. diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/install.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/install.mdx deleted file mode 100644 index ca25cb9e47c..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sops/install.mdx +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: Installation SOPs -navTitle: Installation ---- - -This SOP covers the essential SOPs for installing PGD on a new node, configuring it, and adding it to an existing cluster. -Part of the nature of a distributed system like PGD is that new nodes can be added (and removed) at any time. This means that you do need to know how to install PGD on a fresh node, how to configure it, and how to add it to an existing cluster. - diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/install/add-node.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/install/add-node.mdx new file mode 100644 index 00000000000..4f1f19a9d01 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/install/add-node.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Adding a Node to an Existing Cluster +navTitle: Add Node +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/install/index.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/install/index.mdx new file mode 100644 index 00000000000..06343195091 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/install/index.mdx @@ -0,0 +1,15 @@ +--- +title: Installation and Configuration SOPs +navTitle: Installation +--- + +## Overview + +This SOP covers the essential SOPs for installing PGD, creating a new PGD cluster, adding a node to an existing cluster, and configuring PGD. + +## SOPs + +- [Installing PGD on a New Node](/pgd/latest/essential-how-to/sops/install/new-node) +- [Adding a Node to an Existing Cluster](/pgd/latest/essential-how-to/sops/install/add-node) +- [Creating a New Group](/pgd/latest/essential-how-to/sops/install/new-group) + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/install/new-group.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/install/new-group.mdx new file mode 100644 index 00000000000..d071e96dce7 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/install/new-group.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Creating a New Group +navTitle: New Group +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/install/new-node.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/install/new-node.mdx new file mode 100644 index 00000000000..b68f0090507 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/install/new-node.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Installing PGD on a New Node +navTitle: New Node +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/maintenence/index.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/maintenence/index.mdx new file mode 100644 index 00000000000..892e213ed52 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/maintenence/index.mdx @@ -0,0 +1,17 @@ +--- +title: Maintenance SOPs +navTitle: Maintenance +navigation: +- routine +- node-failures +- online-vacuum +--- + +This section covers the essential SOPs for maintaining a Postgres Distributed (PGD) cluster. Regular maintenance is crucial for ensuring the health and performance of your database system. + +## SOPs + +- [Performing Routine Maintenance](/pgd/latest/essential-how-to/sops/maintenance/routine) +- [Handling Node Failures](/pgd/latest/essential-how-to/sops/maintenance/node-failures) +- [Online Vacuuming](/pgd/latest/essential-how-to/sops/maintenance/online-vacuum) + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/maintenence/node-failures.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/maintenence/node-failures.mdx new file mode 100644 index 00000000000..d7adaee81b2 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/maintenence/node-failures.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Handling Node Failures +navTitle: Node Failures +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/maintenence/online-vacuum.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/maintenence/online-vacuum.mdx new file mode 100644 index 00000000000..ed1eb9cd1a5 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/maintenence/online-vacuum.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Online Vacuuming +navTitle: Online Vacuuming +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/maintenence/routine.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/maintenence/routine.mdx new file mode 100644 index 00000000000..86e819bc3de --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/maintenence/routine.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Performing Routine Maintenance +navTitle: Routine Maintenance +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/monitoring.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/monitoring.mdx deleted file mode 100644 index 07b4c337813..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sops/monitoring.mdx +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Monitoring SOPs -navTitle: Monitoring ---- - -This SOP covers the process of monitoring the Postgres database servers running on the nodes in a PGD cluster. It includes best practices for monitoring, tools to use, and common issues that may arise during the monitoring process. - diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/monitoring/index.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/monitoring/index.mdx new file mode 100644 index 00000000000..fb1eec753d4 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/monitoring/index.mdx @@ -0,0 +1,10 @@ +--- +title: Monitoring SOPs +navTitle: Monitoring +--- + +This section covers the essential SOPs for monitoring a Postgres Distributed (PGD) cluster. Monitoring is crucial for maintaining the health and performance of your database system. + +## SOPs + +- [Monitoring with SQL](/pgd/latest/essential-how-to/sops/monitoring/sql) diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/monitoring/sql.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/monitoring/sql.mdx new file mode 100644 index 00000000000..7b38c8a1a9d --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/monitoring/sql.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Monitoring PGD clusters using SQL +navTitle: With SQL +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/template.txt b/product_docs/docs/pgd/6/essential-how-to/sops/template.txt new file mode 100644 index 00000000000..b76eca8fdb2 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/template.txt @@ -0,0 +1,33 @@ +--- +title: SOP - +navTitle: +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/troubleshooting.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/troubleshooting.mdx deleted file mode 100644 index cac5f087fe0..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sops/troubleshooting.mdx +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Troubleshooting -navTitle: Troubleshooting ---- - diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/troubleshooting/cluster-operations.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/troubleshooting/cluster-operations.mdx new file mode 100644 index 00000000000..8ede35d33e3 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/troubleshooting/cluster-operations.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Troubleshooting Cluster Operations +navTitle: Cluster Operations +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/troubleshooting/index.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/troubleshooting/index.mdx new file mode 100644 index 00000000000..25e76a6f541 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/troubleshooting/index.mdx @@ -0,0 +1,10 @@ +--- +title: Troubleshooting +navTitle: Troubleshooting +--- + +This section provides troubleshooting guidance for common issues encountered in Postgres Distributed (PGD) clusters. It includes solutions for problems related to cluster operations, node management, and performance. + +## SOPs + +- [Troubleshooting Cluster Operations](/pgd/latest/essential-how-to/sops/troubleshooting/cluster-operations) diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/upgrade.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/upgrade.mdx deleted file mode 100644 index 2a0427f5877..00000000000 --- a/product_docs/docs/pgd/6/essential-how-to/sops/upgrade.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Upgrading Postgres -navTitle: Upgrades -redirects: - - /pgd/latest/upgrades ---- - -This SOP covers the process of upgrading the Postgres database servers running on the nodes in a PGD cluster. There are two main upgrade paths: minor and major upgrades. Minor upgrades are typically performed to apply security patches or bug fixes, while major upgrades involve significant changes to the database engine and may require more extensive testing and planning. - -## Minor Upgrades - -## Major Upgrades - -## Upgrading to EDB Postgres Distributed 6 - -See the [reference documentation](/pgd/latest/reference/upgrade) for more information on upgrading to EDB Postgres Distributed 6.0.0. diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/upgrade/index.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/upgrade/index.mdx new file mode 100644 index 00000000000..12891da7894 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/upgrade/index.mdx @@ -0,0 +1,19 @@ +--- +title: Upgrading Postgres +navTitle: Upgrades +redirects: + - /pgd/latest/upgrades +navigation: +- minor +- major +- pgd +--- + +These SOPs cover the process of upgrading the Postgres database servers running on the nodes in a PGD cluster and upgrading PGD itself. This includes minor and major upgrades of Postgres. + +## SOPs + +- [Upgrading Postgres to a Minor Version](/pgd/latest/essential-how-to/sops/upgrade/minor) +- [Upgrading Postgres to a Major Version](/pgd/latest/essential-how-to/sops/upgrade/major) +- [Upgrading Postgres Distributed](/pgd/latest/essential-how-to/sops/upgrade/pgd) + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/upgrade/major.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/upgrade/major.mdx new file mode 100644 index 00000000000..5751e409335 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/upgrade/major.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Major upgrades of Postgres +navTitle: Major Postgres +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/upgrade/minor.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/upgrade/minor.mdx new file mode 100644 index 00000000000..5dad6ecfad9 --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/upgrade/minor.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Minor upgrades of Postgres +navTitle: Minor Postgres +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/upgrade/pgd.mdx b/product_docs/docs/pgd/6/essential-how-to/sops/upgrade/pgd.mdx new file mode 100644 index 00000000000..0be931aacfd --- /dev/null +++ b/product_docs/docs/pgd/6/essential-how-to/sops/upgrade/pgd.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Upgrading PGD in PGD clusters +navTitle: Postgres Distributed +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/install/04-configuring-cluster.mdx b/product_docs/docs/pgd/6/expanded-how-to/install/04-configuring-cluster.mdx index 6744282c007..8753ca03c80 100644 --- a/product_docs/docs/pgd/6/expanded-how-to/install/04-configuring-cluster.mdx +++ b/product_docs/docs/pgd/6/expanded-how-to/install/04-configuring-cluster.mdx @@ -10,47 +10,44 @@ The next step in the process is to configure the database and the cluster. This involves logging into each host and running the `pgd` command to create the cluster as the database user. -These steps vary according to which platform you are using and which version of Postgres you are using. Bute there are some common steps to follow and common variables to set. +These steps will vary according to which platform you are using and which version of Postgres you are using. -### Cluster name +## Cluster name You will need to choose a name for your cluster. This is the name that will be used to identify the cluster in the PGD CLI and in the database. It will be referred to as `` in the examples. If not specified, the default name is `pgd`. -### Group names +## Group names You will also need to choose a name for the group. This is the name that will be used to identify the group in the PGD CLI and in the database. It will be referred to as `` in the examples. The group name must be unique within the cluster. -### Node names +## Node names You will also need to choose a name for each node. This is the name that will be used to identify the node in the PGD CLI and in the database. It will be referred to as `` in the examples. This is separate from the host name, which is the name of the machine on which the node is running. The node name must be unique within the group and within the cluster. -### Paths and users +## Paths and users -The paths, users and ports used in the examples will vary according to which version of Postgres you are using and which platform you are using. +The paths and users used in the examples will vary according to which version of Postgres you are using and which platform you are using. + +Select your Postgres version: -You will use the system's `enterprisedb` user to run the `pgd` command. The database port is 5444. - -```shell -sudo -iu enterprisedb -export PG_VERSION= -export PATH=$PATH:/usr/lib/edb-as/$PG_VERSION/bin/ -export PGDATA=/var/lib/edb-as/$PG_VERSION/main/ -``` +
Then select your platform: | | | |---------------------------|-------------------------------------| -| Postgres Executable files | `/usr/lib/edb-as/$PG_VERSION/bin/` | +| Postgres User | `enterprisedb` | +| Postgres Port | `5444` | +| Postgres Executable files | `/usr/lib/edb-as/$PG_VERSION/bin/` | | Postgres Data Directory | `/var/lib/edb-as/$PG_VERSION/main/` | ```shell @@ -58,21 +55,16 @@ sudo -iu enterprisedb export PG_VERSION= export PATH=$PATH:/usr/lib/edb-as/$PG_VERSION/bin/ export PGDATA=/var/lib/edb-as/$PG_VERSION/main/ +export PGPORT=5444 ``` - -```shell -sudo -iu enterprisedb -export PG_VERSION= -export PATH=$PATH:/usr/lib/edb-as/$PG_VERSION/bin/ -export PGDATA=/var/lib/edb-as/$PG_VERSION/main/ -``` - | | | |---------------------------|------------------------------------| +| Postgres User | `enterprisedb` | +| Postgres Port | `5444` | | Postgres Executable files | `/usr/edb/as$PG_VERSION/bin/` | | Postgres Data Directory | `/var/lib/edb/as$PG_VERSION/data/` | @@ -81,6 +73,7 @@ sudo -iu enterprisedb export PG_VERSION= export PATH=$PATH:/usr/edb/as$PG_VERSION/bin/ export PGDATA=/var/lib/edb/as$PG_VERSION/data/ +export PGPORT=5444 ``` @@ -88,13 +81,15 @@ export PGDATA=/var/lib/edb/as$PG_VERSION/data/ -You will use the system's `postgres` user to run the `pgd` command. The database port is 5432 +
Then select your platform: | | | |---------------------------|--------------------------------------| +| Postgres User | `postgres` | +| Postgres Port | `5432` | | Postgres Executable files | `/usr/lib/edb-pge/$PG_VERSION/bin/` | | Postgres Data Directory | `/var/lib/edb-pge/$PG_VERSION/main/` | @@ -103,6 +98,7 @@ sudo -iu postgres export PG_VERSION= export PATH=$PATH:/usr/lib/edb-pge/$PG_VERSION/bin/ export PGDATA=/var/lib/edb-pge/$PG_VERSION/main/ +export PGPORT=5432 ``` @@ -110,6 +106,8 @@ export PGDATA=/var/lib/edb-pge/$PG_VERSION/main/ | | | |---------------------------|--------------------------------------| +| Postgres User | `postgres` | +| Postgres Port | `5432` | | Postgres Executable files | `/usr/edb/pge$PG_VERSION/bin/` | | Postgres Data Directory | `/var/lib/edb-pge/$PG_VERSION/data/` | @@ -118,6 +116,7 @@ sudo -iu postgres export PG_VERSION= export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ +export PGPORT=5432 ``` @@ -125,13 +124,15 @@ export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ -You will use the system's `postgres` user to run the `pgd` command. The database port is 5432. +
Then select your platform: | | | |---------------------------|-----------------------------------------| +| Postgres User | `postgres` | +| Postgres Port | `5432` | | Postgres Executable files | `/usr/lib/postgresql/$PG_VERSION/bin/` | | Postgres Data Directory | `/var/lib/postgresql/$PG_VERSION/main/` | @@ -140,6 +141,7 @@ sudo -iu postgres export PG_VERSION= export PATH=$PATH:/usr/lib/postgresql/$PG_VERSION/bin/ export PGDATA=/var/lib/postgresql/$PG_VERSION/main/ +export PGPORT=5432 ``` @@ -147,6 +149,8 @@ export PGDATA=/var/lib/postgresql/$PG_VERSION/main/ | | | |---------------------------|------------------------------------| +| Postgres User | `postgres` | +| Postgres Port | `5432` | | Postgres Executable files | `/usr/pgsql-$PG_VERSION/bin/` | | Postgres Data Directory | `/var/lib/pgsql/$PG_VERSION/data/` | @@ -155,6 +159,7 @@ sudo -iu postgres export PG_VERSION= export PATH=$PATH:/usr/pgsql-$PG_VERSION/bin/ export PGDATA=/var/lib/pgsql/$PG_VERSION/data/ +export PGPORT=5432 ``` @@ -164,13 +169,16 @@ export PGDATA=/var/lib/pgsql/$PG_VERSION/data/ ## On each host +Run the commands from the script/settings above to set the environment variables and paths for the Postgres user on each host. +This will ensure that the `pgd` command can find the Postgres executable files and data directory. + 1. Using the appropriate user, log in as the database user. ```bash sudo -iu ``` -1. Set the Postgres version environment variable. +1. Set the Postgres version environment variable. Don't forget to replace `` with the actual version number you are using, such as `17`. ```bash export PG_VERSION= @@ -188,25 +196,22 @@ export PATH=$PATH: export PGDATA= ``` -1. Set the Postgres password environment variable. +1. Set the Postgres password environment variable. Don't forget to replace `` with the actual password you want for the database user. ```bash export PGPASSWORD= ``` -This password is used by the `pgd` command to connect to the database, and when initializing the database. - -1. Run the pgd node setup command. - ### On the first host +The first host in the cluster is also the first node and will be where we begin the cluster creation. On the first host, run the following command to create the cluster: ```bash -pgd node setup --dsn "host= user= port= dbname=" --group-name --create-group +pgd node setup --dsn "host= user= port= dbname=" --group-name ``` -This command will create the cluster and the group on the first host. It will also create the data directory and initialize the database. +This command will create the data directory and initialize the database, then will create the cluster and the group on the first node. ### On the second host @@ -230,29 +235,30 @@ This command will create the node on the third host, and then join the cluster u ## Worked example -In this example, we will configure the PGD Expanded cluster with EDB Postgres Extended Server 17 on a CentOS/RHEL system using an enterprise subscription that we [configured](02-configure-repositories) and [installed](03-installing-database-and-pgd) in the previous steps. +In this example, we will configure the PGD Essential cluster with EDB Postgres Extended Server 17 on a CentOS/RHEL system that we [configured](02-configure-repositories) and [installed](03-installing-database-and-pgd) in the previous steps. -We will now create a cluster called `pgd` with three nodes called `node1`, `node2`, and `node3`. +We will now create a cluster called `pgd` with three nodes called `node-1`, `node-2`, and `node-3`. * The group name will be `group-1`. The hosts are `host-1`, `host-2`, and `host-3`. * The Postgres version is 17. * The database user is `postgres`. * The database port is 5432. +* The database name is `pgddb`. * The Postgres executable files are in `/usr/edb/pge17/bin/`. -* The Postgres data directory is in `/var/lib/edb-pge/17/data/`. -* We will use the `pgddb` database. +* The Postgres data directory is in `/var/lib/edb-pge/17/main/`. * The Postgres password is `secret`. +(Note that we assume the Postgres version environment variable PG_VERSION is set to `17` from the previous step, and that we are preserving the environment variable when switching users.) #### On the first host ```bash -sudo -iu postgres +sudo -iu postgres export PG_VERSION=17 export PATH=$PATH:/usr/edb/pge$PG_VERSION/bin/ export PGDATA=/var/lib/edb-pge/$PG_VERSION/data/ export PGPASSWORD=secret -pgd node node-1 setup --dsn "host=host-1 user=postgres port=5432 dbname=pgddb" --group-name group-1 --update-pgpass +pgd node node-1 setup --dsn "host=host-1 user=postgres port=5432 dbname=pgddb" --group-name group-1 ``` #### On the second host @@ -277,4 +283,5 @@ export PGPASSWORD=secret pgd node node-3 setup --dsn "host=host-3 user=postgres port=5432 dbname=pgddb" --cluster-dsn "host=host-1 user=postgres port=5432 dbname=pgddb" ``` -Next, you can [check the cluster](05-check-cluster) to begin using it. +The next step is to [check the cluster](05-check-cluster). + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/backup-restore/barman.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/backup-restore/barman.mdx new file mode 100644 index 00000000000..97648a22836 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/backup-restore/barman.mdx @@ -0,0 +1,33 @@ +--- +title: Backup and Restore with Barman +navTitle: Barman +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/backup-restore/index.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/backup-restore/index.mdx new file mode 100644 index 00000000000..85af9de8e75 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/backup-restore/index.mdx @@ -0,0 +1,14 @@ +--- +title: Backup and Restore SOPs +navTitle: Backup and Restore +navigation: +- pg_dump +- barman +--- +The SOPs in this section cover the process of backing up and restoring the Postgres database servers running on the nodes in a PGD cluster. It includes best practices for backup and restore, tools to use, and common issues that may arise during the backup and restore process. + +## SOPs + +- [Backup and Restore with pg_dump](/pgd/latest/expanded-how-to/sops/backup-restore/pg_dump) +- [Backup and Restore with Barman](/pgd/latest/expanded-how-to/sops/backup-restore/barman) + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/backup-restore/pg_dump.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/backup-restore/pg_dump.mdx new file mode 100644 index 00000000000..9307ca21037 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/backup-restore/pg_dump.mdx @@ -0,0 +1,33 @@ +--- +title: Backup and Restore with pg_dump +navTitle: pg_dump +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/data-movement/index.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/data-movement/index.mdx new file mode 100644 index 00000000000..d8a12d42942 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/data-movement/index.mdx @@ -0,0 +1,14 @@ +--- +title: Data Movement SOPs +navTitle: Data Movement +navigation: +- move-in +- move-out +--- + +This section covers how to move data in and out of a Postgres Distributed cluster as efficiently as possible. + +## SOPs + +- [Moving Data into a PGD Cluster](/pgd/latest/expanded-how-to/sops/data-movement/move-in) +- [Moving Data out of a PGD Cluster](/pgd/latest/expanded-how-to/sops/data-movement/move-out) diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/data-movement/move-in.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/data-movement/move-in.mdx new file mode 100644 index 00000000000..ca81d71a097 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/data-movement/move-in.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Moving Data into the Cluster +navTitle: Move In +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/data-movement/move-out.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/data-movement/move-out.mdx new file mode 100644 index 00000000000..498bce0fc32 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/data-movement/move-out.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Moving Data Out of the Cluster +navTitle: Move Out +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/how-to-use-sops.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/how-to-use-sops.mdx new file mode 100644 index 00000000000..53208b36222 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/how-to-use-sops.mdx @@ -0,0 +1,24 @@ +--- +title: How to use Standard Operating Procedures +navTitle: How to use +description: How to use Standard Operating Procedures (SOPs) for EDB Postgres Distributed (PGD). +--- + +Standard Operating Procedures, or SOPs, are a set of instructions that cover the expanded tasks for the successful operation of EDB Postgres Distributed (PGD). + +They are designed to be easy to follow and provide step-by-step guidance for performing various tasks. + +To make it easy to follow, each SOP is divided into sections that cover the following: + +- **Overview**: A brief description of the task and its purpose. +- **Prerequisites**: Any requirements or dependencies that must be met before performing the task. +- **Instructions**: Step-by-step generic instructions for performing the task. +- **Worked Example**: A specific example of how to perform the task, including any relevant commands or configurations. +- **Notes**: Additional information or tips that may be helpful. +- **Troubleshooting**: Common issues that may arise during the task and how to resolve them. +- **References**: Links to related documentation or resources. + +## How to use SOPs + +**TODO**: Add a description of how to use SOPs. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/index.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/index.mdx new file mode 100644 index 00000000000..47ad775cc94 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/index.mdx @@ -0,0 +1,49 @@ +--- +title: Expanded Standard Operating Procedures +navTitle: Expanded Standard Operating Procedures +navigation: +- how-to-use-sops +- install +- data-movement +- monitoring +- backup-restore +- upgrade +- monitoring +- troubleshooting +--- + +## Overview + +Standard Operating Procedures (SOPs) are a set of procedures that are expanded for the successful operation of EDB Postgres Distributed (PGD). These procedures cover various aspects of the system, including installation, configuration, backup and restore, upgrades, monitoring, and troubleshooting. + +SOPs are designed to address the most common tasks around using and maintaining a PGD cluster. They provide a structured approach to performing these tasks, ensuring consistency and reliability in operations. Read more about the structure of SOPs in the [How to Use SOPs](/pgd/latest/expanded-how-to/sops/how-to-use-sops). + +This document provides an overview of the SOPs and links to detailed instructions for each procedure. + +## [Installation and Configuration](/pgd/latest/expanded-how-to/sops/install) + +The SOPs in this section cover the procedures for installing PGD, creating a new PGD cluster, adding a node to an existing cluster, and configuring PGD. + +## [Data Movement](/pgd/latest/expanded-how-to/sops/data-movement) + +The SOPs in this section cover the procedures for moving data into or out of a PGD cluster. This include importing and exporting data efficiently. + +## [Monitoring](/pgd/latest/expanded-how-to/sops/monitoring) + +The SOPs in this section cover the procedures for monitoring a Postgres Distributed (PGD) cluster. Monitoring is crucial for maintaining the health and performance of your database system. + +## [Maintenance](/pgd/latest/expanded-how-to/sops/maintenance) + +The SOPs in this section cover the procedures for maintaining a Postgres Distributed (PGD) cluster. It covers routine maintenance tasks and how they should be performed when working with a PGD cluster. + +## [Backup and Restore](/pgd/latest/expanded-how-to/sops/backup-restore) + +The SOPs in this section cover the process of backing up and restoring the Postgres database servers running on the nodes in a PGD cluster. + +## [Upgrade](/pgd/latest/expanded-how-to/sops/upgrade) + +The SOPs in this section cover the process of upgrading the Postgres database servers running on the nodes in a PGD cluster and upgrade PGD itself. This includes minor and major upgrades of Postgres. + +## [Troubleshooting](/pgd/latest/expanded-how-to/sops/troubleshooting) + +The SOPs in this section cover the procedures for troubleshooting common issues that may arise in a Postgres Distributed (PGD) cluster. It includes steps to diagnose and resolve problems effectively. diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/install/add-node.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/install/add-node.mdx new file mode 100644 index 00000000000..4f1f19a9d01 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/install/add-node.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Adding a Node to an Existing Cluster +navTitle: Add Node +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/install/index.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/install/index.mdx new file mode 100644 index 00000000000..e097484c7ba --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/install/index.mdx @@ -0,0 +1,15 @@ +--- +title: Installation and Configuration SOPs +navTitle: Installation +--- + +## Overview + +This SOP covers the expanded SOPs for installing PGD, creating a new PGD cluster, adding a node to an existing cluster, and configuring PGD. + +## SOPs + +- [Installing PGD on a New Node](/pgd/latest/expanded-how-to/sops/install/new-node) +- [Adding a Node to an Existing Cluster](/pgd/latest/expanded-how-to/sops/install/add-node) +- [Creating a New Group](/pgd/latest/expanded-how-to/sops/install/new-group) + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/install/new-group.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/install/new-group.mdx new file mode 100644 index 00000000000..d071e96dce7 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/install/new-group.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Creating a New Group +navTitle: New Group +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/install/new-node.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/install/new-node.mdx new file mode 100644 index 00000000000..b68f0090507 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/install/new-node.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Installing PGD on a New Node +navTitle: New Node +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/index.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/index.mdx new file mode 100644 index 00000000000..7f4f03ba849 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/index.mdx @@ -0,0 +1,17 @@ +--- +title: Maintenance SOPs +navTitle: Maintenance +navigation: +- routine +- node-failures +- online-vacuum +--- + +This section covers the expanded SOPs for maintaining a Postgres Distributed (PGD) cluster. Regular maintenance is crucial for ensuring the health and performance of your database system. + +## SOPs + +- [Performing Routine Maintenance](/pgd/latest/expanded-how-to/sops/maintenance/routine) +- [Handling Node Failures](/pgd/latest/expanded-how-to/sops/maintenance/node-failures) +- [Online Vacuuming](/pgd/latest/expanded-how-to/sops/maintenance/online-vacuum) + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/node-failures.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/node-failures.mdx new file mode 100644 index 00000000000..d7adaee81b2 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/node-failures.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Handling Node Failures +navTitle: Node Failures +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/online-vacuum.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/online-vacuum.mdx new file mode 100644 index 00000000000..ed1eb9cd1a5 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/online-vacuum.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Online Vacuuming +navTitle: Online Vacuuming +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/routine.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/routine.mdx new file mode 100644 index 00000000000..86e819bc3de --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/maintenence/routine.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Performing Routine Maintenance +navTitle: Routine Maintenance +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/monitoring/index.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/monitoring/index.mdx new file mode 100644 index 00000000000..8f809e670d4 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/monitoring/index.mdx @@ -0,0 +1,10 @@ +--- +title: Monitoring SOPs +navTitle: Monitoring +--- + +This section covers the expanded SOPs for monitoring a Postgres Distributed (PGD) cluster. Monitoring is crucial for maintaining the health and performance of your database system. + +## SOPs + +- [Monitoring with SQL](/pgd/latest/expanded-how-to/sops/monitoring/sql) diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/monitoring/sql.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/monitoring/sql.mdx new file mode 100644 index 00000000000..7b38c8a1a9d --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/monitoring/sql.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Monitoring PGD clusters using SQL +navTitle: With SQL +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/template.txt b/product_docs/docs/pgd/6/expanded-how-to/sops/template.txt new file mode 100644 index 00000000000..b76eca8fdb2 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/template.txt @@ -0,0 +1,33 @@ +--- +title: SOP - +navTitle: +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/troubleshooting/cluster-operations.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/troubleshooting/cluster-operations.mdx new file mode 100644 index 00000000000..8ede35d33e3 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/troubleshooting/cluster-operations.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Troubleshooting Cluster Operations +navTitle: Cluster Operations +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/troubleshooting/index.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/troubleshooting/index.mdx new file mode 100644 index 00000000000..195511f51d7 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/troubleshooting/index.mdx @@ -0,0 +1,10 @@ +--- +title: Troubleshooting +navTitle: Troubleshooting +--- + +This section provides troubleshooting guidance for common issues encountered in Postgres Distributed (PGD) clusters. It includes solutions for problems related to cluster operations, node management, and performance. + +## SOPs + +- [Troubleshooting Cluster Operations](/pgd/latest/expanded-how-to/sops/troubleshooting/cluster-operations) diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/index.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/index.mdx new file mode 100644 index 00000000000..10a4a06a005 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/index.mdx @@ -0,0 +1,19 @@ +--- +title: Upgrading Postgres +navTitle: Upgrades +redirects: + - /pgd/latest/upgrades +navigation: +- minor +- major +- pgd +--- + +These SOPs cover the process of upgrading the Postgres database servers running on the nodes in a PGD cluster and upgrading PGD itself. This includes minor and major upgrades of Postgres. + +## SOPs + +- [Upgrading Postgres to a Minor Version](/pgd/latest/expanded-how-to/sops/upgrade/minor) +- [Upgrading Postgres to a Major Version](/pgd/latest/expanded-how-to/sops/upgrade/major) +- [Upgrading Postgres Distributed](/pgd/latest/expanded-how-to/sops/upgrade/pgd) + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/major.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/major.mdx new file mode 100644 index 00000000000..5751e409335 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/major.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Major upgrades of Postgres +navTitle: Major Postgres +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/minor.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/minor.mdx new file mode 100644 index 00000000000..5dad6ecfad9 --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/minor.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Minor upgrades of Postgres +navTitle: Minor Postgres +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/pgd.mdx b/product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/pgd.mdx new file mode 100644 index 00000000000..0be931aacfd --- /dev/null +++ b/product_docs/docs/pgd/6/expanded-how-to/sops/upgrade/pgd.mdx @@ -0,0 +1,33 @@ +--- +title: SOP - Upgrading PGD in PGD clusters +navTitle: Postgres Distributed +--- + +## Overview + +A brief description of the task and its purpose. + +## Prerequisites + +Any requirements or dependencies that must be met before performing the task. + +## Instructions + +Step-by-step generic instructions for performing the task. + +## Worked Example + +A specific example of how to perform the task, including any relevant commands or configurations. + +## Notes + +Additional information or tips that may be helpful. + +## Troubleshooting + +Common issues that may arise during the task and how to resolve them. + +## References + +Links to related documentation or resources. + diff --git a/product_docs/docs/pgd/6/get-started/essential-standard.mdx b/product_docs/docs/pgd/6/get-started/essential-standard.mdx index e25c6d94ea2..0233b544d1c 100644 --- a/product_docs/docs/pgd/6/get-started/essential-standard.mdx +++ b/product_docs/docs/pgd/6/get-started/essential-standard.mdx @@ -13,7 +13,7 @@ The standard architecture is built around a single data group, which is the basi The one-location architecture consists of a single PGD cluster with three nodes. The nodes are located in the same data center or region. Ideally they are in different availability zones, but that isn't required. The nodes are connected to each other using a high-speed network. -The nodes are configured as a data group which means that they replicate data to each other within the same group. While PGD can handle multiple writers in a network, this requires more advanced conflict management and is not supported in PGD Essential. +The nodes are configured as a data group which means that they replicate data to each other within the same group. While PGD can handle multiple writers in a network, this requires more advanced conflict management and is not supported in PGD Essential. Therefore, in the standard architecture, one node is designated as the write leader node, which handles all write transactions. The other nodes in the group are read-only nodes that replicate data from the write leader. diff --git a/product_docs/docs/pgd/6/essential-how-to/sops/backup-restore.mdx b/product_docs/docs/pgd/6/reference/backup-restore.mdx similarity index 100% rename from product_docs/docs/pgd/6/essential-how-to/sops/backup-restore.mdx rename to product_docs/docs/pgd/6/reference/backup-restore.mdx diff --git a/product_docs/docs/pgd/6/reference/cli/command_ref/group/get-option.mdx b/product_docs/docs/pgd/6/reference/cli/command_ref/group/get-option.mdx index f51af09c128..3ce01951ffc 100644 --- a/product_docs/docs/pgd/6/reference/cli/command_ref/group/get-option.mdx +++ b/product_docs/docs/pgd/6/reference/cli/command_ref/group/get-option.mdx @@ -46,7 +46,6 @@ And `