[Fix](cloud) Should consider tablet state change whether to skip sync_rowsets in publish phase
#48400
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
bobhan1
force-pushed
the
fix-tablet-state-change-in-publish
branch
2 times, most recently
from
ca25fc3 to
7ba25fc
Compare
bobhan1
force-pushed
the
fix-tablet-state-change-in-publish
branch
from
7ba25fc to
499e9f3
Compare
bobhan1
requested review from
dataroaring,
gavinchou and
w41ter
as code owners
Contributor
Author
|
run buildall |
Contributor
Author
|
run buildall |
TPC-H: Total hot run time: 32013 ms |
TPC-DS: Total hot run time: 184351 ms |
ClickBench: Total hot run time: 31.27 s |
bobhan1
force-pushed
the
fix-tablet-state-change-in-publish
branch
from
7a66937 to
b0dce74
Compare
Contributor
Author
|
run buildall |
|
TeamCity cloud ut coverage result: |
TPC-H: Total hot run time: 31554 ms |
github-actions
bot
added
approved
Contributor
|
PR approved by anyone and no changes requested. |
Contributor
Author
|
run buildall |
|
TeamCity cloud ut coverage result: |
TPC-H: Total hot run time: 32038 ms |
TPC-DS: Total hot run time: 191000 ms |
ClickBench: Total hot run time: 31.29 s |
Contributor
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
Contributor
Author
|
run p0 |
1 similar comment
Contributor
Author
|
run p0 |
bobhan1
added a commit
to bobhan1/doris
that referenced
this pull request
Mar 5, 2025
…c_rowsets` in publish phase (apache#48400) considering the following situation: 1. heavy SC begins 2. alter task on tablet X(to tablet Y) is sent to be1 3. be1 shutdown for some reason 4. new loads on new tablet Y are routed to be2(which will skip to calculate delete bitmaps in commit phase and publish phase because the tablet's state is `NOT_READY`) 5. be1 restarted and resumed to do alter task 6. alter task on be1 finished and change the tablet's state to `RUNNING` in MS 7. some load on tablet Y on be2 skip to calculate delete bitmap because it doesn't know the tablet's state has changed, which will cause duplicate key problem Like apache#37670, this PR let the meta service return the tablet states along with the getDeleteBitmapUpdateLockResponse to FE and FE will send them to BE to let the BE know whether it should sync_rowsets() due to tablet state change on other BEs.
bobhan1
added a commit
to bobhan1/doris
that referenced
this pull request
Mar 6, 2025
…c_rowsets` in publish phase (apache#48400) considering the following situation: 1. heavy SC begins 2. alter task on tablet X(to tablet Y) is sent to be1 3. be1 shutdown for some reason 4. new loads on new tablet Y are routed to be2(which will skip to calculate delete bitmaps in commit phase and publish phase because the tablet's state is `NOT_READY`) 5. be1 restarted and resumed to do alter task 6. alter task on be1 finished and change the tablet's state to `RUNNING` in MS 7. some load on tablet Y on be2 skip to calculate delete bitmap because it doesn't know the tablet's state has changed, which will cause duplicate key problem Like apache#37670, this PR let the meta service return the tablet states along with the getDeleteBitmapUpdateLockResponse to FE and FE will send them to BE to let the BE know whether it should sync_rowsets() due to tablet state change on other BEs.
dataroaring
pushed a commit
to bobhan1/doris
that referenced
this pull request
Mar 7, 2025
…c_rowsets` in publish phase (apache#48400) considering the following situation: 1. heavy SC begins 2. alter task on tablet X(to tablet Y) is sent to be1 3. be1 shutdown for some reason 4. new loads on new tablet Y are routed to be2(which will skip to calculate delete bitmaps in commit phase and publish phase because the tablet's state is `NOT_READY`) 5. be1 restarted and resumed to do alter task 6. alter task on be1 finished and change the tablet's state to `RUNNING` in MS 7. some load on tablet Y on be2 skip to calculate delete bitmap because it doesn't know the tablet's state has changed, which will cause duplicate key problem Like apache#37670, this PR let the meta service return the tablet states along with the getDeleteBitmapUpdateLockResponse to FE and FE will send them to BE to let the BE know whether it should sync_rowsets() due to tablet state change on other BEs.
bobhan1
added a commit
to bobhan1/doris
that referenced
this pull request
Mar 10, 2025
…c_rowsets` in publish phase (apache#48400) considering the following situation: 1. heavy SC begins 2. alter task on tablet X(to tablet Y) is sent to be1 3. be1 shutdown for some reason 4. new loads on new tablet Y are routed to be2(which will skip to calculate delete bitmaps in commit phase and publish phase because the tablet's state is `NOT_READY`) 5. be1 restarted and resumed to do alter task 6. alter task on be1 finished and change the tablet's state to `RUNNING` in MS 7. some load on tablet Y on be2 skip to calculate delete bitmap because it doesn't know the tablet's state has changed, which will cause duplicate key problem Like apache#37670, this PR let the meta service return the tablet states along with the getDeleteBitmapUpdateLockResponse to FE and FE will send them to BE to let the BE know whether it should sync_rowsets() due to tablet state change on other BEs.
16 tasks
dataroaring
pushed a commit
that referenced
this pull request
Mar 18, 2025
…t tablet states for `GetDeleteBitmapUpdateLockResponse` (#49165) ### What problem does this PR solve? fix for #48400, when fe send `GetDeleteBitmapUpdateLock` rpc to low version MS which will not set tablet states field and get response from it, FE will encounter `IndexOutOfBoundsException`. ``` 2025-03-17 18:05:35,224 WARN (thrift-server-pool-77|200) [FrontendServiceImpl.loadTxnCommit():1676] catch unknown result. java.lang.IndexOutOfBoundsException: Index:0, Size:0 at com.google.protobuf.LongArrayList.ensureIndexInRange(LongArrayList.java:288) ~[protobuf-java-3.24.3.jar:?] at com.google.protobuf.LongArrayList.getLong(LongArrayList.java:136) ~[protobuf-java-3.24.3.jar:?] at com.google.protobuf.LongArrayList.get(LongArrayList.java:131) ~[protobuf-java-3.24.3.jar:?] at com.google.protobuf.LongArrayList.get(LongArrayList.java:45) ~[protobuf-java-3.24.3.jar:?] at org.apache.doris.cloud.transaction.CloudGlobalTransactionMgr.getDeleteBitmapUpdateLock(CloudGlobalTransactionMgr.java:949) ~[doris-fe.jar:1.2-SNAPSHOT] at org.apache.doris.cloud.transaction.CloudGlobalTransactionMgr.commitTransaction(CloudGlobalTransactionMgr.java:361) ~[doris-fe.jar:1.2-SNAPSHOT] at org.apache.doris.cloud.transaction.CloudGlobalTransactionMgr.commitAndPublishTransaction(CloudGlobalTransactionMgr.java:1203) ~[doris-fe.jar:1.2-SNAPSHOT] at org.apache.doris.service.FrontendServiceImpl.loadTxnCommitImpl(FrontendServiceImpl.java:1730) ~[doris-fe.jar:1.2-SNAPSHOT] at org.apache.doris.service.FrontendServiceImpl.loadTxnCommit(FrontendServiceImpl.java:1660) ~[doris-fe.jar:1.2-SNAPSHOT] at jdk.internal.reflect.GeneratedMethodAccessor121.invoke(Unknown Source) ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?] at org.apache.doris.service.FeServer.lambda$start$0(FeServer.java:60) ~[doris-fe.jar:1.2-SNAPSHOT] at jdk.proxy2.$Proxy45.loadTxnCommit(Unknown Source) ~[?:?] at org.apache.doris.thrift.FrontendService$Processor$loadTxnCommit.getResult(FrontendService.java:4282) ~[fe-common-1.2-SNAPSHOT.jar:1.2-SNAPSHOT] at org.apache.doris.thrift.FrontendService$Processor$loadTxnCommit.getResult(FrontendService.java:4262) ~[fe-common-1.2-SNAPSHOT.jar:1.2-SNAPSHOT] at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:38) ~[libthrift-0.16.0.jar:0.16.0] at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:38) ~[libthrift-0.16.0.jar:0.16.0] at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:250) ~[libthrift-0.16.0.jar:0.16.0] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?] at java.lang.Thread.run(Thread.java:833) ~[?:?] ```
github-actions bot
pushed a commit
that referenced
this pull request
Mar 18, 2025
…t tablet states for `GetDeleteBitmapUpdateLockResponse` (#49165) ### What problem does this PR solve? fix for #48400, when fe send `GetDeleteBitmapUpdateLock` rpc to low version MS which will not set tablet states field and get response from it, FE will encounter `IndexOutOfBoundsException`. ``` 2025-03-17 18:05:35,224 WARN (thrift-server-pool-77|200) [FrontendServiceImpl.loadTxnCommit():1676] catch unknown result. java.lang.IndexOutOfBoundsException: Index:0, Size:0 at com.google.protobuf.LongArrayList.ensureIndexInRange(LongArrayList.java:288) ~[protobuf-java-3.24.3.jar:?] at com.google.protobuf.LongArrayList.getLong(LongArrayList.java:136) ~[protobuf-java-3.24.3.jar:?] at com.google.protobuf.LongArrayList.get(LongArrayList.java:131) ~[protobuf-java-3.24.3.jar:?] at com.google.protobuf.LongArrayList.get(LongArrayList.java:45) ~[protobuf-java-3.24.3.jar:?] at org.apache.doris.cloud.transaction.CloudGlobalTransactionMgr.getDeleteBitmapUpdateLock(CloudGlobalTransactionMgr.java:949) ~[doris-fe.jar:1.2-SNAPSHOT] at org.apache.doris.cloud.transaction.CloudGlobalTransactionMgr.commitTransaction(CloudGlobalTransactionMgr.java:361) ~[doris-fe.jar:1.2-SNAPSHOT] at org.apache.doris.cloud.transaction.CloudGlobalTransactionMgr.commitAndPublishTransaction(CloudGlobalTransactionMgr.java:1203) ~[doris-fe.jar:1.2-SNAPSHOT] at org.apache.doris.service.FrontendServiceImpl.loadTxnCommitImpl(FrontendServiceImpl.java:1730) ~[doris-fe.jar:1.2-SNAPSHOT] at org.apache.doris.service.FrontendServiceImpl.loadTxnCommit(FrontendServiceImpl.java:1660) ~[doris-fe.jar:1.2-SNAPSHOT] at jdk.internal.reflect.GeneratedMethodAccessor121.invoke(Unknown Source) ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?] at org.apache.doris.service.FeServer.lambda$start$0(FeServer.java:60) ~[doris-fe.jar:1.2-SNAPSHOT] at jdk.proxy2.$Proxy45.loadTxnCommit(Unknown Source) ~[?:?] at org.apache.doris.thrift.FrontendService$Processor$loadTxnCommit.getResult(FrontendService.java:4282) ~[fe-common-1.2-SNAPSHOT.jar:1.2-SNAPSHOT] at org.apache.doris.thrift.FrontendService$Processor$loadTxnCommit.getResult(FrontendService.java:4262) ~[fe-common-1.2-SNAPSHOT.jar:1.2-SNAPSHOT] at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:38) ~[libthrift-0.16.0.jar:0.16.0] at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:38) ~[libthrift-0.16.0.jar:0.16.0] at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:250) ~[libthrift-0.16.0.jar:0.16.0] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?] at java.lang.Thread.run(Thread.java:833) ~[?:?] ```
koarz
pushed a commit
to koarz/doris
that referenced
this pull request
Jun 4, 2025
…c_rowsets` in publish phase (apache#48400) ### What problem does this PR solve? considering the following situation: 1. heavy SC begins 2. alter task on tablet X(to tablet Y) is sent to be1 3. be1 shutdown for some reason 4. new loads on new tablet Y are routed to be2(which will skip to calculate delete bitmaps in commit phase and publish phase because the tablet's state is `NOT_READY`) 5. be1 restarted and resumed to do alter task 6. alter task on be1 finished and change the tablet's state to `RUNNING` in MS 7. some load on tablet Y on be2 skip to calculate delete bitmap because it doesn't know the tablet's state has changed, which will cause duplicate key problem Like apache#37670, this PR let the meta service return the tablet states along with the getDeleteBitmapUpdateLockResponse to FE and FE will send them to BE to let the BE know whether it should sync_rowsets() due to tablet state change on other BEs.
koarz
pushed a commit
to koarz/doris
that referenced
this pull request
Jun 4, 2025
…t tablet states for `GetDeleteBitmapUpdateLockResponse` (apache#49165) ### What problem does this PR solve? fix for apache#48400, when fe send `GetDeleteBitmapUpdateLock` rpc to low version MS which will not set tablet states field and get response from it, FE will encounter `IndexOutOfBoundsException`. ``` 2025-03-17 18:05:35,224 WARN (thrift-server-pool-77|200) [FrontendServiceImpl.loadTxnCommit():1676] catch unknown result. java.lang.IndexOutOfBoundsException: Index:0, Size:0 at com.google.protobuf.LongArrayList.ensureIndexInRange(LongArrayList.java:288) ~[protobuf-java-3.24.3.jar:?] at com.google.protobuf.LongArrayList.getLong(LongArrayList.java:136) ~[protobuf-java-3.24.3.jar:?] at com.google.protobuf.LongArrayList.get(LongArrayList.java:131) ~[protobuf-java-3.24.3.jar:?] at com.google.protobuf.LongArrayList.get(LongArrayList.java:45) ~[protobuf-java-3.24.3.jar:?] at org.apache.doris.cloud.transaction.CloudGlobalTransactionMgr.getDeleteBitmapUpdateLock(CloudGlobalTransactionMgr.java:949) ~[doris-fe.jar:1.2-SNAPSHOT] at org.apache.doris.cloud.transaction.CloudGlobalTransactionMgr.commitTransaction(CloudGlobalTransactionMgr.java:361) ~[doris-fe.jar:1.2-SNAPSHOT] at org.apache.doris.cloud.transaction.CloudGlobalTransactionMgr.commitAndPublishTransaction(CloudGlobalTransactionMgr.java:1203) ~[doris-fe.jar:1.2-SNAPSHOT] at org.apache.doris.service.FrontendServiceImpl.loadTxnCommitImpl(FrontendServiceImpl.java:1730) ~[doris-fe.jar:1.2-SNAPSHOT] at org.apache.doris.service.FrontendServiceImpl.loadTxnCommit(FrontendServiceImpl.java:1660) ~[doris-fe.jar:1.2-SNAPSHOT] at jdk.internal.reflect.GeneratedMethodAccessor121.invoke(Unknown Source) ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?] at org.apache.doris.service.FeServer.lambda$start$0(FeServer.java:60) ~[doris-fe.jar:1.2-SNAPSHOT] at jdk.proxy2.$Proxy45.loadTxnCommit(Unknown Source) ~[?:?] at org.apache.doris.thrift.FrontendService$Processor$loadTxnCommit.getResult(FrontendService.java:4282) ~[fe-common-1.2-SNAPSHOT.jar:1.2-SNAPSHOT] at org.apache.doris.thrift.FrontendService$Processor$loadTxnCommit.getResult(FrontendService.java:4262) ~[fe-common-1.2-SNAPSHOT.jar:1.2-SNAPSHOT] at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:38) ~[libthrift-0.16.0.jar:0.16.0] at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:38) ~[libthrift-0.16.0.jar:0.16.0] at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:250) ~[libthrift-0.16.0.jar:0.16.0] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?] at java.lang.Thread.run(Thread.java:833) ~[?:?] ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What problem does this PR solve?
considering the following situation:
NOT_READY)RUNNINGin MSLike #37670, this PR let the meta service return the tablet states along with the getDeleteBitmapUpdateLockResponse to FE and FE will send them to BE to let the BE know whether it should sync_rowsets() due to tablet state change on other BEs.
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)