Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 10.0.5
-
Component/s: None
-
Labels:None
Description
I'm not sure if it's a bug, maybe it's supposed to work this way, but it surely looks strange, so I'll file it and leave it to you to decide
When a slave is actively replicating, most of the time @@gtid_current_pos and @@gtid_slave_pos appear to be empty. No special flow seems to be necessary, just regular DML would suffice. For example, the test below performs a thousand of inserts on master while checking the values on the slave at the same time. Here is a typical extract from the output:
Variable_name Value gtid_binlog_pos 0-1-513 gtid_current_pos gtid_slave_pos Variable_name Value gtid_binlog_pos 0-1-523 gtid_current_pos gtid_slave_pos Variable_name Value gtid_binlog_pos 0-1-530 gtid_current_pos 0-1-530 gtid_slave_pos 0-1-530 Variable_name Value gtid_binlog_pos 0-1-540 gtid_current_pos gtid_slave_pos Variable_name Value gtid_binlog_pos 0-1-548 gtid_current_pos gtid_slave_pos Variable_name Value gtid_binlog_pos 0-1-559 gtid_current_pos gtid_slave_pos
If instead of a number of small statements I execute one very big statement, the effect can still be observed, but the empty values only appear during a small fraction of time. So, I presume the "empty phase" has somewhat flat duration per an event group, regardless its size.
Test case:
--source include/master-slave.inc
--source include/have_innodb.inc
--source include/have_binlog_format_row.inc
--connection slave
--source include/stop_slave.inc
change master to master_use_gtid=current_pos;
--source include/start_slave.inc
--connection master
create table t1 (i int, c varchar(8)) engine=InnoDB;
--delimiter |
create procedure p(n int)
begin
while n > 0 do
insert into t1 values (1,'test1'),(2,'test2'),(3,'test3'),(4,'test4');
set n = n - 1;
end while;
end|
--delimiter ;
send call p(1000);
--connection slave
let $run = 100;
--disable_query_log
while ($run)
{
SHOW VARIABLES LIKE 'gtid%pos';
--sleep 1
dec $run;
}
--connection master
--reap
drop table t1;
drop procedure p;
--sync_slave_with_master
--connection master
--source include/rpl_end.inc
bzr version-info
revision-id: sergii@pisem.net-20130610064025-makoe3xkewwwky8j revno: 3761 branch-nick: 10.0
Gliffy Diagrams
Attachments
Issue Links
- relates to
-
MDEV-26 Global transaction ID
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Pushed to 10.0-base
Yeah, it's certainly a bug, good catch!
The window for seeing this is in-between the start and the end of the COMMIT
event when it is executed by the slave SQL thread. The function record_gtid()
deletes too much from the internal in-memory hash, it must keep around at
least one entry.
Will fix.