Read the original article at Make MySQL clustering work for you

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 [...]

For more articles like these go to Sean Hull's Scalable Startups

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.

Read the original article at No tools to reconcile MySQL with two masters

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 [...]

For more articles like these go to Sean Hull's Scalable Startups

Read the original article at Temp tables can break replication

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 [...]

For more articles like these go to Sean Hull's Scalable Startups

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

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

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

Read the original article at How to make MySQL multi-master work for you

Coming soon! Want more? Grab our Scalable Startups monthly for more tips and special content. Here’s a sample Related posts:Transaction isolation breaks when writing two masters MySQL requires an authoritative master to build slaves MySQL needs single master to check data integrity A master isn’t born but made Why does MySQL replication fail?

For more articles like these go to Sean Hull's Scalable Startups

Read the original article at MySQL needs single master to check data integrity

MySQL slaves can drift out of sync. Many of our clients are surprised to find some data differences in their replication topology, once we do some checking and sniffing around. Such checks require a single reliable or authoritative master to compare against. Click through to the end for multi-master solutions that work with MySQL. Reason [...]

For more articles like these go to Sean Hull's Scalable Startups

Read the original article at MySQL requires an authoritative master to build slaves

In MySQL database operations, you often need to rebuild slaves. They fail for a lot of different reasons, fall out of sync or crash. When this happens you may find you need to reclone and start fresh. This is normally done by finding your authoritative master database, and doing a hotbackup. Click through to the [...]

For more articles like these go to Sean Hull's Scalable Startups

Read the original article at Limitations of MySQL row-based replication

MySQL offers a few different options for how you perform replication. Statement-based has been around a lot longer, and though it has some troublesome characteristics they’re known well and can be managed. What’s more it supports online schema changes with multi-master active-passive setup. We recommend this solution. Row-based replication is newer. It attempts to address [...]

For more articles like these go to Sean Hull's Scalable Startups

Read the original article at 10 reaons active-active is hard and how to solve it

Multi-master replication provides redundant copies of your most important business assets. What’s more it allows applications to scale out, which is perfect for cloud hosting solutions like Amazon Web Services. But when you decide you need to scale your write capacity, you may be considering active-active setup. This is dangerous, messy and prone to failure. [...]

For more articles like these go to Sean Hull's Scalable Startups

Read the original article at Why does MySQL replication fail?

When considering active-active multi-master, you must consider it’s foundation technology. Although MySQL replication is straightforward to setup, it can fail in a myriad of ways. Most of those are known and well understood. We can solve them only if we use the technology in the standard way. Click through to the end for multi-master solutions [...]

For more articles like these go to Sean Hull's Scalable Startups

Standard MySQL is configurable such that a single master server can be clustered with a number of read-only slave servers. To enable this master-slave replication, master’s transaction logs are communicated to the slaves (log shipping). Log shipping is a form of asynchronous replication. Under this configuration, the data on the slave always remains behind the master, a condition referred to as slave lag or replication lag. The extent of the slave lag depends on workload, network bandwidth and network latency. Database reads can be served out of the slaves, assuming the application has been designed to tolerate the slave lag and requisite staleness of data (eventual consistency), which can at times be variable and opaque. MySQL master-slave replication offers the possibility of promoting a slave to become the new master

• Rich Mason's keynote on how to Deploy, Scale and Save with Linux, Virtualization and MySQL
• Keith Hollman on stage to discuss how to Embrace Database Diversity
• Mark Swarbrick's lecture on 

Read the original article at AirBNB didn’t have to fail

Today part of Amazon Web Services failed, taking down with it a slew of startups that all run on Amazon’s Cloud infrastructure. AirBNB was one of the biggest, but also Heroku, Reddit, Minecraft, Flipboard & Coursera down with it. Its not the first time. What the heck happened, and why should we care?

1. Root Cause

The AWS service allows companies like AirBNB to build web applications, and host them on servers owned and managed by Amazon.

Attached are the slides for my MySQL Connect talk Evaluating MySQL High-availability alternatives, which I will present today at 14:30 at the MySQL Connect conference.

A bit unusually I'm posting the material ahead of the talk. The point of the talk is about evaluating each alternative from your own perspective. With that in mind, if you're at the talk with your own laptop, feel free to browse the slides at your own pace from here.

read more

Read the original article at 10 ways I avoid trouble in database operations

1. Avoid destructive commands From time to time I’m working with new recruits and bringing them up to speed in operations. The first thing I emphasize is care with destructive commands. What do I mean here? Well there are all sorts of them. SQL commands such as DROP table & DROP database. But also TRUNCATE [...]

For more articles like these go to Sean Hull's Scalable Startups

In the Matrix movie there is a scene where the heroes visit a spiritual councelor, and amongst the people in her waiting room they see a little boy, dressed like a buddhist monk, who can bend a spoon just by looking at it. When they ask him what he does to bend the spoon, the boy's answer is: "There is no spoon". And if you watch the movie to the end, you will see that he is right. (In that spirit, if this post is too long to read for you, just skip to the last paragraph for the answer.)

The title for this blog post is of course inspired by Baron's "Is automated failover the root of all evil?", which is a commentary on GitHub's detailed explanation of their recent Pacemaker-induced downtime. Baron makes a good

As part of a recent engagement, I described the relative products to manage a MySQL pair (i.e. an Active/Passive MySQL masters configuration). This included the steps to undertake a controlled failover for supporting software maintenance using manual procedures. The upcoming Effective MySQL: Replication Techniques in Depth book details each step and all conditions to review over a dozen pages. While the steps are straightforward and generally well known, scripting this for your environment takes a certain amount of work to ensure your information is correct, and application connectivity loss is kept to a minimum.

In Continuent Tungsten (which I have just been reviewing these past few weeks), I achieved the same result with a single command.

$ echo "switch" |