ddl: Fix the physically drop storage instance may block removing regions

[JaySon-Huang]

What problem does this PR solve?

Issue Number: close #9437

Problem Summary:

When a table is dropped in tidb, and exceeds the gc_safepoint, tiflash will generate an InterpreterDropQuery to physically remove the data from the tiflash instance. The "DropQuery" will call DeltaMergeStore::dropAllSegments to remove the Segment at DeltaTree storage one by one. Because there are many segments for the table, running DeltaMergeStore::dropAllSegments is slow.
https://github.com/pingcap/tiflash/blob/v7.1.3/dbms/src/TiDB/Schema/SchemaSyncService.cpp#L216-L227
https://github.com/pingcap/tiflash/blob/v7.1.3/dbms/src/Storages/DeltaMerge/DeltaMergeStore.cpp#L342-L349

[2024/09/16 21:29:29.604 +00:00] [INFO] [SchemaSyncService.cpp:170] ["Performing GC using safe point 452597098965106688"] [source="keyspace=4294967295"] [thread_id=4314]
[2024/09/16 21:29:29.610 +00:00] [INFO] [SchemaSyncService.cpp:216] ["Physically dropping table test_db(694).test_tbl(563080)"] [source="keyspace=4294967295"] [thread_id=4314]
[2024/09/16 21:29:30.446 +00:00] [INFO] [DeltaMergeStore.cpp:413] ["Clear DeltaMerge segments data"] [source="keyspace_id=4294967295 table_id=563080"] [thread_id=4314]
[2024/09/16 21:29:30.465 +00:00] [INFO] [Segment.cpp:2004] ["Finish segment drop its next segment, segment=<segment_id=292469 epoch=2 range=[?,?) next_segment_id=292472 delta_rows=0 delta_bytes=0 delta_deletes=0 stable_file=dmf_1174749 stable_rows=98304 stable_bytes=576748236 dmf_rows=98304 dmf_bytes=576748236 dmf_packs=12>"] [source="keyspace_id=4294967295 table_id=563080 segment_id=292469 epoch=2"] [thread_id=4314]
[2024/09/16 21:29:30.553 +00:00] [INFO] [Segment.cpp:2004] ["Finish segment drop its next segment, segment=<segment_id=292223 epoch=3 range=[?,?) next_segment_id=292469 delta_rows=0 delta_bytes=0 delta_deletes=0 stable_file=dmf_1205953 stable_rows=86440 stable_bytes=507435226 dmf_rows=86440 dmf_bytes=507435226 dmf_packs=11>"] [source="keyspace_id=4294967295 table_id=563080 segment_id=292223 epoch=3"] [thread_id=4314]
...

However, DeltaMergeStore::dropAllSegments does not check that all Regions have been removed from TiFlash before the physical drop action is performed. So at the same time, there are some Region removed actions are performed.
All the raftstore threads that try to remove Region will run into removeObsoleteDataInStorage, calling DeltaMergeStore::flushCache and try to acquire a read latch on table_id=563080. At last, all the raftsotre threads are blocked by the thread that executing DeltaMergeStore::dropAllSegments.

But more raft-message comes into the tiflash instance, the memory usage grows and cause OOM kills. After restarts, the tiflash instance runs into the same blocking again. And at last, all the segments (around 30,000 in total) are removed from tiflash. And tiflash begins to catch-up the raft message.

[2024/09/16 23:25:37.681 +00:00] [INFO] [DeltaMergeStore.cpp:413] ["Clear DeltaMerge segments data"] [source="keyspace_id=4294967295 table_id=563080"] [thread_id=4143]
...
[2024/09/16 23:46:11.570 +00:00] [INFO] [Segment.cpp:2004] ["Finish segment drop its next segment, segment=<segment_id=281216 epoch=2 range=[?,?) next_segment_id=281738 delta_rows=0 delta_bytes=0 delta_deletes=1 stable_file=dmf_1205957 stable_rows=59514 stable_bytes=348855913 dmf_rows=59514 dmf_bytes=348855913 dmf_packs=8>"] [source="keyspace_id=4294967295 table_id=563080 segment_id=281216 epoch=2"] [thread_id=4143]
[2024/09/16 23:46:11.714 +00:00] [INFO] [DeltaMergeStore.cpp:419] ["Clear DeltaMerge segments data done"] [source="keyspace_id=4294967295 table_id=563080"] [thread_id=4143]

What is changed and how it works?

ddl: Fix the physical drop storage instance may block removing regions
Make sure physical drop storage instance only happen after all related regions are removed

Pick PRs:

• ddl: Fix the storage instance may be physically dropped when the region is not removed #8721
• ddl: Fix logging cause by non-dropped table #8955
• ddl: Do not succee the last_gc_safepoint when physically dropping table is skipped #8910
• tests: Fix unstable schema test #8972

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Fix the issue that TiFlash may OOM after running `DROP TABLE` on a table with large amount of rows

[JaySon-Huang]

/run-all-tests

[JaySon-Huang]

/run-all-tests

[CalvinNeo]

lgtm

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: CalvinNeo, Lloyd-Pottiger

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [CalvinNeo,Lloyd-Pottiger]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2024-09-20 08:06:30.130596991 +0000 UTC m=+1207659.871020925: ☑️ agreed by CalvinNeo.
• 2024-09-20 08:33:56.790137941 +0000 UTC m=+1209306.530561881: ☑️ agreed by Lloyd-Pottiger.