Efficient MySQL Performance

Chapter 9. Other Challenges

This chapter is a short but important laundry list of common MySQL challenges and how to mitigate them. These challenges don’t fit into other chapters because most are not directly related to performance. But don’t underestimate them: the first two challenges, for example, can ruin a database. More importantly, these challenges are not special cases that only happen when the stars align and The Fates conspire to ruin your day. These are common challenges. Take them seriously, and expect to face them.

Split-Brain Is the Greatest Risk

Split-brain requires two conditions to occur at the same time, in the same replication topology:

• More than one MySQL instance is writable (read_only=0)

• Writes occur on more than one MySQL instance

Neither of those should ever happen—especially not at the same time—but life is full of surprises, and you cannot avoid bugs or accidents forever. When it happens, it’s called split-brain: instead of all MySQL instances having the same data, they’re figuratively split because data is no longer identical (consistent) on every instance. Not only is inconsistent data fundamentally wrong, it can break replication or—worse—have a ripple effect that causes more data to become inconsistent, which causes the next challenge: data drift.

Note

Split-brain does not apply to MySQL replication topologies intentionally designed to have multiple writable instances.

If split-brain occurs, you must detect and stop it immediately. Why? Because ...