Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[DocDB] cotable ids in flushed frontiers should be consistent with restored tablet #23047

Closed
1 task done
Huqicheng opened this issue Jun 28, 2024 · 0 comments
Closed
1 task done

[DocDB] cotable ids in flushed frontiers should be consistent with restored tablet #23047

Huqicheng opened this issue Jun 28, 2024 · 0 comments
Assignees
@Huqicheng
Labels
2.18 Backport Required 2.20 Backport Required 2.23_blocker 2024.1 Backport Required area/docdb YugabyteDB core features kind/bug This issue is a bug priority/high High Priority

Comments

@Huqicheng
Copy link
Contributor

Huqicheng commented Jun 28, 2024 •
edited by rthallamko3
Loading

Jira Link: DB-11979

Description

When restoring a snapshot of a colocated tablet to a new database/table group, all tables are re-created in the new database so that the cotable ids are different from those in the snapshot.
At restore, the cotables in flushed frontiers should be updated to the ids of newly created tables, otherwise we can hit the following issue after restore:

1. we have 3 sst files after restore
   1.sst (smallest:old_id=0, largest:old_id=0)
   2.sst (smallest:old_id=0, largest:old_id=0)
   3.sst (smallest:old_id=0, largest:old_id=0)
2. compact 1.sst and 2.sst and generate 4.sst
   3.sst (smallest:old_id=0, largest:old_id=0)
   4.sst (smallest:new_id=1, largest:new_id=1)
   After compaction, schema packing with version 0 for new_id can be dropped because from frontier we can only find new_id=1
3. When compact 3.sst and 4.sst
   there are still rows with version 0 for old_id but schema version 0 has been GCed in step 2

Issue Type

kind/bug

Warning: Please confirm that this issue does not contain any sensitive information

  • I confirm this issue does not contain any sensitive information.
