This week is KubeCon in Detroit, and in preparation for attending I have been polishing up my Kubernetes skills. This big rush to put software in containers and have Kubernetes run everything is getting a lot of push in the industry. Many software applications run perfectly well in ready-made packages from a container made for ephemeral consumption much like a can of Campell’s tomato soup. But generally, relational databases like permanence, stability, and a consistent presence. Databases like to run to stock caches and build statistics, so they are not great at running well after being started. But this article is the first in a series for ‘us’ database folks to learn how to keep our databases happy in a containerized world.

With the trip to the Motor City on my calendar, it was time to answer the question “What is the minimalist …

No, I don’t think so. But it is does change our profession and have important implications for software engineers using (not managing) MySQL.

No, I don’t think so. But it is does change our profession and have important implications for software engineers using (not managing) MySQL.

No, I don’t think so. But it is does change our profession and have important implications for software engineers using (not managing) MySQL.

In the previous part, we created our application and our 2 functions.

Now we need to create an API Gateway to be able to call these functions from outside OCI. Using a third party scheduler, our laptop, etc…

Before creating the gateway, we need to create some policy to allow the API Gateway to call our functions. I’ve tried to create the policy after, it seems to not work as expected.

Security

Dynamic Group

We need to create a Dynamic Group that will match our gateway:

The matching rule is checking the type of resource that should be ApiGateway and my compartment’s id:

All {resource.type='ApiGateway', resource.compartment.id = 'ocid1.compartment.oc1..xxxxxxxxx'}

Policy …

In my previous post, I explained how to deal with Performance_Schema and Sys to identify the candidates for Query Optimization but also to understand the workload on the database.

In this article, we will see how we can create an OCI Fn Application that will generate a slow query log from our MySQL Database Service instance and store it to Object Storage.

The creation of the function and its use is similar to the one explained in the …

If like me you are an old experienced MySQL DBA, to analyze your MySQL workload, you certainly have used the slow query log with long_query_time set to 0.

The slow query log is a file that contains all the queries whose execution time is greater than the value of long_query_time. This file can be huge and uses up all available disk space on busy systems.

Constantly writing to that file can also add an overhead to the server.

For those reasons, the slow query log is not available in MySQL Database Service (HeatWave) in OCI.

Plan B ?

As a DBA, what are my options for finding the queries that need to be optimized? As usual, the queries that consume the most time are the ones that need some attention

It can be a very long query or a short query executed too many times.

Currently the MySQL DBAs use …

As we have Kubernetes installed in part one (see Using Percona Kubernetes Operators With K3s Part 1: Installation), now we will install Percona Server for MySQL Operator into the running cluster.

I will copy some ideas from Peter’s Minukube tutorial (see Exploring MySQL on Kubernetes with Minkube).

In this case, I will use not Percona XtraDB Cluster Operator but a regular Percona Server for MySQL with Asynchronous replication.

We have recently released version 0.3.0 and it is still in the technical preview state, so we are actively looking for more feedback!

If we go with all …

Let’s continue our journey of deploying the MySQL Database System on OCI with Terraform.
This time we will see how we can use a backup (see [1] and [2]) as a source (initial data) for a new instance.

Within the oci_mysql_mysql_db_system it’s possible to define a source detailing how to provision the initial data of the db system.

Let’s deploy a new MySQL Database Instance using a manual backup we made earlier:

We can also find the backup’s ocid using the oci cli command:

 $ oci mysql backup list …

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 = …