[wk989898]

What problem does this PR solve?

Issue Number: close #12672

What is changed and how it works?

Check List

Tests

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

Questions

Will it cause performance regression or break compatibility?

Do you need to update user documentation, design documentation or monitoring documentation?

Release note

Please refer to [Release Notes Language Style Guide](https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/release-notes-style-guide.html) to write a quality release note.

If you don't think this PR needs a release note then fill it with `None`.

[gemini-code-assist]

Code Review

This pull request updates import paths in dm/checker/checker.go and dm/loader/lightning.go to reference relocated packages under github.com/pingcap/tidb/lightning/pkg and github.com/pingcap/tidb/pkg/lightning/importdef. Additionally, it upgrades the Go version to 1.25.10 and updates various third-party dependencies in go.mod and go.sum. All review comments were filtered out as they commented on version numbers, so there is no additional feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[wk989898]

/retest

[3AceShowHand]

why bump this ?

[OliverS929]

pingcap/tidb#67778 changes schemacmp so charset/collation comparison is no longer strict singleton matching: utf8/utf8mb3 -> utf8mb4 and latin1 -> utf8mb4 are treated as compatible upgrades, while unrelated charset/collation families remain incompatible.

My current understanding is that this is explainable for DM optimistic shard DDL, since DM also relies on schemacmp semantics here. The direction looks reasonable to me, but could @D3Hunter and @GMHDBJD help confirm whether this matches the intended DM behavior?

A follow-up could also consider covering the classic DM optimistic shard DDL path with a small charset/collation case, so this behavior is pinned on the DM side as well.

[OliverS929]

Since this PR also changes engine-related files, I think @D3Hunter's approval is needed before merging.

[OliverS929]

pingcap/tidb#67778 changes schemacmp so charset/collation comparison is no longer strict singleton matching: utf8/utf8mb3 -> utf8mb4 and latin1 -> utf8mb4 are treated as compatible upgrades, while unrelated charset/collation families remain incompatible.

My current understanding is that this is explainable for DM optimistic shard DDL, since DM also relies on schemacmp semantics here. The direction looks reasonable to me, but could @D3Hunter and @GMHDBJD help confirm whether this matches the intended DM behavior?

A follow-up could also consider covering the classic DM optimistic shard DDL path with a small charset/collation case, so this behavior is pinned on the DM side as well.

@alastori PTAL.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 3AceShowHand, GMHDBJD

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [3AceShowHand,GMHDBJD]
• dm/OWNERS [GMHDBJD]
• engine/OWNERS [GMHDBJD]

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:

• 2026-06-05 07:17:20.86195138 +0000 UTC m=+512341.932268770: ☑️ agreed by 3AceShowHand.
• 2026-06-09 03:41:57.120386418 +0000 UTC m=+845018.190703828: ☑️ agreed by GMHDBJD.

[wk989898]

/retest

[wk989898]

/retest

[OliverS929]

/retest

[alastori]

@OliverS929 Thanks for the context. Non-blocking PM note from the customer-impact angle.

The direction makes sense for rolling charset upgrades in sharded DM tasks. A common customer scenario is one shard moving from utf8/utf8mb3 to utf8mb4 before the others; treating that as a compatible widening avoids a false optimistic DDL conflict.

The main caveat I want to make explicit is latin1. I think we should frame latin1 -> utf8mb4 as schema compatibility, not as a data conversion guarantee. For example, a latin1 value like Café may be stored as bytes 43 61 66 E9, while the same value in utf8mb4 is 43 61 66 C3 A9. If DM treats the schema change as compatible, can we confirm how full-load and incremental paths handle existing latin1 bytes after the downstream schema is widened? I want to make sure we are not accidentally changing equality, uniqueness, sorting, or query behavior for users with non-ASCII latin1 data.

For test coverage, I would prioritize the customer-facing boundaries that should remain incompatible:

• Collation changes that alter comparison semantics. Example: utf8mb4_bin vs utf8mb4_general_ci, where values like A and a may compare differently.
• Unrelated charset families. Example: utf8mb4 vs gbk should still conflict because this is not a simple widening path.

A lower-priority follow-up is table-default-only changes, for example ALTER TABLE ... DEFAULT CHARACTER SET utf8mb4, because changing the table default does not necessarily convert existing explicit columns.

[OliverS929]

/retest

[OliverS929]

/retest

[OliverS929]

/retest

[OliverS929]

/retest

[wk989898]

/retest

[ti-chi-bot]

@wk989898: 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
pull-syncdiff-integration-test	d352679	link	unknown	/test pull-syncdiff-integration-test
pull-dm-integration-test	d352679	link	unknown	/test pull-dm-integration-test

Full PR test history. Your PR dashboard.

Details

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.