@Huqicheng Huqicheng added the area/docdb YugabyteDB core features label Jun 28, 2024
@Huqicheng Huqicheng self-assigned this Jun 28, 2024
@yugabyte-ci yugabyte-ci added kind/bug This issue is a bug priority/medium Medium priority issue labels Jun 28, 2024
@yugabyte-ci yugabyte-ci added 2.23_blocker priority/high High Priority and removed priority/medium Medium priority issue labels Jul 11, 2024
@Huqicheng Huqicheng mentioned this issue Jul 15, 2024
Closed
1 task
Huqicheng added a commit that referenced this issue Jul 16, 2024
@Huqicheng
[#23215] docdb: disable packed for colocated tables by default
13c0ced 
Summary:
Packed + colocated + restore can cause corruption of tablet schema packings: #23047
We are disabling the feature for now, will re-enable it when #23047 is fixed

`ysql_enable_packed_row_for_colocated_table` is on by default only in master, so it's sufficient to only land this diff to master.
Jira: DB-12158

Test Plan: Jenkins

Reviewers: rthallam

Reviewed By: rthallam

Subscribers: ybase, yql

Differential Revision: https://phorge.dev.yugabyte.com/D36591
Huqicheng added a commit that referenced this issue Jul 18, 2024
@Huqicheng
[#23047] docdb: Fix cotable ids in flushed frontier at restore
550458d 
Summary:
When restoring a snopshot of a colocated tablet to a new database/table group, all tables are re-created in the new database so that the cotable ids are different from those in the snapshot.
At restore, the cotables in flushed frontiers should be updated to the ids of newly created tables, otherwise we will probably hit the following issue after restore:
```
1. we have 3 sst files after restore
   1.sst (smallest:old_id=0, largest:old_id=0)
   2.sst (smallest:old_id=0, largest:old_id=0)
   3.sst (smallest:old_id=0, largest:old_id=0)
2. compact 1.sst and 2.sst and generate 4.sst
   3.sst (smallest:old_id=0, largest:old_id=0)
   4.sst (smallest:new_id=1, largest:new_id=1)
   After compaction, schema packing with version 0 for new_id can be dropped because from frontier we can only find new_id=1
3. When compact 3.sst and 4.sst
   there are still rows with version 0 for old_id but schema version 0 has been GCed in step 2
```
Jira: DB-11979

Test Plan:
PackedRows/YBBackupTestWithPackedRowsAndColocation.*/1
CrossColocationTests/YBBackupCrossColocation.TestYSQLRestoreWithInvalidIndex/1
TableRewriteTests/YBBackupTestWithTableRewrite.TestYSQLBackupAndRestoreAfterRewrite/1
TableRewriteTests/YBBackupTestWithTableRewrite.TestYSQLBackupAndRestoreAfterFailedRewrite/1

Reviewers: sergei, zdrudi, mhaddad

Reviewed By: zdrudi

Subscribers: ybase, qhu

Differential Revision: https://phorge.dev.yugabyte.com/D36041
jasonyb pushed a commit that referenced this issue Jul 19, 2024
@yugabyte-ci @jaki
[BACKPORT pg15-cherrypicks] all: Bulk port from master - 59
b0de783 
Summary:
 a64fbfc [#23120] YSQL: Do not wait for a safe snapshot in serializable read only deferrable mode.
 9f82c01 [#23188] DocDB: Persist new colocated_id mapping discovered as part of processing CHANGE_METADATA_OP in xCluster ClusterConfig.
 1522522 Update third-party dependencies to remove CentOS 7
 cd7410c 2.18.1.1 release notes (#23241)
 550458d [#23047] docdb: Fix cotable ids in flushed frontier at restore
 225ddfe [PLAT-14700] Make node-agent error message on installation to be more precise
 9c9a059 [PLAT-14563] Fixing disk mounting logic to use mount points defined in the config
 84eefbd [DOC-368] Azure workload identity docs changes (#22881)
 781af0d [#23183] xCluster: Move Setup, Bootstrap, Alter and Delete Target Replication functions out of CatalogManager
 1d646b1 [docs] Add ysql_output_buffer_size to yb-tserver config reference. (#23233)
 2d95dd2 Fix the issue yaml parsing
 dd9e85b [PLAT-14534]Add regex match for GCP Instance template
 d3bba18 update diagram (#23245)
 78b317c [/PLAT-14708] Fix JSON field name in TaskInfo query
 ac9164b [#23173] DocDB: Allow large bytes to be passed to RateLimiter

Test Plan: Jenkins: rebase: pg15-cherrypicks

Reviewers: jason, tfoucher

Tags: #jenkins-ready

Differential Revision: https://phorge.dev.yugabyte.com/D36723
Huqicheng added a commit that referenced this issue Aug 1, 2024
@Huqicheng
[BACKPORT 2024.1][#23047] docdb: Fix cotable ids in flushed frontier …
1e0f747 
…at restore

Summary:
Original commit: 550458d / D36041
When restoring a snopshot of a colocated tablet to a new database/table group, all tables are re-created in the new database so that the cotable ids are different from those in the snapshot.
At restore, the cotables in flushed frontiers should be updated to the ids of newly created tables, otherwise we will probably hit the following issue after restore:
```
1. we have 3 sst files after restore
   1.sst (smallest:old_id=0, largest:old_id=0)
   2.sst (smallest:old_id=0, largest:old_id=0)
   3.sst (smallest:old_id=0, largest:old_id=0)
2. compact 1.sst and 2.sst and generate 4.sst
   3.sst (smallest:old_id=0, largest:old_id=0)
   4.sst (smallest:new_id=1, largest:new_id=1)
   After compaction, schema packing with version 0 for new_id can be dropped because from frontier we can only find new_id=1
3. When compact 3.sst and 4.sst
   there are still rows with version 0 for old_id but schema version 0 has been GCed in step 2
```
Jira: DB-11979

Test Plan:
PackedRows/YBBackupTestWithPackedRowsAndColocation.*/1
CrossColocationTests/YBBackupCrossColocation.TestYSQLRestoreWithInvalidIndex/1
TableRewriteTests/YBBackupTestWithTableRewrite.TestYSQLBackupAndRestoreAfterRewrite/1
TableRewriteTests/YBBackupTestWithTableRewrite.TestYSQLBackupAndRestoreAfterFailedRewrite/1

Reviewers: sergei, zdrudi, mhaddad

Reviewed By: zdrudi

Subscribers: qhu, ybase

Tags: #jenkins-ready

Differential Revision: https://phorge.dev.yugabyte.com/D36930
Huqicheng added a commit that referenced this issue Aug 1, 2024
@Huqicheng
[BACKPORT 2.20][#23047] docdb: Fix cotable ids in flushed frontier at…
dcaf12c 
… restore

Summary:
Original commit: 550458d / D36041
When restoring a snopshot of a colocated tablet to a new database/table group, all tables are re-created in the new database so that the cotable ids are different from those in the snapshot.
At restore, the cotables in flushed frontiers should be updated to the ids of newly created tables, otherwise we will probably hit the following issue after restore:
```
1. we have 3 sst files after restore
   1.sst (smallest:old_id=0, largest:old_id=0)
   2.sst (smallest:old_id=0, largest:old_id=0)
   3.sst (smallest:old_id=0, largest:old_id=0)
2. compact 1.sst and 2.sst and generate 4.sst
   3.sst (smallest:old_id=0, largest:old_id=0)
   4.sst (smallest:new_id=1, largest:new_id=1)
   After compaction, schema packing with version 0 for new_id can be dropped because from frontier we can only find new_id=1
3. When compact 3.sst and 4.sst
   there are still rows with version 0 for old_id but schema version 0 has been GCed in step 2
```
Jira: DB-11979

Test Plan:
PackedRows/YBBackupTestWithPackedRowsAndColocation.*/1
CrossColocationTests/YBBackupCrossColocation.TestYSQLRestoreWithInvalidIndex/1
TableRewriteTests/YBBackupTestWithTableRewrite.TestYSQLBackupAndRestoreAfterRewrite/1
TableRewriteTests/YBBackupTestWithTableRewrite.TestYSQLBackupAndRestoreAfterFailedRewrite/1

Reviewers: sergei, zdrudi, mhaddad

Reviewed By: zdrudi

Subscribers: qhu, ybase

Tags: #jenkins-ready

Differential Revision: https://phorge.dev.yugabyte.com/D36931
@rthallamko3 rthallamko3 mentioned this issue Aug 9, 2024
Closed
1 task
Huqicheng added a commit that referenced this issue Aug 20, 2024
@Huqicheng
[BACKPORT 2.18][#23047] docdb: Fix cotable ids in flushed frontier at…
4c4df20 
… restore

Summary:
Original commit: 550458d / D36041
When restoring a snopshot of a colocated tablet to a new database/table group, all tables are re-created in the new database so that the cotable ids are different from those in the snapshot.
At restore, the cotables in flushed frontiers should be updated to the ids of newly created tables, otherwise we will probably hit the following issue after restore:
```
1. we have 3 sst files after restore
   1.sst (smallest:old_id=0, largest:old_id=0)
   2.sst (smallest:old_id=0, largest:old_id=0)
   3.sst (smallest:old_id=0, largest:old_id=0)
2. compact 1.sst and 2.sst and generate 4.sst
   3.sst (smallest:old_id=0, largest:old_id=0)
   4.sst (smallest:new_id=1, largest:new_id=1)
   After compaction, schema packing with version 0 for new_id can be dropped because from frontier we can only find new_id=1
3. When compact 3.sst and 4.sst
   there are still rows with version 0 for old_id but schema version 0 has been GCed in step 2
```
Jira: DB-11979

Test Plan:
PackedRows/YBBackupTestWithPackedRowsAndColocation.*/1
CrossColocationTests/YBBackupCrossColocation.TestYSQLRestoreWithInvalidIndex/1
TableRewriteTests/YBBackupTestWithTableRewrite.TestYSQLBackupAndRestoreAfterRewrite/1
TableRewriteTests/YBBackupTestWithTableRewrite.TestYSQLBackupAndRestoreAfterFailedRewrite/1

Reviewers: sergei, zdrudi, mhaddad

Reviewed By: zdrudi

Subscribers: qhu, ybase

Tags: #jenkins-ready

Differential Revision: https://phorge.dev.yugabyte.com/D36932
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Huqicheng Huqicheng

Labels
2.18 Backport Required 2.20 Backport Required 2.23_blocker 2024.1 Backport Required area/docdb YugabyteDB core features kind/bug This issue is a bug priority/high High Priority
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rthallamko3 @yugabyte-ci @Huqicheng