[Fix](merge-on-write) cloud mow table should sync rowsets in publish phase if compaction on other BE finished during this load #37670
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
|
Thank you for your contribution to Apache Doris. Since 2024-03-18, the Document has been moved to doris-website. |
Contributor
Author
|
run buildall |
Contributor
|
clang-tidy review says "All clean, LGTM! 👍" |
TPC-H: Total hot run time: 40373 ms |
TPC-DS: Total hot run time: 175142 ms |
ClickBench: Total hot run time: 30.44 s |
Contributor
Author
|
run buildall |
Contributor
|
clang-tidy review says "All clean, LGTM! 👍" |
TPC-H: Total hot run time: 39991 ms |
TPC-DS: Total hot run time: 175580 ms |
ClickBench: Total hot run time: 31.06 s |
github-actions
bot
added
the
approved
Contributor
|
PR approved by at least one committer and no changes requested. |
Contributor
|
PR approved by anyone and no changes requested. |
dataroaring
pushed a commit
that referenced
this pull request
Jul 13, 2024
…phase if compaction on other BE finished during this load (#37670) ## Proposed changes Due to #35838, when executing load job, BE will not `sync_rowsets()` in publish phase if a compaction job is finished on another BE on the same tablet between the commit phase and the publish phase of the current load job. This PR let the meta service return the tablet compaction stats 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 compaction on other BEs.
seawinde
pushed a commit
to seawinde/doris
that referenced
this pull request
Jul 17, 2024
…phase if compaction on other BE finished during this load (apache#37670) ## Proposed changes Due to apache#35838, when executing load job, BE will not `sync_rowsets()` in publish phase if a compaction job is finished on another BE on the same tablet between the commit phase and the publish phase of the current load job. This PR let the meta service return the tablet compaction stats 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 compaction on other BEs.
bobhan1
added a commit
to bobhan1/doris
that referenced
this pull request
Jul 18, 2024
…publish phase if compaction on other BE finished during this load (apache#37670)" This reverts commit 5f51a85.
dataroaring
pushed a commit
that referenced
this pull request
Aug 7, 2024
dataroaring
pushed a commit
that referenced
this pull request
Aug 7, 2024
wyxxxcat
pushed a commit
to wyxxxcat/doris
that referenced
this pull request
Aug 14, 2024
## Proposed changes fix a typo in apache#37670
Closed
dataroaring
pushed a commit
that referenced
this pull request
Aug 28, 2024
…ad in calcDeleteBitmapForMow (#39791) ## Proposed changes Issue Number: close #xxx #37670 Let FE call get_delete_bitmap_update_lock in calcDeleteBitmapForMow to get the latest compaction stats of the corresponding partition at the same time, so that in the downstream calcDelete bitmap task, it can let BE determine if there is a concurrent compaction conflict. However, this PR uses snapshot read when fetching the partition stats, which makes it possible for us to fetch outdated stats, thus allowing the BE to miss the conflict processing of concurrent compaction, and generating duplicate keys.
dataroaring
pushed a commit
that referenced
this pull request
Aug 28, 2024
…ad in calcDeleteBitmapForMow (#39791) ## Proposed changes Issue Number: close #xxx #37670 Let FE call get_delete_bitmap_update_lock in calcDeleteBitmapForMow to get the latest compaction stats of the corresponding partition at the same time, so that in the downstream calcDelete bitmap task, it can let BE determine if there is a concurrent compaction conflict. However, this PR uses snapshot read when fetching the partition stats, which makes it possible for us to fetch outdated stats, thus allowing the BE to miss the conflict processing of concurrent compaction, and generating duplicate keys.
16 tasks
16 tasks
gavinchou
pushed a commit
that referenced
this pull request
Dec 17, 2024
…ck be able to be in different fdb txns (#45206) #37670 let the meta service return the tablet compaction stats along with the `getDeleteBitmapUpdateLockResponse` to FE to let the BE know whether it should `sync_rowsets()` due to successful compaction on other BEs on the same tablet. That PR makes the process of reading tablets' stats and writing the delete bitmap update lock KV in one fdb txn to achieve the atomic sematic. However, when a load involves a large number of tablets, the process of reading tablets' stats may take longer than fdb txn's 5 seconds limitation and cause `TXN_TOO_OLD` error. This PR re-arrange the process so that the read of tablet stats can be not necessarily in the same fdb txn with the txn which update the lock_info.lock_id. In detail, we do as the following: 1. gain the delete bitmap update lock in MS (write delete bitmap update lock KV) 2. read tablets' stats to get the compaction counts. 3. check if the delete bitmap update lock is still held by the current load.
github-actions bot
pushed a commit
that referenced
this pull request
Dec 17, 2024
…ck be able to be in different fdb txns (#45206) #37670 let the meta service return the tablet compaction stats along with the `getDeleteBitmapUpdateLockResponse` to FE to let the BE know whether it should `sync_rowsets()` due to successful compaction on other BEs on the same tablet. That PR makes the process of reading tablets' stats and writing the delete bitmap update lock KV in one fdb txn to achieve the atomic sematic. However, when a load involves a large number of tablets, the process of reading tablets' stats may take longer than fdb txn's 5 seconds limitation and cause `TXN_TOO_OLD` error. This PR re-arrange the process so that the read of tablet stats can be not necessarily in the same fdb txn with the txn which update the lock_info.lock_id. In detail, we do as the following: 1. gain the delete bitmap update lock in MS (write delete bitmap update lock KV) 2. read tablets' stats to get the compaction counts. 3. check if the delete bitmap update lock is still held by the current load.
16 tasks
zhannngchen
pushed a commit
that referenced
this pull request
Mar 5, 2025
…c_rowsets` in publish phase (#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 #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 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.
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 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.
Proposed changes
Due to #35838, when executing load job, BE will not
sync_rowsets()in publish phase if a compaction job is finished on another BE on the same tablet between the commit phase and the publish phase of the current load job. This PR let the meta service return the tablet compaction stats along with the getDeleteBitmapUpdateLockResponse to FE and FE will send them to BE to let the BE know whether it shouldsync_rowsets()due to compaction on other BEs.