Skip to content

Conversation

@yujun777
Copy link
Contributor

Proposed changes

For a new clone replica, its init state is CLONE. During CLONE state, the replica can not load data.

When cloning finishing, check this replica is catchup with the partition. Check new replica's version is not enough. Because replica not write txn during CLONE, when these txns change from prepare to commit or visible, the new replica will be fallbehind (last failed version > 0). Later check this tablet is reduant and the new replica will be removed cause its last failed version > 0.

To fix this, when clone a new replica finished, we should check the txns during CLONE should be finished.

TEST: Let write txn continuously and none-stop, and make be clone a full snapshot cost 20s. Then let balance occur, later the new replica can success cloning after two or three further repair, and the old replica will be removed later.

Further comments

If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...

@yujun777
Copy link
Contributor Author

run buildall

@doris-robot
Copy link

(From new machine)TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 46.56 seconds
stream load tsv: 555 seconds loaded 74807831229 Bytes, about 128 MB/s
stream load json: 20 seconds loaded 2358488459 Bytes, about 112 MB/s
stream load orc: 65 seconds loaded 1101869774 Bytes, about 16 MB/s
stream load parquet: 31 seconds loaded 861443392 Bytes, about 26 MB/s
insert into select: 28.6 seconds inserted 10000000 Rows, about 349K ops/s
storage size: 17162222571 Bytes

Copy link
Contributor

@dataroaring dataroaring left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dataroaring dataroaring merged commit 60ce1ed into apache:master Sep 25, 2023
@github-actions github-actions bot added the approved Indicates a PR has been approved by one committer. label Sep 25, 2023
@github-actions
Copy link
Contributor

PR approved by at least one committer and no changes requested.

@github-actions
Copy link
Contributor

PR approved by anyone and no changes requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by one committer. dev/2.0.3-merged merge_conflict reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants