1. 11 Nov, 2009 1 commit
  2. 04 Nov, 2009 1 commit
    • Luis Soares's avatar
      BUG#48048: Deprecated constructs need removal in Betony · 6e068a9c
      Luis Soares authored
      NOTE: Backport of:
      
      bzr log -r revid:sp1r-serg@sergbook.mysql.com-20070505200319-38337
      ------------------------------------------------------------
      revno: 2469.263.4
      committer: serg@sergbook.mysql.com
      timestamp: Sat 2007-05-05 13:03:19 -0700
      message:
        Removing deprecated features:
        --master-XXX command-line options
        log_bin_trust_routine_creators
        table_type
        BACKUP TABLE ...
        RESTORE TABLE ...
        SHOW PLUGIN
        LOAD TABLE ... FROM MASTER
        LOAD DATA FROM MASTER
        SHOW INNODB STATUS
        SHOW MUTEX STATUS
        SHOW TABLE TYPES
        ... TIMESTAMP(N)
        ... TYPE=engine
        
        RESET SLAVE don't reset connection parameters anymore
        LOAD DATA: check opt_secure_file_priv before access(filename)
        improved WARN_DEPRECATED macro
      6e068a9c
  3. 27 Oct, 2009 1 commit
  4. 23 Oct, 2009 5 commits
  5. 20 Oct, 2009 1 commit
    • 's avatar
      Bug#13963 SHOW SLAVE HOSTS is unreliable · d17245e7
      authored
            
            Before the patch, slaves only appear in the output of SHOW SLAVE HOSTS 
            when report-host option is set. If an expected slave does not appear in  
            the list, nobody knows whether the slave does not connect or has started
            without the "report-host" option. The output also contains a strange  
            field "Rpl_recovery_rank" which has never been implemented and the manual 
            of MySQL5.4 declares that the field has been removed from MySQL5.4.
                                              
            This patch is done with these,
            According to the manual of MySQL5.4, "Rpl_recovery_rank" is removed.
            Slaves will register themselves to master no matter if report_host option is set
            or not. When slaves are registering themselves, their Server_ids, report_host
            and other information are together sent to master. Sever_ids are never null 
            and is unique in one replication group. Slaves always can be identified with  
            different Server_ids no matter if report_host exists.
      d17245e7
  6. 18 Oct, 2009 1 commit
    • He Zhenxing's avatar
      Postfix of bug#45674 · f71b836e
      He Zhenxing authored
      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.
      f71b836e
  7. 14 Oct, 2009 1 commit
  8. 13 Oct, 2009 1 commit
  9. 12 Oct, 2009 5 commits
    • He Zhenxing's avatar
      Backport post fix for semisync · dab1162b
      He Zhenxing authored
      Remove functions that no longer needed
      Fix warning suppressions
      dab1162b
    • He Zhenxing's avatar
      Backport BUG#47298 Semisync: always wait until timeout if no semi-sync slave available · b92ec529
      He Zhenxing authored
      Add an option to control whether the master should keep waiting
      until timeout when it detected that there is no semi-sync slave
      available.
      
      The bool option 'rpl_semi_sync_master_wait_no_slave' is 1 by
      defalt, and will keep waiting until timeout. When set to 0, the
      master will switch to asynchronous replication immediately when
      no semi-sync slave is available.
      b92ec529
    • He Zhenxing's avatar
      BUG#45674 FLUSH STATUS does not reset semisynchronous counters · 64fc766c
      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.
      64fc766c
    • He Zhenxing's avatar
      Backport Bug#45852 Semisynch: Last_IO_Error: Fatal error: Failed to run 'after_queue_event' hook · 7d3d0fc3
      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.
      7d3d0fc3
    • He Zhenxing's avatar
      Backport BUG#45848 Semisynchronous replication internals are visible in SHOW PROCESSLIST and logs · 55842061
      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.
      55842061
  10. 10 Oct, 2009 1 commit
  11. 09 Oct, 2009 1 commit
  12. 07 Oct, 2009 2 commits
  13. 06 Oct, 2009 1 commit
  14. 03 Oct, 2009 5 commits
  15. 02 Oct, 2009 13 commits