If you’ve wanted to see how well MySQL Fabric actually works and how easy it makes setting up replication and switching Masters & Slaves back and forth, with a sample use case of having the master stored in a USB stick, then feel free to have a look at:
o la versión en Español:
Please let me know what you think.
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.
So, the good thing about MEM 3.0 is that it’s agentless, i.e. you don’t need an agent to use Query Analyzer data and see when performance is at it’s worst and dive into the offending SQL’s and explain plans to see what’s happening.
That’s great, however, sometimes it’s not always an easy road to migrate to 5.6 and even if you’re doing so, there’s nearly always a time when you want to continue viewing things in 5.5.x and compare performance between the 2.
The thing is, that in order to see the Explain Plans we need 5.6.14 or upwards (and setting “UPDATE performance_schema.setup_consumers SET enabled = ‘YES’ WHERE name = ‘events_statements_history_long';” ).
So, here’s how to do it: