Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

in v5.0.2, tidb_gc_scan_lock_mode default value is different in scratch installed server and upgrade server #25100

Closed
seiya-annie opened this issue Jun 3, 2021 · 3 comments · Fixed by #25112
Labels
severity/minor sig/transaction SIG:Transaction type/bug The issue is confirmed as a bug.

Comments

@seiya-annie
Copy link

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

in scratch install server, the default value for tidb_gc_scan_lock_mode is PHYSICAL
but in the upgraded server(don't change this param before upgrade), the default value is LEGACY

MySQL [(none)]>

2. What did you expect to see? (Required)

3. What did you see instead (Required)

MySQL [(none)]> show variables like '%tidb_gc_scan_lock_mode%'
-> ;
+------------------------+----------+
| Variable_name | Value |
+------------------------+----------+
| tidb_gc_scan_lock_mode | PHYSICAL |
+------------------------+----------+
1 row in set (0.38 sec)

[tidb@centos76_vm 501]$ diff 501_systemvar.txt 502_systemvar.txt
548c548
< tidb_gc_scan_lock_mode PHYSICAL

tidb_gc_scan_lock_mode LEGACY
650c650

4. What is your TiDB version? (Required)

| Release Version: v5.0.2
Edition: Community
Git Commit Hash: f610f8b
Git Branch: heads/refs/tags/v5.0.2
UTC Build Time: 2021-06-02 02:00:45
GoVersion: go1.13
Race Enabled: false
TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306
Check Table Before Drop: false |

@seiya-annie seiya-annie added type/bug The issue is confirmed as a bug. severity/major labels Jun 3, 2021
@MyonKeminta
Copy link
Contributor

The problem is, on a new-created cluster that haven't do GC, the entry tikv_gc_scan_lock_mode is no written into the mysql.tidb table, and querying the tidb_gc_scan_lock_mode returns the wrong result "PHYSICAL", but the actual behavior is still "LEGACY".

@ti-srebot
Copy link
Contributor

ti-srebot commented Jun 3, 2021

Please edit this comment or add a new comment to complete the following information

Bug

1. Root Cause Analysis (RCA) (optional)

On a new-created cluster that has never do GC, the entry tikv_gc_scan_lock_mode is no written into the mysql.tidb table, and querying the tidb_gc_scan_lock_mode returns the wrong result "PHYSICAL", but the actual behavior is still "LEGACY". The reason is that the global variable loaded the default value from a different place.

2. Symptom (optional)

Create a new cluster and immediately execute select @@global.tidb_gc_scan_lock_mode, it returns "PHYSICAL", instead of the actual mode "LEGACY"

3. All Trigger Conditions (optional)

On a new created cluster (within 10 minutes since starting cluster)

4. Workaround (optional)

No.

5. Affected versions

[v5.0.0:v5.0.2]

6. Fixed versions

[v5.0.3]

@ti-srebot
Copy link
Contributor

( component or sig(label) ) fields are empty.

@seiya-annie seiya-annie added the sig/transaction SIG:Transaction label Jun 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity/minor sig/transaction SIG:Transaction type/bug The issue is confirmed as a bug.
Projects
None yet
3 participants