In my previous post (Puzzled by MySQL Replication), I describe a weird, but completely documented, behavior of replication that had me scratching my head for hours because it was causing data corruption. I did not give too many details then as I also wanted allowing you to scratch your head if you wished. In this post, I describe this behavior in more details.
Showing posts with label Master High Availability. Show all posts
Showing posts with label Master High Availability. Show all posts
Monday, January 27, 2020
A Legacy Behavior of MySQL Corrupting Restored Backups (replicate-same-server-id = OFF)
Labels:
Bugs,
Circular Replication,
Feature Request,
GTID,
Master High Availability,
MySQL,
Replication,
Ring Replication,
War Story
Thursday, January 9, 2020
Puzzled by MySQL Replication (War Story)
Recently, I was puzzled by MySQL replication ! Some weird, but completely documented, behavior of replication had me scratching my head for hours. I am sharing this war story so you can avoid losing time like me (and also maybe avoid corrupting your data when restoring a backup). The exact justification will come in a follow-up post, so you can also scratch your head trying to understand what I faced. So let's dive-in.
Labels:
GTID,
Master High Availability,
MySQL,
Orchestrator,
Replication,
War Story
Tuesday, February 26, 2019
MySQL Master High Availability and Failover: more thoughts
Some months ago, Shlomi Noach published a series about Service Discovery. In his posts, Shlomi describes many ways for an application to find the master. He also gives detail on how these solutions cope with failing-over to a slave, including their integration with Orchestrator.
This is a great series, and I recommend its reading for everybody implementing master failover, with or without Orchestrator, even if you are not fully automating the process yet. Taking a step back, I realized that service discovery is only one of the five parts of a full MySQL Master Failover Strategy; this post is about these five parts. In some follow-up posts, I might analyze some deployments using the framework presented in this post.
This is a great series, and I recommend its reading for everybody implementing master failover, with or without Orchestrator, even if you are not fully automating the process yet. Taking a step back, I realized that service discovery is only one of the five parts of a full MySQL Master Failover Strategy; this post is about these five parts. In some follow-up posts, I might analyze some deployments using the framework presented in this post.
Labels:
Backup,
Binlog Server,
Disaster Recovery,
Galera,
Group Replication,
GTID,
Lossless Semi-Sync,
Master High Availability,
MySQL,
Percona XtraDB Cluster,
Replication
Subscribe to:
Posts (Atom)