ddl: add states to remove old objects during modifying column (#62549)

[ti-chi-bot]

This is an automated cherry-pick of #62549

What problem does this PR solve?

Issue Number: close #60264, close #62531

Problem Summary:

-- origin schema
create table t (a int primary key, b varchar(255), key k_b (b))
-- ddl
alter table t modify column b int unsigned not null;

-- write-reorg -> public
-- non-owner schema (_Col$ and _Idx$ are not visible to users)
create table t (a int primary key, b int, _Col$_b varchar(255), key k_b (b), key _Idx$_k_b (_Col$_b));
-- owner schema
create table t (a int primary key, b int, key k_b (b));

-- owner insert (OLD INDEX IS NOT MAINTAINED!)
insert into t values (10, " 09.60 ");

-- non-owner select
select * from t where a = 10;
10 <nil>

-- non-owner admin check
admin check table t;
[admin:8223]data inconsistency in table: t, index: k_b, handle: 10, index-values:"" != record-values:"handle: 10, values: [KindNull <nil>]"

The root cause is that the assumption of "two adjacent schema versions are compatible" is broken for modifying columns covered with indexes:

• Non-owner TiDB has schema version n-1. Only old indexes and old columns are visible.
• Owner TiDB has schema version n. Only new indexes are visible.

When owner TiDB inserts or deletes a record, only new indexes will be maintained. If you run SELECT or ADMIN CHECK on non-owner TiDB with schema version n-1, either the data has one more record than the index, or the index has one more record than the data, depending on whether the non-owner node executes an insert or delete statement.

This issue doesn't happen on ADD INDEX because non-owner TiDBs don't have an "old" index. Any SELECT statements will use TableScan instead of IndexLookup. There is no such chance to see inconsistent data on non-owner TiDBs.

What changed and how does it work?

Before removing public columns/indexes, we should follow the path public -> write-only -> delete-only -> none. In the above case, owner TiDB is still aware of the old index (which is in write-only state). As long as it maintains the old index mutations, there is no data inconsistent issue.

• Break changing column step write-reorg -> public into multiple steps:
  • changing column write-reorg, old column & indexes public
  • changing column public, old column & indexes write-only
  • changing column public, old column & indexes delete-only
  • changing column public, old column & indexes none(removed)
• Don't use column name to locate "old column" anymore. This PR changes to use column ID, and it is persisted to job arguments after the first execution.
• Add an internal column / index name prefix _Tomestone$_ to represent the objects that need to be removed eventually.

Example 1

create table t (a int not null default 1, b int default 2, c int not null default 0, primary key(c), index idx(b), index idx1(a), index idx2(b, c));

alter table t change column b bb mediumint first;

Example 2

create table t (a int, b int, c int, index i1(a), index i2(b), index i3(c), index i4(a, b), index i5(a, b, c));

alter table t modify column a tinyint, modify column b tinyint, modify column c tinyint;

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
  Run the script mentioned in Meet "Data is corrupted, missing data for NOT NULL column" when running "delete from xxx" along with DDL (modify column) concurrently #62531 for 20 min, no data inconsistent issue found.
• No need to test

  • I checked and no code files have been changed.

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

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[ti-chi-bot]

This cherry pick PR is for a release branch and has not yet been approved by triage owners.
Adding the do-not-merge/cherry-pick-not-approved label.

To merge this cherry pick:

1. It must be approved by the approvers firstly.
2. AFTER it has been approved by approvers, please wait for the cherry-pick merging approval from triage owners.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ti-chi-bot]

@tangenta This PR has conflicts, I have hold it.
Please resolve them or ask others to resolve them, then comment /unhold to remove the hold label.

[ti-chi-bot]

@ti-chi-bot: ## If you want to know how to resolve it, please read the guide in TiDB Dev Guide.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign ekexium for approval. For more information see the Code Review Process.
Please ensure that each of them provides their approval before proceeding.

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

Needs approval from an approver in each of these files:

• OWNERS

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]

@ti-chi-bot: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
idc-jenkins-ci-tidb/check_dev_2	acc4308	link	true	/test check-dev2
idc-jenkins-ci-tidb/mysql-test	acc4308	link	true	/test mysql-test
idc-jenkins-ci-tidb/build	acc4308	link	true	/test build
idc-jenkins-ci-tidb/check_dev	acc4308	link	true	/test check-dev
idc-jenkins-ci-tidb/unit-test	acc4308	link	true	/test unit-test

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.