-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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.
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
[Feature] Support restoring from a cluster snapshot for shared-data mode (part 3, introduce gtid for tablet metadata) #54326
[Feature] Support restoring from a cluster snapshot for shared-data mode (part 3, introduce gtid for tablet metadata) #54326
Conversation
fe/fe-core/src/main/java/com/starrocks/alter/LakeTableSchemaChangeJob.java
Show resolved
Hide resolved
2cda723
to
11f7c5c
Compare
The introduction of global transaction id is a very important change. Can you explain its necessity in more detail? I hope you can give some examples. |
@@ -70,10 +70,11 @@ public static void buildPartitionsSequentially(long dbId, OlapTable table, List< | |||
int partitionGroupSize = Math.max(1, numBackends * 200 / Math.max(1, avgReplicasPerPartition)); | |||
boolean enableTabletCreationOptimization = table.isCloudNativeTableOrMaterializedView() | |||
&& Config.lake_enable_tablet_creation_optimization; | |||
long gtid = GlobalStateMgr.getCurrentState().getGtidGenerator().nextGtid(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is not a good idea to generate a global transaction id here, because it is a low-level function. It is far from the actual meaning of gtid. How can we ensure that a transaction will not call the buildPartition function multiple times? I think it should be placed in the upper-level begin transaction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added option arg to pass the gtid to the low-level function
…ode (part 3, introduce gtid for tablet metadata) Signed-off-by: xiangguangyxg <[email protected]>
11f7c5c
to
795446b
Compare
Quality Gate passedIssues Measures |
[Java-Extensions Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
[FE Incremental Coverage Report]✅ pass : 48 / 52 (92.31%) file detail
|
[BE Incremental Coverage Report]✅ pass : 5 / 5 (100.00%) file detail
|
@mergify backport branch-3.4 |
✅ Backports have been created
|
…ode (part 3, introduce gtid for tablet metadata) (#54326) Signed-off-by: xiangguangyxg <[email protected]> (cherry picked from commit f977337) # Conflicts: # fe/fe-core/src/main/java/com/starrocks/task/CreateReplicaTask.java # fe/fe-core/src/main/java/com/starrocks/task/TabletTaskExecutor.java # gensrc/proto/lake_types.proto # gensrc/thrift/AgentService.thrift
…ode (part 3, introduce gtid for tablet metadata) (backport #54326) (#54450) Signed-off-by: xiangguangyxg <[email protected]> Co-authored-by: xiangguangyxg <[email protected]>
…ode (part 3, introduce gtid for tablet metadata) (StarRocks#54326) Signed-off-by: xiangguangyxg <[email protected]>
…ode (part 3, introduce gtid for tablet metadata) (StarRocks#54326) Signed-off-by: xiangguangyxg <[email protected]>
Why I'm doing:
The dirty data must be detected when restoring from a cluster snapshot.
What I'm doing:
Introduce gtid for tablet metadata, gtid will be used for the following:
select a from b before t
.Fixes #53867
What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist:
Bugfix cherry-pick branch check: