This is a follow-up post in the MySQL Master Replication Crash Safety series. In the two previous posts, we explored the consequence of reducing durability on masters (including setting sync_binlog to a value different than 1) when slaves are using legacy file+position replication. In this post, we cover GTID replication. This introduces a new inconsistency scenario with a potential
This is Part #2 of the MySQL Master Replication Crash Safety series. In the previous post, we explored the consequence of reducing durability on masters with slaves using legacy file+position replication. The consequences are data inconsistencies with a clear warning sign: the slaves stop replicating and report an error. In this post, we extend our understanding of the impact of running a
A well-known performance booster in MySQL is to set sync_binlog to 0. However, this configuration alone comes with serious consequences on consistency and on durability (the C and D of ACID); I explore those in this series. In this post, I give some background on the sync_binlog parameter and I explain part of the problem with setting it to 0 (or to a value different from 1). The other
There is often confusion as to how it can be claimed that MySQL Cluster delivers in-memory performance while also providing durability (the “D” in ACID). This post explains how that can be achieved as well as how to mix and match scalability, High Availability and Durability.
MySQL Cluster deployment options
As an aside, the user can specify specific MySQL Cluster tables or columns to be stored on disk rather than in memory – this is a solution for extra capacity but you don’t need to take this performance hit just to have the data persisted to disk. This post focuses on the in-memory approach.
There is a great deal of flexibility in how you deploy MySQL Cluster with in-memory data – allowing the user to decide which features they want to make use of.
The simplest (and least common) topology …[Read more]