iSignal
diff --git a/‎.github/vale-styles/Yugabyte/spelling-exceptions.txt‎
Lines changed: 1 addition & 0 deletions b/‎.github/vale-styles/Yugabyte/spelling-exceptions.txt‎
Lines changed: 1 addition & 0 deletions
diff --git a/‎docs/content/preview/architecture/docdb-replication/cdc-logical-replication.md‎
Lines changed: 2 additions & 2 deletions b/‎docs/content/preview/architecture/docdb-replication/cdc-logical-replication.md‎
Lines changed: 2 additions & 2 deletions
diff --git a/‎docs/content/preview/architecture/docdb-replication/change-data-capture.md‎
Lines changed: 1 addition & 1 deletion b/‎docs/content/preview/architecture/docdb-replication/change-data-capture.md‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎docs/content/preview/explore/change-data-capture/_index.md‎
Lines changed: 5 additions & 9 deletions b/‎docs/content/preview/explore/change-data-capture/_index.md‎
Lines changed: 5 additions & 9 deletions
diff --git a/‎docs/content/preview/explore/change-data-capture/using-logical-replication/_index.md‎
Lines changed: 107 additions & 8 deletions b/‎docs/content/preview/explore/change-data-capture/using-logical-replication/_index.md‎
Lines changed: 107 additions & 8 deletions
diff --git a/‎docs/content/preview/explore/change-data-capture/using-logical-replication/advanced-configuration.md‎
Lines changed: 29 additions & 5 deletions b/‎docs/content/preview/explore/change-data-capture/using-logical-replication/advanced-configuration.md‎
Lines changed: 29 additions & 5 deletions
@@ -445,6 +445,7 @@ Patroni
 performant
 PgBouncer
 pgLoader
+pg_recvlogical
 Phabricator
 phaser
 phasers
 
@@ -17,7 +17,7 @@ type: docs
 
 Change data capture (CDC) in YugabyteDB provides technology to ensure that any changes in data due to operations such as inserts, updates, and deletions are identified, captured, and made available for consumption by applications and other tools.
 
-CDC in YugabyteDB is based on the PostgreSQL Logical Replication model. The fundamental concept here is that of the Replication Slot. A Replication Slot represents a stream of changes that can be replayed to the client in the order they were made on the origin server in a manner that preserves transactional consistency. This is the basis for the support for Transactional CDC in YugabyteDB. Where the strict requirements of Transactional CDC are not present, multiple replication slots can be used to stream changes from unrelated tables in parallel.
+CDC in YugabyteDB is based on the PostgreSQL Logical Replication model. The fundamental concept is that of the Replication Slot. A Replication Slot represents a stream of changes that can be replayed to the client in the order they were made on the origin server in a manner that preserves transactional consistency. This is the basis for the support for Transactional CDC in YugabyteDB. Where the strict requirements of Transactional CDC are not present, multiple replication slots can be used to stream changes from unrelated tables in parallel.
 
 ## Architecture
 
@@ -35,7 +35,7 @@ The following are the main components of the Yugabyte CDC solution:
 
 Logical replication starts by copying a snapshot of the data on the publisher database. After that is done, changes on the publisher are streamed to the server as they occur in near real time.
 
-To setup Logical Replication, an application will first have to create a replication slot. When a replication slot is created, a boundary is established between the snapshot data and the streaming changes. This boundary or `consistent_point` is a consistent state of the source database. It corresponds to a commit time (HybridTime value). Data from transactions with commit time <= commit time corresponding to the `consistent_point` are consumed as part of the initial snapshot. Changes from transactions with commit time greater than the commit time of the `consistent_point` are consumed in the streaming phase in transaction commit time order.
+To set up Logical Replication, an application will first have to create a replication slot. When a replication slot is created, a boundary is established between the snapshot data and the streaming changes. This boundary or `consistent_point` is a consistent state of the source database. It corresponds to a commit time (HybridTime value). Data from transactions with commit time <= commit time corresponding to the `consistent_point` are consumed as part of the initial snapshot. Changes from transactions with commit time greater than the commit time of the `consistent_point` are consumed in the streaming phase in transaction commit time order.
 
 #### Initial Snapshot
 
 
