1. 12 Oct, 2009 3 commits
    • He Zhenxing's avatar
      BUG#45674 FLUSH STATUS does not reset semisynchronous counters · 26b47d93
      He Zhenxing authored
      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.
      26b47d93
    • He Zhenxing's avatar
      Backport Bug#45852 Semisynch: Last_IO_Error: Fatal error: Failed to run 'after_queue_event' hook · 825dce21
      He Zhenxing authored
      Errors when send reply to master should never cause the IO thread
      to stop, because master can fall back to async replication if it
      does not get reply from slave.
      
      The problem is fixed by deliberately ignoring the return value of
      slaveReply.
      825dce21
    • He Zhenxing's avatar
      Backport BUG#45848 Semisynchronous replication internals are visible in SHOW PROCESSLIST and logs · f8155de0
      He Zhenxing authored
      Semi-sync uses an extra connection from slave to master to send
      replies, this is a normal client connection, and used a normal
      SET query to set the reply information on master, which is visible
      to user and may cause some confusion and complaining.
      
      This problem is fixed by using the method of sending reply by
      using the same connection that is used by master dump thread to
      send binlog to slave. Since now the semi-sync plugins are integrated
      with the server code, it is not a problem to use the internal net
      interfaces to do this.
      
      The master dump thread will mark the event requires a reply and
      wait for the reply when the event just sent is the last event
      of a transaction and semi-sync status is ON; And the slave will
      send a reply to master when it received such an event that requires
      a reply.
      f8155de0
  2. 03 Oct, 2009 1 commit
    • He Zhenxing's avatar
      Fix semisync master/slave status always showed as OFF on sparc · d8724a45
      He Zhenxing authored
      On sparc, semisync master/slave status is always showed as OFF, this
      is fixed by change rpl_semisync_master/slave_status variables from
      long to char.
      
      plugin/semisync/semisync_master.cc:
        Change rpl_semisync_master_status variables from long to char
      plugin/semisync/semisync_master.h:
        Change rpl_semisync_master_status variables from long to char
      plugin/semisync/semisync_slave.cc:
        Change rpl_semisync_slave_status variables from long to char
      plugin/semisync/semisync_slave.h:
        Change rpl_semisync_slave_status variables from long to char
      d8724a45
  3. 02 Oct, 2009 2 commits
  4. 30 Sep, 2009 2 commits
  5. 26 Sep, 2009 1 commit
  6. 21 Sep, 2009 1 commit
  7. 04 Sep, 2009 1 commit
  8. 03 Sep, 2009 6 commits
  9. 02 Sep, 2009 17 commits
  10. 01 Sep, 2009 6 commits