When maintainng any piece of software, we usually deal with two kind of actions:

• bug fixing,
• new features.

bugs and features

A bug happens when there is an error in the software, which does not behave according to the documentation or the specifications. In short, it's a breech of contract between the software maintainer and the users. The promise, i.e. the software API that was published at every major version, is broken, and the software must be reconciled with the expectations and fixed, so that it behaves again as the documentation says. When we fix a bug in this way, we increment the revision number of the software version (e.g. 1.0.0 to 1.0.1. See semantic …

I have some free time today, but I am still lazy enough to work on numerous planned and pending "ToDo" kind of posts, so why not to continue review of older MySQL bugs I am subscribed to. Today I am going to list 15 more bugs reported more than a year ago and still not fixed:

• Bug #85805 - "Incorrect ER_BAD_NULL_ERROR after LOAD DATA LOCAL INFILE". This detailed bug report by Tsubasa Tanaka stays "Verified" for more than a year already. It's a great example of gdb use for MySQL troubleshooting. Setting a couple of breakpoints may really help to understand how MySQL works and why some …

MySQL 8.0.11 seems to be around the corner and the new MySQL Shell will take advantage of all the new improvements made in MySQL 8.0 like SET PERSIST, RESTART, … see this previous post.

In the video below, I show you how easy it’s to deploy a MySQL InnoDB Cluster using the Shell that connects remotely to all the instances:

I …

I think it's time to review some bugs I've subscribed to several months ago, those older than in the first post from this series. There are several really serious bugs in the list of 15 below:

• Bug #87560 - "XA PREPARE log order error in replication and binlog recovery". This bug was reported by Wei Zhao, who also provided patches.
• Bug #87526 - "The output of 'XA recover convert xid' is not useful". This bug reported by Sveta Smirnova is well known and is a real pain for DBAs who have to deal with incomplete XA transactions after some crash or unexpected restart. Check  …

If you are interested in MySQL Performance and you are looking for an optimal storage, you should have a look at this presentation by Frank Ober where you will be able to see how MySQL behaves on Intel Optane SSDs:

This session was recorded during the Silicon Valley MySQL Group meetup of last March 28th.

You will also find an overview of the tools you can use to test your environment.

Thank you to Intel for testing MySQL 8.0 and having collaborated with Dimitri.

Dimitri will also …

At the end we all agree that what really matters is the Query Response Time, isn’t it ?

MySQL 8.0 engineers have added more visibility in the summary tables as explained in this previous post. But to add more details, now the Performance_Schema also collects the statements latency and provide their distribution thanks to the collected histogram data.

Two tables have been added to Performance_Schema:

• events_statements_histogram_by_digest: details about latency related to schema and query digest
• events_statements_histogram_global: global latency summary across all schemas and queries

Let’s have a look at what we can see:

Recently on MySQL Forums, somebody was looking for documentation or procedure to upgrade a MySQL InnoDB Cluster (or Group Replication cluster) to a newer version.

In this post I am illustrating the best practices to achieve this task safely.

To illustrate the procedure, I will use an InnoDB Cluster of 3 members: mysql1, mysql2 and mysql3. The cluster is setup in Single-Primary mode (mysql1) and runs MySQL 5.7.21.

Let’s have a look at the cluster status:

 MySQL / mysql1:3306 / JS / cluster.status()
{
    "clusterName": "MyCluster", 
    "defaultReplicaSet": {
        "name": "default", 
        "primary": "mysql1:3306", 
        "ssl": "DISABLED", 
        "status": "OK", 
        "statusText": "Cluster is ONLINE and can tolerate up to …

MySQL 8.0 GA is right around the corner. I don't have precise information about its release, as I don't work at Oracle. If I did, I would probably know, but I couldn't tell when the release is scheduled to appear because of company policies. I can, however, speculate and infer, based of my experience with previous releases. My personal assessment is that the release will appear before 9:00am PT on April 24, 2018. The "before" can be anything from a few minutes to one week in advance.
Then, again, it may not happen at all if someone finds an atrocious bug that needs to be fixed asap.

Either way, users are keen on testing the new release in its current state of release candidate. Here I show a few methods that allow you to have a taste of the new …

I've subscribed to more than 15 new MySQL bug reports since the previous post in this series, so it's time for a new one. I am trying to follow important, funny or hard to process bug reports every day. Here is the list of the most interesting recent ones starting from the latest (with several still not processed properly):

• Bug #90211 - "Various warnings and errors when compiling MySQL 8 with Clang".  Roel Van de Paar and Percona in general continue their QA efforts in a hope to make MySQL 8 better. Current opinion of Oracle …

Among other things Geir Hoydalsvik stated in his nice post yesterday:
 "We’ve fixed a number of bugs detected by UBsan and Asan." This is indeed true, I already noted many related bugs fixed in recent MySQL 8.0.4. But I think that a couple of details are missing in the blog post. First of all, there still a notable number of bugs detected by ASan or noted in builds with ASan that remain "Verified". Second, who actually found and reported these bugs?

I decided to do a quick search and present my summary to clarify these details. Let me start with the list of "Verified" or "Open" bugs in public MySQL bugs database, starting from the oldest one:

• Bug #69715 - "UBSAN: Item_func_mul::int_op() mishandles …