log_status has wrong binary_log_position of gtid_executed

Description

Description:
When the server is under heavy write operation
,binary_log_position of gitid_executed shown in log_status doesn't match with the position of that gitd shown in the binary log file.

How to repeat:
Run below load
sysbench /usr/local/Cellar/sysbench/1.0.20/share/sysbench/oltp_insert.lua --mysql-db=test --mysql-user=root --mysql-socket=$SOCKET --threads=10 --time=1500 --report-interval=1 --events=0 --db-driver=mysql prepare

Query binary_log_position and gtid_executed from log_status table.

position of the GTID in binlog file is different from what is shown above

Environment

None

Smart Checklist

Activity

Show:

Venkatesh Prasad March 17, 2025 at 7:24 AM

This bug is fixed by Oracle.

Venkatesh Prasad January 7, 2021 at 12:55 PM

When client/slave applier threads update the executed_gtids gtid set, it doesn't take write lock on the global_sid_lock (https://github.com/percona/percona-server/blob/8.0/sql/rpl_gtid_state.cc#L174) but instead takes read_lock for updating the structure.

When log_status query tries to take write lock on global_sid_lock, it will wait until all reader threads to finish updating the executed gtids structure. But these client threads, after updating the executed_gtids are allowed to execute, till they wait for the lock on the binary log to update the log position.

Since, the required lock is held by the log_status query, we will always get the consistent binlog file and the position, but we may not always get the consistent executed_gtids if there are already some threads updating it when log_status query tries to acquire the write lock on the global_sid_lock.

Details

Assignee

Reporter

Labels

Upstream Bug URL

Time tracking

1d 1h logged

Affects versions

Priority

Smart Checklist

Created January 7, 2021 at 12:26 PM
Updated March 17, 2025 at 7:24 AM