What’s New in MySQL 5.5 and 5.6

Hi All 

 

I checked the presentation of  Data charmer and Sheeri. It's awasome.

 

 What’s New in MySQL 5.5 and 5.6 Replication

1.    MySQL  5.5 supports  Semi Synchronous replication

2.    MySQL  5.6 supports delayed replication

3.    Server UUID ( New: Added  to ensure  Global transaction ID )

4.    Crash-Safe Slave

5.    Multi-threaded slave (Most Awaited features)

6.    Global transaction identifiers

 MySQL 5.5 – Semi synchronous replication

It increases reliability of slaves by making sure that the changes of master are committed on at least one of the slaves before the write query is returned.

To use it, you will require to install the plug-in rpl_semi_sync_master on the master and rpl_semi_sync_slave on the slave. Then you can configure the master/slave to use the plug-in. You need to restart both the master and slave to activate the plug-in and configurations.

Once you restart you will see variables like rpl_semi_sync and you can see whether it’s enabled, what the timeout, trace level, etc are.

Rpl_semi_sync_master_no_trx (how many transactions didn’t go to the slaves) and Rpl_semi_sync_master_yes_trx (was it successfully sent) are status variables or counters on the master.

 MySQL 5.6 – Delayed replication

It is part of the MySQL 5.6 that ships with MySQL, No need to install plug-ins. You need to execute below command after stopping slave.

CHANGE MASTER TO MASTER_DELAY=#seconds;

Show slave status shows you two parameters in output SQL_Delay and SQL_Remaining_Delay.  Where SQL_Delay show total defined delay and SQL_remaining_delay shows the remaining delay.

UUID – Each master has a UUID in addition to the server_id. This is important for global transaction IDs, which makes sure that even if you change server_id’s the global transaction ID is still associated with the same server.  So you can finally identify the each transaction on a server.

More crash-safe replication: Replication in MySQL 5.6 is crash-safe.   It will make sure a statement is going to execute more than one time.

Execute below command
SHOW VARIABLES LIKE ‘%info%’ ;

Apart from these variables one more variables use is called slave_parallel_workers.

These variables help ensure that if the slave crashes, the relay log and master.info files are kept in sync and don’t try to retrieve or apply a statement more than once.

The crash-safe features are only for innodb, but MySQL ships the following tables with MyISAM engines.

1.    slave_master_info

2.    slave_relay_log_info

3.    slave_worker_info

So when you start working with it, change engine of these tables to innodb using command

 ALTER TABLE …ENGINE=INNODB

When you do SHOW SLAVE STATUS you’ll see Master_info_file: mysql.slave_master_info

When you will check these tables , you will   get a lot of information. Table slave_master_info is most, but not all, of the same info in SHOW SLAVE STATUS.

Table slave_worker_info has 1 line for each worker you have set.

Multi-threaded slave aka parallel replication

1.    It requires MySQL 5.6 in both master and slave (can’t do 5.5 master, 5.6 slave) to actually do parallel replication.

2.    Parallel replication with a MySQL 5.5 master will slow down replication – so you can do parallel replication but it’s 3x slower (right now).

3.    Data gets parallelized by the schema – so if you have 2 queries in the same schema, they can’t be done in parallel, but 2 queries in 2 different schemas, they can be done in parallel. If you only have one schema, don’t bother using parallel replication.

To use it configure the global dynamic parameter:

SET GLOBAL slave_parallel_workers=10; (or 3, or whatever, default is 0).

 How do you choose the # of parallel workers to choose? MySQL is smart enough to figure out how to use the parallel workers around the schemas you have. In tests, parallel replication was 3-4x faster than regular replication.

Global transaction ID – If a master fails, all the data from the master cannot be accessed. So you have to figure out which slave is the most advanced one (in terms of time ), promote that slave to the master, and figure out which transactions the other slaves were missing. But it’s hard to know in the relay log, because it can be a different file/position in each slave. So the global transaction id uses a unique number, so you don’t have to worry about the relay log filename/position. To use the global transaction id, all machines in the cluster (master and slaves) should have following parameters in their configuration files.

log-bin
log-slave-updates
gtid-mode=ON
disable-gtd-unsafe-statemnets –tricky

Why tricky? This feature does not work on non-transactional tables, like MyISAM. If you try to remove the anonymous user from the mysql.user table and you have this set, it’s not safe so it doesn’t work and you get a master error. GRANT, REVOKE, DROP USER will work, but DELETE, INSERT, etc don’t work.

CREATE TABLE…SELECT does not work with this feature, so don’t turn it on if you use that.

After changing the variables in the mysql config file, restart the servers to pick up the changes.

You then see the

 @@SESSION.GTID_NEXT=’44556A96-8417-11E1-9589-2BD5ACDD51FD:1′
After the : is the transaction ID number (1 in this case), everything before it is the server’s UUID. Using this information you can more easily find which transactions in the binary log you need.

There are 2 more lines in SHOW SLAVE STATUS\G:
Retrieved_Gtid_Set:1-100
Executed_Gtid_Set:1-100

The show slave output will be like below now.