I recently had the opportunity to test out Ansible’s ability to interact with docker containers. Some might ask why we would want Ansible to connect to running containers. Afterall, we can build the containers to our liking using ansible-container, or even mundane tools such as Docker’s Dockerfile. Also, we can link configuration files at runtime to override the container’s settings where appropriate.

The point, though, is to leverage Ansible’s capability as an orchestration tool.

As a very basic example, assume that you have plays for your non-docker environment to ensure MySQL users exist. How do you do that with Docker containers?

You have a few options:

1. Assume you have users with appropriate privileges that can connect remotely, you can execute the Ansible plays locally to connect to MySQL over the …

Introduction

This is the final installment of a five part blog series to explore InnoDB internals by looking at the related tunable system variables. In this section we’re going to cover variables that relate to enforcing data consistency, and how index statistics are handled and stored.

Just like previous sections, I would like to emphasize something that was written in part one of this blog post series.

“I should note that while tuning recommendations are provided, this objective of this blog post series was NOT meant to be a tuning primer, but instead to explore the mechanics that each variable interacts with. As such I would like to advise against reading this guide and trying to fine tune all of the available InnoDB variables. System variable tuning is an exercise in diminishing returns, the most benefit you’ll get out of tuning your MySQL server will occur within the first 15 minutes of configuration. In …

Introduction

This is part four of a five part blog series to explore InnoDB internals by looking at the related tunable system variables. In this section we’re going to explore the mechanics that impact CPU resourcing and how InnoDB handles concurrent threads. You’ll notice that a lot of the variables covered in section relate to features that are now disabled but were a lot more prevalent in previous versions of MySQL, particularly those that were released at a time where system context switching had a greater cost than it does today. These variables are still worth discussing as you may run into older systems that utilize these mechanics, and there are even modern systems I’ve worked with that have implemented these features to tune performance to its highest potential.

Just like previous sections, I would like to emphasize something that was written in part one of this blog post series.

“I should note that …

Introduction

This is part three of a five part blog series to explore InnoDB internals by looking at the related tunable system variables. In part 2 we covered variables that had the greatest impact on the file structure of InnoDB as well as how data is written to logs. In this section we will continue looking at I/O but more specifically looking at the mechanics on how data gets written to table files as well as how background threads read from them.

Just like in part two, I would like to emphasize something that was written in part one of this blog post series.

“I should note that while tuning recommendations are provided, this objective of this blog post series was NOT meant to be a tuning primer, but instead to explore the mechanics that each variable interacts with. As such I would …

Introduction

This is part two of a five part blog series to explore InnoDB internals by looking at the related tunable system variables. In part one we covered variables that had the greatest impact on memory, and in this instalment we will cover the variables that have the greatest impact on the file structure of InnoDB as well as how data is written to logs, which can have a large impact on transaction commit overhead. Originally I was considering putting all the I/O related InnoDB related variable in one post, however that’s a lot of ground to cover. Instead you can look forward to an upcoming instalment of this blog series that will cover I/O as it relates to table data.

Before we begin, I would like to emphasize something that was written in part one of this blog post series.

“I should note that while tuning recommendations are provided, this objective of this blog post series was NOT meant to be a tuning …

Introduction

A couple of months ago I decided to give myself a refresher on the mechanics of InnoDB. Having a high level understanding of what’s going on under the hood can help provide the context needed in order to resolve issues you may encounter as well as assist you in ensuring that your MySQL instance is running efficiently. Everyone can stand to go back to basics every now and then, as it can help you pick up concepts that you may have missed the last time you researched the topic.

This time around I decided to give myself a refresher by re-reading the MySQL 5.6 reference manual, chapter 14, which covers the InnoDB engine. Despite having a wealth of documented knowledge and insights, I found that a lot of the points in the documentations were unclear, leading me to do more research and experimentation in order to get a bit of clarity on some of the specifics that I felt were missing. In order to help make the information …

The behavior of vm.swappiness was always a bit confusing for novice linux users, as setting vm.swappiness to 0 would not completely disable swapping in the system during a memory crunch. vm.swappiness would only affect the agressiveness of swapping.

Following upstream commit tried to give more control to parameter. This commit tried to avoid swapping completely when vm.swappiness is set to 0.

commit fe35004fbf9eaf67482b074a2e032abb9c89b1dd
Author: Satoru Moriya
Date: Tue May 29 15:06:47 2012 -0700
mm: avoid swapping out with swappiness==0

With above commit, setting vm.swappiness to “0” instructs the kernel not to initiate swapping until the amount of free and file-backed pages is less than the high water mark in a memory zone. In other words, it tries to reclaim as much memory that can be reclaimed, before swapping starts.
This greatly reduced the chances of swapping.

When this …

Most people know that you can use SHOW SLAVE STATUS to verify if a slave is running in MySQL. Most people also know that you need to check both Slave_IO_Running and Slave_SQL_Running.

View the code on Gist.

A few years ago, I responded to a question on dba.stackexchange.com on how to verify if a slave is running outside of SHOW SLAVE STATUS.

Prior to MySQL 5.7, you could get this information from SHOW GLOBAL STATUS:

View the code on Gist.

Keep in mind that certain versions of 5.1 …

Overview

When working with Amazon AWS Aurora, there are some steps to consider when trying to get data out of an active Aurora master into a slave, potentially into a EC2 instance or offsite in another data centre. Creating an external mysql to Aurora gives the option to move out of Aurora, or to have the flexibility to move data around as desired. With AWS RDS instances this task is pretty simple because you can do the following :

1. Create a read replica
2. Stop the slave process
3. Capture the positioning
4. Dump the database

With Aurora it’s a little trickier, because a read replica in Aurora has no slave process. All of the replication is handled on the back end and cannot be controlled. However, setting up an external slave can be done.

Amazon AWS Documentation

In …

This Week’s log buffer edition covers some of the useful blog posts from Oracle, SQL Server and MySQL.

Oracle:

ASM disks – lsdg compared with the v$asm_diskgroup view

Can a query on the standby update the primary ?

What should I know about SQL?

Setting Environment Variables in Application Server/Process Scheduler Tuxedo Domains

Oracle …