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
In a MySQL hosting replication setup, the parameter Seconds_Behind_Master (SBM), as displayed by the SHOW SLAVE STATUS command, is commonly used as an indication of the current replication lag of the slave. In this blog post, we examine how to understand and interpret this value in various situations.
Possible Values of Seconds Behind Master
The value of SBM, as explained in the MySQL documentation, depends on the state of the MySQL slave in general, and the states of MySQL slave SQL_THREAD and IO_THREAD in particular. While IO_THREAD connects with the master and reads the updates, SQL_THREAD applies these updates on the slave. Let’s examine the possible values of SBM during different states of the MySQL Slave.
When SBM Value is Null
- SBM is …
Today I'd like to continue my tradition of ignoring MySQL 8 (after all,
I can not even build 8.0.14 any more on my Ubuntu
14.04, it's not supported suddenly because of old gcc
version) and, of all MySQL server versions released by Oracle
this week, concentrate on bugs reported in public bugs database
and fixed in the latest minor release of MySQL 5.7 branch,
This time there is only one InnoDB community-reported bug fixed, Buig #87423 - "os0file.cc assertion failed 'offset > 0' in os_file_io_complete", from Vasily Nemkov. See also it's duplicate, …
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]
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]