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 …

Today I would share a nice book related to MySQL 8.0 for our Chinese users.

The original title of this book by Scott Yao, is MySQL 8.0 运维与优化

I had the chance to read parts of the book before it was published to have my comment on the back cover.

This book is very detailed with many examples on how to administer a MySQL server.
It covers the new features of MySQL 8.0 and Scott illustrates perfectly how to take advantage of them.

Reading the book, it is obvious that the author is an experienced MySQL DBA and is sharing his experience that many junior DBAs can certainly benefit from.

This is a very technical book, as I like, I really recommend it to all Chinese people and I hope to see it translated into English too.

And finally I would thanks Scott for having sent to me a hard signed copy of the …

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

A few weeks back, we faced an issue in a replication environment for a Managed Services client:

LAST_ERROR_MESSAGE: Worker 2 failed executing transaction ‘UUID:GTID’ at master binlog.0012345, end_log_pos 98765; Error ‘Operation CREATE USER failed for ‘test_user’@’10.10.10.10” on query. Default database: ‘mysql’. Query: ‘CREATE USER ‘test_user’@’10.10.10.10’ IDENTIFIED WITH ‘mysql_native_password’ AS ‘************”

After some initial investigation, we noticed that the user in the replica didn’t exist! Was MySQL going crazy? But then the customer mentioned they had the following error in the primary before being able to execute the query successfully:

root@localhost [mysql]> CREATE USER 'test_user'@'10.10.10.10' identified WITH 'mysql_native_password' BY …

In the previous blog, we have gone through the Basic operation of the Skeema tool. In this blog, we will see the production use case of the Skeema tool.

1. Selective schema setup :
2. All (Global) servers :
3. Selective server execution:
4. …

If you watched Finding Poorly Designed Schemas and How to Fix Them you witnessed Marcos Albe use some very interesting queries. These queries let you find tables without primary keys, tables with non-integer primary keys, tables that do not use InnoDB, tables and indexes with the most latency, indexes that are 50% larger than the table, find duplicate indexes, and find unused indexes. As promised, they are below.

— Find tables without PK
SELECT t.table_schema,t.table_name,t.engine
FROM information_schema.tables t
JOIN information_schema.columns c
ON t.table_schema=c.table_schema
AND t.table_name=c.table_name
WHERE t.table_schema NOT IN (‘mysql’, ‘information_schema’, ‘sys’, ‘performance_schema’)
AND t.table_type = ‘BASE TABLE’
GROUP BY t.table_schema,t.table_name, t.engine
HAVING …

MySQL gave us the JSON data type back in mid-2015 with the release of MySQL 5.7.8. Since then, it has been used as a way to escape rigid column definitions and store JSON documents of all shapes and sizes: audit logs, configuration settings, 3rd party payloads, user-defined fields, and more. Although MySQL gives us functions for reading and writing JSON data, you’ll quickly discover something that is conspicuously missing: the ability to directly index your JSON columns. In other databases, the best way to directly index a JSON column is usually through a type of index known as a Generalized Inverted Index, or GIN for short. Since MySQL doesn’t offer GIN indexes, we’re unable to directly index an entire stored JSON document. All is not lost though, because MySQL does give us a way to indirectly index parts of our stored JSON documents. Depending on the version of MySQL that you're using, you have two options for indexing JSON. In MySQL 5.7 you …

Learn how to index JSON in MySQL with generated columns and functional indexes.

I recently had the chance to read in preview Bill Karwin‘s new book: SQL Antipatterns, Volume 1: Avoiding the Pitfalls of Database Programming.

This book is a rework of Bill’s best seller from 2010. The new book can be considered as the second edition and is updated with Bill’s latest observations about common mistakes.

The author took in consideration the feedback about the first edition.

This new edition is full of information for beginners but also for experts who will appreciate to see how antipatterns are solved and most of the time surely propose different approaches.

Each antipatterns are identified by their names like “jaywalking“, …

Overview Ever find yourself building a database only to start questioning what data types you should use for a specific column? In this entry of the MySQL data types series, we’ll explore the various ways you can save strings and text to a database to help demystify the options you have as a developer, starting with VARCHAR and CHAR. VARCHAR vs CHAR VARCHAR is probably the most widely used data type for strings. It stores a string of variable length up to a maximum of 65,535 characters. When creating a VARCHAR field, you’ll be able to specify the maxmimum number of characters the field will accept using the VARCHAR(n) format, where n is the maximum number of characters to be stored. Due to the fact that is is variable length, it will only allocate enough disk space to store the contents of the string, not the full length of the contents passed in. VARCHAR also allocates a little bit of extra space with each value stored. Depending on the space …