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
10 Older Entries »
I published another article on the Percona Community Blog. This time, it is about Semi-Synchronous Replication. You can read the post here:
Question about Semi-Synchronous Replication: the Answer with all the Details
I previously wrote about my motivation to publish on the Percona Community Blog. Things have not changed: I still believe it is a great community initiative that I want to
I was recently asked a question by mail about MySQL Lossless Semi-Synchronous Replication. As I think the answer could benefit many people, I am answering it in a blog post. The answer brings us to the internals of transaction committing, of semi-synchronous replication, of MySQL (server) crash recovery, and of storage engine (InnoDB) crash recovery. I am also debunking some misconceptions that I have often seen and heard repeated by many. Let’s start by stating one of those misconceptions.
One of those misconceptions is the following (this is NOT true): semi-synchronous enabled slaves are always the most up-to-date slaves (again, this is NOT true). If you hear it yourself, then please call people out on it to avoid this spreading more. Even if some slaves have semi-synchronous replication disabled (I will use semi-sync for …[Read more]
I just posted an article on the Percona Community Blog. You can access it following this link:
A Nice Feature in MariaDB 10.3: no InnoDB Buffer Pool in Core Dumps
I do not know if I will stop publishing posts on my personal blog or use both, I will see how things go. In the rest of this post, I will share why I published there and how things went in the process.
So there is a Percona
MariaDB 10.3 is now generally available (10.3.7 was released GA on 2018-05-25). The article What’s New in MariaDB Server 10.3 by the MariaDB Corporation lists three key improvements in 10.3: temporal data processing, Oracle compatibility features, and purpose-built storage engines. Even if I am excited about MyRocks and curious on Spider, I am also very interested in less flashy but still very important changes that make running the database in production easier. This post describes such improvement: no InnoDB Buffer Pool in core dumps.
Hidden in the …[Read more]
I am now in an airport, waiting for one of the four flights that will bring me to Percona Live Santa Clara 2018. This is a good time to write some details about my tutorial on parallel replication. But before talking about Percona Live, I will share thoughts on MySQL/MariaDB bugs that caught my attention in the last weeks/months (Valeriy: you clearly have an influence on me).
In a previous post, I talked about the existence of a CREATE TABLE that is crashing MySQL up to versions 5.5.58, 5.6.38 and 5.7.20, and MariaDB up to version 5.5.57, 10.0.32, 10.1.26 and 10.2.7. I hope you upgraded (or can mitigate this problem in another way) as I am now publishing the CREATE TABLE of death.
The first thing to clarify about the CREATE TABLE of death is that it is not a bug in
I ended one of my last posts - Fun with InnoDB Persistent Statistics - with a cryptic sentence: there is more to say about this but I will stop here for now. What I did not share at the time is the existence of a crashing bug somehow related to what I found. But let's start with some context.
In Bug#86926, I found a way to put more than 64 characters in the field table_name of the
TL;DR: unless you know what you are doing, you should always have a primary key on your tables when replicating in RBR (and maybe even all the time).
TL;DR2: MariaDB 10.1 has an interesting way to protect against missing a primary key (innodb_force_primary_key) but it could be improved.
A few weeks ago, I was called off hours because replication delay on all the slaves from a replication chain
In one of my previous posts, I shared InnoDB table compression statistics for a read-only dataset using the default value of innodb_compression_level (6). In it, I claimed, without giving much detail, that using the maximum value for the compression level (9) would not make a big difference. In this post, I will share more details about this claim.
TL;DR: tuning innodb_compression_level is not
10 Older Entries »