MySQL 8.0.1 has just been released with a wonderful set of features across the board. Specifically in replication, there is plenty of new and exciting functionality as well as performance improvements. In this post I am going to summarize the replication features of this development milestone release.…
In this tutorial, we are going to guide you through the process of preparing and configuring RPM based distributions, such as OEL, Fedora or CentOS, for InnoDB cluster usage. We will address the steps from the initial configurations, to the cluster creation, and finally the MySQL Router configuration to map the data traffic.…
In this tutorial, we are going to guide you through the whole process of configuring Debian based distributions for InnoDB cluster usage; the most popular being Ubuntu. We will address the steps from the initial configurations, to the cluster creation, and finally the MySQL Router configuration to map the data traffic.…
Nowadays, it’s very important to have a high availability solution that gives you serenity and security for your data. The task of ensuring your data will always be available is a challenging one, that not everyone wants to do because it demands a lot of knowledge about tools, configuration, and technologies.…
You might already have seen the announcement of the MySQL InnoDB Cluster Release Candidate (RC), available for download from our MySQL APT (Ubuntu, Debian) and YUM (Redhat, OEL, Fedora) repositories and from dev.mysql.com. As usual, this releases contains the following three components.…
MySQL Cluster is a highly available, distributed, shared-nothing database with very interesting performance characteristics for some workloads. Among other features, it supports automatic sharding and allows us to bypass the SQL layer if we don’t need it, via the NDB API (which in my eyes, makes it one of the few transactional nosql databases out there).
In this post, I’ll describe how we can set up replication from MySQL Cluster into a standalone MySQL server using Innodb as the storage engine.
Introduction
There are a few reasons to set up replication between MySQL Cluster and a non-NDB based MySQL server. These reasons include (but are not limited to): the need …
[Read more]UPDATE: Some of the language in the original post was considered overly-critical of Oracle by some community members. This was not my intent, and I’ve modified the language to be less so. I’ve also changed term “synchronous” (which the use of is inaccurate and misleading) to “virtually synchronous.” This term is more accurate and already used by both technologies’ founders, and should be less misleading.
I also wanted to thank Jean-François Gagné for pointing out the incorrect sentence about multi-threaded slaves in Group Replication, which I also corrected accordingly.
In today’s blog post, I will briefly compare two major virtually synchronous replication technologies available today for MySQL.
More Than Asynchronous Replication
…
[Read more]
Sometimes MySQL surprises you in ways you would have never
imagined.
Would you think that the order in which the indexes appear in a
table matters?
It does. Mind you, not the order of the columns - the order of
the indexes.
MySQL optimizer can, in specific circumstances, take different
paths, sometimes with nefarious effects.
Please consider the following table:
CREATE TABLE `mypartitionedtable ` (
`HASH_ID` char(64) NOT NULL,
`RAW_DATA` mediumblob NOT NULL,
`EXPIRE_DATE` timestamp NOT NULL DEFAULT
CURRENT_TIMESTAMP,
KEY `EXPIRE_DATE_IX` (`EXPIRE_DATE`),
KEY `HASH_ID_IX` (`HASH_ID`)
) ENGINE=TokuDB DEFAULT CHARSET=latin1
ROW_FORMAT=TOKUDB_UNCOMPRESSED
/*!50100 PARTITION BY RANGE (UNIX_TIMESTAMP(EXPIRE_DATE))
(PARTITION p2005 VALUES LESS THAN (1487847600) ENGINE = …
In this blog post, we’ll look at a workaround for MySQL bug 72804.
Recently I worked on a ticket where a customer performed a point-in-time recovery PITR using a large set of binary logs. Normally we handle this by applying the last backup, then re-applying all binary logs created since the last backup. In the middle of the procedure, their new server crashed. We identified the binary log position and tried to restart the PITR from there. However, using the option
--start-position
, the restore failed with the error “The BINLOG statement of type
Table_map
was not preceded by a format description
BINLOG statement.” This is a known bug and is reported as MySQL
…
This blog we describe an issue with MySQL 5.7’s super_read_only feature when used alongside with GTID in chained slave instances.
Background
In MySQL 5.7.5 and onward introduced the
gtid_executed
table in the MySQL database to store
every GTID. This allows slave instances to use the GTID feature
regardless whether the binlog option is set or not. Here is an
example of the rows in the gtid_executed
table:
mysql> SELECT * FROM mysql.gtid_executed; +--------------------------------------+----------------+--------------+ | source_uuid | interval_start | interval_end | …[Read more]