Uh oh!
There was an error while loading. Please reload this page.
[Fix](cloud) Should consider tablet state change whether to skip sync_rowsets in publish phase - #48400
Merged
zhannngchen merged 13 commits intoMar 5, 2025
Merged
Conversation
Thearas
commented
Feb 26, 2025
Contributor
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
bobhan1force-pushed
the
fix-tablet-state-change-in-publish
branch
2 times, most recently
from
February 27, 2025 08:37
ca25fc3 to
7ba25fcComparebobhan1force-pushed
the
fix-tablet-state-change-in-publish
branch
from
February 27, 2025 08:54
7ba25fc to
499e9f3Comparebobhan1
marked this pull request as ready for review
February 27, 2025 09:08
bobhan1
requested review from
dataroaring, gavinchou and w41ter
as code ownersFebruary 27, 2025 09:08
bobhan1
commented
Feb 27, 2025
ContributorAuthor
run buildall |
bobhan1
commented
Feb 27, 2025
ContributorAuthor
run buildall |
doris-robot
commented
Feb 27, 2025
TPC-H: Total hot run time: 32013 ms |
doris-robot
commented
Feb 27, 2025
TPC-DS: Total hot run time: 184351 ms |
doris-robot
commented
Feb 27, 2025
ClickBench: Total hot run time: 31.27 s |
bobhan1force-pushed
the
fix-tablet-state-change-in-publish
branch
from
February 27, 2025 11:17
7a66937 to
b0dce74Comparebobhan1
commented
Feb 27, 2025
ContributorAuthor
run buildall |
doris-robot
commented
Feb 27, 2025
TeamCity cloud ut coverage result: |
doris-robot
commented
Feb 27, 2025
TPC-H: Total hot run time: 31554 ms |
Contributor
PR approved by anyone and no changes requested. |
bobhan1
commented
Mar 4, 2025
ContributorAuthor
run buildall |
doris-robot
commented
Mar 4, 2025
TeamCity cloud ut coverage result: |
doris-robot
commented
Mar 4, 2025
TPC-H: Total hot run time: 32038 ms |
doris-robot
commented
Mar 4, 2025
TPC-DS: Total hot run time: 191000 ms |
doris-robot
commented
Mar 4, 2025
ClickBench: Total hot run time: 31.29 s |
hello-stephen
commented
Mar 4, 2025
Contributor
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
bobhan1
commented
Mar 4, 2025
ContributorAuthor
run p0 |
1 similar comment
bobhan1
commented
Mar 4, 2025
ContributorAuthor
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-actionsBot
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) ~[?:?] ```
Closed
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) ~[?:?] ```
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
Sign up for freeto 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)