[MDEV-30608] rpl.rpl_delayed_parallel_slave_sbm sometimes fails with Seconds_Behind_Master should not have used second transaction timestamp Created: 2023-02-07  Updated: 2023-02-09  Resolved: 2023-02-09

Status: Closed
Project: MariaDB Server
Component/s: Replication, Tests
Affects Version/s: 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, 10.11
Fix Version/s: 10.11.3, 11.0.1, 10.4.29, 10.5.20, 10.6.13, 10.8.8, 10.9.6, 10.10.4

Type: Bug Priority: Major
Reporter: Angelique Sklavounos (Inactive) Assignee: Brandon Nesterenko
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-29639 Seconds_Behind_Master is incorrect fo... Closed
relates to MDEV-30619 Parallel Slave SQL Thread Can Update ... Closed

 Description   

https://buildbot.mariadb.net/buildbot/builders/kvm-fulltest2/builds/39795

10.7 bc656c4fa

rpl.rpl_delayed_parallel_slave_sbm 'row' w3 [ fail ]
        Test ended at 2023-02-07 10:31:30
 
CURRENT_TEST: rpl.rpl_delayed_parallel_slave_sbm
mysqltest: At line 102: Seconds_Behind_Master should not have used second transaction timestamp
 
The result from queries just before the failure was:
< snip >
connection slave;
UNLOCK TABLES;
include/sync_with_master_gtid.inc
#
# Pt 2) If the SQL thread has not entered an idle state, ensure
# following events do not update SBM
# Stop slave IO thread so it receives both events together on restart
connection slave;
include/stop_slave_io.inc
connection master;
# Sleep 2 to allow a buffer between events for SBM check
insert into t1 values (1);
# Sleep 3 to create gap between events
insert into t1 values (2);
connection slave;
LOCK TABLES t1 WRITE;
START SLAVE IO_THREAD;
# Wait for first transaction to complete SQL delay and begin execution..
# Validate SBM calculation doesn't use the second transaction because SQL thread shouldn't have gone idle..
# SBM 0 was more recent than time since last transaction (1 seconds)


Generated at Thu Feb 08 10:17:32 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.