Skip to content

2.25.1.0-b54

2.25.1.0-b54: [#23955] xCluster: Support Table Rewrite for XCluster DDL Replication
@yusong-yan yusong-yan tagged this 19 Dec 03:39 
Summary:
**Background:**

A regular table rewrite involves the following steps:
1. Create a New Table: A new table is created with a new OID and relfilenode. A corresponding DocDB table is also created.
2. Load Data: Data from the original table is loaded into the new table.
3. DocDB Table Swap: The relfilenode of the original and new tables are swapped.
4. Index Rebuilding: Dependent index tables are rebuilt to reflect the new table structure.
5. Original Table and Index Drop: The original table and its dependent indexes are dropped.
After the Rewrite:
The table will have the same OID but different relfilenode id.
The DocDB’s UUID changes due to the new relfilenode id.

**Tablet Rewrite for DDL Replication:**

Source Side:
* A table rewrite event trigger occurs before executing the table rewrite, capturing the OID of the table that is about to be rewritten.
* After the table rewrite is complete, the `ddl_command_end` event trigger is fired. By checking the OID of the rewritten table from the previous step, we can retrieve the table name and new relfilenode of the altered table and dependent index tables. These are then inserted into the ddl_queue table along with the table rewrite DDL string, which will be sent to the target universe. For instance, if the source executes a table rewrite DDL command such as ALTER TABLE test ADD PRIMARY KEY (t);, it adds this command along with the relfilenode ID and table name of the rewritten tables to the ddl_queue, allowing the target to execute the same.

Target Side:
* Execute the table rewrite DDL without loading data (skipping table rewrite step 2) for the table and dependent indexes. This essentially involves dropping the original table and its index tables, then creating new ones with no data in them. The reason for skipping the data loading step is to avoid non-deterministic data changes, such as adding a column with a random default value (`ALTER TABLE table_name ADD t float DEFAULT (random())`).
* Set up replication: Use the table names and new relfilenodes from the source cluster to set up replication between source tables and new target tables, and let the usual xcluster replication mechanism handle the data replication.

Supported Tablet Rewrite DDLs:
`ALTER TABLE ADD/DROP PRIMARY KEY`
`ALTER TABLE ADD COLUMN ... PRIMARY KEY`
`ALTER TABLE ADD COLUMN ... DEFAULT (volatile)`

`ALTER TABLE ... ALTER COLUMN ... TYPE` is currently blocked and will be supported once https://github.com/yugabyte/yugabyte-db/issues/24007 is resolved.
Jira: DB-12854

Test Plan:
```
./yb_build.sh --cxx-test xcluster_ddl_replication-test --gtest_filter "XClusterDDLReplicationTableRewriteTest.AddAndDropPrimaryKeyTest"
./yb_build.sh --cxx-test xcluster_ddl_replication-test --gtest_filter "XClusterDDLReplicationTableRewriteTest.AddColumnPrimaryKeyTest"
./yb_build.sh --cxx-test xcluster_ddl_replication-test --gtest_filter "XClusterDDLReplicationTableRewriteTest.AddColumnDefaultVolatile"
./yb_build.sh --cxx-test xcluster_ddl_replication-test --gtest_filter "XClusterDDLReplicationTableRewriteTest.AlterTypeIsBlocked"
./yb_build.sh --cxx-test xcluster_ddl_replication_pgregress-test --gtest_filter "XClusterPgRegressDDLReplicationTest.PgRegressTableRewrite"
```

Reviewers: jhe, xCluster, hsunder, myang

Reviewed By: jhe, myang

Subscribers: svc_phabricator, ybase, yql

Differential Revision: https://phorge.dev.yugabyte.com/D38124
Assets 2
Loading