I wanted to be brave and I installed MySQL Group Replication manually…. it was painful !

Then I realized that managing those servers and especially deal with MySQL Routers was even more painful !

What are my options now ? Is there a solution or do I need to restart from scratch ?

Asking the answer is already answering it… and once again MySQL Shell at the rescue.

MySQL Group Replication

I’ve configured everything manually. I also loaded group_replication and clone plugins and finally after having bootstrapped my Group here is what I have:

mysql> select member_host, member_port port, member_state state, 
       member_role role, member_version version 
       from performance_schema.replication_group_members;
+-------------+------+--------+-----------+---------+
| member_host | port | state  | role      | version | …

This morning, a user asked in the MySQL Community Slack if somebody had an idea why the error log was filled up continuously with a warning messages like this one:

2020-07-24T06:54:00.877128Z 46 [Warning] [MY-013360] [Server] 
Plugin sha256_password reported: ''sha256_password' is deprecated and will be removed in 
a future release. Please use caching_sha2_password instead'

The context was that the user upgraded from MySQL 5.7 to MySQL 8.0 and changed the authentication plugin of all users to caching_sha2_password.

As the warning message was written to the error log almost twice per second, I suspected a monitoring tool. The user said, that no application, no monitoring was using this server yet.

Of course we verified that all users had the plugin changed.

This is important when helping people (friends, colleagues, …

In MySQL, it’s very common and recommended to you an auto_increment as Primary Key.

However that integer can have different types each having their size limitation, and they can also be signed or not.

Many people when creating a table use by default the following syntax do define their auto_increment primary key:

id int auto_increment primary key

This is a signed integer where the maximum value is 2,147,483,647.

It’s recommended as a DBA to keep an eye on how fast your tables are filling up and how much records can still be added to your tables.

And this can happen even to the bests ! (see this Github Availability Report on May 5th at 00:45)

MySQL Shell Plugin

Once again, MySQL Shell comes to the rescue with an easy plugin: …

In MySQL 8.0.21, we can see who and how mysqld was stopped and when the process ended.

Let’s have a look at different scenarios in this article.

SHUTDOWN SQL statement

The first test is to initiate the shutdown of MySQL from a SQL client:

mysql> shutdown;

In the error log (log_error_verbosity is set to 2, the default), we can see:

2020-07-14T07:17:28.865274Z 10 [System] [MY-013172] [Server] 
          Received SHUTDOWN from user root. Shutting down mysqld (Version: 8.0.21).
2020-07-14T07:17:31.258884Z 0 [System] [MY-010910] [Server] 
         /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.21) MySQL Community Server - GPL.

We can easily identify when the server started the shutdown process and when it finished.

Stopping using systemd

MySQL 8.0.21 has been released today, wooohooo \o/

As usual, this release contains contributions and let me thanks all the contributors on behalf of the MySQL Team.

MySQL 8.0.21 includes contributions from Edgars Irmejs, Daniël van Eeden, Jeremy Cole, Wenfeng Shih, Billy O’Neal, Lou Shuai, Tsubasa Tanaka and Facebook.

Thank you all for your great contributions. MySQL is an Open Source project, GPL, and we accept contributions !

Here is the list of the contributions above:

• Filesort …

As proven again very recently by my colleague and friend Dimitri K, with the TPCC “Mystery”, sysbench made by a former colleague and friend Alexey K, is really the recommended framework to benchmark your system.

I use sysbench of course to benchmark MySQL but also my OS and hardware capabilities.

For those willing to benchmark MySQL 8.0 with sysbench using all supported authentication methods including of course the much more secure default one, caching_sha2_password, you need to compile sysbench using the MySQL libs.

And …

MySQL Backup and Disaster Recovery Webinar (Thursday, June 18, 2020 – 06:00 PM to 07:00 PM PDT)

There can be several reasons for a MySQL database outage: hardware failure, power outage, human error, natural disaster etc. We may not be able prevent all the disaster from happening but investing on a robust disaster recovery plan is very important for building fault-tolerant database infrastructure operations on MySQL.  Every MySQL DBA is accountable for developing a disaster recovery plan addressing data sensitivity, data loss tolerance and data security. Join Shiv Iyer, Founder and Principal of MinervaDB to lean about the best practices for building highly reliable MySQL DR strategy and operations on Thursday, June 18, 2020 – 06:00 PM to 07:00 PM PDT. Building DR for a high traffic MySQL database infrastructure means deep understanding of multiple backup strategies and choosing optimal ones which are best suited for performance …

With this post we are reaching the end of our journey to HA for WordPress & MySQL 8.0 on OCI.

If you have not read the two previous articles, this is just the right time.

• MySQL 8.0 InnoDB ReplicaSet with WordPress in OCI
• MySQL 8.0 InnoDB ReplicaSet with WordPress in OCI – part II

We started this trip using the MySQL InnoDB ReplicaSet where only 2 servers are sufficient but doesn’t provide automatic fail-over.

In this article we will upgrade our InnoDB ReplicaSet to …

Today’s article is again related to WordPress and MySQL 8.0. We will see how we can setup MySQL InnoDB ReplicaSet and configure WordPress to split the load using both MySQL Instances: we will split reads and writes between the Primary and the Secondary member of our ReplicaSet.

This will be the first part of our journey to achieve HA for our WordPress site on OCI and using all MySQL Servers we have deployed. We don’t want to have a server idle just waiting to take over in case of an incident.

MySQL InnoDB ReplicaSet

First some words about MySQL InnoDB ReplicaSet.

The ease of use of …

On a busy server, the binary logs can end up being one of the largest contributors to amount of disk space used. That means higher I/O, larger backups (you are backing up your binary logs, right?), potentially more network traffic when replicas fetch the logs, and so on. In general, binary logs compress well, so it has been a long time wish for a feature that allowed you to compress the logs while MySQL are still using them. Starting from MySQL 8.0.20 that is now possible. I will take a look at the new feature in this post.

Configuration

The binary log compression feature is controlled by two variables, one for enabling the feature and another to specify the compression level. These are summarized in the below table.