MySQL Cluster: El ‘qué’ y el ‘cómo’.
Para aquellos que encuentran mucho sobre MySQL en Inglés pero poco en Español: mi pequeña aportación.
En el enlace tenéis información sobre qué es MySQL Cluster y cómo funciona. Incluso con ejemplos técnicos para romper las barreras y ayudar a simplificarlo (espero).
One of the cool new features in 5.7 Release Candidate is Multi Source Replication, as I previously looked into in 5.7.5 DMR.
I’ve had more and more people like the idea of this, so here’s a quick set-up as to what’s needed and how it could work.
1. Prepare master environments.
2. Prepare 40 masters for replication.
3. Create slave.
4. Insert data into the Masters.
Carrying on with my MySQL 5.7 Labs Multi Source Replication scenario, I wanted to evaluate performance impact via MySQL Enterprise Monitor.
Whilst I opened my environment, I remember that I had generated lots of different skeleton scripts that allowed me to deploy the 50 servers quickly, and I didn’t want to add each of my targets 1 by 1 in MEM. So, I used one of the many features available, “Add Bulk MySQL Instances”.
A customer asked whether we they could have 10 or more masters consolidate all the data into a single central slave. After getting a bit more information from them and seeing the application functionality, it was clear that MySQL Labs 5.7.5 Multi Source Replication could be a good candidate. Why?:
– Each master is independent from the rest of the masters.
– One-way traffic: there is only one way to update a row, and that’s from the master.
– All the masters use the same schema and table, but no single master will ever need to, nor be able to update a row from another master.
– PK determined via app & master env.
Multisource replication is still in http://labs.mysql.com, but here’s what I did to test it out.
Ok, so I wanted to look into the new compression options of MEB 3.10.
And I would like to share my tests with you. Remember, they’re just this, tests, so please feel free to copy n paste and obtain your own results and conclusions, and should I say it, baselines, in order to compare future behaviour, on your own system.
An Oracle Linux 6.3 virtual machine with 3Gb RAM, 2 virtual threads, on a 1x quad core, windows laptop. Not pretty, but hey.
So, these tests are solely about backup. I’ll do restore when I get some *more* time.
In addition to my recent post, I just had to go into using the –use-tts for specific tables and selective backup sets.
As all my schemas were employeesn, I thought it would be a good idea to run:
mysqlbackup -uroot --socket=/tmp/mysql.sock --backup-dir=/home/mysql/MEB/restore \
--with-timestamp --use-tts --include=employees* backup
In this post I go into some performance metrics and time spent on using MySQL Enterprise Backup instead of mysqldump, and seeing how far I could go with some parallel configuration.