infoschema: fix a snapshot infoschema cache bug after v1 v2 switch

[tiancaiamao]

What problem does this PR solve?

Issue Number: close #54926

Problem Summary:

In infoschema cache.go, we maintain the infoschema snapsht history.
As the comment says:

	// `GetByVersion` is allowed to load the latest schema that is less than argument
	// `version` when the argument `version` <= the latest schema version.
	// if `version` > the latest schema version, always return nil, loadInfoSchema
	// will use this behavior to decide whether to load schema diffs or full reload.
	// Consider cache has values [10, 9, _, _, 6, 5, 4, 3, 2, 1], version 8 and 7 is empty because of the diff is empty.
	// If we want to get version 8, we can return version 6 because v7 and v8 do not change anything, they are totally the same,
	// in this case the `i` will not be 0.

However, when v1 & v2 infoschema switch, we reset the history (because co-exists of v1 and v2 would make the memory usage double), that change break the assumption.

	// For example:
	//     Before
	//              infoschema 51
	//              infoschema 52
	//              infoschema 53
	//              infoschema 54
	//              infoschema 55
	//              infoschema 56
	//     After Upsert()
	//              infoschema 56
	//     Then load historial snapshot version 51
	//              infoschema 51
	//              infoschema 56
	// Now, request for schema version 55, return infoschem 51 would be wrong!

What changed and how does it work?

If upsert is called, use exact match for schema version compare.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• 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

[tiprow]

Hi @tiancaiamao. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

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.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.9423%. Comparing base (cf4bb51) to head (460e907).
Report is 26 commits behind head on master.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #54966        +/-   ##
================================================
+ Coverage   74.7249%   74.9423%   +0.2173%     
================================================
  Files          1558       1568        +10     
  Lines        363817     447671     +83854     
================================================
+ Hits         271862     335495     +63633     
- Misses        72284      92080     +19796     
- Partials      19671      20096       +425     

Flag	Coverage Δ
integration	50.0908% <100.0000%> (?)
unit	72.0063% <100.0000%> (-1.6066%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
dumpling	52.9567% <ø> (-2.2327%)	⬇️
parser	∅ <ø> (∅)
br	52.7087% <ø> (+4.9822%)	⬆️

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: crazycs520, wjhuang2016

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:

• pkg/infoschema/OWNERS [wjhuang2016]

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-07-27 05:03:45.015901742 +0000 UTC m=+68509.142961893: ☑️ agreed by crazycs520.
• 2024-07-29 03:01:48.419919132 +0000 UTC m=+152024.699967240: ☑️ agreed by wjhuang2016.

[wjhuang2016]

/retest

[tiancaiamao]

/retest

[tiprow]

@tiancaiamao: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

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.