Bug #45674 FLUSH STATUS does not reset semisynchronous counters

Submitted:	23 Jun 2009 11:22	Modified:	12 Nov 2009 14:48
Reporter:	Philip Stoev	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S3 (Non-critical)
Version:	5.4	OS:	Any
Assigned to:	Zhenxing He	CPU Architecture:	Any

Description:
FLUSH STATUS does not reset the Rpl_semi_sync_master_yes_tx variable (and maybe the others as well) 

We are talking about a counter that is incremented for each DML statement, so there may be issues with wrap-around and monitoring tools.

How to repeat:
Start server:

MTR_VERSION=1 perl mysql-test-run.pl \
--start-and-exit \
 --mysqld=--plugin-dir=/build/bzr/azalea/plugin/semisync/.libs \
--mysqld=--plugin-load=rpl_semi_sync_master=libsemisync_master.so \
--mysqld=--rpl_semi_sync_master_enabled=1 \
rpl_alter

mysql> flush status;
Query OK, 0 rows affected (0.00 sec)

mysql> show status like '%Rpl_semi_sync_master_yes_tx%';
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| Rpl_semi_sync_master_yes_tx | 15    |
+-----------------------------+-------+
1 row in set (0.00 sec)

mysql> flush status;
Query OK, 0 rows affected (0.00 sec)

mysql> show status like '%Rpl_semi_sync_master_yes_tx%';
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| Rpl_semi_sync_master_yes_tx | 16    |
+-----------------------------+-------+
1 row in set (0.00 sec)

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/83562

3605 He Zhenxing	2009-09-17
      BUG#45674 FLUSH STATUS does not reset semisynchronous counters
      
      Semi-sync status were not reset by FLUSH STATUS, this was because
      all semi-sync status variables are defined as SHOW_FUNC and FLUSH
      STATUS could only reset SHOW_LONG type variables.
      
      This problem is fixed by change all status variables that should
      be reset by FLUSH STATUS from SHOW_FUNC to SHOW_LONG.
      
      After the fix, the following status variables will be reset by
      FLUSH STATUS:
        Rpl_semi_sync_master_yes_tx
        Rpl_semi_sync_master_no_tx
      
      Note: normally, FLUSH STATUS itself will be written into binlog
      and be replicated, so after FLUSH STATS, one of
        Rpl_semi_sync_master_yes_tx
        Rpl_semi_sync_master_no_tx
      can be 1 dependent on the semi-sync status. So it's recommended
      to use FLUSH NO_WRITE_TO_BINLOG STATUS to avoid this.
     @ mysql-test/suite/rpl/t/rpl_semi_sync.test
        Test FLUSH STATUS will reset certain semi-sync status variables
     @ plugin/semisync/semisync_master.cc
        Use the global status variable directly instead of the status member variables
     @ plugin/semisync/semisync_master.h
        Remove status member variables from ReplSemiSyncMaster
        Renamed variables to make them consistent with the corresponding server status variables.
     @ plugin/semisync/semisync_master_plugin.cc
        Changed status variables that should be reset by FLUSH STATUS from SHOW_FUNC to SHOW_LONG, because FLUSH STATUS can only reset SHOW_LONG type variables.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/83563

3605 He Zhenxing	2009-09-17
      BUG#45674 FLUSH STATUS does not reset semisynchronous counters
      
      Semi-sync status were not reset by FLUSH STATUS, this was because
      all semi-sync status variables are defined as SHOW_FUNC and FLUSH
      STATUS could only reset SHOW_LONG type variables.
      
      This problem is fixed by change all status variables that should
      be reset by FLUSH STATUS from SHOW_FUNC to SHOW_LONG.
      
      After the fix, the following status variables will be reset by
      FLUSH STATUS:
        Rpl_semi_sync_master_yes_tx
        Rpl_semi_sync_master_no_tx
      
      Note: normally, FLUSH STATUS itself will be written into binlog
      and be replicated, so after FLUSH STATS, one of
        Rpl_semi_sync_master_yes_tx
        Rpl_semi_sync_master_no_tx
      can be 1 dependent on the semi-sync status. So it's recommended
      to use FLUSH NO_WRITE_TO_BINLOG STATUS to avoid this.
     @ mysql-test/suite/rpl/r/rpl_semi_sync.result
        Update test result
     @ mysql-test/suite/rpl/t/rpl_semi_sync.test
        Test FLUSH STATUS will reset certain semi-sync status variables
     @ plugin/semisync/semisync_master.cc
        Use the global status variable directly instead of the status member variables
     @ plugin/semisync/semisync_master.h
        Remove status member variables from ReplSemiSyncMaster
        Renamed variables to make them consistent with the corresponding server status variables.
     @ plugin/semisync/semisync_master_plugin.cc
        Changed status variables that should be reset by FLUSH STATUS from SHOW_FUNC to SHOW_LONG, because FLUSH STATUS can only reset SHOW_LONG type variables.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/84716

