While doing benchmarks on 5.7 and 8.0, I came across a performance regression in MySQL 8.0 over 5.7 and opened a bug (Bug #111353 : 3x Performance Regression from 5.7 to 8.0 on ALTER TABLE FORCE).  There has been recent activity on this bug, showing an easy workaround.  This, even if it is known since 16 July 2024, has not been talked about much, so this deserves a blog post.

MySQL warnings are an anti-pattern when it comes to maintaining data integrity. When the information retrieved from a database does not match what was entered, and this is not identified immediately, this can be permanently lost.

MySQL by default for several decades until the most recent versions enabled you to insert incorrect data, or insert data that was then truncated, or other patterns that resulted in failed data integrity. Very few applications considered handling warnings as errors, and there is a generation of software products that have never informed the developers that warnings were occurring.

The most simplest example is:

CREATE SCHEMA IF NOT EXISTS warnings;
USE warnings;

CREATE TABLE short_name(
  id INT UNSIGNED NOT NULL AUTO_INCREMENT,
  name VARCHAR(20) NOT NULL,
  PRIMARY KEY(id)
);

INSERT INTO short_name (name) VALUES ('This name is too long and will get truncated');
ERROR 1406 (22001): Data too long for …

In MySQL 8.0.12, we introduced a new algorithm for DDLs that won’t block the table when changing its definition. The first instant operation was adding a column at the end of a table, this was a contribution from Tencent Games.

Then in MySQL 8.0.29 we added the possibility to add (or remove) a column anywhere in the table.

For more information, please check these articles from Mayank Prasad : [1], [2]

In this article, I want to focus on some dangers …

Galera Manager supports three modes for supporting your Percona XtraDB Clusters: deploying to either Amazon Web Services, deploying to your own on premises hosts, and also just monitoring your clusters. In this blog post, we will go thru houw you should deploying a 3-node Percona XtraDB Cluster via Galera Manager on Amazon Web Services Elastic Compute Cloud (AWS EC2). You will realise that this process happens with just a simple API key and instance selection, so effectively you can have a Galera Manager setup in under fifteen minutes!

On AWS EC2, it is worth noting that Galera Manager itself can be deployed on the free tier for testing purposes. However, in production environments, you might expect up to 100GB of logs on a monthly basis, so you should plan accordingly.

Obtain Galera Manager by …

The momentum around Galera Manager development has been amazing. You report bugs or feature requests, and we fix them!

The major reason to release this was to ensure that Galera Manager would accept the new signing keys of Galera Cluster (key ID: 8DA84635).

One will now also note that gm-installer reports a new version: gm-installer version 1.12.0 (linux/amd64). And when you install it, Galera Manager itself is now at version 1.8.3. One of the major fixes is that Ubuntu 22.04 support for self-provided hosts is now exposed in the UI. This fixes …

Sie haben sicher schon davon gehört, dass MySQL 5.7 im Oktober 2023 das End of Life (EOL) erreicht hat. In diesem Webinar zeigen wir Ihnen, dass die Migration von MySQL 5.7 Galera Cluster nicht schwierig ist. MySQL 8.0 ist seit 5 Jahren allgemein verfügbar, und das Galera Cluster für MySQL 8.0 hat sich seit über 3 Jahren im Markt bewährt. Es ist also wirklich an der Zeit, sich auf die Migration vorzubereiten.

Im ersten Webinar dieser Reihe werden wir uns mit den neuen Funktionen von Galera Cluster mit MySQL 8 befassen:

* Die neuen Funktionen von Galera Cluster für MySQL 8, von denen Sie profitieren können, einschliesslich der in der Galera Cluster Enterprise Edition (EE) verfügbaren Funktionen
* Wie man eine Migration von MySQL 5.7 auf MySQL 8.0 plant
* Dinge, die vor der Migration getestet werden sollten
* Häufige Fallstricke bei einer solchen Migration
* Wie Sie sicherstellen, dass Ihr Galera …

If you are deploying MySQL on containers, one of the first tasks is to find the right image.

There’s a certain amount of confusion, especially when we’re trying to help someone who’s having problems with their deployment.

For example, when people say I’m using the official docker image… what does that really mean?

Docker Hub, provides their official image (https://hub.docker.com/_/mysql), but this is not the official MySQL image that we, the MySQL Team at Oracle, support.

Before the mess with Docker Hub ([1], [2], [3]), the real official images for MySQL …

In our lab environment, we received some emails from our provider, DigitalOcean saying a few nodes would be going down, because of issues with the physical nodes. Since we run a 9-node Galera Cluster in the lab, across 3 regions (San Francisco, London and Singapore), this posed an interesting problem!

Upon connecting to one of the nodes, we see:

mysql> show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 7     |
+--------------------+-------+
1 row in set (0.02 sec)

So we know that 2 of the nodes are down. Presuming you do not have any monitoring setup (might we recommend …

On the Internet, you can get a lot of advice from almost anywhere when you’re looking for information on how to do your DBA job.

My blog is one of these sources of advice, and depending on the source, we generally trust the advice more or less.

But sometimes advice doesn’t take the whole picture into account, and even if it comes from a recognized authority, it can lead to more or less serious problems.

Let’s consider the following situation:

We have an InnoDB ReplicaSet with 1 replication source (primary) and 2 replicas:

 JS > rs.status()
{
    "replicaSet": {
        "name": "myReplicaSet", 
        "primary": "127.0.0.1:3310", 
        "status": "AVAILABLE", 
        "statusText": "All instances available.", 
        "topology": {
            "127.0.0.1:3310": {
                "address": "127.0.0.1:3310", 
                "instanceRole": "PRIMARY", 
                "mode": "R/W", …

To continue our journey to Moodle on Oracle Cloud Infrastructure using Ampere compute instances and MySQL HeatWave Database Service [1] [2], in this article we will see how to scale our architecture using multiple Moodle instances, High Availability for the Database and Read Scale-Out.

This is the architecture we will deploy:

The same principles can be applied to other projects, not just Moodle.

Multiple Compute Instances & MySQL HeatWave High Availability

The first step is to use again the Stack to deploy the initial resources. We must insure that we use a MySQL Shape that has at least 4 OCPUs to …