[BugFix] Recalculate max_continuous_version after schema change finished #28473

sevev · 2023-08-02T05:49:19Z

We will create a new tablet for each original tablet and we will write original tablet and new tablet during schema change. We will construct a version_graph to keep versions info for each table and the following code is how to update version_graph:

void VersionGraph::add_version_to_graph(const Version& version) {
    _add_version_to_graph(version);
    if (version.first == _max_continuous_version + 1) {
        _max_continuous_version = _get_max_continuous_version_from(_max_continuous_version + 1);
    } else if (version.first == 0) {
        // We need to reconstruct max_continuous_version from zero if input version is starting from zero
        // e.g.
        // 1. Tablet A is doing schema change
        // 2. We create a new tablet B releated A, and we will create a initial rowset and _max_continuous_version
        //    will be updated to 1
        // 3. Tablet A has a rowset R with version (0, m)
        // 4. Schema change will try convert R
        // 5. The start version of R (0) is not equal to `_max_continuous_version + 1`, and the _max_continuous_version
        //    will not update
        _max_continuous_version = _get_max_continuous_version_from(0);
    }
}

There exists a scenario where _max_continuous_version cannot be updated correctly
e.g.

create a new tablet t2 for origin tablet t1 during schema change and t2 has version 91,92,93,95,96,97,98. version 94 write failed.
when running schema change job, alter version is 98 and t1 has version [0-90], [91-96], 97, 98
max_continuous_version of t2 is 0 before convert rowset. After convert version [0-90], max_continuous_version is update to 93 because t2 has version 91-93 before.
max_continuous_version don't update because the left rowsets version is not satisfy update condition(version.fisrt == 0 or version.first == _max_continuous_verison + 1). So the max_continuous_version will keep 93 after convert rowset finished.
we will check the max_continuous_version of t2 at last and it should not less than alter version. But max_continuous_version(93) is less than alter version(98), so the alter job failed at last.

The main reason is we don't update _max_continuous_version correctly during alter job, we should recalculate the max_continuous_version after rowset conversion.

What type of PR is this:

Checklist:

I have added test cases for my bug fix or my new feature
This pr will affect users' behaviors
This pr needs user documentation (for new or modified features or behaviors)
- I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

Signed-off-by: zhangqiang <[email protected]>

wanpengfei-git · 2023-08-02T08:06:55Z

[FE PR Coverage Check]

😍 pass : 0 / 0 (0%)

luohaha · 2023-08-02T08:37:51Z

This problem can be check here:

int64_t Tablet::max_continuous_version() const {
    if (_updates != nullptr) {
        return _updates->max_version();
    } else {
        std::shared_lock rdlock(_meta_lock);
        int64_t v = _timestamped_version_tracker.get_max_continuous_version();
        if (tablet_state() == TABLET_RUNNING) {
            // can be check here:
            DCHECK_EQ(v, _max_continuous_version_from_beginning_unlocked().second);
        }
        return v;
    }
}

Because DCHECK_EQ can only work on asan mode, so I think we can add some ERROR log here to dig such bug out early

wanpengfei-git · 2023-08-02T10:10:09Z

@Mergifyio backport branch-3.1

wanpengfei-git · 2023-08-02T10:10:10Z

@Mergifyio backport branch-3.0

wanpengfei-git · 2023-08-02T10:10:12Z

@Mergifyio backport branch-2.5

mergify · 2023-08-02T10:10:12Z

backport branch-3.1

✅ Backports have been created

#28510 [BugFix] Recalculate max_continuous_version after schema change finished (backport #28473) has been created for branch branch-3.1

mergify · 2023-08-02T10:10:14Z

backport branch-3.0

✅ Backports have been created

#28511 [BugFix] Recalculate max_continuous_version after schema change finished (backport #28473) has been created for branch branch-3.0 but encountered conflicts

mergify · 2023-08-02T10:10:18Z

backport branch-2.5

✅ Backports have been created

#28512 [BugFix] Recalculate max_continuous_version after schema change finished (backport #28473) has been created for branch branch-2.5 but encountered conflicts

…hed (#28473) We will create a new tablet for each original tablet and we will write original tablet and new tablet during schema change. We will construct a `version_graph` to keep versions info for each table and the following code is how to update `version_graph`: ``` void VersionGraph::add_version_to_graph(const Version& version) { _add_version_to_graph(version); if (version.first == _max_continuous_version + 1) { _max_continuous_version = _get_max_continuous_version_from(_max_continuous_version + 1); } else if (version.first == 0) { // We need to reconstruct max_continuous_version from zero if input version is starting from zero // e.g. // 1. Tablet A is doing schema change // 2. We create a new tablet B releated A, and we will create a initial rowset and _max_continuous_version // will be updated to 1 // 3. Tablet A has a rowset R with version (0, m) // 4. Schema change will try convert R // 5. The start version of R (0) is not equal to `_max_continuous_version + 1`, and the _max_continuous_version // will not update _max_continuous_version = _get_max_continuous_version_from(0); } } ``` There exists a scenario where _max_continuous_version cannot be updated correctly e.g. 1. create a new tablet `t2` for origin tablet `t1` during schema change and `t2` has version 91,92,93,95,96,97,98. version 94 write failed. 2. when running schema change job, alter version is 98 and `t1` has version [0-90], [91-96], 97, 98 3. `max_continuous_version` of `t2` is 0 before convert rowset. After convert version [0-90], `max_continuous_version` is update to 93 because `t2` has version 91-93 before. 4. `max_continuous_version` don't update because the left rowsets version is not satisfy update condition(version.fisrt == 0 or version.first == _max_continuous_verison + 1). So the `max_continuous_version` will keep 93 after convert rowset finished. 5. we will check the max_continuous_version of `t2` at last and it should not less than alter version. But max_continuous_version(93) is less than alter version(98), so the alter job failed at last. The main reason is we don't update `_max_continuous_version` correctly during alter job, we should recalculate the `max_continuous_version` after rowset conversion. --------- Signed-off-by: zhangqiang <[email protected]> (cherry picked from commit bbedba4) # Conflicts: # be/src/storage/tablet.h

…hed (#28473) We will create a new tablet for each original tablet and we will write original tablet and new tablet during schema change. We will construct a `version_graph` to keep versions info for each table and the following code is how to update `version_graph`: ``` void VersionGraph::add_version_to_graph(const Version& version) { _add_version_to_graph(version); if (version.first == _max_continuous_version + 1) { _max_continuous_version = _get_max_continuous_version_from(_max_continuous_version + 1); } else if (version.first == 0) { // We need to reconstruct max_continuous_version from zero if input version is starting from zero // e.g. // 1. Tablet A is doing schema change // 2. We create a new tablet B releated A, and we will create a initial rowset and _max_continuous_version // will be updated to 1 // 3. Tablet A has a rowset R with version (0, m) // 4. Schema change will try convert R // 5. The start version of R (0) is not equal to `_max_continuous_version + 1`, and the _max_continuous_version // will not update _max_continuous_version = _get_max_continuous_version_from(0); } } ``` There exists a scenario where _max_continuous_version cannot be updated correctly e.g. 1. create a new tablet `t2` for origin tablet `t1` during schema change and `t2` has version 91,92,93,95,96,97,98. version 94 write failed. 2. when running schema change job, alter version is 98 and `t1` has version [0-90], [91-96], 97, 98 3. `max_continuous_version` of `t2` is 0 before convert rowset. After convert version [0-90], `max_continuous_version` is update to 93 because `t2` has version 91-93 before. 4. `max_continuous_version` don't update because the left rowsets version is not satisfy update condition(version.fisrt == 0 or version.first == _max_continuous_verison + 1). So the `max_continuous_version` will keep 93 after convert rowset finished. 5. we will check the max_continuous_version of `t2` at last and it should not less than alter version. But max_continuous_version(93) is less than alter version(98), so the alter job failed at last. The main reason is we don't update `_max_continuous_version` correctly during alter job, we should recalculate the `max_continuous_version` after rowset conversion. --------- Signed-off-by: zhangqiang <[email protected]> (cherry picked from commit bbedba4)

…hed (#28473) We will create a new tablet for each original tablet and we will write original tablet and new tablet during schema change. We will construct a `version_graph` to keep versions info for each table and the following code is how to update `version_graph`: ``` void VersionGraph::add_version_to_graph(const Version& version) { _add_version_to_graph(version); if (version.first == _max_continuous_version + 1) { _max_continuous_version = _get_max_continuous_version_from(_max_continuous_version + 1); } else if (version.first == 0) { // We need to reconstruct max_continuous_version from zero if input version is starting from zero // e.g. // 1. Tablet A is doing schema change // 2. We create a new tablet B releated A, and we will create a initial rowset and _max_continuous_version // will be updated to 1 // 3. Tablet A has a rowset R with version (0, m) // 4. Schema change will try convert R // 5. The start version of R (0) is not equal to `_max_continuous_version + 1`, and the _max_continuous_version // will not update _max_continuous_version = _get_max_continuous_version_from(0); } } ``` There exists a scenario where _max_continuous_version cannot be updated correctly e.g. 1. create a new tablet `t2` for origin tablet `t1` during schema change and `t2` has version 91,92,93,95,96,97,98. version 94 write failed. 2. when running schema change job, alter version is 98 and `t1` has version [0-90], [91-96], 97, 98 3. `max_continuous_version` of `t2` is 0 before convert rowset. After convert version [0-90], `max_continuous_version` is update to 93 because `t2` has version 91-93 before. 4. `max_continuous_version` don't update because the left rowsets version is not satisfy update condition(version.fisrt == 0 or version.first == _max_continuous_verison + 1). So the `max_continuous_version` will keep 93 after convert rowset finished. 5. we will check the max_continuous_version of `t2` at last and it should not less than alter version. But max_continuous_version(93) is less than alter version(98), so the alter job failed at last. The main reason is we don't update `_max_continuous_version` correctly during alter job, we should recalculate the `max_continuous_version` after rowset conversion. --------- Signed-off-by: zhangqiang <[email protected]> (cherry picked from commit bbedba4) # Conflicts: # be/src/storage/tablet.h

…hed (StarRocks#28473) We will create a new tablet for each original tablet and we will write original tablet and new tablet during schema change. We will construct a `version_graph` to keep versions info for each table and the following code is how to update `version_graph`: ``` void VersionGraph::add_version_to_graph(const Version& version) { _add_version_to_graph(version); if (version.first == _max_continuous_version + 1) { _max_continuous_version = _get_max_continuous_version_from(_max_continuous_version + 1); } else if (version.first == 0) { // We need to reconstruct max_continuous_version from zero if input version is starting from zero // e.g. // 1. Tablet A is doing schema change // 2. We create a new tablet B releated A, and we will create a initial rowset and _max_continuous_version // will be updated to 1 // 3. Tablet A has a rowset R with version (0, m) // 4. Schema change will try convert R // 5. The start version of R (0) is not equal to `_max_continuous_version + 1`, and the _max_continuous_version // will not update _max_continuous_version = _get_max_continuous_version_from(0); } } ``` There exists a scenario where _max_continuous_version cannot be updated correctly e.g. 1. create a new tablet `t2` for origin tablet `t1` during schema change and `t2` has version 91,92,93,95,96,97,98. version 94 write failed. 2. when running schema change job, alter version is 98 and `t1` has version [0-90], [91-96], 97, 98 3. `max_continuous_version` of `t2` is 0 before convert rowset. After convert version [0-90], `max_continuous_version` is update to 93 because `t2` has version 91-93 before. 4. `max_continuous_version` don't update because the left rowsets version is not satisfy update condition(version.fisrt == 0 or version.first == _max_continuous_verison + 1). So the `max_continuous_version` will keep 93 after convert rowset finished. 5. we will check the max_continuous_version of `t2` at last and it should not less than alter version. But max_continuous_version(93) is less than alter version(98), so the alter job failed at last. The main reason is we don't update `_max_continuous_version` correctly during alter job, we should recalculate the `max_continuous_version` after rowset conversion. --------- Signed-off-by: zhangqiang <[email protected]>

sevev · 2023-08-02T10:25:01Z

#28513 backport branch-2.5

…hed (#28473) We will create a new tablet for each original tablet and we will write original tablet and new tablet during schema change. We will construct a `version_graph` to keep versions info for each table and the following code is how to update `version_graph`: ``` void VersionGraph::add_version_to_graph(const Version& version) { _add_version_to_graph(version); if (version.first == _max_continuous_version + 1) { _max_continuous_version = _get_max_continuous_version_from(_max_continuous_version + 1); } else if (version.first == 0) { // We need to reconstruct max_continuous_version from zero if input version is starting from zero // e.g. // 1. Tablet A is doing schema change // 2. We create a new tablet B releated A, and we will create a initial rowset and _max_continuous_version // will be updated to 1 // 3. Tablet A has a rowset R with version (0, m) // 4. Schema change will try convert R // 5. The start version of R (0) is not equal to `_max_continuous_version + 1`, and the _max_continuous_version // will not update _max_continuous_version = _get_max_continuous_version_from(0); } } ``` There exists a scenario where _max_continuous_version cannot be updated correctly e.g. 1. create a new tablet `t2` for origin tablet `t1` during schema change and `t2` has version 91,92,93,95,96,97,98. version 94 write failed. 2. when running schema change job, alter version is 98 and `t1` has version [0-90], [91-96], 97, 98 3. `max_continuous_version` of `t2` is 0 before convert rowset. After convert version [0-90], `max_continuous_version` is update to 93 because `t2` has version 91-93 before. 4. `max_continuous_version` don't update because the left rowsets version is not satisfy update condition(version.fisrt == 0 or version.first == _max_continuous_verison + 1). So the `max_continuous_version` will keep 93 after convert rowset finished. 5. we will check the max_continuous_version of `t2` at last and it should not less than alter version. But max_continuous_version(93) is less than alter version(98), so the alter job failed at last. The main reason is we don't update `_max_continuous_version` correctly during alter job, we should recalculate the `max_continuous_version` after rowset conversion. --------- Signed-off-by: zhangqiang <[email protected]>

…hed (StarRocks#28473) We will create a new tablet for each original tablet and we will write original tablet and new tablet during schema change. We will construct a `version_graph` to keep versions info for each table and the following code is how to update `version_graph`: ``` void VersionGraph::add_version_to_graph(const Version& version) { _add_version_to_graph(version); if (version.first == _max_continuous_version + 1) { _max_continuous_version = _get_max_continuous_version_from(_max_continuous_version + 1); } else if (version.first == 0) { // We need to reconstruct max_continuous_version from zero if input version is starting from zero // e.g. // 1. Tablet A is doing schema change // 2. We create a new tablet B releated A, and we will create a initial rowset and _max_continuous_version // will be updated to 1 // 3. Tablet A has a rowset R with version (0, m) // 4. Schema change will try convert R // 5. The start version of R (0) is not equal to `_max_continuous_version + 1`, and the _max_continuous_version // will not update _max_continuous_version = _get_max_continuous_version_from(0); } } ``` There exists a scenario where _max_continuous_version cannot be updated correctly e.g. 1. create a new tablet `t2` for origin tablet `t1` during schema change and `t2` has version 91,92,93,95,96,97,98. version 94 write failed. 2. when running schema change job, alter version is 98 and `t1` has version [0-90], [91-96], 97, 98 3. `max_continuous_version` of `t2` is 0 before convert rowset. After convert version [0-90], `max_continuous_version` is update to 93 because `t2` has version 91-93 before. 4. `max_continuous_version` don't update because the left rowsets version is not satisfy update condition(version.fisrt == 0 or version.first == _max_continuous_verison + 1). So the `max_continuous_version` will keep 93 after convert rowset finished. 5. we will check the max_continuous_version of `t2` at last and it should not less than alter version. But max_continuous_version(93) is less than alter version(98), so the alter job failed at last. The main reason is we don't update `_max_continuous_version` correctly during alter job, we should recalculate the `max_continuous_version` after rowset conversion. --------- Signed-off-by: zhangqiang <[email protected]>

…after schema change finished (#28473) (#28522) We will create a new tablet for each original tablet and we will write original tablet and new tablet during schema change. We will construct a `version_graph` to keep versions info for each table and the following code is how to update `version_graph`: ``` void VersionGraph::add_version_to_graph(const Version& version) { _add_version_to_graph(version); if (version.first == _max_continuous_version + 1) { _max_continuous_version = _get_max_continuous_version_from(_max_continuous_version + 1); } else if (version.first == 0) { // We need to reconstruct max_continuous_version from zero if input version is starting from zero // e.g. // 1. Tablet A is doing schema change // 2. We create a new tablet B releated A, and we will create a initial rowset and _max_continuous_version // will be updated to 1 // 3. Tablet A has a rowset R with version (0, m) // 4. Schema change will try convert R // 5. The start version of R (0) is not equal to `_max_continuous_version + 1`, and the _max_continuous_version // will not update _max_continuous_version = _get_max_continuous_version_from(0); } } ``` There exists a scenario where _max_continuous_version cannot be updated correctly e.g. 1. create a new tablet `t2` for origin tablet `t1` during schema change and `t2` has version 91,92,93,95,96,97,98. version 94 write failed. 2. when running schema change job, alter version is 98 and `t1` has version [0-90], [91-96], 97, 98 3. `max_continuous_version` of `t2` is 0 before convert rowset. After convert version [0-90], `max_continuous_version` is update to 93 because `t2` has version 91-93 before. 4. `max_continuous_version` don't update because the left rowsets version is not satisfy update condition(version.fisrt == 0 or version.first == _max_continuous_verison + 1). So the `max_continuous_version` will keep 93 after convert rowset finished. 5. we will check the max_continuous_version of `t2` at last and it should not less than alter version. But max_continuous_version(93) is less than alter version(98), so the alter job failed at last. The main reason is we don't update `_max_continuous_version` correctly during alter job, we should recalculate the `max_continuous_version` after rowset conversion. --------- Signed-off-by: zhangqiang <[email protected]>

…hed (#28473) We will create a new tablet for each original tablet and we will write original tablet and new tablet during schema change. We will construct a `version_graph` to keep versions info for each table and the following code is how to update `version_graph`: ``` void VersionGraph::add_version_to_graph(const Version& version) { _add_version_to_graph(version); if (version.first == _max_continuous_version + 1) { _max_continuous_version = _get_max_continuous_version_from(_max_continuous_version + 1); } else if (version.first == 0) { // We need to reconstruct max_continuous_version from zero if input version is starting from zero // e.g. // 1. Tablet A is doing schema change // 2. We create a new tablet B releated A, and we will create a initial rowset and _max_continuous_version // will be updated to 1 // 3. Tablet A has a rowset R with version (0, m) // 4. Schema change will try convert R // 5. The start version of R (0) is not equal to `_max_continuous_version + 1`, and the _max_continuous_version // will not update _max_continuous_version = _get_max_continuous_version_from(0); } } ``` There exists a scenario where _max_continuous_version cannot be updated correctly e.g. 1. create a new tablet `t2` for origin tablet `t1` during schema change and `t2` has version 91,92,93,95,96,97,98. version 94 write failed. 2. when running schema change job, alter version is 98 and `t1` has version [0-90], [91-96], 97, 98 3. `max_continuous_version` of `t2` is 0 before convert rowset. After convert version [0-90], `max_continuous_version` is update to 93 because `t2` has version 91-93 before. 4. `max_continuous_version` don't update because the left rowsets version is not satisfy update condition(version.fisrt == 0 or version.first == _max_continuous_verison + 1). So the `max_continuous_version` will keep 93 after convert rowset finished. 5. we will check the max_continuous_version of `t2` at last and it should not less than alter version. But max_continuous_version(93) is less than alter version(98), so the alter job failed at last. The main reason is we don't update `_max_continuous_version` correctly during alter job, we should recalculate the `max_continuous_version` after rowset conversion. --------- Signed-off-by: zhangqiang <[email protected]> (cherry picked from commit bbedba4)

BugFix: Recalculate max_continuous_version after schema change finished

746511e

Signed-off-by: zhangqiang <[email protected]>

github-actions bot added 3.1 3.0 2.5 labels Aug 2, 2023

mergify bot assigned sevev Aug 2, 2023

code format

8cf748b

Signed-off-by: zhangqiang <[email protected]>

trueeyu approved these changes Aug 2, 2023

View reviewed changes

decster approved these changes Aug 2, 2023

View reviewed changes

decster merged commit bbedba4 into StarRocks:main Aug 2, 2023
22 checks passed

github-actions bot removed 3.1 3.0 labels Aug 2, 2023

github-actions bot removed the 2.5 label Aug 2, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BugFix] Recalculate max_continuous_version after schema change finished #28473

[BugFix] Recalculate max_continuous_version after schema change finished #28473

sevev commented Aug 2, 2023 •

edited

Loading

wanpengfei-git commented Aug 2, 2023

luohaha commented Aug 2, 2023

wanpengfei-git commented Aug 2, 2023

wanpengfei-git commented Aug 2, 2023

wanpengfei-git commented Aug 2, 2023

mergify bot commented Aug 2, 2023 •

edited

Loading

mergify bot commented Aug 2, 2023 •

edited

Loading

mergify bot commented Aug 2, 2023 •

edited

Loading

sevev commented Aug 2, 2023

[BugFix] Recalculate max_continuous_version after schema change finished #28473

[BugFix] Recalculate max_continuous_version after schema change finished #28473

Conversation

sevev commented Aug 2, 2023 • edited Loading

What type of PR is this:

Checklist:

Bugfix cherry-pick branch check:

wanpengfei-git commented Aug 2, 2023

[FE PR Coverage Check]

luohaha commented Aug 2, 2023

wanpengfei-git commented Aug 2, 2023

wanpengfei-git commented Aug 2, 2023

wanpengfei-git commented Aug 2, 2023

mergify bot commented Aug 2, 2023 • edited Loading

✅ Backports have been created

mergify bot commented Aug 2, 2023 • edited Loading

✅ Backports have been created

mergify bot commented Aug 2, 2023 • edited Loading

✅ Backports have been created

sevev commented Aug 2, 2023

sevev commented Aug 2, 2023 •

edited

Loading

mergify bot commented Aug 2, 2023 •

edited

Loading

mergify bot commented Aug 2, 2023 •

edited

Loading

mergify bot commented Aug 2, 2023 •

edited

Loading