Fix the bug that duplicated page file block GC#2170
Fix the bug that duplicated page file block GC#2170ti-srebot merged 7 commits intopingcap:masterfrom
Conversation
|
/run-all-tests |
|
Why "Maybe some old files are held by snapshot for a long time" can cause "generate a PageFile "page_1000_1" again" ? |
Signed-off-by: JaySon-Huang <jayson.hjs@gmail.com>
Signed-off-by: JaySon-Huang <jayson.hjs@gmail.com>
Signed-off-by: JaySon-Huang <jayson.hjs@gmail.com>
Signed-off-by: JaySon-Huang <jayson.hjs@gmail.com>
Signed-off-by: JaySon-Huang <jayson.hjs@gmail.com>
Signed-off-by: JaySon-Huang <jayson.hjs@gmail.com>
f2908a6 to
9c23003
Compare
| // In case that those files are hold by snapshot and do migratePages to same `migrate_file_id` again, we need to check | ||
| // whether gc_file (and its legacy file) is already exist. | ||
| // | ||
| // For example: | ||
| // First round: | ||
| // PageFile_998_0, PageFile_999_0, PageFile_1000_0 | ||
| // ^ ^ | ||
| // └────────────────────────────────┘ | ||
| // Only PageFile_998_0 and PageFile_1000_0 are picked as candidates, it will generate PageFile_1000_1 for storing | ||
| // GC data in this round. | ||
| // | ||
| // Second round: | ||
| // PageFile_998_0, PageFile_999_0, PageFile_1000_0 | ||
| // ^ ^ ^ | ||
| // └────────────────┵───────────────┘ | ||
| // Some how PageFile_1000_0 don't get deleted (maybe there is a snapshot that need to read Pages inside it) and | ||
| // we start a new round of GC. PageFile_998_0(again), PageFile_999_0(new), PageFile_1000_0(again) are picked into | ||
| // candidates and 1000_0 is the largest file_id. |
There was a problem hiding this comment.
Why "Maybe some old files are held by snapshot for a long time" can cause "generate a PageFile "page_1000_1" again" ?
I've added an example for it.
Adding those PageFiles with no valid pages to candidates is useless but I still want to log them in DataCompactor::logMigrationDetails to easily find unexpected situation that some PageFiles are not really get removed for several GC round.
Maybe we can do some refactor on DataCompactor::selectCandidateFiles to avoid adding PageFile with no valid pages into candidates. But let's do it in a separate PR.
@flowbehappy
|
/run-all-tests |
|
/merge |
|
/run-all-tests |
|
cherry pick to release-4.0 in PR #2183 |
|
cherry pick to release-5.0 in PR #2185 |
|
cherry pick to release-5.1 in PR #2186 |
Signed-off-by: ti-srebot <ti-srebot@pingcap.com> Co-authored-by: JaySon <tshent@qq.com>
What problem does this PR solve?
Issue Number: close #2169
Problem Summary:
In
DataCompactor::migratePages, we avoid generating a PageFile that already exists, but we didn't check whether its "Legacy" mode exists or not.https://github.com/pingcap/tics/blob/74c69fb1d35da3582cb9279ecb4d8597e4a78d00/dbms/src/Storages/Page/gc/DataCompactor.cpp#L150-L158
https://github.com/pingcap/tics/blob/74c69fb1d35da3582cb9279ecb4d8597e4a78d00/dbms/src/Storages/Page/PageStorage.cpp#L1137-L1145
For example,
What is changed and how it works?
Check whether page file with same <id, level>, status in [Formal, Legacy] exists before generating PageFile for GC data
Related changes
Check List
Tests
Side effects
Release note