Liveblogging: What’s New In MySQL 5.5 and 5.6 Replication

Liveblogging: What’s New In MySQL 5.5 and 5.6 Replication:
Liveblog: What’s New In MySQL 5.5 and 5.6 Replication

presented by Giuseppe Maxia at the Percona Live MySQL Conference and Expo.
Has been working with MySQL for 11 years.

Yesterday Oracle released MySQL 5.6.5 with new stuff, so the content was rewritten last night.

main features we’ll talk about:

5.5 semi synchronous replication

5.6 delayed replication

server uuid

crash-safe slave

multi-threaded slave

global transaction identifiers
In MySQL 5.5 – what is semisync replication? It increases reliability by making sure that the changes are committed on at least one of the slaves before the write query is returned.

To use it, install the plugin rpl_semi_sync_master on the master, and rpl_semi_sync_slave on the slave. Then you configure the master to use the plugin, and then you restart both the master and slave to activate the plugin and config.
Once you restart you 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 trx didn’t go to the slaves) and Rpl_semi_sync_master_yes_tx (was it successfully sent) are status variables = counters on the master.
In MySQL 5.6 – delayed replication is part of the MySQL that ships with MySQL, you no longer need to use pt-slave-delay.

CHANGE MASTER TO MASTER_DELAY=#seconds;
show slave status shows you SQL_Delay and SQL_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. [Giuseppe did not know why the server_id wasn't abandoned totally in favor of the UUID.]
More crash-safe replication:

SHOW VARIABLES LIKE ‘%info%’ ;

there are master_info_repository, relay_log_info_file, relay_log_info_repository, sync_master_info, sync_relay_log_info

also there’s a variables 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 as MyISAM:

slave_master_info

slave_relay_log_info

slave_worker_info

so when you start, ALTER TABLE …ENGINE=INNODB
When you do SHOW SLAVE STATUS you’ll see

Master_info_file: mysql.slave_master_info
SELECT * FROM tables you get a lot of info – slave_master_info is most, but not all, of the same info in SHOW SLAVE STATUS.
slave_worker_info has 1 line for each worker you have set.
facts about multi-threaded slave aka parallel replication
Requires MySQL 5.6 in both master and slave (can’t do 5.5 master, 5.6 slave) to actually do parallel replication.

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).

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.
do it by setting the global dynamic parameter:
SET GLOBAL slave_parallel_worker=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):

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

(That’s the set of numbers)
—–
And that’s it, he then took questions.

PlanetMySQL Voting:
Vote UP /
Vote DOWN