log_status table reports wrong executed_gtid
Description
Environment
Attachments
Activity
Venkatesh Prasad March 17, 2025 at 7:26 AM
This bug is fixed by Oracle
Ref:
puneet.kaushik January 4, 2022 at 4:41 PM
Bug Fix verified in PS 8.0.26-17 , MTR tests also passed successfully .
George Lorch August 9, 2021 at 3:52 PM
Echoing Rahuls comment to be clear, this is an upstream server issue, not an Xtrabackup issue. Xtrabackup captures the coordinates contained within the log_status table and assumes, according to MySQL documentation, that the snapshot view of that table is 100% consistent. Oracle has confirmed that this is an issue within MySQL but has not yet releases a fix for it.
Rahul Malik January 7, 2021 at 12:46 PM
It is because of upstream bug https://bugs.mysql.com/bug.php?id=102175
The problem is binlog_position and gtid in log_status table should match with gtid position in binlog file.
Jira Bot December 16, 2020 at 12:56 PM
To: Former user
CC:
Hi, I'm jira-bot, Percona's Jira automation tool. I've detected that someone from
Percona has made an edit to the Summary field of an issue that you reported.
I'm not sentient (yet) so I'm not sure whether the person fixed a typo, changed
a few words, or completely rewrote the text. In any case, it is Percona Engineering's
intention to make the Summary and Description of an issue as accurate as possible
so that we're fixing the actual problem you're encountering, and to avoid
misunderstandings about symptoms and causes.
If the current Summary does not accurately reflect the problem you are reporting,
or if you feel the change was otherwise inappropriate in some way, please add a
new comment explaining things and we'll address it as soon as we can.
This message will be added only once per issue, regardless of how many times
the Summary is edited.
message-code:summary-edited
Details
Details
Assignee
Reporter
Labels
Upstream Bug URL
Needs Review
Time tracking
Fix versions
Affects versions
Priority
Medium
This causes issues with Xtrabackup. In high concurrent environments, ps.log_status table might report stalled gtid_executed values.
版本信息：
xtrabackup version 8.0.7 based on MySQL server 8.0.16 Linux (x86_64) (revision id: 069e0e6)
备份命令：
xtrabackup --defaults-file=~/conf/mysql3306.cnf --log-copy-interval=500 --user=root --password=pass --slave-info --socket=/data/mysqldata/mysql3306/mysql3306.sock --parallel=1 --tmpdir=/media/diskpool/ --no-timestamp --backup --target-dir=/media/diskpool/backup
问题：
当我的备份从库流量比较大时，我使用上面的命令备份生成备份文件，扩容新的从库，从库启动复制，很大概率会发生复制中断。数据重复或者其他导致复制中断的问题。
在8.0里面，SELECT COUNT FROM information_schema.tables WHERE engine = 'MyISAM' OR engine = 'RocksDB' 记录数是0，查看备份的命令执行如下的命令
FLUSH NO_WRITE_TO_BINLOG BINARY LOGS
SELECT server_uuid, local, replication, storage_engines FROM performance_schema.log_status
SHOW VARIABLES
SHOW SLAVE STATUS
SHOW VARIABLES
FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS
有一定的概率，下面的两个记录位点不一样，在新启动的从库上，有部分GTID已经执行了，但是xtrabackup_binlog_info 信息记录的比较靠前，导致新库无法正常复制。
cat xtrabackup_binlog_pos_innodb
mysql-bin.000002 15585
cat xtrabackup_binlog_info
mysql-bin.000002 13942 0a686001-b11e-11ea-99aa-6c92bfb04128:1-3947566996