Recently I wrote an article on how to define a backup policy for MySQL Database Service in OCI using Terraform. We saw that it was possible to define tags (defined_tags and freeform_tags) in the backup_policy section of a oci_mysql_mysql_db_system resource.

However, it seems that these tags are never used for manual or automated backups in the MySQL Database Service backup process. In the strategy implemented on OCI, the backups inherit the tags from the MySQL DB system itself.

This means that if you want to have some custom tags on your backups, you need to specify them in the MySQL Database resource like this (on line 12):

resource "oci_mysql_mysql_db_system" "MDSinstance" {
    admin_password = var.admin_password
    admin_username = …

Let’s continue the discovery of the MySQL Database Resource when deploying on Oracle Cloud Infrastructure using Terraform.

Last week, we saw how to create custom configurations and define user variables. Today we will see how we can define a backup policy and a maintenance window.

Backup Policy

In the oci_mysql_mysql_db_system resource, we will add a new section called backup_policy like this:

backup_policy {
       is_enabled        = "true"
       retention_in_days = "3"
       window_start_time = "01:00-00:00"
       freeform_tags = {"backup_defined_by"="Terraform"}
       pitr_policy {
            is_enabled = "true"
       }
}

This part of code (you can see in a working Terraform architecture sample), enables backup, sets the retention days to 3. It also defines the starting time …

With Terraform OCI provider 4.90.0 (released August 24th, 2022), we have added the possibility to specify the value of editable configuration variables directly from Terraform.

These variables must be defined in a resource of type oci_mysql_mysql_configuration like this:

resource "oci_mysql_mysql_configuration" "mds_mysql_configuration" {
        #Required
        compartment_id = var.compartment_ocid
    shape_name   = var.mysql_shape

         …

This is one of the exciting troubleshooting related to XA transactions let’s dive in. Let me provide a few backgrounds.

For one of our clients, when we try to drop a table, it is waiting for metadata lock. On debugging it is one of the XA transactions is holding the shared write lock and causing metadata lock on all the other local transactions.

Let us view the metadata locks from the Performance Schema.

More and more people are using UUID’s to identify records in their database.

As you already know, for MySQL’s storage engine (InnoDB) the primary key is very important ! (for performance, memory and disk space).

See the following links:

• https://lefred.be/content/mysql-invisible-column-part-ii/
• https://dev.mysql.com/doc/refman/8.0/en/create-table-gipks.html (GIPK mode in MySQL 8.0.30 !)

Problems

There are 2 major problems having a UUID as Primary Key in InnoDB:

1. generally they are random and cause clustered index to be rebalanced
2. they are included in each secondary indexes (consuming disk and memory)

Let’s have a look at …

Recently, somebody asked me how he can find the long running transactions in MySQL.

I already have one MySQL Shell plugin that allows you to find the current transactions sorted by time. The plugin allows you to also get the details about the desired transaction. See check.getRunningStatements().

Let’s see how we can easily find those long transaction that can be a nightmare for the DBAs (see MySQL History List Length post).

SELECT thr.processlist_id AS mysql_thread_id,
       concat(PROCESSLIST_USER,'@',PROCESSLIST_HOST) User,
       Command,
       FORMAT_PICO_TIME(trx.timer_wait) AS trx_duration,
       current_statement as `latest_statement`
  FROM …

Since 8.0.30, you have the possibility to modify the InnoDB Redo Log Capacity online. An undersized Redo Log Capacity is problematic and lead to performance issues.

However, it’s not recommended to oversize the Redo Log either. Redo Log files consume disk space and increases the recovery time in case of a restart (innodb_fast_shutdown=1) or a sudden crash. And it also slows down shutdown when innodb_fast_shutdown=0.

This means that now, you don’t need to restart MySQL if you want to increase or decrease the size of the InnoDB Redo Logs files. In fact, we don’t talk anymore about file size but about capacity ! The DBA doesn’t need to specify any file size and/or amount of files for Redo Logs anymore …

During my summer holidays, we released MySQL 8.0.30.

MySQL 8.0.30 was released on July 26th 2022. If you are using 8.0.29, it’s highly recommended to upgrade as there was a bug corrupting InnoDB files in a rare and specific case.

This new release contains several contributions from our awesome Community and on behalf of the entire MySQL Team, as usual, I would like to thanks all our contributors !

This new release contains patches from Facebook/Meta, Marcelo Altmann (Percona), Mengchu Shi, Zhou Xinjing (Tencent), Yuxiang Jiang (Tencent), Namrata Bhave, Hongyuan Li, Alexey Kopytov, Wei Zhao, Piotr Jurkiewicz, Dennis Gao, Zheng Lai, Bin Wang, Hao Wu (Tencent), Weijie Wu and Rahul Malik (Percona).

Once again, thank you all for your great contributions and to the companies you are working for.

…

Usually, I receive a lot of emails, and sometimes I read them on my phone and then… I forgot about them.. (shame on me).

On my Linux desktop, I used to use Get Things Gnome for a long time, due to the declining appeal of the project and the end of the extension for Thunderbird, I found it less and less useful.

I was then looking for a solution to have my todolist accessible from everywhere and that I could manage it myself, not hosted somewhere.

I found a very nice, fast and practical project that was easy to deploy and was using MySQL as backend: myTinyTodo.

However, I was missing the possibility to easily create a new task from an email (and especially on my phone).

This is why I decided to write a script that would perform exactly what I was looking for and integrated …

Full table scans can be problematic for performance. Certainly if the scanned tables are large. The worst case is when full table scans are involved in joins and particularly when the scanned table is not the first one (this was dramatic before MySQL 8.0 as Block Nested Loop was used) !

A full table scans means that MySQL was not able to use an index (no index or no filters using it).

Effects

When Full Table Scans happen (depending of the size of course), a lot of data gets pulled into the Buffer Pool and maybe other important data from the working set is pulled out. Most of the time that new data in the Buffer Pool might even not be required by the application, what a waste of resources !

You then understand that another side effect of Full Table Scans is the increase of I/O operations.

The most noticeable symptoms of Full Table Scans are:

• increase of CPU usage
• increase of …