We’ve told you all about MySQL mult-master replication’s limitations. If you write to two masters it is bound to fail for myriad reasons. Now what? Do what the pros do that’s what. A. Don’t write to both masters Using multi-master replication works great as long as you do so in active-passive mode. Never write to [...]
Good morning Percona Live visitors! Attached to this post you can find a spreadsheet (both LibreOffice or Excel, as you prefer) that you can use towards the end of my tutorial. I've also attached the slides so you can download a copy of them.
We were delighted last week to find out that we’d been named one of the ‘2013 Top 100 Europe’ winning companies by the Red Herring editorial team. Congratulations to all companies involved!
We were delighted last week to find out that we’d been named one of the ‘2013 Top 100 Europe’ winning companies by the Red Herring editorial team. Congratulations to all companies involved!
Swapping has always been something bad for MySQL performance but it is even more important for HA systems. It is so important to avoid swapping with HA that NDB cluster basically forbids calling malloc after the startup phase and hence its rather complex configuration.
Probably most readers of this blog know (or should know) about Linux swappiness setting, which basically controls how important is the file cache for Linux. Basically, with InnoDB, since the file cache is not important we add “vm.swappiness = 0″ to “/etc/sysctl.conf” and run “sysctl -p” and we are done.
Swappiness solves part of the swapping issue but not all. With Numa systems, the picture is more complex and swapping can occur because of a memory imbalance between the physical cpus, the sockets and not cores. Jeremy Cole explained this here and …
[Read more]Here’s the last nail in the coffin. We hope this convinces you not to write to multiple masters with MySQL replication. Reason 10 – No tools to reconcile inconsistent masters For all the endless reasons we’ve already outlined MySQL replication is prone to failure. We know it’s going to happen, you now know too. When [...]
If you’re not convinced yet that writing to dual masters is a bad idea, we have a couple more reasons. 9. Temp tables break replication after restart MySQL’s replication is sensitive to temporary tables. You shouldn’t use them. If your queries create them to work against, and a node crashes, the temp tables will be [...]
Read the original article at Crashed nodes corrupt your MySQL cluster
Writing to two masters is like walking around with a loaded shotgun. Eventually one of your instances will fail and when it does, replications position & synchronization information could easily become corrupt! Reason 8 – Crashed nodes cause big problems MySQL instances, unfortunately can crash. When that happens, they don’t always sync the replication position [...]
For more articles like these go to Sean Hull's Scalable Startups
Related posts:
[Read more]Read the original article at Transaction isolation breaks when writing two masters
Continuing our discussion of multi-master replication, we hit on five more reasons why writing to two masters aka active-active replication is very dangerous. Click through to the end for multi-master solutions that work with MySQL. Reason 6 – You lose transaction isolation This may sound like a theoretical point to some. But hopefully we can [...]
For more articles like these go to Sean Hull's Scalable Startups
Related posts:
[Read more]Read the original article at Active-active replication reduces operational flexibility
Among the myriad data integrity and corruption risks associated with active-active replication, you also lose out on configurability and operational flexibility. Reason 7 – Can’t add nodes easily The often touted solution to use auto_increment_increment and auto_increment_offset fixes you to a given setup forever. You can set it up with a discrete two nodes, all [...]
For more articles like these go to Sean Hull's Scalable Startups
Related posts:
[Read more]