From fa28c91fe35b16912f7af944d250d67d4da27b9e Mon Sep 17 00:00:00 2001 From: Vaibhav Kushwaha Date: Tue, 31 Dec 2024 13:22:52 +0530 Subject: [PATCH 1/9] added example record structure for pgcompatible --- .../using-logical-replication/transformers.md | 125 ++++++++++++++++++ .../yugabytedb-grpc-transformers.md | 125 ++++++++++++++++++ 2 files changed, 250 insertions(+) create mode 100644 docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md create mode 100644 docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md diff --git a/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md b/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md new file mode 100644 index 000000000000..8a2e39c976b4 --- /dev/null +++ b/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md @@ -0,0 +1,125 @@ +--- +title: YugabyteDB connector transformers +headerTitle: YugabyteDB connector transformers +linkTitle: Connector transformers +description: YugabyteDB connector transformers for Change Data Capture in YugabyteDB. +menu: + preview: + parent: yugabytedb-connector + identifier: yugabytedb-connector-transformers + weight: 70 +type: docs +--- + +The connector comes bundled with some SMTs which can ease in the data flow and help achieve the right message format as per the requirement. The following transformers are bundled with the connector jar file available on [GitHub releases](https://github.com/yugabyte/debezium/releases): + +* YBExtractNewRecordState +* PGCompatible + +{{< note title="Important" >}} + +The above mentioned transformers are only expected to be used with logical replication when the [plugin](../using-logical-replication/key-concepts#output-plugin) being used is `yboutput`. + +{{ < /note >}} + +Note that for maintaining simplicity, only the `before` and `after` fields of the `payload` of the message published by the connector will be mentioned in the following examples. Any information pertaining to the record schema, if same as the standard Debezium connector for Postgres, will be skipped. + +Consider a table created using the following statement: + +```sql +CREATE TABLE test (id INT PRIMARY KEY, name TEXT, aura INT); +``` + +The following DML statements will be used to demonstrate payload in case of individual replica identities: + +```sql +-- statement 1 +INSERT INTO test VALUES (1, 'Vaibhav', 9876); + +-- statement 2 +UPDATE test SET aura = 9999 WHERE id = 1; + +-- statement 3 +UPDATE test SET name = 'Vaibhav Kushwaha', aura = 10 WHERE id = 1; + +-- statement 4 +UPDATE test SET aura = NULL WHERE id = 1; + +-- statement 5 +DELETE FROM test WHERE id = 1; +``` + +## YBExtractNewRecordState + +**Transformer class:** + +### PGCompatible + +**Transformer class:** `io.debezium.connector.postgresql.transforms.PGCompatible` + +By default, the YugabyteDB CDC service publishes events with a schema that only includes columns that have been modified. The source connector then sends the value as `null` for columns that are missing in the payload. Each column payload includes a `set` field that is used to signal if a column has been set to `null` because it wasn't present in the payload from YugabyteDB. + +However, some sink connectors may not understand the preceding format. `PGCompatible` transforms the payload to a format that is compatible with the format of the standard change data events. Specifically, it transforms column schema and value to remove the `set` field and collapse the payload such that it only contains the data type schema and value. + +`PGCompatible` differs from `YBExtractNewRecordState` by recursively modifying all the fields in a payload. + +Following are the examples how the payload would look like for each [replica identity](../using-logical-replication/key-concepts/#replica-identity). + +### CHANGE + +``` +-- statement 1 +"before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} + +-- statement 2 +"before":null,"after":{"id":1,"name":null,"aura":9999} + +-- statement 3 +"before":null,"after":{"id":1,"name":"Vaibhav Kushwaha","aura":10} + +-- statement 4 +"before":null,"after":{"id":1,"name":null,"aura":null} + +-- statement 5 +"before":{"id":1,"name":null,"aura":null},"after":null +``` + +Do note that for statement 2 and 4, the columns which were not updated as a part of the `UPDATE` statement, they're `null` in the output field. + +### DEFAULT + +``` +-- statement 1 +"before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} + +-- statement 2 +"before":null,"after":{"id":1,"name":"Vaibhav","aura":9999} + +-- statement 3 +"before":null,"after":{"id":1,"name":"Vaibhav Kushwaha","aura":10} + +-- statement 4 +"before":null,"after":{"id":1,"name":"Vaibhav Kushwaha","aura":null} + +-- statement 5 +"before":{"id":1,"name":null,"aura":null},"after":null +``` + +### FULL + +``` +-- statement 1 +"before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} + +-- statement 2 +"before":{"id":1,"name":"Vaibhav","aura":9876},"after":{"id":1,"name":"Vaibhav","aura":9999} + +-- statement 3 +"before":{"id":1,"name":"Vaibhav","aura":9999},"after":{"id":1,"name":"Vaibhav Kushwaha","aura":10} + +-- statement 4 +"before":{"id":1,"name":"Vaibhav Kushwaha","aura":10},"after":{"id":1,"name":"Vaibhav Kushwaha","aura":null} + +-- statement 5 +"before":{"id":1,"name":"Vaibhav Kushwaha","aura":null},"after":null +``` diff --git a/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md b/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md new file mode 100644 index 000000000000..fdcb56757a9f --- /dev/null +++ b/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md @@ -0,0 +1,125 @@ +--- +title: YugabyteDB gRPC connector transformers +headerTitle: YugabyteDB gRPC connector transformers +linkTitle: gRPC connector transformers +description: YugabyteDB gRPC connector transformers for Change Data Capture in YugabyteDB. +menu: + preview: + parent: debezium-connector-yugabytedb + identifier: yugabytedb-grpc-connector-transformers + weight: 50 +type: docs +--- + +The connector comes bundled with some SMTs which can ease in the data flow and help achieve the right message format as per the requirement. The following transformers are bundled with the connector jar file available on [GitHub releases](https://github.com/yugabyte/debezium-connector-yugabytedb/releases): + +* YBExtractNewRecordState +* PGCompatible + +{{< note title="Important" >}} + +The above mentioned transformers are only expected to be used with logical replication when the [plugin](../using-logical-replication/key-concepts#output-plugin) being used is `yboutput`. + +{{ < /note >}} + +Note that for maintaining simplicity, only the `before` and `after` fields of the `payload` of the message published by the connector will be mentioned in the following examples. Any information pertaining to the record schema, if same as the standard Debezium connector for Postgres, will be skipped. + +Consider a table created using the following statement: + +```sql +CREATE TABLE test (id INT PRIMARY KEY, name TEXT, aura INT); +``` + +The following DML statements will be used to demonstrate payload in case of individual replica identities: + +```sql +-- statement 1 +INSERT INTO test VALUES (1, 'Vaibhav', 9876); + +-- statement 2 +UPDATE test SET aura = 9999 WHERE id = 1; + +-- statement 3 +UPDATE test SET name = 'Vaibhav Kushwaha', aura = 10 WHERE id = 1; + +-- statement 4 +UPDATE test SET aura = NULL WHERE id = 1; + +-- statement 5 +DELETE FROM test WHERE id = 1; +``` + +## YBExtractNewRecordState + +**Transformer class:** `io.debezium.connector.yugabytedb.transforms.YBExtractNewRecordState` + +### PGCompatible + +**Transformer class:** `io.debezium.connector.yugabytedb.transforms.PGCompatible` + +By default, the YugabyteDB CDC service publishes events with a schema that only includes columns that have been modified. The source connector then sends the value as `null` for columns that are missing in the payload. Each column payload includes a `set` field that is used to signal if a column has been set to `null` because it wasn't present in the payload from YugabyteDB. + +However, some sink connectors may not understand the preceding format. `PGCompatible` transforms the payload to a format that is compatible with the format of the standard change data events. Specifically, it transforms column schema and value to remove the set field and collapse the payload such that it only contains the data type schema and value. + +PGCompatible differs from `YBExtractNewRecordState` by recursively modifying all the fields in a payload. + +Following are the examples how the payload would look like for each [before image mode](../using-yugabytedb-grpc-replication/cdc-get-started/#before-image-modes). + +### CHANGE + +``` +-- statement 1 +"before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} + +-- statement 2 +"before":null,"after":{"id":1,"name":null,"aura":9999} + +-- statement 3 +"before":null,"after":{"id":1,"name":"Vaibhav Kushwaha","aura":10} + +-- statement 4 +"before":null,"after":{"id":1,"name":null,"aura":null} + +-- statement 5 +"before":{"id":1,"name":null,"aura":null},"after":null +``` + +Do note that for statement 2 and 4, the columns which were not updated as a part of the `UPDATE` statement, they're `null` in the output field. + +### FULL_ROW_NEW_IMAGE + +``` +-- statement 1 +"before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} + +-- statement 2 +"before":null,"after":{"id":1,"name":"Vaibhav","aura":9999} + +-- statement 3 +"before":null,"after":{"id":1,"name":"Vaibhav Kushwaha","aura":10} + +-- statement 4 +"before":null,"after":{"id":1,"name":"Vaibhav Kushwaha","aura":null} + +-- statement 5 +"before":{"id":1,"name":"Vaibhav Kushwaha","aura":null},"after":null +``` + +### ALL + +``` +-- statement 1 +"before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} + +-- statement 2 +"before":{"id":1,"name":"Vaibhav","aura":9876},"after":{"id":1,"name":"Vaibhav","aura":9999} + +-- statement 3 +"before":{"id":1,"name":"Vaibhav","aura":9999},"after":{"id":1,"name":"Vaibhav Kushwaha","aura":10} + +-- statement 4 +"before":{"id":1,"name":"Vaibhav Kushwaha","aura":10},"after":{"id":1,"name":"Vaibhav Kushwaha","aura":null} + +-- statement 5 +"before":{"id":1,"name":"Vaibhav Kushwaha","aura":null},"after":null +``` From 872a19d9907a5603414ca2655a145d004c3854d2 Mon Sep 17 00:00:00 2001 From: Vaibhav Kushwaha Date: Thu, 2 Jan 2025 16:14:05 +0530 Subject: [PATCH 2/9] added example --- .../yugabytedb-grpc-transformers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md b/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md index fdcb56757a9f..a094c5f4b709 100644 --- a/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md +++ b/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md @@ -18,7 +18,7 @@ The connector comes bundled with some SMTs which can ease in the data flow and h {{< note title="Important" >}} -The above mentioned transformers are only expected to be used with logical replication when the [plugin](../using-logical-replication/key-concepts#output-plugin) being used is `yboutput`. +The above mentioned transformers are only expected to be used with gRPC replication. {{ < /note >}} From ed2e3ee1e1ae464ce87890a1110ce26ee9fe48dd Mon Sep 17 00:00:00 2001 From: Vaibhav Kushwaha Date: Thu, 2 Jan 2025 16:21:07 +0530 Subject: [PATCH 3/9] added example --- .../using-logical-replication/transformers.md | 2 +- .../yugabytedb-grpc-transformers.md | 21 ++++++++++++++++++- 2 files changed, 21 insertions(+), 2 deletions(-) diff --git a/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md b/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md index 8a2e39c976b4..ceed4f1fa8f6 100644 --- a/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md +++ b/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md @@ -53,7 +53,7 @@ DELETE FROM test WHERE id = 1; **Transformer class:** -### PGCompatible +## PGCompatible **Transformer class:** `io.debezium.connector.postgresql.transforms.PGCompatible` diff --git a/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md b/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md index a094c5f4b709..c69979976112 100644 --- a/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md +++ b/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md @@ -53,7 +53,7 @@ DELETE FROM test WHERE id = 1; **Transformer class:** `io.debezium.connector.yugabytedb.transforms.YBExtractNewRecordState` -### PGCompatible +## PGCompatible **Transformer class:** `io.debezium.connector.yugabytedb.transforms.PGCompatible` @@ -105,6 +105,25 @@ Do note that for statement 2 and 4, the columns which were not updated as a part "before":{"id":1,"name":"Vaibhav Kushwaha","aura":null},"after":null ``` +### MODIFIED_COLUMNS_OLD_AND_NEW_IMAGES + +``` +-- statement 1 +"before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} + +-- statement 2 +"before":{"id":1,"name":null,"aura":9876},"after":{"id":1,"name":null,"aura":9999} + +-- statement 3 +"before":{"id":1,"name":"Vaibhav","aura":9999},"after":{"id":1,"name":"Vaibhav Kushwaha","aura":10} + +-- statement 4 +"before":{"id":1,"name":null,"aura":10},"after":{"id":1,"name":null,"aura":null} + +-- statement 5 +"before":{"id":1,"name":null,"aura":null},"after":null +``` + ### ALL ``` From 4759bf0cd8d3b2feac7a03458ba436c2f420b8b8 Mon Sep 17 00:00:00 2001 From: Vaibhav Kushwaha Date: Thu, 2 Jan 2025 16:31:57 +0530 Subject: [PATCH 4/9] fixed shortcode --- .../using-logical-replication/transformers.md | 2 +- .../yugabytedb-grpc-transformers.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md b/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md index ceed4f1fa8f6..284ec965a8fe 100644 --- a/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md +++ b/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md @@ -20,7 +20,7 @@ The connector comes bundled with some SMTs which can ease in the data flow and h The above mentioned transformers are only expected to be used with logical replication when the [plugin](../using-logical-replication/key-concepts#output-plugin) being used is `yboutput`. -{{ < /note >}} +{{< /note >}} Note that for maintaining simplicity, only the `before` and `after` fields of the `payload` of the message published by the connector will be mentioned in the following examples. Any information pertaining to the record schema, if same as the standard Debezium connector for Postgres, will be skipped. diff --git a/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md b/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md index c69979976112..13d7bd844556 100644 --- a/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md +++ b/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md @@ -20,7 +20,7 @@ The connector comes bundled with some SMTs which can ease in the data flow and h The above mentioned transformers are only expected to be used with gRPC replication. -{{ < /note >}} +{{< /note >}} Note that for maintaining simplicity, only the `before` and `after` fields of the `payload` of the message published by the connector will be mentioned in the following examples. Any information pertaining to the record schema, if same as the standard Debezium connector for Postgres, will be skipped. From a246cd830a8362c16f296114d8dbb3e06d10bb71 Mon Sep 17 00:00:00 2001 From: Vaibhav Kushwaha Date: Mon, 20 Jan 2025 12:31:41 +0530 Subject: [PATCH 5/9] committed to docs --- .../using-logical-replication/transformers.md | 4 ---- .../yugabytedb-grpc-transformers.md | 4 ---- 2 files changed, 8 deletions(-) diff --git a/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md b/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md index 284ec965a8fe..aeb8cee5cecf 100644 --- a/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md +++ b/docs/content/preview/explore/change-data-capture/using-logical-replication/transformers.md @@ -49,10 +49,6 @@ UPDATE test SET aura = NULL WHERE id = 1; DELETE FROM test WHERE id = 1; ``` -## YBExtractNewRecordState - -**Transformer class:** - ## PGCompatible **Transformer class:** `io.debezium.connector.postgresql.transforms.PGCompatible` diff --git a/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md b/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md index 13d7bd844556..65ffc0953630 100644 --- a/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md +++ b/docs/content/preview/explore/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md @@ -49,10 +49,6 @@ UPDATE test SET aura = NULL WHERE id = 1; DELETE FROM test WHERE id = 1; ``` -## YBExtractNewRecordState - -**Transformer class:** `io.debezium.connector.yugabytedb.transforms.YBExtractNewRecordState` - ## PGCompatible **Transformer class:** `io.debezium.connector.yugabytedb.transforms.PGCompatible` From bc718ef6f173a9e6b760b409d83544f0fba0cb92 Mon Sep 17 00:00:00 2001 From: Dwight Hodge Date: Mon, 20 Jan 2025 15:50:40 -0500 Subject: [PATCH 6/9] edits --- .../using-logical-replication/transformers.md | 24 +++++++++------- .../yugabytedb-grpc-transformers.md | 28 +++++++++---------- .../using-logical-replication/transformers.md | 22 +++++++++------ 3 files changed, 40 insertions(+), 34 deletions(-) diff --git a/docs/content/preview/develop/change-data-capture/using-logical-replication/transformers.md b/docs/content/preview/develop/change-data-capture/using-logical-replication/transformers.md index aeb8cee5cecf..5eb4aaba078b 100644 --- a/docs/content/preview/develop/change-data-capture/using-logical-replication/transformers.md +++ b/docs/content/preview/develop/change-data-capture/using-logical-replication/transformers.md @@ -11,18 +11,22 @@ menu: type: docs --- -The connector comes bundled with some SMTs which can ease in the data flow and help achieve the right message format as per the requirement. The following transformers are bundled with the connector jar file available on [GitHub releases](https://github.com/yugabyte/debezium/releases): +The YugabyteDB Connector comes bundled with Single Message Transformers (SMTs). SMTs are applied to messages as they flow through Kafka Connect so that sinks understand the format in which data is sent. SMTs transform inbound messages after a source connector has produced them, but before they are written to Kafka. SMTs transform outbound messages before they are sent to a sink connector. + +The following SMTs are bundled with the connector jar file available on [GitHub releases](https://github.com/yugabyte/debezium/releases): * YBExtractNewRecordState * PGCompatible {{< note title="Important" >}} -The above mentioned transformers are only expected to be used with logical replication when the [plugin](../using-logical-replication/key-concepts#output-plugin) being used is `yboutput`. +These SMTs are only compatible with the [yboutput plugin](../key-concepts#output-plugin). {{< /note >}} -Note that for maintaining simplicity, only the `before` and `after` fields of the `payload` of the message published by the connector will be mentioned in the following examples. Any information pertaining to the record schema, if same as the standard Debezium connector for Postgres, will be skipped. +## Example + +For simplicity, only `before` and `after` fields of the `payload` of the message published by the connector are mentioned in the following examples. Any information pertaining to the record schema, if it is the same as the standard Debezium connector for PostgreSQL, is skipped. Consider a table created using the following statement: @@ -55,15 +59,15 @@ DELETE FROM test WHERE id = 1; By default, the YugabyteDB CDC service publishes events with a schema that only includes columns that have been modified. The source connector then sends the value as `null` for columns that are missing in the payload. Each column payload includes a `set` field that is used to signal if a column has been set to `null` because it wasn't present in the payload from YugabyteDB. -However, some sink connectors may not understand the preceding format. `PGCompatible` transforms the payload to a format that is compatible with the format of the standard change data events. Specifically, it transforms column schema and value to remove the `set` field and collapse the payload such that it only contains the data type schema and value. +However, some sink connectors may not understand this format. PGCompatible transforms the payload to a format that is compatible with the format of standard change data events. Specifically, it transforms column schema and value to remove the `set` field and collapse the payload such that it only contains the data type schema and value. -`PGCompatible` differs from `YBExtractNewRecordState` by recursively modifying all the fields in a payload. +PGCompatible differs from YBExtractNewRecordState by recursively modifying all the fields in a payload. -Following are the examples how the payload would look like for each [replica identity](../using-logical-replication/key-concepts/#replica-identity). +The following examples show what the payload would look like for each [replica identity](../key-concepts/#replica-identity). ### CHANGE -``` +```output -- statement 1 "before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} @@ -80,11 +84,11 @@ Following are the examples how the payload would look like for each [replica ide "before":{"id":1,"name":null,"aura":null},"after":null ``` -Do note that for statement 2 and 4, the columns which were not updated as a part of the `UPDATE` statement, they're `null` in the output field. +Note that for statement 2 and 4, the columns that were not updated as a part of the UPDATE statement are `null` in the output field. ### DEFAULT -``` +```output -- statement 1 "before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} @@ -103,7 +107,7 @@ Do note that for statement 2 and 4, the columns which were not updated as a part ### FULL -``` +```output -- statement 1 "before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} diff --git a/docs/content/preview/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md b/docs/content/preview/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md index 65ffc0953630..60501d28424d 100644 --- a/docs/content/preview/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md +++ b/docs/content/preview/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md @@ -11,18 +11,16 @@ menu: type: docs --- -The connector comes bundled with some SMTs which can ease in the data flow and help achieve the right message format as per the requirement. The following transformers are bundled with the connector jar file available on [GitHub releases](https://github.com/yugabyte/debezium-connector-yugabytedb/releases): +The YugabyteDB gRPC Connector comes bundled with Single Message Transformers (SMTs). SMTs are applied to messages as they flow through Kafka Connect so that sinks understand the format in which data is sent. SMTs transform inbound messages after a source connector has produced them, but before they are written to Kafka. SMTs transform outbound messages before they are sent to a sink connector. + +The following SMTs are bundled with the connector jar file available on [GitHub releases](https://github.com/yugabyte/debezium-connector-yugabytedb/releases): * YBExtractNewRecordState * PGCompatible -{{< note title="Important" >}} - -The above mentioned transformers are only expected to be used with gRPC replication. +## Example -{{< /note >}} - -Note that for maintaining simplicity, only the `before` and `after` fields of the `payload` of the message published by the connector will be mentioned in the following examples. Any information pertaining to the record schema, if same as the standard Debezium connector for Postgres, will be skipped. +For simplicity, only `before` and `after` fields of the `payload` of the message published by the connector are mentioned in the following examples. Any information pertaining to the record schema, if it is the same as the standard Debezium connector for PostgreSQL, is skipped. Consider a table created using the following statement: @@ -55,15 +53,15 @@ DELETE FROM test WHERE id = 1; By default, the YugabyteDB CDC service publishes events with a schema that only includes columns that have been modified. The source connector then sends the value as `null` for columns that are missing in the payload. Each column payload includes a `set` field that is used to signal if a column has been set to `null` because it wasn't present in the payload from YugabyteDB. -However, some sink connectors may not understand the preceding format. `PGCompatible` transforms the payload to a format that is compatible with the format of the standard change data events. Specifically, it transforms column schema and value to remove the set field and collapse the payload such that it only contains the data type schema and value. +However, some sink connectors may not understand the preceding format. PGCompatible transforms the payload to a format that is compatible with the format of the standard change data events. Specifically, it transforms column schema and value to remove the `set` field and collapse the payload such that it only contains the data type schema and value. -PGCompatible differs from `YBExtractNewRecordState` by recursively modifying all the fields in a payload. +PGCompatible differs from YBExtractNewRecordState by recursively modifying all the fields in a payload. -Following are the examples how the payload would look like for each [before image mode](../using-yugabytedb-grpc-replication/cdc-get-started/#before-image-modes). +The following examples show what the payload would look like for each [before image mode](../using-yugabytedb-grpc-replication/cdc-get-started/#before-image-modes). ### CHANGE -``` +```output -- statement 1 "before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} @@ -80,11 +78,11 @@ Following are the examples how the payload would look like for each [before imag "before":{"id":1,"name":null,"aura":null},"after":null ``` -Do note that for statement 2 and 4, the columns which were not updated as a part of the `UPDATE` statement, they're `null` in the output field. +Note that for statement 2 and 4, the columns that were not updated as a part of the UPDATE statement are `null` in the output field. ### FULL_ROW_NEW_IMAGE -``` +```output -- statement 1 "before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} @@ -103,7 +101,7 @@ Do note that for statement 2 and 4, the columns which were not updated as a part ### MODIFIED_COLUMNS_OLD_AND_NEW_IMAGES -``` +```output -- statement 1 "before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} @@ -122,7 +120,7 @@ Do note that for statement 2 and 4, the columns which were not updated as a part ### ALL -``` +```output -- statement 1 "before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} diff --git a/docs/content/stable/develop/change-data-capture/using-logical-replication/transformers.md b/docs/content/stable/develop/change-data-capture/using-logical-replication/transformers.md index aeb8cee5cecf..3323557ddb29 100644 --- a/docs/content/stable/develop/change-data-capture/using-logical-replication/transformers.md +++ b/docs/content/stable/develop/change-data-capture/using-logical-replication/transformers.md @@ -11,18 +11,22 @@ menu: type: docs --- -The connector comes bundled with some SMTs which can ease in the data flow and help achieve the right message format as per the requirement. The following transformers are bundled with the connector jar file available on [GitHub releases](https://github.com/yugabyte/debezium/releases): +The YugabyteDB Connector comes bundled with Single Message Transformers (SMTs). SMTs are applied to messages as they flow through Kafka Connect so that sinks understand the format in which data is sent. SMTs transform inbound messages after a source connector has produced them, but before they are written to Kafka. SMTs transform outbound messages before they are sent to a sink connector. + +The following SMTs are bundled with the connector jar file available on [GitHub releases](https://github.com/yugabyte/debezium/releases): * YBExtractNewRecordState * PGCompatible {{< note title="Important" >}} -The above mentioned transformers are only expected to be used with logical replication when the [plugin](../using-logical-replication/key-concepts#output-plugin) being used is `yboutput`. +These SMTs are only compatible with the [yboutput plugin](../key-concepts#output-plugin). {{< /note >}} -Note that for maintaining simplicity, only the `before` and `after` fields of the `payload` of the message published by the connector will be mentioned in the following examples. Any information pertaining to the record schema, if same as the standard Debezium connector for Postgres, will be skipped. +## Example + +For simplicity, only `before` and `after` fields of the `payload` of the message published by the connector are mentioned in the following examples. Any information pertaining to the record schema, if it is the same as the standard Debezium connector for PostgreSQL, is skipped. Consider a table created using the following statement: @@ -55,15 +59,15 @@ DELETE FROM test WHERE id = 1; By default, the YugabyteDB CDC service publishes events with a schema that only includes columns that have been modified. The source connector then sends the value as `null` for columns that are missing in the payload. Each column payload includes a `set` field that is used to signal if a column has been set to `null` because it wasn't present in the payload from YugabyteDB. -However, some sink connectors may not understand the preceding format. `PGCompatible` transforms the payload to a format that is compatible with the format of the standard change data events. Specifically, it transforms column schema and value to remove the `set` field and collapse the payload such that it only contains the data type schema and value. +However, some sink connectors may not understand this format. PGCompatible transforms the payload to a format that is compatible with the format of standard change data events. Specifically, it transforms column schema and value to remove the `set` field and collapse the payload such that it only contains the data type schema and value. -`PGCompatible` differs from `YBExtractNewRecordState` by recursively modifying all the fields in a payload. +PGCompatible differs from YBExtractNewRecordState by recursively modifying all the fields in a payload. -Following are the examples how the payload would look like for each [replica identity](../using-logical-replication/key-concepts/#replica-identity). +The following examples show what the payload would look like for each [replica identity](../key-concepts/#replica-identity). ### CHANGE -``` +```output -- statement 1 "before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} @@ -84,7 +88,7 @@ Do note that for statement 2 and 4, the columns which were not updated as a part ### DEFAULT -``` +```output -- statement 1 "before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} @@ -103,7 +107,7 @@ Do note that for statement 2 and 4, the columns which were not updated as a part ### FULL -``` +```output -- statement 1 "before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} From 2bb3c511871937a6d94127111346b2dca73748b5 Mon Sep 17 00:00:00 2001 From: Vaibhav Kushwaha Date: Tue, 21 Jan 2025 09:35:13 +0530 Subject: [PATCH 7/9] added page to stable as well --- .../yugabytedb-grpc-tranasformers.md | 138 ++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 docs/content/stable/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-tranasformers.md diff --git a/docs/content/stable/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-tranasformers.md b/docs/content/stable/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-tranasformers.md new file mode 100644 index 000000000000..60501d28424d --- /dev/null +++ b/docs/content/stable/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-tranasformers.md @@ -0,0 +1,138 @@ +--- +title: YugabyteDB gRPC connector transformers +headerTitle: YugabyteDB gRPC connector transformers +linkTitle: gRPC connector transformers +description: YugabyteDB gRPC connector transformers for Change Data Capture in YugabyteDB. +menu: + preview: + parent: debezium-connector-yugabytedb + identifier: yugabytedb-grpc-connector-transformers + weight: 50 +type: docs +--- + +The YugabyteDB gRPC Connector comes bundled with Single Message Transformers (SMTs). SMTs are applied to messages as they flow through Kafka Connect so that sinks understand the format in which data is sent. SMTs transform inbound messages after a source connector has produced them, but before they are written to Kafka. SMTs transform outbound messages before they are sent to a sink connector. + +The following SMTs are bundled with the connector jar file available on [GitHub releases](https://github.com/yugabyte/debezium-connector-yugabytedb/releases): + +* YBExtractNewRecordState +* PGCompatible + +## Example + +For simplicity, only `before` and `after` fields of the `payload` of the message published by the connector are mentioned in the following examples. Any information pertaining to the record schema, if it is the same as the standard Debezium connector for PostgreSQL, is skipped. + +Consider a table created using the following statement: + +```sql +CREATE TABLE test (id INT PRIMARY KEY, name TEXT, aura INT); +``` + +The following DML statements will be used to demonstrate payload in case of individual replica identities: + +```sql +-- statement 1 +INSERT INTO test VALUES (1, 'Vaibhav', 9876); + +-- statement 2 +UPDATE test SET aura = 9999 WHERE id = 1; + +-- statement 3 +UPDATE test SET name = 'Vaibhav Kushwaha', aura = 10 WHERE id = 1; + +-- statement 4 +UPDATE test SET aura = NULL WHERE id = 1; + +-- statement 5 +DELETE FROM test WHERE id = 1; +``` + +## PGCompatible + +**Transformer class:** `io.debezium.connector.yugabytedb.transforms.PGCompatible` + +By default, the YugabyteDB CDC service publishes events with a schema that only includes columns that have been modified. The source connector then sends the value as `null` for columns that are missing in the payload. Each column payload includes a `set` field that is used to signal if a column has been set to `null` because it wasn't present in the payload from YugabyteDB. + +However, some sink connectors may not understand the preceding format. PGCompatible transforms the payload to a format that is compatible with the format of the standard change data events. Specifically, it transforms column schema and value to remove the `set` field and collapse the payload such that it only contains the data type schema and value. + +PGCompatible differs from YBExtractNewRecordState by recursively modifying all the fields in a payload. + +The following examples show what the payload would look like for each [before image mode](../using-yugabytedb-grpc-replication/cdc-get-started/#before-image-modes). + +### CHANGE + +```output +-- statement 1 +"before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} + +-- statement 2 +"before":null,"after":{"id":1,"name":null,"aura":9999} + +-- statement 3 +"before":null,"after":{"id":1,"name":"Vaibhav Kushwaha","aura":10} + +-- statement 4 +"before":null,"after":{"id":1,"name":null,"aura":null} + +-- statement 5 +"before":{"id":1,"name":null,"aura":null},"after":null +``` + +Note that for statement 2 and 4, the columns that were not updated as a part of the UPDATE statement are `null` in the output field. + +### FULL_ROW_NEW_IMAGE + +```output +-- statement 1 +"before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} + +-- statement 2 +"before":null,"after":{"id":1,"name":"Vaibhav","aura":9999} + +-- statement 3 +"before":null,"after":{"id":1,"name":"Vaibhav Kushwaha","aura":10} + +-- statement 4 +"before":null,"after":{"id":1,"name":"Vaibhav Kushwaha","aura":null} + +-- statement 5 +"before":{"id":1,"name":"Vaibhav Kushwaha","aura":null},"after":null +``` + +### MODIFIED_COLUMNS_OLD_AND_NEW_IMAGES + +```output +-- statement 1 +"before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} + +-- statement 2 +"before":{"id":1,"name":null,"aura":9876},"after":{"id":1,"name":null,"aura":9999} + +-- statement 3 +"before":{"id":1,"name":"Vaibhav","aura":9999},"after":{"id":1,"name":"Vaibhav Kushwaha","aura":10} + +-- statement 4 +"before":{"id":1,"name":null,"aura":10},"after":{"id":1,"name":null,"aura":null} + +-- statement 5 +"before":{"id":1,"name":null,"aura":null},"after":null +``` + +### ALL + +```output +-- statement 1 +"before":null,"after":{"id":1,"name":"Vaibhav","aura":9876} + +-- statement 2 +"before":{"id":1,"name":"Vaibhav","aura":9876},"after":{"id":1,"name":"Vaibhav","aura":9999} + +-- statement 3 +"before":{"id":1,"name":"Vaibhav","aura":9999},"after":{"id":1,"name":"Vaibhav Kushwaha","aura":10} + +-- statement 4 +"before":{"id":1,"name":"Vaibhav Kushwaha","aura":10},"after":{"id":1,"name":"Vaibhav Kushwaha","aura":null} + +-- statement 5 +"before":{"id":1,"name":"Vaibhav Kushwaha","aura":null},"after":null +``` From a4142205bf819fec33852e1cfa52906d6fb92224 Mon Sep 17 00:00:00 2001 From: Dwight Hodge Date: Tue, 21 Jan 2025 13:52:06 -0500 Subject: [PATCH 8/9] menus --- .../using-logical-replication/transformers.md | 2 +- .../yugabytedb-grpc-tranasformers.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/content/stable/develop/change-data-capture/using-logical-replication/transformers.md b/docs/content/stable/develop/change-data-capture/using-logical-replication/transformers.md index 3323557ddb29..eb698c878a58 100644 --- a/docs/content/stable/develop/change-data-capture/using-logical-replication/transformers.md +++ b/docs/content/stable/develop/change-data-capture/using-logical-replication/transformers.md @@ -4,7 +4,7 @@ headerTitle: YugabyteDB connector transformers linkTitle: Connector transformers description: YugabyteDB connector transformers for Change Data Capture in YugabyteDB. menu: - preview: + stable: parent: yugabytedb-connector identifier: yugabytedb-connector-transformers weight: 70 diff --git a/docs/content/stable/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-tranasformers.md b/docs/content/stable/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-tranasformers.md index 60501d28424d..5abe68064b25 100644 --- a/docs/content/stable/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-tranasformers.md +++ b/docs/content/stable/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-tranasformers.md @@ -4,7 +4,7 @@ headerTitle: YugabyteDB gRPC connector transformers linkTitle: gRPC connector transformers description: YugabyteDB gRPC connector transformers for Change Data Capture in YugabyteDB. menu: - preview: + stable: parent: debezium-connector-yugabytedb identifier: yugabytedb-grpc-connector-transformers weight: 50 From 11d9a4b1ce8cd1881b2653882762f6de730a0c7b Mon Sep 17 00:00:00 2001 From: Dwight Hodge Date: Tue, 21 Jan 2025 14:26:43 -0500 Subject: [PATCH 9/9] format --- .../using-logical-replication/get-started.md | 79 ++++++------------- .../using-logical-replication/transformers.md | 2 +- .../yugabytedb-grpc-transformers.md | 4 +- .../using-logical-replication/transformers.md | 2 +- .../yugabytedb-grpc-tranasformers.md | 4 +- 5 files changed, 31 insertions(+), 60 deletions(-) diff --git a/docs/content/preview/develop/change-data-capture/using-logical-replication/get-started.md b/docs/content/preview/develop/change-data-capture/using-logical-replication/get-started.md index f2b942eb07d2..06925d578366 100644 --- a/docs/content/preview/develop/change-data-capture/using-logical-replication/get-started.md +++ b/docs/content/preview/develop/change-data-capture/using-logical-replication/get-started.md @@ -42,13 +42,6 @@ Using Debezium requires three separate services: [Zookeeper](http://zookeeper.ap In this tutorial, you will set up a single instance of each service using Docker and the Debezium container images. -To start the services needed for this tutorial, you must: - -- [Start Zookeeper](#start-zookeeper) -- [Start Kafka](#start-kafka) -- [Start YugabyteDB](#start-yugabytedb) -- [Start Kafka Connect](#start-kafka-connect) - #### Start Zookeeper Zookeeper is the first service you must start. @@ -79,43 +72,29 @@ In this tutorial, you will always connect to Kafka from in a Docker container. A At this point, you have started Zookeeper and Kafka, but you still need a database server from which Debezium can capture changes. In this procedure, you start a YugabyteDB instance with an example database. The example uses sample data in SQL scripts that are included with your YugabyteDB installation in the `share` directory. -Follow the [Quick Start](/preview/tutorials/quick-start) to start an instance using yugabyted. - -{{< note title="Note" >}} - -You need to start the database on an IP that is resolvable by the docker containers. If you use the localhost address (that is, `127.0.0.1`) then if you deploy the connectors in the docker containers, they won't be able to talk to the database and will keep trying to connect to `127.0.0.1` inside the container. Use the [--advertise_address option for yugabyted](../../../../reference/configuration/yugabyted#flags-8) to specify the IP you want to start your database instance. +1. Start YugabyteDB by following the instructions in [Quick Start](/preview/tutorials/quick-start). -For example, Linux users can use the following: + You need to start the database on an IP that is resolvable by the docker containers. If you use the localhost address (that is, `127.0.0.1`) then if you deploy the connectors in the docker containers, they won't be able to talk to the database and will keep trying to connect to `127.0.0.1` inside the container. Use the [--advertise_address option for yugabyted](../../../../reference/configuration/yugabyted/#flags-8) to specify the IP you want to start your database instance. -```sh -./bin/yugabyted start --advertise_address $(hostname -i) -``` - -{{< /note >}} - -##### Use the YSQL command line client - -After starting YugabyteDB, use ysqlsh to create your database: - -1. Connect the client to the database process running on the IP you specified when you started up the database instance. + For example, Linux users can use the following: ```sh - ./bin/ysqlsh -h + ./bin/yugabyted start --advertise_address $(hostname -i) ``` - You should see output similar to the following: +1. Using ysqlsh, connect to the database process running on the IP you specified when you started up the database instance. - ```output - ysqlsh (11.2-YB-{{}}-b0) - Type "help" for help. - - yugabyte=# + ```sh + ./bin/ysqlsh -h ``` 1. Load the schema of the sample tables. ```sql yugabyte=# \i share/schema.sql + ``` + + ```output CREATE TABLE CREATE TABLE CREATE TABLE @@ -149,8 +128,11 @@ After starting YugabyteDB, use ysqlsh to create your database: yugabyte=# \i share/products.sql ``` - ```output + ```sql yugabyte=# select count(*) from products; + ``` + + ```output count ------- 200 @@ -199,14 +181,7 @@ These commands use `localhost`. If you are using a non-native Docker platform (s ### Deploy the YugabyteDB connector -After starting the Debezium and YugabyteDB service, you are ready to deploy the YugabyteDB connector. To deploy the connector, you must: - -- [Register the YugabyteDB connector to monitor the `yugabyte` database](#register-a-connector-to-monitor-yugabyte-database) -- Watch the connector start - -#### Register a connector to monitor yugabyte database - -By registering the YugabyteDB connector, the connector will start monitoring the YugabyteDB database's table `products`. When a row in the table changes, Debezium generates a change event. +After starting the Debezium and YugabyteDB service, you are ready to deploy the YugabyteDB connector. To deploy the connector, you register the YugabyteDB connector to monitor your database. By registering the YugabyteDB connector, the connector will start monitoring the YugabyteDB database's table (`products` in this example). When a row in the table changes, Debezium generates a change event. {{< note title="Note" >}} @@ -214,6 +189,8 @@ In a production environment, you would typically either use the Kafka tools to m {{< /note >}} +To register the connector, do the following: + 1. Review the configuration of the YugabyteDB connector that you will register. Before registering the connector, you should be familiar with its configuration. In the next step, you will register the following connector: ```json @@ -282,8 +259,6 @@ Windows users may need to escape the double-quotes. ["ybconnector"] ``` -#### Watch the connector start - When you register a connector, it generates a large amount of log output in the Kafka Connect container. By reviewing this output, you can better understand the process that the connector goes through from the time it is created until it begins reading the change events. After registering the `ybconnector` connector, you can review the log output in the Kafka Connect container (`connect`) to track the connector's status. @@ -300,7 +275,7 @@ Kafka Connect reports some "errors". However, you can safely ignore these warnin ### View change events -After deploying the YugabyteDB connector, it starts monitoring the `yugabyte` database for data change events. +After it is deployed, the YugabyteDB connector starts monitoring the `yugabyte` database for data change events. For this tutorial, you will explore the `dbserver1.public.products` topic. @@ -308,13 +283,13 @@ For this tutorial, you will explore the `dbserver1.public.products` topic. Open a new terminal, and use it to start the watch-topic utility to watch the `dbserver1.public.products` topic from the beginning of the topic. -The following command runs the `watch-topic` utility in a new container using the `2.5.2.Final` version of the `debezium/kafka` image: +The following command runs the watch-topic utility in a new container using the 2.5.2.Final version of the `debezium/kafka` image: ```sh docker run -it --rm --name consumer --link zookeeper:zookeeper --link kafka:kafka debezium/kafka:2.5.2.Final watch-topic -a dbserver1.public.products ``` -The `watch-topic` utility returns the event records from the `products` table. There will be 200 events, one for each row in the table which was snapshotted. Each event is formatted in JSON, because that is how you configured the Kafka Connect service. There are two JSON documents for each event: one for the key, and one for the value. +The watch-topic utility returns the event records from the `products` table. There will be 200 events, one for each row in the table which was snapshotted. Each event is formatted in JSON, because that is how you configured the Kafka Connect service. There are two JSON documents for each event: one for the key, and one for the value. You should see output similar to the following: @@ -328,11 +303,7 @@ Contents of topic dbserver1.public.products: ... ``` -{{< note title="Note" >}} - -This utility keeps watching the topic, so any new events will automatically appear as long as the utility is running. - -{{< /note >}} +The watch-topic utility keeps watching the topic, so any new events appear automatically as long as the utility is running. #### Update the database and view the update event @@ -359,7 +330,7 @@ By completing this procedure, you will learn how to find details about what chan (1 row) ``` -1. Switch to the terminal running `watch-topic` to see a new event. +1. Switch to the terminal running watch-topic to see a new event. By changing a record in the `products` table, the YugabyteDB connector generated a new event. @@ -388,7 +359,7 @@ By completing this procedure, you will learn how to find details about what chan } ``` -Note that the fields which were not updated are coming out as `null`. This is because the [REPLICA IDENTITY](../key-concepts/#replica-identity) of the table is `CHANGE` by default, where you only send the values of the updated columns in the change event. +Note that the fields which were not updated are coming out as `null`. This is because the [REPLICA IDENTITY](../key-concepts/#replica-identity) of the table is CHANGE by default, where you only send the values of the updated columns in the change event. #### Delete a row and view the delete event @@ -398,7 +369,7 @@ Note that the fields which were not updated are coming out as `null`. This is be delete from products where id = 22; ``` -1. Switch to the terminal running `watch-topic` to see two new events. By deleting a row in the `products` table, the YugabyteDB connector generated 2 new events. +1. Switch to the terminal running watch-topic to see two new events. By deleting a row in the `products` table, the YugabyteDB connector generated 2 new events. The details for the payload of the first event will look similar to the following (formatted for readability): @@ -450,7 +421,7 @@ The second event will have a *key* but the *value* will be `null`; that is a [to ### Clean up -After you are finished with the tutorial, you can use Docker to stop all of the running containers. +After you are finished, you can use Docker to stop all of the running containers. Run the following command: diff --git a/docs/content/preview/develop/change-data-capture/using-logical-replication/transformers.md b/docs/content/preview/develop/change-data-capture/using-logical-replication/transformers.md index 5eb4aaba078b..fe595c6cf5cd 100644 --- a/docs/content/preview/develop/change-data-capture/using-logical-replication/transformers.md +++ b/docs/content/preview/develop/change-data-capture/using-logical-replication/transformers.md @@ -2,7 +2,7 @@ title: YugabyteDB connector transformers headerTitle: YugabyteDB connector transformers linkTitle: Connector transformers -description: YugabyteDB connector transformers for Change Data Capture in YugabyteDB. +description: YugabyteDB connector transformers for Change Data Capture. menu: preview: parent: yugabytedb-connector diff --git a/docs/content/preview/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md b/docs/content/preview/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md index 60501d28424d..dabcbb4a219c 100644 --- a/docs/content/preview/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md +++ b/docs/content/preview/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-transformers.md @@ -1,8 +1,8 @@ --- title: YugabyteDB gRPC connector transformers headerTitle: YugabyteDB gRPC connector transformers -linkTitle: gRPC connector transformers -description: YugabyteDB gRPC connector transformers for Change Data Capture in YugabyteDB. +linkTitle: Connector transformers +description: YugabyteDB gRPC connector transformers for Change Data Capture. menu: preview: parent: debezium-connector-yugabytedb diff --git a/docs/content/stable/develop/change-data-capture/using-logical-replication/transformers.md b/docs/content/stable/develop/change-data-capture/using-logical-replication/transformers.md index eb698c878a58..daca1339d0d7 100644 --- a/docs/content/stable/develop/change-data-capture/using-logical-replication/transformers.md +++ b/docs/content/stable/develop/change-data-capture/using-logical-replication/transformers.md @@ -2,7 +2,7 @@ title: YugabyteDB connector transformers headerTitle: YugabyteDB connector transformers linkTitle: Connector transformers -description: YugabyteDB connector transformers for Change Data Capture in YugabyteDB. +description: YugabyteDB connector transformers for Change Data Capture. menu: stable: parent: yugabytedb-connector diff --git a/docs/content/stable/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-tranasformers.md b/docs/content/stable/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-tranasformers.md index 5abe68064b25..3a7514af6f15 100644 --- a/docs/content/stable/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-tranasformers.md +++ b/docs/content/stable/develop/change-data-capture/using-yugabytedb-grpc-replication/yugabytedb-grpc-tranasformers.md @@ -1,8 +1,8 @@ --- title: YugabyteDB gRPC connector transformers headerTitle: YugabyteDB gRPC connector transformers -linkTitle: gRPC connector transformers -description: YugabyteDB gRPC connector transformers for Change Data Capture in YugabyteDB. +linkTitle: Connector transformers +description: YugabyteDB gRPC connector transformers for Change Data Capture. menu: stable: parent: debezium-connector-yugabytedb