@@ -33,7 +33,7 @@ Each tablet has its own WAL file. WAL is NOT in-memory, but it is disk persisted
 
 YugabyteDB normally purges WAL segments after some period of time. This means that the connector does not have the complete history of all changes that have been made to the database. Therefore, when the connector first connects to a particular YugabyteDB database, it starts by performing a consistent snapshot of each of the database schemas.
 
-The Debezium YugabyteDB connector captures row-level changes in the schemas of a YugabyteDB database. The first time it connects to a YugabyteDB cluster, the connector takes a consistent snapshot of all schemas. After that snapshot is complete, the connector continuously captures row-level changes that insert, update, and delete database content, and that were committed to a YugabyteDB database.
+The YugabyteDB Debezium connector captures row-level changes in the schemas of a YugabyteDB database. The first time it connects to a YugabyteDB cluster, the connector takes a consistent snapshot of all schemas. After that snapshot is complete, the connector continuously captures row-level changes that insert, update, and delete database content, and that were committed to a YugabyteDB database.
 
 ![How does CDC work](/images/explore/cdc-overview-work.png)
 
 
@@ -4,7 +4,7 @@ headerTitle: Change data capture (CDC)
 linkTitle: Change data capture
 description: CDC or Change data capture is a process to capture changes made to data in the database.
 headcontent: Capture changes made to data in the database
-image: /images/section_icons/index/develop.png
+image: fa-light fa-rotate
 cascade:
   earlyAccess: /preview/releases/versioning/#feature-maturity
 menu:
@@ -26,23 +26,19 @@ In databases, change data capture (CDC) is a set of software design patterns use
 
 YugabyteDB supports the following methods for reading change events.
 
-## PostgreSQL Logical Replication Protocol (Recommended)
+## PostgreSQL Replication Protocol
 
-This method uses the PostgreSQL replication protocol, ensuring compatibility with PostgreSQL CDC systems. Logical replication operates through a publish-subscribe model. It replicates data objects and their changes based on the replication identity.
+This method uses the [PostgreSQL replication protocol](using-logical-replication/key-concepts/#replication-protocols), ensuring compatibility with PostgreSQL CDC systems. Logical replication operates through a publish-subscribe model. It replicates data objects and their changes based on the replication identity.
 
 It works as follows:
 
 1. Create Publications in the YugabyteDB cluster similar to PostgreSQL.
 1. Deploy the YugabyteDB Connector in your preferred Kafka Connect environment.
 1. The connector uses replication slots to capture change events and publishes them directly to a Kafka topic.
 
-This is the recommended approach for most CDC applications due to its compatibility with PostgreSQL.
-
-<!--
 {{<lead link="./using-logical-replication/">}}
-To learn about PostgreSQL Logical Replication, see [Using PostgreSQL Logical Replication](./debezium-connector-yugabytedb/).
+To learn about CDC in YugabyteDB using the PostgreSQL Replication Protocol, see [CDC using PostgreSQL Replication Protocol](./using-logical-replication).
 {{</lead>}}
--->
 
 ## YugabyteDB gRPC Replication Protocol
 
@@ -55,5 +51,5 @@ It works as follows:
 1. The connector captures change events using YugabyteDB's native gRPC replication and directly publishes them to a Kafka topic.
 
 {{<lead link="./using-yugabytedb-grpc-replication/">}}
-To learn about gRPC Replication, see [Using YugabyteDB gRPC Replication](./using-yugabytedb-grpc-replication/).
+To learn about CDC in YugabyteDB using the gRPC Replication Protocol, see [CDC using gRPC Replication Protocol](./using-yugabytedb-grpc-replication/).
 {{</lead>}}
@@ -1,10 +1,9 @@
-<!---
-title: Using logical replication
-headerTitle: Using logical replication
-linkTitle: Using logical replication
-description: CDC or Change data capture is a process to capture changes made to data in the database.
+---
+title: CDC using PostgreSQL replication protocol
+headerTitle: CDC using PostgreSQL replication protocol
+linkTitle: PostgreSQL protocol
+description: CDC using YugabyteDB PostgreSQL replication protocol.
 headcontent: Capture changes made to data in the database
-image: /images/section_icons/index/develop.png
 cascade:
   earlyAccess: /preview/releases/versioning/#feature-maturity
 menu:
@@ -13,5 +12,105 @@ menu:
     parent: explore-change-data-capture
     weight: 240
 type: indexpage
-private: true
---->
+showRightNav: true
+---
+
+## Overview
+
+YugabyteDB CDC captures changes made to data in the database and streams those changes to external processes, applications, or other databases. CDC allows you to track and propagate changes in a YugabyteDB database to downstream consumers based on its Write-Ahead Log (WAL). YugabyteDB CDC captures row-level changes resulting from INSERT, UPDATE, and DELETE operations in the configured database and publishes it further to be consumed by downstream applications.
+
+### Highlights
+
+#### Resilience
+
+YugabyteDB CDC with PostgreSQL Logical Replication provides resilience as follows:
+
+1. Following a failure of the application, server, or network, the replication can continue from any of the available server nodes.
+
+2. Replication continues from the transaction immediately after the transaction that was last acknowledged by the application. No transactions are missed by the application.
+
+#### Security
+
+Because YugabyteDB is using the PostgreSQL Logical Replication model, the following applies:
+
+- The CDC user persona will be a PostgreSQL replication client.
+
+- A standard replication connection is used for consumption, and all the server-side configurations for authentication, authorizations, SSL modes, and connection load balancing can be leveraged automatically.
+
+#### Guarantees
+
+CDC in YugabyteDB provides the following guarantees.
+
+| GUARANTEE | DESCRIPTION |
+| :----- | :----- |
+| Per-slot ordered delivery guarantee | Changes from transactions from all the tables that are part of the replication slot's publication are received in the order they were committed. This also implies ordered delivery across all the tablets that are part of the publication's table list. |
+| At least once delivery | Changes from transactions are streamed at least once. Changes from transactions may be streamed again in case of restart after failure. For example, this can happen in the case of a Kafka Connect node failure. If the Kafka Connect node pushes the records to Kafka and crashes before committing the offset, it will again get the same set of records upon restart. |
+| No gaps in change stream | Receiving changes that are part of a transaction with commit time *t* implies that you have already received changes from all transactions with commit time lower than *t*. Thus, receiving any change for a row with commit timestamp *t* implies that you have received all older changes for that row. |
+
+## Key concepts
+
+The YugabyteDB logical replication feature makes use of PostgreSQL concepts like replication slot, publication, replica identity, and so on. Understanding these key concepts is crucial for setting up and managing a logical replication environment effectively.
+
+{{<lead link="./key-concepts">}}
+To know more about the key concepts of YugabyteDB CDC with logical replication, see [Key concepts](./key-concepts).
+{{</lead>}}
+
+## Getting started
+
+Get started with YugabyteDB logical replication using the YugabyteDB Connector.
+
+{{<lead link="./get-started">}}
+
+To learn how get started with the connector, see [Get started](./get-started).
+
+{{</lead>}}
+
+## Monitoring
+
+You can monitor the activities and status of the deployed connectors using the http end points provided by YugabyteDB.
+
+{{<lead link="./monitor">}}
+To know more about how to monitor your CDC setup, see [Monitor](./monitor/).
+{{</lead>}}
+
+## YugabyteDB Connector
+
+To capture and stream your changes in YugabyteDB to an external system, you need a connector that can read the changes in YugabyteDB and stream it out. For this, you can use the YugabyteDB Connector, which is based on the Debezium platform. The connector is deployed as a set of Kafka Connect-compatible connectors, so you first need to define a YugabyteDB connector configuration and then start the connector by adding it to Kafka Connect.
+
+{{<lead link="./yugabytedb-connector/">}}
+To understand how the various features and configuration of the connector, see [YugabyteDB Connector](./yugabytedb-connector/).
+{{</lead>}}
+
+## Limitations
+
+- LSN Comparisons Across Slots.
+
+    In the case of YugabyteDB, the LSN  does not represent the byte offset of a WAL record. Hence, arithmetic on LSN and any other usages of the LSN making this assumption will not work. Also, currently, comparison of LSN values from messages coming from different replication slots is not supported.
+
+- The following functions are currently unsupported:
+
+  - `pg_current_wal_lsn`
+  - `pg_wal_lsn_diff`
+  - `IDENTIFY SYSTEM`
+  - `txid_current`
+  - `pg_stat_replication`
+
+  Additionally, the functions responsible for pulling changes instead of the server streaming it are unsupported as well. They are described in [Replication Functions](https://www.postgresql.org/docs/11/functions-admin.html#FUNCTIONS-REPLICATION) in the PostgreSQL documentation.
+
+- Restriction on DDLs
+
+    DDL operations should not be performed from the time of replication slot creation till the start of snapshot consumption of the last table.
+
+- There should be a primary key on the table you want to stream the changes from.
+
+- CDC is not supported on a target table for xCluster replication [11829](https://github.com/yugabyte/yugabyte-db/issues/11829).
+
+- Currently we don't support schema evolution for changes that require table rewrites (ex: ALTER TYPE).
+
+- YCQL tables aren't currently supported. Issue [11320](https://github.com/yugabyte/yugabyte-db/issues/11320).
+
+- Support for point-in-time recovery (PITR) is tracked in issue [10938](https://github.com/yugabyte/yugabyte-db/issues/10938).
+
+- Support for transaction savepoints is tracked in issue [10936](https://github.com/yugabyte/yugabyte-db/issues/10936).
+
+- Support for enabling CDC on Read Replicas is tracked in issue [11116](https://github.com/yugabyte/yugabyte-db/issues/11116).
@@ -1,12 +1,36 @@
 ---
-title: Advanced Configurations
-headerTitle: Advanced Configurations
-linkTitle: Advanced Configurations
-description: Advanced Configurations for Change Data Capture in YugabyteDB.
+title: Advanced configurations for CDC using Logical Replication
+headerTitle: Advanced configuration
+linkTitle: Advanced configuration
+description: Advanced Configurations for Logical Replication.
+headcontent: Tune your CDC configuration
 menu:
   preview:
     parent: explore-change-data-capture-logical-replication
     identifier: advanced-configurations
     weight: 40
 type: docs
----
+---
+
+## YB-TServer flags
+
+You can use the following [YB-TServer flags](../../../../reference/configuration/yb-tserver/) to tune logical replication deployment configuration:
+
+- [ysql_yb_default_replica_identity](../../../../reference/configuration/yb-tserver/#ysql-yb-default-replica-identity)
+- [cdcsdk_enable_dynamic_table_support](../../../../reference/configuration/yb-tserver/#cdcsdk-enable-dynamic-table-support)
+- [cdcsdk_publication_list_refresh_interval_secs](../../../../reference/configuration/yb-tserver/#cdcsdk-publication-list-refresh-interval-secs)
+- [cdcsdk_max_consistent_records](../../../../reference/configuration/yb-tserver/#cdcsdk-max-consistent-records)
+- [cdcsdk_vwal_getchanges_resp_max_size_bytes](../../../../reference/configuration/yb-tserver/#cdcsdk-vwal-getchanges-resp-max-size-bytes)
+
+## Retention of resources
+
+CDC retains resources (such as WAL segments) that contain information related to the changes involved in the transactions. These resources are typically retained until the consuming client acknowledges the receipt of all the transactions contained in that resource.
+
+Retaining resources has an impact on the system. Clients are expected to consume these transactions within configurable duration limits. Resources will be released if the duration exceeds these configured limits.
+
+Use the following flags to control the duration for which resources are retained:
+
+- [cdc_wal_retention_secs](../../../../reference/configuration/yb-tserver/#cdc-wal-retention-secs)
+- [cdc_intent_retention_ms](../../../../reference/configuration/yb-tserver/#cdc-intent-retention-ms)
+
+Resources are retained for each tablet of a table that is part of a database whose changes are being consumed using a replication slot. This includes those tables that may not be currently part of the publication specification.