3605 He Zhenxing	2009-09-26
      BUG#45674 FLUSH STATUS does not reset semisynchronous counters
      
      Semi-sync status were not reset by FLUSH STATUS, this was because
      all semi-sync status variables are defined as SHOW_FUNC and FLUSH
      STATUS could only reset SHOW_LONG type variables.
      
      This problem is fixed by change all status variables that should
      be reset by FLUSH STATUS from SHOW_FUNC to SHOW_LONG.
      
      After the fix, the following status variables will be reset by
      FLUSH STATUS:
        Rpl_semi_sync_master_yes_tx
        Rpl_semi_sync_master_no_tx
      
      Note: normally, FLUSH STATUS itself will be written into binlog
      and be replicated, so after FLUSH STATS, one of
        Rpl_semi_sync_master_yes_tx
        Rpl_semi_sync_master_no_tx
      can be 1 dependent on the semi-sync status. So it's recommended
      to use FLUSH NO_WRITE_TO_BINLOG STATUS to avoid this.
     @ mysql-test/suite/rpl/r/rpl_semi_sync.result
        Update test result
     @ mysql-test/suite/rpl/t/rpl_semi_sync.test
        Test FLUSH STATUS will reset certain semi-sync status variables
     @ plugin/semisync/semisync_master.cc
        Use the global status variable directly instead of the status member variables
     @ plugin/semisync/semisync_master.h
        Remove status member variables from ReplSemiSyncMaster
        Renamed variables to make them consistent with the corresponding server status variables.
     @ plugin/semisync/semisync_master_plugin.cc
        Changed status variables that should be reset by FLUSH STATUS from SHOW_FUNC to SHOW_LONG, because FLUSH STATUS can only reset SHOW_LONG type variables.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/84717

2838 He Zhenxing	2009-09-26 [merge]
      Merge BUG#45674 to 6.0-codebase-bugfixing

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/85121

3628 He Zhenxing	2009-09-30
      BUG#45674 FLUSH STATUS does not reset semisynchronous counters
      
      Semi-sync status were not reset by FLUSH STATUS, this was because
      all semi-sync status variables are defined as SHOW_FUNC and FLUSH
      STATUS could only reset SHOW_LONG type variables.
      
      This problem is fixed by change all status variables that should
      be reset by FLUSH STATUS from SHOW_FUNC to SHOW_LONG.
      
      After the fix, the following status variables will be reset by
      FLUSH STATUS:
        Rpl_semi_sync_master_yes_tx
        Rpl_semi_sync_master_no_tx
      
      Note: normally, FLUSH STATUS itself will be written into binlog
      and be replicated, so after FLUSH STATS, one of
        Rpl_semi_sync_master_yes_tx
        Rpl_semi_sync_master_no_tx
      can be 1 dependent on the semi-sync status. So it's recommended
      to use FLUSH NO_WRITE_TO_BINLOG STATUS to avoid this.
     @ mysql-test/suite/rpl/r/rpl_semi_sync.result
        Update test result
     @ mysql-test/suite/rpl/t/rpl_semi_sync.test
        Test FLUSH STATUS will reset certain semi-sync status variables
     @ plugin/semisync/semisync_master.cc
        Use the global status variable directly instead of the status member variables
     @ plugin/semisync/semisync_master.h
        Remove status member variables from ReplSemiSyncMaster
        Renamed variables to make them consistent with the corresponding server status variables.
     @ plugin/semisync/semisync_master_plugin.cc
        Changed status variables that should be reset by FLUSH STATUS from SHOW_FUNC to SHOW_LONG, because FLUSH STATUS can only reset SHOW_LONG type variables.

Pushed into 6.0.14-alpha (revid:alik@ibmvm-20091009083208-0o0f0i9w1sq3c1kn) (version source revid:zhenxing.he@sun.com-20090930040024-ns9117k6khr4a9f6) (merge vers: 6.0.14-alpha) (pib:12)

Documented fix in the 6.0.14 changelog as follows:

        FLUSH STATUS failed to reset the status variables
        Rpl_semi_sync_master_yes_tx and Rpl_semi_sync_master_no_tx.

Set to NDI, waiting for 5.4 push. (?)

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/86575

3116 He Zhenxing	2009-10-12
      BUG#45674 FLUSH STATUS does not reset semisynchronous counters
      
      Semi-sync status were not reset by FLUSH STATUS, this was because
      all semi-sync status variables are defined as SHOW_FUNC and FLUSH
      STATUS could only reset SHOW_LONG type variables.
      
      This problem is fixed by change all status variables that should
      be reset by FLUSH STATUS from SHOW_FUNC to SHOW_LONG.
      
      After the fix, the following status variables will be reset by
      FLUSH STATUS:
        Rpl_semi_sync_master_yes_tx
        Rpl_semi_sync_master_no_tx
      
      Note: normally, FLUSH STATUS itself will be written into binlog
      and be replicated, so after FLUSH STATS, one of
        Rpl_semi_sync_master_yes_tx
        Rpl_semi_sync_master_no_tx
      can be 1 dependent on the semi-sync status. So it's recommended
      to use FLUSH NO_WRITE_TO_BINLOG STATUS to avoid this.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/87241

3119 He Zhenxing	2009-10-18
      Postfix of bug#45674
      
      rpl_semi_sync_master_wait_sessions was reset by FLUSH STATUS,
      which could cause the master fail to wake up waiting sessions and
      result in master timeout waiting for slave reply.
      
      rpl_semi_sync_master_wait_session should not be reset, this 
      problem is fixed by this patch.
     @ plugin/semisync/semisync_master_plugin.cc
        Change wait_sessions from SHOW_LONG back to SHOW_FUNC so that it will not be reset by FLUSH STATUS.

Pushed into 6.0.14-alpha (revid:alik@sun.com-20091027094604-9p7kplu1vd2cvcju) (version source revid:zhenxing.he@sun.com-20091026140226-uhnqejkyqx1aeilc) (merge vers: 6.0.14-alpha) (pib:13)

Already documented in 6.0.14 changelog; re-closing.

Pushed into 5.5.0-beta (revid:alik@sun.com-20091110093229-0bh5hix780cyeicl) (version source revid:alik@sun.com-20091027095744-rf45u3x3q5d1f5y0) (merge vers: 5.5.0-beta) (pib:13)

Also documented in the 5.5.0 changelog; closed.

Page generated in 0.076 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.