From 3a90b6fa7ec7e28c2d71601f90dcf74874a79fda Mon Sep 17 00:00:00 2001 From: edb-slonik Date: Thu, 19 May 2022 17:24:25 +0000 Subject: [PATCH] [create-pull-request] automated change --- product_docs/docs/bdr/3.7/backup.mdx | 50 +++++++++++++++++- product_docs/docs/bdr/3.7/configuration.mdx | 38 ++++++++++++++ product_docs/docs/bdr/3.7/nodes.mdx | 4 ++ product_docs/docs/bdr/3.7/release-notes.mdx | 58 +++++++++++++++++++++ product_docs/docs/bdr/3.7/repsets.mdx | 34 ++++++------ 5 files changed, 165 insertions(+), 19 deletions(-) diff --git a/product_docs/docs/bdr/3.7/backup.mdx b/product_docs/docs/bdr/3.7/backup.mdx index ad5f2b01ae5..963d4b3b609 100644 --- a/product_docs/docs/bdr/3.7/backup.mdx +++ b/product_docs/docs/bdr/3.7/backup.mdx @@ -20,7 +20,7 @@ Recovery (DR), such as in the following situations: ## Backup -### `pg_dump` +### pg_dump `pg_dump`, sometimes referred to as "logical backup", can be used normally with BDR. @@ -232,6 +232,54 @@ of a single BDR node, optionally plus WAL archives: - Add further BDR nodes with the standard procedure based on the `bdr.join_node_group()` function call. +### pg_dump restore + +The restore procedure using pg_dump is somehow simpler (but not as consistent +as phisycal backups because it only makes a snapshot of a given moment in time). +The dump only takes personal data and not catalog data (BDR). + +Creating a new cluster from a dump needs only a new Postgresql instance where +to restore normally the dump. +The result is a plain postgres instance with all personal data. + +**No catalog changes are restored from the original BDR node.** +You need to manually create the BDR cluster from ths instance. +Create the BDR extension , create the node, create the bdr group, etc. and +eventually join other nodes to this instance. + +There is only one caveat to keep in mind when restoring a BDR dump. +BDR creates two policies on the `bdr.conflict_history table`. Postgresql normal +behavior does not allow to tie policies to an extension so these will be dumped +together with your data. These policies, unless removed from the dump, will drag +also the BDR extension and grant some permissions. + +You need to manually remove those statements from the dump prior restoring it. + +The statements you need to delete from the dump are the following: + +```sql +CREATE EXTENSION IF NOT EXISTS bdr WITH SCHEMA pg_catalog; +COMMENT ON EXTENSION bdr IS 'Bi-Directional Replication for PostgreSQL'; +CREATE POLICY conflict_filter ON bdr.conflict_history FOR SELECT USING (((( SELECT c.relowner + FROM pg_class c + WHERE (c.oid = conflict_history.reloid)) = ( SELECT pg_roles.oid + FROM pg_roles + WHERE (pg_roles.rolname = CURRENT_USER))) AND ( SELECT (NOT (c.relrowsecurity AND c.relforcerowsecurity)) + FROM pg_class c + WHERE (c.oid = conflict_history.reloid)))); +ALTER TABLE bdr.conflict_history ENABLE ROW LEVEL SECURITY; +CREATE POLICY conflict_read_all ON bdr.conflict_history FOR SELECT TO bdr_read_all_conflicts USING (true); +REVOKE ALL ON TABLE bdr.conflict_history FROM postgres; +REVOKE SELECT ON TABLE bdr.conflict_history FROM PUBLIC; +GRANT ALL ON TABLE bdr.conflict_history TO bdr_superuser; +GRANT SELECT ON TABLE bdr.conflict_history TO PUBLIC; +``` + +!!! Note + In the example, `postgres` is the initdb user, if you create the PostgreSQL + instance with a different user, then that user will be shown instead in the + dump, related to the `REVOKE` on `bdr.conflict_history` table. + #### Cleanup BDR Metadata The cleaning of leftover BDR metadata is achieved as follows: diff --git a/product_docs/docs/bdr/3.7/configuration.mdx b/product_docs/docs/bdr/3.7/configuration.mdx index 80fa0a3e973..2770d197839 100644 --- a/product_docs/docs/bdr/3.7/configuration.mdx +++ b/product_docs/docs/bdr/3.7/configuration.mdx @@ -104,6 +104,44 @@ pglogical internally to implement the basic replication. - `pglogical.max_writers_per_subscription` - Maximum number of writers per subscription (sets upper limit for the setting above). +### `pglogical.min_worker_backoff_delay` and `pglogical.max_worker_backoff_delay` + +Rate limit BDR background worker launches by preventing a given worker +from being relaunched more often than every +`pglogical.min_worker_backoff_delay` milliseconds. On repeated errors, the back-off +increases exponentially with added jitter up to maximum of +`pglogical.max_worker_backoff_delay`. + +Time-unit suffixes are supported. + +!!! Note + This setting currently only affects receiver worker, which means it + primarily affects how fast a subscription will try to reconnect on error + or connection failure. + +The default for `pglogical.min_worker_backoff_delay` 1 second, for +`pglogical.max_worker_backoff_delay` it is 1 minute. + +If the backoff delay setting is changed and the PostgreSQL configuration is +reloaded then all current backoff waits will be reset. Additionally, the +`pglogical.worker_task_reset_backoff_all()` function is provided to allow the +administrator to force all backoff intervals to immediately expire. + +A tracking table in shared memory is maintained to remember the last launch +time of each type of worker. This tracking table is not persistent; it is +cleared by PostgreSQL restarts, including soft-restarts during crash recovery +after an unclean backend exit. + +The view `pglogical.worker_tasks` may be used to inspect this state so the +administrator can see any backoff rate-limiting currently in effect. + +For rate limiting purposes, workers are classified by "task". This key consists +of the worker role, database oid, subscription id, subscription writer id, +extension library name and function name, extension-supplied worker name, and +the remote relation id for sync writers. `NULL` is used where a given +classifier does not apply, e.g. manager workers don't have a subscription ID +and receivers don't have a writer id. + ## BDR Specific Settings There are also BDR specific configuration settings that can be set. diff --git a/product_docs/docs/bdr/3.7/nodes.mdx b/product_docs/docs/bdr/3.7/nodes.mdx index e03768f10cd..3bfd34739e7 100644 --- a/product_docs/docs/bdr/3.7/nodes.mdx +++ b/product_docs/docs/bdr/3.7/nodes.mdx @@ -1311,6 +1311,10 @@ worker stopping depends on the value of `immediate`; if set to `true`, the workers will be stopped immediately; if set to `false`, they will be stopped at the `COMMIT` time. +!!! Note + With the parameter `immediate` set to `true`, the stop will however wait + for the workers to finish current work. + ## Node Management Commands BDR also provides a command line utility for adding nodes to the BDR group via diff --git a/product_docs/docs/bdr/3.7/release-notes.mdx b/product_docs/docs/bdr/3.7/release-notes.mdx index c0d320f7584..ff77655a4fd 100644 --- a/product_docs/docs/bdr/3.7/release-notes.mdx +++ b/product_docs/docs/bdr/3.7/release-notes.mdx @@ -5,6 +5,57 @@ originalFilePath: release-notes.md --- +## BDR 3.7.16 + +This is a maintenance release for BDR 3.7 which includes minor +improvements as well as fixes for issues identified in previous +versions. + +Check also release notes for pglogical 3.7.16 for resolved issues +which affect BDR as well. + +### Resolved Issues + +- Make ALTER TABLE lock the underlying relation only once (RT80204) + This avoids the ALTER TABLE operation falling behind in the queue + when it released the lock in between internal operations. With this + fix, concurrent transactions trying to acquire the same lock after + the ALTER TABLE command will properly wait for the ALTER TABLE to + finish. + +- Show a proper wait event for CAMO / Eager confirmation waits (BDR-1899, RT75900) + Show correct "BDR Prepare Phase"/"BDR Commit Phase" in `bdr.stat_activity` + instead of the default “unknown wait event”. + +- Correct `bdr.monitor_local_replslots` for down nodes (BDR-2080) + This function mistakenly returned an okay result for down nodes + before. + +- Reduce log for bdr.run_on_nodes (BDR-2153, RT80973) + Don't log when setting `bdr.ddl_replication` to off if it's + done with the "run_on_nodes" variants of function. This eliminates + the flood of logs for monitoring functions. + +- Correct an SDW decoder restart edge case (BDR-2109) + Internal testing revealed a possible error during WAL decoder + recovery about mismatch between confirmed_flush LSN of WAL decoder + slot also stating: "some LCR segments might be missing". This could + happen before in case the WAL decoder exited immediately after + processing a "Standby" WAL record other than "RUNNING_XACTS" and + would lead to a halt of replication with the decoder processes + continuing to restart. + +### Improvements + +- Use 64 bits for calculating lag size in bytes (BDR-2215) + +### Upgrades + +This release supports upgrading from the following versions of BDR: + +- 3.7.9 and higher +- 3.6.29 and higher + ## BDR 3.7.15 This is a maintenance release for BDR 3.7 which includes minor @@ -78,6 +129,13 @@ which affect BDR as well. requests or time consuming consensus requests, for example during join of a new node. +### Upgrades + +This release supports upgrading from the following versions of BDR: + +- 3.7.9 and higher +- 3.6.29 and higher + ## BDR 3.7.14 This is a maintenance release for BDR 3.7 which includes minor diff --git a/product_docs/docs/bdr/3.7/repsets.mdx b/product_docs/docs/bdr/3.7/repsets.mdx index 44dc54d5d13..2c70f019088 100644 --- a/product_docs/docs/bdr/3.7/repsets.mdx +++ b/product_docs/docs/bdr/3.7/repsets.mdx @@ -461,16 +461,15 @@ Use the following SQL to show those replication sets that the current node publishes and subscribes from: ```sql -SELECT s.node_id, - s.node_name, + SELECT node_id, + node_name, COALESCE( - i.pub_repsets, s.pub_repsets + pub_repsets, pub_repsets ) AS pub_repsets, COALESCE( - i.sub_repsets, s.sub_repsets + sub_repsets, sub_repsets ) AS sub_repsets -FROM bdr.local_node_summary s -INNER JOIN bdr.node_local_info i ON i.node_id = s.node_id; + FROM bdr.local_node_summary; ``` This produces output like this: @@ -490,17 +489,16 @@ the following query: WITH node_repsets AS ( SELECT jsonb_array_elements( bdr.run_on_all_nodes($$ - SELECT s.node_id, - s.node_name, - COALESCE( - i.pub_repsets, s.pub_repsets - ) AS pub_repsets, - COALESCE( - i.sub_repsets, s.sub_repsets - ) AS sub_repsets - FROM bdr.local_node_summary s - INNER JOIN bdr.node_local_info i - ON i.node_id = s.node_id; + SELECT + node_id, + node_name, + COALESCE( + pub_repsets, pub_repsets + ) AS pub_repsets, + COALESCE( + sub_repsets, sub_repsets + ) AS sub_repsets + FROM bdr.local_node_summary; $$)::jsonb ) AS j ) @@ -508,7 +506,7 @@ SELECT j->'response'->'command_tuples'->0->>'node_id' AS node_id, j->'response'->'command_tuples'->0->>'node_name' AS node_name, j->'response'->'command_tuples'->0->>'pub_repsets' AS pub_repsets, j->'response'->'command_tuples'->0->>'sub_repsets' AS sub_repsets -FROM node_repsets;; +FROM node_repsets; ``` This will show, for example: