[xCluster] Dropping tables should automatically remove it from xCluster replication #16971
Closed
1 task done
Assignees
Labels
area/docdb
YugabyteDB core features
kind/enhancement
This is an enhancement of an existing feature
priority/medium
Medium priority issue
xCluster
Label for xCluster related issues/improvements
Comments
hari90
added
area/docdb
yugabyte-ci
added
kind/bug
yugabyte-ci
added
priority/high
yugabyte-ci
added
priority/medium
hari90
added a commit
that referenced
this issue
Feb 6, 2024
Summary: As part of creating a new table, also create xCluster stream if the table belongs to a namespace that is part of an xClusterOutboundReplicationGroup. As part of table creation we create `AddTableToXClusterSourceTask` for each ReplicationGroup that we want to add the table to. The task invokes `XClusterOutboundReplicationGroup::AddTable` to create a xcluster stream checkpointed to `OpId().Min()` (0,0) so that replication will start from the beginning of the WAL. We currently skip extending WAL retention of the table since this requires an ALTER Table operation which cannot be performed unless the table creation has completed. #20769 tracks the task which will remove the need for performing ALTER Table in the first place. #20938 tracks the race conditions when tables are created concurrently with xcluster replication groups #16971 tracks delete of tables that are under replication **Upgrade/Rollback safety:** All the changes are guarded under flag `TEST_enable_xcluster_api_v2` Fixes #20422 Jira: DB-9415 Test Plan: TEST_F(XClusterOutboundReplicationGroupMockedTest, AddTable) TEST_F(XClusterOutboundReplicationGroupTest, AddTable) Reviewers: mlillibridge, jhe, slingam, xCluster Reviewed By: mlillibridge Subscribers: yql, xCluster, ybase, bogdan Differential Revision: https://phorge.dev.yugabyte.com/D31935
hari90
added a commit
that referenced
this issue
Mar 5, 2024
Summary: When a table is dropped it sometimes gets hidden instead and later lazily dropped. The code that covers the logic for determining when the table is hidden and when it is dropped is spread across components and non intuitive to follow. This change simplifies the logic and makes it more extensible for new features like db scoped xcluster to hide the table in the future. Delete request for tables and tablets occur in the following places: 1. A individual tablet is deleted when it is split, and the split OpId has been applied. The tservers call `DeleteNotServingTablet` on master when this happens. 2. A table and all its tablets are deleted by `DeleteTableInternal` which is called from a user initiated table drop, failed table create and index backfill. 3. `DeleteYsqlDBTables` drops all the tables in the YSQL DB. All 3 now end up calling `DeleteOrHideTabletsOfTable` with a `TabletDeleteRetainerInfo` object. `TabletDeleteRetainerInfo` contains the context for when a table\tablet should be Hidden instead of being directly Deleted. This object is populated in one function `CatalogManager::GetTabletDeleteRetainerInfo`. This function passes the object to all master managers which may require the object to be Hidden. This is currently the `MasterSnapshotCoordinator` and `xrepl_catalog_manager`. In a later change `xcluster_manager` will also be hooked in here. `DeleteYsqlDBTables` does not currently hide tables, so it uses `TabletDeleteRetainerInfo::AlwaysDelete`. The tablet will be Hidden as long as `CatalogManager::ShouldRetainHiddenTablet` returns true. Similar to `GetTabletDeleteRetainerInfo` this calls the master managers which require the object to be retained as Hidden. When we require tables to be hidden for other purposes in the future we only need to update `GetTabletDeleteRetainerInfo`, `ShouldRetainHiddenTablet` and `TabletDeleteRetainerInfo`. `CatalogManager::CleanupHiddenTables` will delete Hidden tables after all its tablets have been deleted. `CatalogManager::CleanupHiddenTablets` uses `ShouldRetainHiddenTablet` to determine when it is safe to clean it up. All Snapshot related retention logic has been moved into `MasterSnapshotCoordinator`. All xCluster and cdcsdk related code have been moved into xrepl_catalog_manager. Some functions names have been changed to make them cleaner. Jira: DB-6295 Test Plan: Jenkins Reviewers: jhe, asrivastava, xCluster Reviewed By: jhe Subscribers: bogdan, ybase Differential Revision: https://phorge.dev.yugabyte.com/D32780
hari90
added a commit
that referenced
this issue
Mar 23, 2024
…B Scoped replication Summary: Original commit: e5655b5 / D33051 When a YSQL table is dropped it will now properly clean it up from xCluster. On the target cluster when the YSQL table is dropped, it will be removed from all the` UniverseReplicationGroups`. As part of this step we delete the stream on the source cluster. On the source cluster when the YSQL table is dropped, it is hidden and kept until all its xCluster streams are dropped. This ensures data gets replicated to target clusters that are lagging behind. When the target table is dropped it will delete the source stream which will then delete the source tablets, and table. Also, the source streams belonging to dropped tables are automatically deleted after `FLAGS_cdc_wal_retention_time_secs`. This will cover the case when the two clusters are network partitioned, or the target cluster is down. When the sourcer cluster xCluster stream is deleted as part of its cleanup we now delete it from the xCluster Outbound ReplicationGroups. Drop of YCQL tables under xCluster replication are blocked. Drop of YSQL dbs with tables under xCluster replication are blocked. Moved all code related to removing tables from xCluster out of catalog manager. `RemoveTablesFromReplication` has been renamed to `RemoveTablesFromReplicationGroup` and moved to `xcluster_replication_group.cc`. `DeleteXReplStatesForIndexTables` has been moved to `XClusterTargetManager::RemoveDroppedTablesOnConsumer`. Added a Background task in `XClusterTargetManager` to `RemoveDroppedTablesFromReplication` Fixes #16971 Fixes #20206 Jira: DB-6295, DB-9160 Test Plan: XClusterYsqlTest, DropTableOnConsumerThenProducer XClusterYsqlTest, ConsumerMasterRestartAfterTableDrop XClusterYsqlTest, DropTableOnProducerThenConsumer XClusterYsqlTest, ProducerMasterRestartAfterTableDrop XClusterYsqlTest, DropTableWithWorkload XClusterYsqlTest, DropTableOnProducerOnly XClusterDBScopedTest, DropTableOnProducerThenConsumer Reviewers: jhe, slingam, xCluster Reviewed By: slingam Subscribers: bogdan, ybase Tags: #jenkins-ready Differential Revision: https://phorge.dev.yugabyte.com/D33488
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Jira Link: DB-6295
Description
When a table is dropped we need it remove it from xcluster consumer.
Warning: Please confirm that this issue does not contain any sensitive information
The text was updated successfully, but these errors were encountered: