By now you must have read our documentation on isolation levels and also our Support for Transaction Isolation Levels. It is worth noting that the default transaction isolation level in MySQL 8 is REPEATABLE READ.

Here is a simple example of this, in action (you can test this on two different nodes, even across a 9-node Galera Cluster!).

First we do some simple setup:

CREATE DATABASE isolate;

USE isolate;

CREATE TABLE products (
id INT PRIMARY KEY,
name VARCHAR(50),
price DECIMAL(10, 2)
);

Then we insert some initial data:

INSERT INTO products (id, name, …

Just thought I’d share a script I use daily and helps me redirect my attention if needed.

This is but a mere pointer, guideline and starting point in any task. I just thought I’d share and hope someone else’s day becomes slightly easier thanks to some brief investigation and command tweaking.

Now the really handy thing here is that I only hard code the router01 node name, as I’m using that as a potential endpoint (thinking cloud, XaaS, etc…) where it could also be a VIP, LBR or similar. It’s the entry point so I can query the P_S table error_log so I can get different views and act accordingly.

For example:

• First, give me the InnoDB Cluster ordered server list so I can take a step back from my usual pains and worries, and see the architecture view. And make me type “Y” or similar to move on. Here if there were any server missing, I’d see the summary right away so I don’t really need to …

I have been scratching my head about MySQL startup for some time.  There is much to say about this, and many other posts will probably follow.  For now, it is enough to know that with many tables (millions) the startup of MySQL 8.0+ (including 8.0, 8.4 and 9.0) is suboptimal (to say the least).  With very little changes, I was able to speed it up, from 2:39 to 1:09 (1 minute and 9

The aim of this long article is to give you the instructions and tools to migrate your production database, from your current environment to a solution based on Percona Everest (MySQL).

Nice, you decided to test Percona Everest, and you found that it is the tool you were looking for to manage your private DBaaS. For sure the easiest part will be to run new environments to get better understanding and experience on how the solution works. However, the day when you will look to migrate your existing environments will come. What should you do?

Prepare a plan! In which the first step is to understand your current environment. 

 When I say understand the current environment, I mean that you need to have a clear understanding of:

• the current dimensions (CPU/Memory/Disk utilization)
• the way it is accessed by the …

 Check and review recommended MySQL InnoDB setting using MySQL Shell for optimal Performance. 

Performance of MySQL is always top priority for each organisations because data holds valuable insight into organizational productivity and proactive decision making. High-performing databases help organizations stay ahead by enabling faster insights, quicker adaptation to changes, and superior customer experiences. When performance of MySQL is slow it impacts user experience and data driven innovation. 
Performance has different meaning at different context however it’s important to keep MySQL instance healthy by balancing the hardware vis-à-vis InnoDB settings. 
I have been asked multiple times by MySQL customer about 

1. Does MySQL has right set of InnoDB configurations ? 
   
2. What are the InnoDB parameters to tune …

Mysterious warning Recently, I was involved in an investigation whose goal was to find out the reason for a warning message like this: [crayon-67411361d0174713773630/] The message looks clear, isn’t it? Well, the problem was that this particular table had not been changed for years, and so no DDL (ALTER) query was involved here. Moreover, there […]

This post will explain how to troubleshoot MySQL HeatWave by accessing information in the MySQL error log table and the HeatWave audit log.

MySQL Shell offer many features to make life easier for DBAs and developers. In this post we discuss how we can add custom functionality to MySQL Shell using startup scripts.

This blog post will explain how to tell whether a given MySQL server is an LTS release or not. The features described are implemented in MySQL 8.4.0 (the mysql_upgrade_history file) and 8.4.1 (the INFO_SRC extension). The features are available in on-premise as well as cloud releases.

I thought I’d share some quick intro steps into how we can monitor the MySQL Router.

This can be useful if we’re observing intermittent outages, network packet drops or you’re just not sure if everythings fine in your MySQL InnoDB Cluster.

My scenario: The drupal servers are connecting and sometimes the users are getting connection errors. I don’0t see anything at MySQL server level of any instance nor cluster problem. Let’s review the Routers.

On all MySQL Router servers, double check the config file for the log location and also the log level. At /etc/mysqlrouter/mysqlrouter.conf (default rpm install location):

[DEFAULT]
name=myrouter
user=mysqlrouter
..
..
logging_folder=/routerlog/log
..
[logger]
level=DEBUG
#level=INFO

I’ve changed my logger level to DEBUG which will give you a lot more info about connections and counters so you can see what’s happening …