As the second part of the earlier post Give Love to Your SSDs – Reduce innodb_io_capacity_max! we wanted to put together some concepts on how InnoDB flushing works in recent Percona Server for MySQL versions (8.0.x prior to 8.0.19, or 5.7.x). It is important to understand this aspect of InnoDB in order to tune it correctly. This post is a bit long and complex as it goes very deep into some InnoDB internals.

InnoDB internally handles flush operations in the background to remove dirty pages from the buffer pool. A dirty page is a page that is modified in memory but not yet flushed to disk. This is done to lower the write load and the latency of the transactions. Let’s explore the various sources of flushing inside InnoDB.

Idle Flushing

We already discussed the idle flushing in the previous post …

In this blog post, we will continue to explore Vitess and test an example database provided in its repository. This is Part III of the previously discussed installation of Vitess on minikube environment, so please make sure to follow those steps to bring the cluster up to the following level.  

$ kubectl get pods,jobs
NAME                                                                READY     STATUS    RESTARTS   AGE
po/etcd-global-kbbcqlgvp9                                           1/1       Running   0          43m
po/etcd-zone1-lpc5zmdxxn                                            1/1       Running   0          43m
po/my-release-etcd-operator-etcd-backup-operator-6684dd6d8c-pr4n4   1/1       Running   0          1h
po/my-release-etcd-operator-etcd-operator-86d94989d6-w9lpx          1/1       Running …

In this blog post, I’d like to share some experiences in setting up a Vitess environment for local tests and development on OSX/macOS. As previously, I have presented How To Test and Deploy Kubernetes Operator for MySQL(PXC) in OSX/macOS, this time I will be showing how to Run Vitess on Kubernetes.

Since running Kubernetes on a laptop is only experimental, I had faced several issues going through straight forward installation steps so I had to apply a few workarounds to the environment. This setup will have only minimum customization involved.

For a high-level overview of Vitess, please visit Part I of this series, …

The promise of DBaaS like RDS is to reduce operational overhead (among other things) and one of the stellar cases is upgrades (major and minor). The suggested procedure involves just a couple of steps. For example, using AWS Console, you can enable “Auto minor upgrade” or modify the DB instance and schedule the upgrade to run in the next maintenance window.

But, both these options are risky because the upgrade process will start during the maintenance window but it is NOT guaranteed that the upgrade will be completed within the specified duration. 

The Problem

RDS performs a few extra steps to ensure the data consistency and rollback, making the minor version upgrade a time-consuming process:

• It takes a backup (if automated backups are enabled) prior to starting the upgrade process.
• Performs slow shutdown after setting …

In this blog post series, we will discuss an overview of Vitess technology. Vitess is a database clustering solution for horizontal scaling of data sets currently suitable to 250Gb – 300Gb in sizes*. It’s a proven technology used by several web-scale companies including YouTube. PlanetScale is the company behind developing and supporting this open-sourced project. 

Introduction to Vitess 

Here’s high-level Vitess architecture visually explained. 

Ref: Sugu Sougoumarane presents an overview of Vitess at Highload in Moscow.

Basic Vitess Components

There are two main components of Vitess. One of them is vtgate which works as a query router where vttablet is a proxy to MySQL to serve the data. 

• …

While we’ve had MySQL Group Replication support in ProxySQL since version 1.3 (native as of v1.4), development has continued in subsequent versions. I’d like to describe a scenario of how latency can affect ProxySQL in a MySQL Group Replication environment, and outline a few new features that might help mitigate those issues. Before we dive into the specifics of the discussion, however, let’s take a quick overview of ProxySQL and Group Replication for those who may not be familiar.

MySQL Group Replication

Similar in functionality to Percona XtraDB Cluster or Galera, MySQL Group Replication is the only synchronous native HA solution for MySQL*. With built-in automatic distributed recovery, conflict detection, and group membership, MySQL GR provides a completely native HA solution for MySQL environments.

In a high concurrency world, where more and more users->connections->threads are used, contention is a given. But how do we identify the contention point easily?

Different approaches had been discussed previously, like the one using Perf and Flame graphs to track down the function taking way more time than expected. That method is great but how can we do it with what one normally has, like the MySQL Client? Enter: the SEMAPHORES section from the SHOW ENGINE INNODB STATUS command output.

SEMAPHORES

The SEMAPHORES section displays all the metrics related to InnoDB mechanics on waits. This section is your best friend if you have a high concurrency workload. In short, it contains 2 kinds of data: …

As the world’s most popular open-source database, MySQL has been around the block more than a few times. Traditionally installed in on-premise data centers, recent years have shown a major trend for MySQL in the cloud, and near the top of this list is Amazon RDS.

Amazon RDS allows you to deploy scalable MySQL servers within minutes in a cost-efficient manner with easily resizable hardware capacity. This frees you up to focus on application development and leaves many of the traditional database administration tasks such as backups, patching, and monitoring in the hands of AWS.

In this post I’d like to go over six important benefits of Amazon RDS, and why a move into RDS may be the right move for you.

Easy Deployment

Amazon RDS allows you to use either the AWS Management Console or a set of APIs to create, delete, and modify your database instances. You have full control of access and security …

The innodb_io_capacity and innodb_io_capacity_max are often misunderstood InnoDB parameters. As consultants, we see, at least every month, people setting this variable based on the top IO write specifications of their storage. Is this a correct choice? Is it an optimal value for performance? What about the SSD/Flash wear leveling?

Innodb_io_capacity 101

Let’s begin with what the manual has to say about innodb_io_capacity:

“The innodb_io_capacity variable defines the number of I/O operations per second (IOPS) available to InnoDB background tasks, such as flushing pages from the buffer pool and merging data from the change buffer.“

What does this mean exactly? …

If you do a quick web search about UUIDs and MySQL, you’ll get a fair number of results. Here are just a few examples:

• Storing UUID and Generated Columns
• Storing UUID Values in MySQL
• Illustrating Primary Key models in InnoDB and their impact on disk usage
• MySQL UUID Smackdown: UUID vs. INT for Primary Key
• GUID/UUID Performance Breakthrough
• …