Mysql：Changes in MySQL 5.6.0 (Not released, Milestone 4)：Global UUID

Changes in MySQL 5.6.0 (Not released, Milestone 4)

Globally Unique Server IDs

• Replication: Globally unique IDs for MySQL servers were implemented. A UUID is now obtained automatically when the MySQL server starts. The server first checks for a UUID written in the auto.cnf file (in the server's data directory), and uses this UUID if found. Otherwise, the server generates a new UUID and saves it to this file (and creates the file if it does not already exist). This UUID is available as the server_uuid system variable.

  MySQL replication masters and slaves know each other's UUIDs. The value of a slave's UUID can be read in the output of SHOW SLAVE HOSTS. After a slave is started using START SLAVE, the value of the master's UUID is available on the slave in the output of SHOW SLAVE STATUS. (Bug #33815, Bug #11747723)

  References: See also: Bug #16927, Bug #11745543.

Functionality Added or Changed

• Partitioning: It is now possible to exchange a partition of a partitioned table or a subpartition of a subpartitioned table with a nonpartitioned table that otherwise has the same structure using the ALTER TABLE ... EXCHANGE PARTITION statement. This can be used, for example, for importing and exporting partitions.

  For more information and examples, see Exchanging Partitions and Subpartitions with Tables.

• Replication: MySQL now supports delayed replication such that a slave server deliberately lags behind the master by at least a specified amount of time. The default delay is 0 seconds. Use the new MASTER_DELAY option for CHANGE MASTER TO to set the delay to N seconds:

  CHANGE MASTER TO MASTER_DELAY = N;
  

  An event received from the master is not executed until at least N seconds later than its execution on the master.

  START SLAVE and STOP SLAVE take effect immediately and ignore any delay. RESET SLAVE resets the delay to 0.

  SHOW SLAVE STATUS has three new fields that provide information about the delay:

  • SQL_Delay: The number of seconds that the slave must lag the master.

  • SQL_Remaining_Delay: When Slave_SQL_Running_State is Waiting until MASTER_DELAY seconds after master executed event, this field contains the number of seconds left of the delay. At other times, this field is NULL.

  • Slave_SQL_Running_State: The state of the SQL thread (analogous to Slave_IO_State). The value is identical to the State value of the SQL thread as displayed by SHOW PROCESSLIST.

  When the slave SQL thread is waiting for the delay to elapse before executing an event, SHOW PROCESSLIST displays its State value as Waiting until MASTER_DELAY seconds after master executed event.

  The relay-log.info file now contains the delay value, so the file format has changed. See Slave Status Logs. In particular, the first line of the file now indicates how many lines are in the file. If you downgrade a slave server to a version older than MySQL 5.6, the older server will not read the file correctly. To address this, modify the file in a text editor to delete the initial line containing the number of lines.

  The introduction of delayed replication entails these restrictions:

  • Previously the BINLOG statement could execute all types of events. Now it can execute only format description events and row events.

  • The output from mysqlbinlog --base64-output=ALWAYS cannot be parsed. ALWAYS becomes an invalid value for this option in 5.6.1.

  For additional information, see Delayed Replication. (Bug #28760, Bug #11746794)