Bug #74423 RECEIVED_TRANSACTION_SET field on replication_connection_status shows garbage

• Submitted: 16 Oct 2014 22:36
• Modified: 11 Jun 2015 13:55
• Reporter: Pedro Gomes
• Status: Closed
• Category: MySQL Server: Replication
• Severity: S3 (Non-critical)
• Version: 5.7+
• OS: Any
• CPU Architecture: Any

[16 Oct 2014 22:36] Pedro Gomes

Description:
On the performance schema table, replication_connection_status, the field that shows the received transactions sometimes shows garbage.
This happens after executing a reset slave all and a change master, right before the slave start.
On this point, the user can check the table, but replication is not yet start so it's fields should be empty.

How to repeat:
Run the following test:

--source include/master-slave.inc

connection master;

create table test.t1(a int) engine=innodb;
insert into test.t1 values (1);

sync_slave_with_master;

query_vertical SELECT * FROM performance_schema.replication_connection_status;

--source include/stop_slave.inc

RESET SLAVE ALL;

--disable_query_log
eval CHANGE MASTER TO MASTER_USER='root', MASTER_CONNECT_RETRY=1, MASTER_HOST='127.0.0.1', MASTER_PORT=$MASTER_MYPORT;
--enable_query_log

query_vertical SELECT * FROM performance_schema.replication_connection_status;

--source include/start_slave.inc

connection master;

DROP TABLE t1;
sync_slave_with_master;

--source include/rpl_end.inc

Suggested fix:
Look for possible unclean structures and improve the test for detecting if the retrieved  GITD set is empty or not.
AFAIK, this condition:

    if ((m_row.received_transaction_set_length=
         io_gtid_set->to_string(&m_row.received_transaction_set)) < 0)
    {

is not met on this case.

[11 Jun 2015 13:55] David Moss

The following was added to the 5.7.7 changelog:
After issuing RESET SLAVE, the RECEIVED_TRANSACTION_SET field in the
performance_schema.replication_connection_status table showed incorrect
values. This could cause an incorrect string value error.