From f3fbc70bd7cb42bd8b163d6b6b1ab8e3fc046b57 Mon Sep 17 00:00:00 2001 From: Sumukh-Phalgaonkar Date: Wed, 29 Jan 2025 13:25:38 +0530 Subject: [PATCH 1/6] Doc changes for the recent update in the default values of CDC flags --- .../using-logical-replication/advanced-topic.md | 16 +++++++++------- .../preview/explore/change-data-capture.md | 4 +++- .../preview/reference/configuration/yb-master.md | 12 ++++++++++++ .../reference/configuration/yb-tserver.md | 2 +- .../using-logical-replication/advanced-topic.md | 16 +++++++++------- .../stable/explore/change-data-capture.md | 4 +++- .../stable/reference/configuration/yb-master.md | 12 ++++++++++++ .../stable/reference/configuration/yb-tserver.md | 2 +- 8 files changed, 50 insertions(+), 18 deletions(-) diff --git a/docs/content/preview/develop/change-data-capture/using-logical-replication/advanced-topic.md b/docs/content/preview/develop/change-data-capture/using-logical-replication/advanced-topic.md index 982b731e2bb8..cd9c159e1871 100644 --- a/docs/content/preview/develop/change-data-capture/using-logical-replication/advanced-topic.md +++ b/docs/content/preview/develop/change-data-capture/using-logical-replication/advanced-topic.md @@ -114,19 +114,19 @@ CREATE TABLE test_table_2(id INT PRIMARY KEY, aa INT, bb INT); ### YugabyteDB semantics -Unlike PostgreSQL, any changes made to the publication's tables list are not applied immediately in YugabyteDB. Instead the publication's tables list is periodically refreshed, and changes, if any, are applied. The refresh interval is managed using the [cdcsdk_publication_list_refresh_interval_secs](../../../../reference/configuration/yb-tserver/#cdcsdk-publication-list-refresh-interval-secs) flag. The default is one hour (3600 sec). This means that any changes made to the publication's tables list will be applied after `cdcsdk_publication_list_refresh_interval_secs` in the worst case. +Unlike PostgreSQL, any changes made to the publication's tables list are not applied immediately in YugabyteDB. Instead the publication's tables list is periodically refreshed, and changes, if any, are applied. The refresh interval is managed using the [cdcsdk_publication_list_refresh_interval_secs](../../../../reference/configuration/yb-tserver/#cdcsdk-publication-list-refresh-interval-secs) flag. The default is 15 minutes (900 sec). This means that any changes made to the publication's tables list will be applied after `cdcsdk_publication_list_refresh_interval_secs` in the worst case. Consider the following example: -- Suppose that the value of the flag `cdcsdk_publication_list_refresh_interval_secs` is 3600 sec (1 hour) and the publication's tables list is being refreshed every hour at 8 am, 9 am, 10 am, and so on. +- Suppose that the value of the flag `cdcsdk_publication_list_refresh_interval_secs` is 900 sec (15 minutes) and the publication's tables list is being refreshed every 15 minutes at 8:00 am, 8:15 am, 8:30 am and so on. -- If any change is made to publication's tables list at 8:01 am, then this change will be applied at 9:00 am. However, any change made to publication's tables list at 8:59 am will also be applied at 9:00 am. +- If any change is made to publication's tables list at 8:01 am, then this change will be applied at 8:15 am. However, any change made to publication's tables list at 8:14 am will also be applied at 8:15 am. The value of this flag can be changed at run time, but the change becomes effective only after some time. Continuing the example: -- Suppose that the value of the flag `cdcsdk_publication_list_refresh_interval_secs` is changed from 3600 sec (1 hour) to 600 sec (10 minutes) at 8:01 am. +- Suppose that the value of the flag `cdcsdk_publication_list_refresh_interval_secs` is changed from 900 sec (15 minutes) to 300 sec (5 minutes) at 8:01 am. -- This change will only be applied after 9:00 am. That is, the publication's tables list will be next refreshed at 9:00 am. Then, the next refresh will happen at 9:10 am, and the subsequent refreshes will take place every 10 minutes. +- This change will only be applied after 8:15 am. That is, the publication's tables list will be next refreshed at 8:15 am. Then, the next refresh will happen at 8:20 am, and the subsequent refreshes will take place every 5 minutes. ### Required settings @@ -138,12 +138,14 @@ To enable dynamic table addition, perform the following steps: ./yb-ts-cli --server_address= set_flag cdcsdk_publication_list_refresh_interval_secs 120 ``` -1. After you start receiving records from the newly added table in the publication, reset the `cdcsdk_publication_list_refresh_interval_secs` flag to a high value (for example, 3600 seconds). +1. After you start receiving records from the newly added table in the publication, reset the `cdcsdk_publication_list_refresh_interval_secs` flag back to original value (i.e 900 seconds). ```sh - ./yb-ts-cli --server_address= set_flag cdcsdk_publication_list_refresh_interval_secs 3600 + ./yb-ts-cli --server_address= set_flag cdcsdk_publication_list_refresh_interval_secs 900 ``` +> **Note:** In the event that a user ends up reducing the value of `cdcsdk_publication_list_refresh_interval_secs`, it is recommended to increase the value of the flag back to its original value once you start receiving changes from the new table. + ## Initial snapshot The [initial snapshot](../../../../architecture/docdb-replication/cdc-logical-replication/#initial-snapshot) data for a table is consumed by executing a snapshot query (SELECT statement). To ensure that the streaming phase continues exactly from where the snapshot left, this snapshot query is executed as of a specific database state. In YugabyteDB, this database state is represented by a value of `HybridTime`. Changes due to transactions with commit time strictly greater than this snapshot `HybridTime` will be consumed during the streaming phase. diff --git a/docs/content/preview/explore/change-data-capture.md b/docs/content/preview/explore/change-data-capture.md index be94dfb12cb8..1572694aaf2b 100644 --- a/docs/content/preview/explore/change-data-capture.md +++ b/docs/content/preview/explore/change-data-capture.md @@ -57,7 +57,7 @@ To set up pg_recvlogical, create and start the local cluster by running the foll ./bin/yugabyted start \ --advertise_address=127.0.0.1 \ --base_dir="${HOME}/var/node1" \ - --tserver_flags="cdcsdk_publication_list_refresh_interval_secs=2" + --tserver_flags="cdcsdk_publication_list_refresh_interval_secs=120" ``` ### Create tables @@ -166,6 +166,8 @@ table public.projects: INSERT: project_id[integer]:1 name[character varying]:'Pr COMMIT 3 ``` +The yugabyte semantics are different from Postgres when it comes to streaming added tables to a publication. Refer the [yugabyte semantics](../develop/change-data-capture/using-logical-replication/advanced-topic.md#yugabytedb-semantics) for more details. + {{% explore-cleanup-local %}} ## Learn more diff --git a/docs/content/preview/reference/configuration/yb-master.md b/docs/content/preview/reference/configuration/yb-master.md index ec73dd5eb2b9..42569f581fd5 100644 --- a/docs/content/preview/reference/configuration/yb-master.md +++ b/docs/content/preview/reference/configuration/yb-master.md @@ -933,6 +933,18 @@ WAL retention time, in seconds, to be used for tables for which a CDC stream was Default: `28800` (8 hours) +##### --cdc_intent_retention_ms + +The time period, in milliseconds, after which the intents will be cleaned up if there is no client polling for the change records. + +Default: `28800000` (8 hours) + +##### --cdcsdk_tablet_not_of_interest_timeout_secs + +Timeout after which it is inferred that a particular tablet is not of interest for CDC. To indicate that a particular tablet is of interest for CDC, it should be polled at least once within this interval of stream / slot creation. + +Default: `14400` (4 hours) + ##### --enable_tablet_split_of_cdcsdk_streamed_tables Toggle automatic tablet splitting for tables in a CDCSDK stream, enhancing user control over replication processes. diff --git a/docs/content/preview/reference/configuration/yb-tserver.md b/docs/content/preview/reference/configuration/yb-tserver.md index a67d994b7205..d58d6692160e 100644 --- a/docs/content/preview/reference/configuration/yb-tserver.md +++ b/docs/content/preview/reference/configuration/yb-tserver.md @@ -1368,7 +1368,7 @@ Default: `true` Interval in seconds at which the table list in the publication will be refreshed. -Default: `3600` +Default: `900` ##### --cdc_stream_records_threshold_size_bytes diff --git a/docs/content/stable/develop/change-data-capture/using-logical-replication/advanced-topic.md b/docs/content/stable/develop/change-data-capture/using-logical-replication/advanced-topic.md index b710c61d5da8..ff7761230ce6 100644 --- a/docs/content/stable/develop/change-data-capture/using-logical-replication/advanced-topic.md +++ b/docs/content/stable/develop/change-data-capture/using-logical-replication/advanced-topic.md @@ -112,19 +112,19 @@ CREATE TABLE test_table_2(id INT PRIMARY KEY, aa INT, bb INT); ### YugabyteDB semantics -Unlike PostgreSQL, any changes made to the publication's tables list are not applied immediately in YugabyteDB. Instead the publication's tables list is periodically refreshed, and changes, if any, are applied. The refresh interval is managed using the [cdcsdk_publication_list_refresh_interval_secs](../../../../reference/configuration/yb-tserver/#cdcsdk-publication-list-refresh-interval-secs) flag. The default is one hour (3600 sec). This means that any changes made to the publication's tables list will be applied after `cdcsdk_publication_list_refresh_interval_secs` in the worst case. +Unlike PostgreSQL, any changes made to the publication's tables list are not applied immediately in YugabyteDB. Instead the publication's tables list is periodically refreshed, and changes, if any, are applied. The refresh interval is managed using the [cdcsdk_publication_list_refresh_interval_secs](../../../../reference/configuration/yb-tserver/#cdcsdk-publication-list-refresh-interval-secs) flag. The default is 15 minutes (900 sec). This means that any changes made to the publication's tables list will be applied after `cdcsdk_publication_list_refresh_interval_secs` in the worst case. Consider the following example: -- Suppose that the value of the flag `cdcsdk_publication_list_refresh_interval_secs` is 3600 sec (1 hour) and the publication's tables list is being refreshed every hour at 8 am, 9 am, 10 am, and so on. +- Suppose that the value of the flag `cdcsdk_publication_list_refresh_interval_secs` is 900 sec (15 minutes) and the publication's tables list is being refreshed every 15 minutes at 8:00 am, 8:15 am, 8:30 am and so on. -- If any change is made to publication's tables list at 8:01 am, then this change will be applied at 9:00 am. However, any change made to publication's tables list at 8:59 am will also be applied at 9:00 am. +- If any change is made to publication's tables list at 8:01 am, then this change will be applied at 8:15 am. However, any change made to publication's tables list at 8:14 am will also be applied at 8:15 am. The value of this flag can be changed at run time, but the change becomes effective only after some time. Continuing the example: -- Suppose that the value of the flag `cdcsdk_publication_list_refresh_interval_secs` is changed from 3600 sec (1 hour) to 600 sec (10 minutes) at 8:01 am. +- Suppose that the value of the flag `cdcsdk_publication_list_refresh_interval_secs` is changed from 900 sec (15 minutes) to 300 sec (5 minutes) at 8:01 am. -- This change will only be applied after 9:00 am. That is, the publication's tables list will be next refreshed at 9:00 am. Then, the next refresh will happen at 9:10 am, and the subsequent refreshes will take place every 10 minutes. +- This change will only be applied after 8:15 am. That is, the publication's tables list will be next refreshed at 8:15 am. Then, the next refresh will happen at 8:20 am, and the subsequent refreshes will take place every 5 minutes. ### Required settings @@ -136,12 +136,14 @@ To enable dynamic table addition, perform the following steps: ./yb-ts-cli --server_address= set_flag cdcsdk_publication_list_refresh_interval_secs 120 ``` -1. After you start receiving records from the newly added table in the publication, reset the `cdcsdk_publication_list_refresh_interval_secs` flag to a high value (for example, 3600 seconds). +1. After you start receiving records from the newly added table in the publication, reset the `cdcsdk_publication_list_refresh_interval_secs` flag back to original value (i.e 900 seconds). ```sh - ./yb-ts-cli --server_address= set_flag cdcsdk_publication_list_refresh_interval_secs 3600 + ./yb-ts-cli --server_address= set_flag cdcsdk_publication_list_refresh_interval_secs 900 ``` +> **Note:** In the event that user ends up reducing the value of `cdcsdk_publication_list_refresh_interval_secs`, it is recommended to increase the value of the flag back to its original value once you start receiving changes from the new table. + ## Initial snapshot The [initial snapshot](../../../../architecture/docdb-replication/cdc-logical-replication/#initial-snapshot) data for a table is consumed by executing a snapshot query (SELECT statement). To ensure that the streaming phase continues exactly from where the snapshot left, this snapshot query is executed as of a specific database state. In YugabyteDB, this database state is represented by a value of `HybridTime`. Changes due to transactions with commit time strictly greater than this snapshot `HybridTime` will be consumed during the streaming phase. diff --git a/docs/content/stable/explore/change-data-capture.md b/docs/content/stable/explore/change-data-capture.md index 1eff18651c43..7cbf6e95e90b 100644 --- a/docs/content/stable/explore/change-data-capture.md +++ b/docs/content/stable/explore/change-data-capture.md @@ -57,7 +57,7 @@ To set up pg_recvlogical, create and start the local cluster by running the foll ./bin/yugabyted start \ --advertise_address=127.0.0.1 \ --base_dir="${HOME}/var/node1" \ - --tserver_flags="cdcsdk_publication_list_refresh_interval_secs=2" + --tserver_flags="cdcsdk_publication_list_refresh_interval_secs=120" ``` ### Create tables @@ -166,6 +166,8 @@ table public.projects: INSERT: project_id[integer]:1 name[character varying]:'Pr COMMIT 3 ``` +The yugabyte semantics are different from Postgres when it comes to streaming added tables to a publication. Refer the [yugabyte semantics](../develop/change-data-capture/using-logical-replication/advanced-topic.md#yugabytedb-semantics) for more details. + {{% explore-cleanup-local %}} ## Learn more diff --git a/docs/content/stable/reference/configuration/yb-master.md b/docs/content/stable/reference/configuration/yb-master.md index 3fc61acfc329..34ea4460640a 100644 --- a/docs/content/stable/reference/configuration/yb-master.md +++ b/docs/content/stable/reference/configuration/yb-master.md @@ -941,6 +941,18 @@ WAL retention time, in seconds, to be used for tables for which a CDC stream was Default: `28800` (8 hours) +##### --cdc_intent_retention_ms + +The time period, in milliseconds, after which the intents will be cleaned up if there is no client polling for the change records. + +Default: `28800000` (8 hours) + +##### --cdcsdk_tablet_not_of_interest_timeout_secs + +Timeout after which it is inferred that a particular tablet is not of interest for CDC. To indicate that a particular tablet is of interest for CDC, it should be polled at least once within this interval of stream / slot creation. + +Default: `14400` (4 hours) + ##### --enable_tablet_split_of_cdcsdk_streamed_tables Toggle automatic tablet splitting for tables in a CDCSDK stream, enhancing user control over replication processes. diff --git a/docs/content/stable/reference/configuration/yb-tserver.md b/docs/content/stable/reference/configuration/yb-tserver.md index 08c16a3df33f..3aa3115c2257 100644 --- a/docs/content/stable/reference/configuration/yb-tserver.md +++ b/docs/content/stable/reference/configuration/yb-tserver.md @@ -1376,7 +1376,7 @@ Default: `true` Interval in seconds at which the table list in the publication will be refreshed. -Default: `3600` +Default: `900` ##### --cdc_stream_records_threshold_size_bytes From 86e594dc267828d00aef5526bbf1404aab259db3 Mon Sep 17 00:00:00 2001 From: Sumukh-Phalgaonkar Date: Thu, 6 Feb 2025 16:25:18 +0530 Subject: [PATCH 2/6] Add limitation about multiple consumers and mention cdcsdk_flush_lag metric --- .../change-data-capture/using-logical-replication/_index.md | 2 ++ .../change-data-capture/using-logical-replication/monitor.md | 3 ++- .../change-data-capture/using-logical-replication/_index.md | 2 ++ .../change-data-capture/using-logical-replication/monitor.md | 4 +++- 4 files changed, 9 insertions(+), 2 deletions(-) diff --git a/docs/content/preview/develop/change-data-capture/using-logical-replication/_index.md b/docs/content/preview/develop/change-data-capture/using-logical-replication/_index.md index 0c6680b3500b..42557c35eb25 100644 --- a/docs/content/preview/develop/change-data-capture/using-logical-replication/_index.md +++ b/docs/content/preview/develop/change-data-capture/using-logical-replication/_index.md @@ -116,3 +116,5 @@ For reference documentation, see [YugabyteDB Connector](./yugabytedb-connector/) - Support for enabling CDC on Read Replicas is tracked in issue [11116](https://github.com/yugabyte/yugabyte-db/issues/11116). - Support for tablet splitting with logical replication is disabled from v2024.1.4 and v2024.2.1. Tracked in issue [24918](https://github.com/yugabyte/yugabyte-db/issues/24918). + +- A replication slot should be consumed by atmost one consumer at a time. However currently, there does not exist a locking mechanism to enforce this. Hence the user should ensure that multiple consumers should not consume from a slot simultaneously. Tracked in issue [20755](https://github.com/yugabyte/yugabyte-db/issues/20755) diff --git a/docs/content/preview/develop/change-data-capture/using-logical-replication/monitor.md b/docs/content/preview/develop/change-data-capture/using-logical-replication/monitor.md index c0fd089c0cf3..fc56ebb1ffce 100644 --- a/docs/content/preview/develop/change-data-capture/using-logical-replication/monitor.md +++ b/docs/content/preview/develop/change-data-capture/using-logical-replication/monitor.md @@ -79,8 +79,9 @@ Provide information about the CDC service in YugabyteDB. | :---- | :---- | :---- | | cdcsdk_change_event_count | `long` | The number of records sent by the CDC Service. | | cdcsdk_traffic_sent | `long` | Total traffic sent, in bytes. | -| cdcsdk_sent_lag_micros | `long` | The LAG metric is calculated by subtracting the timestamp of the latest record in the WAL of a tablet from the last record sent to the CDC connector. | +| cdcsdk_sent_lag_micros | `long` | This lag metric is calculated by subtracting the timestamp of the latest record in the WAL of a tablet from the last record sent to the CDC connector. | | cdcsdk_expiry_time_ms | `long` | The time left to read records from WAL is tracked by the Stream Expiry Time (ms). | +| cdcsdk_flush_lag | `long` | This lag metric shows the difference between the timestamp of the latest record in the WAL and the replication slot's restart time.| CDC service metrics are only calculated for tablets that are of interest for a replication slot. By default, tablets are considered to be of interest if they are polled at least once in 4 hours. You can configure the frequency using the [cdcsdk_tablet_not_of_interest_timeout_secs](../../../../reference/configuration/yb-tserver/#cdcsdk-tablet-not-of-interest-timeout-secs) YB-TServer flag. Metrics are calculated considering unpolled tablets until this timeout elapses. diff --git a/docs/content/stable/develop/change-data-capture/using-logical-replication/_index.md b/docs/content/stable/develop/change-data-capture/using-logical-replication/_index.md index 1dd0175e6d70..f82aa4016064 100644 --- a/docs/content/stable/develop/change-data-capture/using-logical-replication/_index.md +++ b/docs/content/stable/develop/change-data-capture/using-logical-replication/_index.md @@ -114,3 +114,5 @@ For reference documentation, see [YugabyteDB Connector](./yugabytedb-connector/) - Support for enabling CDC on Read Replicas is tracked in issue [11116](https://github.com/yugabyte/yugabyte-db/issues/11116). - Support for tablet splitting with logical replication is disabled from v2024.1.4 and v2024.2.1. Tracked in issue [24918](https://github.com/yugabyte/yugabyte-db/issues/24918). + +- A replication slot should be consumed by atmost one consumer at a time. However currently, there does not exist a locking mechanism to enforce this. Hence the user should ensure that multiple consumers should not consume from a slot simultaneously. Tracked in issue [20755](https://github.com/yugabyte/yugabyte-db/issues/20755) diff --git a/docs/content/stable/develop/change-data-capture/using-logical-replication/monitor.md b/docs/content/stable/develop/change-data-capture/using-logical-replication/monitor.md index 5391e9c8c9bb..3ae7c7cd31a8 100644 --- a/docs/content/stable/develop/change-data-capture/using-logical-replication/monitor.md +++ b/docs/content/stable/develop/change-data-capture/using-logical-replication/monitor.md @@ -77,8 +77,10 @@ Provide information about the CDC service in YugabyteDB. | :---- | :---- | :---- | | cdcsdk_change_event_count | `long` | The number of records sent by the CDC Service. | | cdcsdk_traffic_sent | `long` | Total traffic sent, in bytes. | -| cdcsdk_sent_lag_micros | `long` | The LAG metric is calculated by subtracting the timestamp of the latest record in the WAL of a tablet from the last record sent to the CDC connector. | +| cdcsdk_sent_lag_micros | `long` | This lag metric is calculated by subtracting the timestamp of the latest record in the WAL of a tablet from the last record sent to the CDC connector. | | cdcsdk_expiry_time_ms | `long` | The time left to read records from WAL is tracked by the Stream Expiry Time (ms). | +| cdcsdk_flush_lag | `long` | This lag metric shows the difference between the timestamp of the latest record in the WAL and the replication slot's restart time.| + CDC service metrics are only calculated for tablets that are of interest for a replication slot. By default, tablets are considered to be of interest if they are polled at least once in 4 hours. You can configure the frequency using the [cdcsdk_tablet_not_of_interest_timeout_secs](../../../../reference/configuration/yb-tserver/#cdcsdk-tablet-not-of-interest-timeout-secs) YB-TServer flag. Metrics are calculated considering unpolled tablets until this timeout elapses. From 6dafc26661b8ce6632e7484a1e37a4cd63b77bb4 Mon Sep 17 00:00:00 2001 From: Sumukh-Phalgaonkar <61342752+Sumukh-Phalgaonkar@users.noreply.github.com> Date: Wed, 19 Feb 2025 19:05:36 +0530 Subject: [PATCH 3/6] Update docs/content/preview/develop/change-data-capture/using-logical-replication/_index.md Co-authored-by: Vaibhav Kushwaha <34186745+vaibhav-yb@users.noreply.github.com> --- .../change-data-capture/using-logical-replication/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/preview/develop/change-data-capture/using-logical-replication/_index.md b/docs/content/preview/develop/change-data-capture/using-logical-replication/_index.md index 42557c35eb25..48b315a79eac 100644 --- a/docs/content/preview/develop/change-data-capture/using-logical-replication/_index.md +++ b/docs/content/preview/develop/change-data-capture/using-logical-replication/_index.md @@ -117,4 +117,4 @@ For reference documentation, see [YugabyteDB Connector](./yugabytedb-connector/) - Support for tablet splitting with logical replication is disabled from v2024.1.4 and v2024.2.1. Tracked in issue [24918](https://github.com/yugabyte/yugabyte-db/issues/24918). -- A replication slot should be consumed by atmost one consumer at a time. However currently, there does not exist a locking mechanism to enforce this. Hence the user should ensure that multiple consumers should not consume from a slot simultaneously. Tracked in issue [20755](https://github.com/yugabyte/yugabyte-db/issues/20755) +- A replication slot should be consumed by at most one consumer at a time. However currently, there does not exist a locking mechanism to enforce this. Hence the user should ensure that multiple consumers should not consume from a slot simultaneously. Tracked in issue [20755](https://github.com/yugabyte/yugabyte-db/issues/20755). From 395da8c3c0259e6ef09ebf45d963e04128884113 Mon Sep 17 00:00:00 2001 From: Sumukh-Phalgaonkar <61342752+Sumukh-Phalgaonkar@users.noreply.github.com> Date: Wed, 19 Feb 2025 19:06:51 +0530 Subject: [PATCH 4/6] Update docs/content/preview/develop/change-data-capture/using-logical-replication/advanced-topic.md Co-authored-by: Vaibhav Kushwaha <34186745+vaibhav-yb@users.noreply.github.com> --- .../using-logical-replication/advanced-topic.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/content/preview/develop/change-data-capture/using-logical-replication/advanced-topic.md b/docs/content/preview/develop/change-data-capture/using-logical-replication/advanced-topic.md index cd9c159e1871..cb428627e0cc 100644 --- a/docs/content/preview/develop/change-data-capture/using-logical-replication/advanced-topic.md +++ b/docs/content/preview/develop/change-data-capture/using-logical-replication/advanced-topic.md @@ -144,7 +144,9 @@ To enable dynamic table addition, perform the following steps: ./yb-ts-cli --server_address= set_flag cdcsdk_publication_list_refresh_interval_secs 900 ``` -> **Note:** In the event that a user ends up reducing the value of `cdcsdk_publication_list_refresh_interval_secs`, it is recommended to increase the value of the flag back to its original value once you start receiving changes from the new table. +{{< note title="Important" >}} +In the event that a user ends up reducing the value of `cdcsdk_publication_list_refresh_interval_secs`, it is recommended to increase the value of the flag back to its original value once you start receiving changes from the new table. +{{< /note >}} ## Initial snapshot From 4ce8ffb0f78e8521b546b0b44a97abf3e92a6f27 Mon Sep 17 00:00:00 2001 From: Sumukh-Phalgaonkar <61342752+Sumukh-Phalgaonkar@users.noreply.github.com> Date: Wed, 19 Feb 2025 19:07:06 +0530 Subject: [PATCH 5/6] Update docs/content/preview/explore/change-data-capture.md Co-authored-by: Vaibhav Kushwaha <34186745+vaibhav-yb@users.noreply.github.com> --- docs/content/preview/explore/change-data-capture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/preview/explore/change-data-capture.md b/docs/content/preview/explore/change-data-capture.md index 1572694aaf2b..834561fb3229 100644 --- a/docs/content/preview/explore/change-data-capture.md +++ b/docs/content/preview/explore/change-data-capture.md @@ -166,7 +166,7 @@ table public.projects: INSERT: project_id[integer]:1 name[character varying]:'Pr COMMIT 3 ``` -The yugabyte semantics are different from Postgres when it comes to streaming added tables to a publication. Refer the [yugabyte semantics](../develop/change-data-capture/using-logical-replication/advanced-topic.md#yugabytedb-semantics) for more details. +YugabyteDB semantics are different from PostgreSQL when it comes to streaming added tables to a publication. Refer the [YugabyteDB semantics](../develop/change-data-capture/using-logical-replication/advanced-topic.md#yugabytedb-semantics) for more details. {{% explore-cleanup-local %}} From 6b10da9de10a1f6cfc02990ace38b46a738a1dc3 Mon Sep 17 00:00:00 2001 From: Sumukh-Phalgaonkar Date: Thu, 20 Feb 2025 18:08:24 +0530 Subject: [PATCH 6/6] Addressed review comments --- .../change-data-capture/using-logical-replication/_index.md | 2 +- .../using-logical-replication/advanced-topic.md | 4 +++- docs/content/stable/explore/change-data-capture.md | 2 +- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/content/stable/develop/change-data-capture/using-logical-replication/_index.md b/docs/content/stable/develop/change-data-capture/using-logical-replication/_index.md index f82aa4016064..f9f59627831f 100644 --- a/docs/content/stable/develop/change-data-capture/using-logical-replication/_index.md +++ b/docs/content/stable/develop/change-data-capture/using-logical-replication/_index.md @@ -115,4 +115,4 @@ For reference documentation, see [YugabyteDB Connector](./yugabytedb-connector/) - Support for tablet splitting with logical replication is disabled from v2024.1.4 and v2024.2.1. Tracked in issue [24918](https://github.com/yugabyte/yugabyte-db/issues/24918). -- A replication slot should be consumed by atmost one consumer at a time. However currently, there does not exist a locking mechanism to enforce this. Hence the user should ensure that multiple consumers should not consume from a slot simultaneously. Tracked in issue [20755](https://github.com/yugabyte/yugabyte-db/issues/20755) +- A replication slot should be consumed by at most one consumer at a time. However currently, there does not exist a locking mechanism to enforce this. Hence the user should ensure that multiple consumers should not consume from a slot simultaneously. Tracked in issue [20755](https://github.com/yugabyte/yugabyte-db/issues/20755). diff --git a/docs/content/stable/develop/change-data-capture/using-logical-replication/advanced-topic.md b/docs/content/stable/develop/change-data-capture/using-logical-replication/advanced-topic.md index ff7761230ce6..066f6bb9e500 100644 --- a/docs/content/stable/develop/change-data-capture/using-logical-replication/advanced-topic.md +++ b/docs/content/stable/develop/change-data-capture/using-logical-replication/advanced-topic.md @@ -142,7 +142,9 @@ To enable dynamic table addition, perform the following steps: ./yb-ts-cli --server_address= set_flag cdcsdk_publication_list_refresh_interval_secs 900 ``` -> **Note:** In the event that user ends up reducing the value of `cdcsdk_publication_list_refresh_interval_secs`, it is recommended to increase the value of the flag back to its original value once you start receiving changes from the new table. +{{< note title="Important" >}} +In the event that user ends up reducing the value of `cdcsdk_publication_list_refresh_interval_secs`, it is recommended to increase the value of the flag back to its original value once you start receiving changes from the new table. +{{< /note >}} ## Initial snapshot diff --git a/docs/content/stable/explore/change-data-capture.md b/docs/content/stable/explore/change-data-capture.md index 7cbf6e95e90b..138d25c6bb27 100644 --- a/docs/content/stable/explore/change-data-capture.md +++ b/docs/content/stable/explore/change-data-capture.md @@ -166,7 +166,7 @@ table public.projects: INSERT: project_id[integer]:1 name[character varying]:'Pr COMMIT 3 ``` -The yugabyte semantics are different from Postgres when it comes to streaming added tables to a publication. Refer the [yugabyte semantics](../develop/change-data-capture/using-logical-replication/advanced-topic.md#yugabytedb-semantics) for more details. +YugabyteDB semantics are different from PostgreSQL when it comes to streaming added tables to a publication. Refer the [YugabyteDB semantics](../develop/change-data-capture/using-logical-replication/advanced-topic.md#yugabytedb-semantics) for more details. {{% explore-cleanup-local %}}