Using Docker for development is a great way of ensuring that what you develop will be the same that you deploy in production. This is true for almost everything. If you develop on Linux, the above statement holds. If you develop on a different operating system (OSX or Windows) there are several restrictions.

I showed one of those issues in a recent article (MySQL and Docker on a Mac: networking oddity.) When you want to export a port from a service running in the container, the exported port is not available in your mac, but in the virtual machine that runs Docker services. This happens with any application that listens to a port.

The second limitation I found affects only MySQL, and it is related to using volumes. The proper way of achieving data persistence with …

In this blog post, we’ll discuss some of the basics regarding Docker MySQL replication. Docker has gained widespread popularity in recent years as a lightweight alternative to virtualization. It is ideal for building virtual development and testing environments. The solution is flexible and seamlessly integrates with popular CI tools.

This post walks through the setup of MySQL replication with Docker using Percona Server 5.6 images. To keep things simple we’ll configure a pair of instances and override only the most important variables for replication. You can add whatever other variables you want to override in the configuration files for each instance.

Note: the configuration described here is suitable for development or testing. We’ve also used the …

This blogpost extends last one. In the last blogpost, we had a look into Docker Network and how it makes the communication between the containers (over multiple hosts) easier. Of course we used Galera for that :)

In this blogpost we are going to use Docker Swarm to bootstrap a Galera Cluster.

Why using Docker Swarm?

Docker Swarm is (simplified) a proxy. So we've got one accesspoint to manage multiple hosts. (The swarm manage service will run on 172.17.152.11:2376). We also use Docker Swarm to abstract from the nodes. As we want the cluster to be running but we don't want to define explicitly where to run them. (Think about a 3-node-cluster on Docker Swarm with 100 nodes.)

Let us point the local docker to Docker Swarm:

export DOCKER_HOST=tcp://172.17.152.11:2376

We still got …

Galera und Docker Network

Using Docker to run Galera on multiple nodes is quite a mess as described here. It is possible but no fun at all. As Docker does NATing every bidirectional setup is complicated.

Starting with Docker Network (version 1.9) you can simply span a Docker owned network (multiple of them) over multiple nodes. These networks are separated as the known bridged network Docker uses by default. It also provides a simple node/container discovery using the --name switch. Feels like a simple DNS.

Let's have a look how easy it is to deploy a Galera cluster. It is not for production. I use my own Docker image. It is just to play around.

There are our nodes:

• Swarm1 IP=172.17.152.11
• Swarm2 IP=172.17.152.12
• Swarm3 IP=172.17.152.13

At the …

Overview

When I got interested in Docker, I started playing idly with the idea of integrating containers and MySQL Sandbox. My first experiments were not encouraging. Using a container the same way I would use a regular server produced horrible results. I started by creating a Debian or CentOS container, installing MySQL Sandbox, and then importing an expanded tarball into the container. What happens is that tarballs of recent MySQL versions expand to roughly 2 GB of binaries. When you try to put that into a container you get a bloated file system. If you want to expand more than one tarball, you get an enormous unusable blob that is contrary to what containers should be used for. There is, of course, the possibility of using volumes, which would avoid the problem of making the container …

Saturday I was in my favorite grocery store, standing in the line, browsing the net on my phone. I read Vadim Tkachenko‘s blog post about Measuring Percona Server Docker CPU/network overhead and his findings were opposite than mine – he didn’t found any measurable difference. Reading his post, he did found huge impact in networking […]

Saturday I was in my favourite grocery store, standing in the line, browsing the net on my phone. I read Vadim Tkachenko‘s blog post about Measuring Percona Server Docker CPU/network overhead and his findings were the opposite than mine – he didn’t found any measurable difference. Reading his post, he did found huge impact in networking which I didn’t […]

This will be another post on using Percona Server via a Docker image. I want to follow up on my previous post regarding CPU/Network overhead in Docker “Measuring Percona Server Docker CPU/network overhead” by measuring  if there is any docker IO overhead on operations.

After running several tests, it appears (spoiler alert) that there is no Docker IO overhead. I still think it is useful to understand the different ways Docker can be used with data volumes, however. Docker’s philosophy is to provide ephemeral containers, but ephemeral does not work well for data – we do not want our data to disappear.

So, the first pattern is to create data inside a docker container. This …

Now that we have our Percona Server Docker images, I wanted to measure the performance overhead when we run the database in the container. Since Docker promises to use a lightweight container, in theory there should be very light overhead. We need to verify that claim, however. In this post I will show the numbers for CPU and network intensive workloads, and later I will take a look at IO.

For the CPU-bound load, I will use a sysbench OLTP read-only workload with data fitting into memory (so there is no IO performed, and the execution path only goes through the network and CPU).

My server is 24 cores (including hyper-threads), with Intel(R) Xeon(R) CPU E5-2643 v2 @ …

Docker is incredibly popular tool for deploying software, so we decided to provide a Percona Docker image for both Percona Server MySQL and Percona Server for MongoDB.

We want to create an easy way to try our products.

There are actually some images available from https://hub.docker.com/_/percona/, but these images are provided by Docker itself, not from Percona.

In our images, we provide all the varieties of storage engines available in Percona Server (MySQL/MongoDB).

Our images are available from https://hub.docker.com/r/percona/.

The simplest way to get going is to run the following:

docker run --name ps -e MYSQL_ROOT_PASSWORD=secret -d …