Some time ago I've noted that one of the tools I use for testing various MySQL and MariaDB cases and to reproduce potential bugs, MySQL-Sandbox, is not updated any more. It turned out that active development switched to its port in Go called dbdeployer. You can find detailed information about dbdeployer and reasons behind developing it provided by its author, Giuseppe Maxia, here and there. See also this post at Percona blog for some quick review of its main features. One of the points of …[Read more]
10 Older Entries »
It's time to continue my review of MySQL bug reports that I
considered interesting for some reason recently. I had not got
any notable reaction from Oracle engineers to my previous post about recent regression bugs in
MySQL 8.0.13, so probably this topic is not really that hot. In
this boring post I'll just review some bugs I've subscribed to
since August that are still not closed,
starting from the oldest.
Let me start with a couple of bug reports that remain "Open":
- Bug #91959 - "UBSAN: signed integer overflow in lock_update_trx_age". It's really unusual to see bug reported by …
Quickly Add a Node to an InnoDB Cluster or Group Replication (Shutterstock)
In this blog, we’ll look at how to quickly add a node to an InnoDB Cluster or Group Replication using Percona XtraBackup.
Adding nodes to a Group Replication cluster can be easy (documented here), but it only works if the existing nodes have retained all the binary logs since the creation of the cluster. Obviously, this is possible if you create a new cluster from scratch. The nodes rotate old logs after some time, however. Technically, if the
set is non-empty, it means you will need another method to add a new node to a cluster. You also …[Read more]
MySQL supports replicating to a slave that is one release higher. This allows us to easily upgrade our MySQL setup to a new version, by promoting the slave and pointing the application to it. However, though unsupported, there are times when the MySQL version of slave deployed is one release lower. In this scenario, if your application has been performing much better on an older version of MySQL, you would like to have a convenient option to downgrade. You can simply promote the slave to get the old performance back.
The MySQL manual says that ROW based
replication can be used to replicate to a lower version, provided
that no DDLs replicated are incompatible with the slave. One such
incompatible command is
ALTER USER which is a new
feature in MySQL 5.7 and not available on 5.6. :
ALTER USER …[Read more]
While writing about problematic Oracle MySQL features previously I
concentrated mostly on InnoDB problems that I have to fight with
really often and deliberately skipped replication from even the
preliminary list of features to study in details for that blog
post. First of all, I mostly work with MariaDB users now, and
implementation of many replication features in MariaDB is notably
different already (and has its own list of known problems). But this
happened also because (asynchronous) replication plays a key role
in most MySQL environments and deserves a detailed study in a
A colleague brought an article to my attention. I did not see it on Planet MySQL where I get most of the MySQL news (or it did not catch my eye there). As it is interesting replication stuff, I think it is important to bring it to the attention of the MySQL Community, so I am writing this short post.
The surprising part for me is that it uses my 4-year-old work for online migration to GTID
This tutorial demands a service restart since some flags here presented can not be dynamically changed
What is GTID and why do I need it? Directly from the MySQL documentation (excerpt taken as
is with different jargons than used here, for
slave we are using
A global transaction identifier (GTID) is a unique identifier created and associated with each transaction committed on the server of origin (the master). This identifier is unique not only to the server on which it originated, but is unique across all servers in a given replication topology.
GTID assignment distinguishes between client transactions, which are committed on the master, and replicated transactions, which are reproduced on a slave. When a client transaction is committed …[Read more]
Several MySQL releases happened yesterday, but of them all I am
mostly interested in MySQL 5.7.23, as MySQL 5.7 (either directly or
indirectly, via forks and upstream fixes they merge) is probably
the most widely used MySQL GA release at the moment.
In this post (in a typical manner for this "Fun with Bugs" series) I'd like to describe several bugs reported by MySQL Community users and fixed in MySQL 5.7.23. As usual, I'll try to concentrate mostly on InnoDB, replication, partitioning and optimizer-related bugs (if any).
In MariaDB 10.2.12, these two don’t yet work together. GTID = Global Transaction ID. In the master-slave asynchronous replication realm, this means that you can reconnect a slave to another server (change its master) and it’ll happily continue replicating from the correct point. No more fussing with filenames and offsets (which of course will both differ on different machines).
So in concept the GTIID is “globally” unique – that means it’s consistent across an entire infra: a binlogged write transaction will have the same GTID no matter on which machine you look at it.
- OK: if you are transitioning from async replication to Galera cluster, and have a cluster as slave of the old infra, then GTID will work fine.
- PROBLEM: if you want to run an async slave in a Galera cluster, GTID will currently not work. At least not reliably.
The overview issue is …[Read more]
GTID replication has made it convenient to setup and maintain MySQL replication. You need not worry about binary log file and position thanks to GTID and auto-positioning. However, things can go wrong when pointing a slave to a different master. Consider a situation where the new master has executed transactions that haven’t been executed on the old master. If the corresponding binary logs have been purged already, how do you point the slave to the new master?
Based on technical requirements and architectural change, there is a need to point the slave to a different master by
- Pointing it to another node in a PXC cluster
- Pointing it to another master in master/master replication
- Pointing it to another slave of a master
- Pointing it to the slave of a slave of the master … and so on and so forth.
Theoretically, pointing to a new master with GTID …[Read more]
10 Older Entries »