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 …

Ahoi, I made three proposals for Percona Live. (Even I know being a lonely (sniff) freelancer with no backup).  At least I'm for sure an early adopter about the three topics I submitted and know for sure what I'm talking about *g*   

• Using Ansible to Deploy MySQL

Even being Puppet certified. Ansible is my love. Never been that fast in doing automation \o/

• Dockerize it/IT

This is a tutorial about Docker and Galera/MySQL. 

• Docker …

With the release of 10.1.8, MariaDB takes a next step. MariaDB 10.1 is now considered a stable release.

MariaDB 10.1 has a couple of main themes:

• Security
• High Availability
• Scalability

During the last few years there have been many request for more security features in MariaDB. Actually it’s a trend in general. Since open source software is getting more attractive all the time, more functionality is wanted in areas where proprietary software typically has been leading. This is especially true for databases. In addition data privacy is a very hot topic.

The big new thing in security for MariaDB 10.1 is a complete data at rest encryption solution. The encryption that now is in use originates from Google’s encryption patch. It has now been migrated into MariaDB 10.1. The …

State Snapshot Transfer (SST) at a glance

PXC uses a protocol called State Snapshot Transfer to provision a node joining an existing cluster with all the data it needs to synchronize.  This is analogous to cloning a slave in asynchronous replication:  you take a full backup of one node and copy it to the new one, while tracking the replication position of the backup.

PXC automates this process using scriptable SST methods.  The most common of these methods is the xtrabackup-v2 method which is the default in PXC 5.6.  Xtrabackup generally is more favored over other SST methods because it is non-blocking on the Donor node (the node contributing the backup).

The basic flow of this method is:

• The Joiner:
  • joins the cluster …

Sun of database technologies is shining through the cloud technology. Oracle, SQL Server, MySQL and various other databases are bringing forth some nifty offerings and this Log Buffer Edition covers some of them.

Oracle:

• How to create your own Oracle database merge patch.
• Finally the work of a database designer will be recognized! Oracle has announced the Oracle Database Developer Choice Awards.
• Oracle Documents Cloud Service R4: Why You Should Seriously Consider It for Your Enterprise.
• Mixing Servers in a Server …

In my previous post, I used incremental backups in Percona XtraBackup as a method for rebuilding a Percona XtraDB Cluster (PXC) node without triggering an actual SST. Practically this reproduces the SST steps, but it can be handy if you already had backups available to use.

In this post, I want to present another methodology for this that also uses a full backup, but instead of incrementals uses any binary logs that the cluster may be producing.

Binary logs on PXC

Binary logs are not strictly needed in PXC for replication, but …

Beware the SST

In Percona XtraDB Cluster (PXC) I often run across users who are fearful of SSTs on their clusters. I’ve always maintained that if you can’t cope with a SST, PXC may not be right for you, but that doesn’t change the fact that SSTs with multiple Terabytes of data can be quite costly.

SST, by current definition, is a full backup of a Donor to Joiner.  The most popular method is Percona XtraBackup, so we’re talking about a donor node that must:

1. Run a full XtraBackup that reads its entire datadir
2. Keep up with Galera replication to it as much as possible (though laggy donors don’t send flow control)
3. Possibly still be serving application traffic if you don’t remove Donors from rotation.
…

The MariaDB project is pleased to announce the immediate availability of MariaDB Galera Cluster 10.0.20 and MariaDB Galera Cluster 5.5.44. These are Stable (GA) releases.

Download MariaDB Galera Cluster 10.0.20

Release Notes Changelog What is MariaDB Galera Cluster?

Download …

Some applications have a heavy write workload on a few records – for instance when incrementing a global counter: this is called a write hotspot. Because you cannot update the same row simultaneously from multiple threads, this can lead to performance degradation. When using Percona XtraDB Cluster (PXC), some users try to solve this specific issue by writing on multiple nodes at the same time. Good idea or bad idea? Read on!

Simultaneous writes on a standalone InnoDB server

Say you have these 3 transactions being run simultaneously (id is the primary key of the table):

# T1
UPDATE t SET ... WHERE id = 100
# T2
UPDATE t SET ... WHERE id = 100
# T3
UPDATE t SET ... WHERE id = 101

All transactions will require a row lock on the record they want to modify. So T3 can commit at the same time than T1 and/or T2, because it will …

It seems these days if anyone knows anything about tuning InnoDB, it’s that you MUST tune your innodb_buffer_pool_size to 80% of your physical memory. This is such prolific tuning advice, it seems engrained in many a DBA’s mind.  The MySQL manual to this day refers to this rule, so who can blame the DBA?  The question is: does it makes sense?

What uses the memory on your server?

Before we question such advice, let’s consider what can take up RAM in a typical MySQL server in their broad categories.  This list isn’t necessarily complete, but I think it outlines the large areas a MySQL server could consume memory.

• OS Usage: Kernel, running processes, filesystem cache, etc.
• MySQL fixed usage: query cache, InnoDB …