Wednesday, September 9, 2015

How to clone a GTID MySQL 5.6 server using raw data files.

Steps to clone a MySQL 5.6 GTID server using the raw data files (i.e. without using mysqldump).

Overview

Need to clone a MySQL server with large amounts of data? So do we and like you we do not have the time to perform a mysqldump and restore. Fortunately, MySQL does permit copying the raw data files. In this article we will be doing a complete clone - a clone of everything - except for a few files that are specific to each MySQL instance.

You should read the MySQL article 17.1.1.6 Creating a Data Snapshot Using Raw Data Files as these steps are composed from the MySQL article plus some experience thrown in.

We are a Linux shop therefore this article will be using Linux features and commands. Other Linux/Unix flavors should be adaptable. Microsoft Windows Server is not a real server and won't be mentioned again.

This article also assumes you are familiar with MySQL 5.6 GTID replication.


Gotchas!

Incompatibilities

There is one specific gotcha that you should be aware of. This pertains to advance MySQL configurations which is mentioned in the above MySQL article:
"This method also does not work reliably if the master and slave have different values for ft_stopword_file, ft_min_word_len, or ft_max_word_len and you are copying tables having full-text indexes."

Service Shutdown / Cold Backup

The steps utilized in this article require performing a cold backup from the source server. That means you will need to shutdown the MySQL service on the source server. This is detailed below. This article does NOT consider performing warm or hot backups.

Backup your GTID (auto.cnf file)!

Before doing any of the steps outlined in this article I strongly recommend you backup your auto.cnf file located in your MySQL data directory. Backup this file to a directory outside of the MySQL data directory structure. This file contains the local servers unique GTID used for GTID replication. This file cannot be duplicated in replication or severe grief it may cause you. Yes, I do know there are instances where it can be duplicated but that is beyond the scope of this article.

Our Environment

We are using MySQL Server version 5.6.28 (from the MySQL apt repository) deployed on Ubuntu 12.04 and 14.04 servers. We use GTID replication and have four master servers configured in a circular (aka looped) replication. Two master servers are in our primary data center and two are in our DR (disaster-recovery) data center. There are several read-only slaves in each data center. It is akin to a Hub and Spoke: The four master servers are the hub and the slaves are the spokes.

All of our servers are configured identically. The only difference is the number of CPUs and the amount of RAM. All MySQL data files are stored using the same directory structure.

Thursday, May 29, 2014

MySQL 5.6 GTID replication 'Got fatal error 1236 from master when reading data from binary log'

MySQL 5.6 GTID replication 'Got fatal error 1236 from master when reading data from binary log' typically occurs when the MASTER purges it's binary logs and your SLAVE is using either replicate-do-db or replicate-ignore-db.

Thursday, May 22, 2014

Monitoring Multi-Master MySQL Deployments GTIDs using gtidmonitor

MySQL GTID is relatively new and the popular tools for monitoring MySQL servers are still playing catch-up. Here is a rudimentary web-based tool for monitoring MySQL GTIDs in multi-master multi-slave deployments: gtidmonitor