The latest from the MySQL community

The Percona Backup Service managed service launched today. It ensures properly configured backups run successfully as scheduled on customer provided backup storage – whether on premise, in the cloud, or a hybrid. Backup issues or production data recovery are efficiently handled by Percona Managed Services technicians with deep knowledge of MySQL.

As we state in our white papers, “MySQL backup and recovery are a foundational piece of any infrastructure. A well-tested backup and recovery system can be the difference between a minor outage and the end of a business.” While MySQL backups are “foundational,” they …

So of course Percona has documentation that explain the process. The goal of this blog is to go into a little more detail in hopes that can help someone.

Hyperlinks for review:

• CentOS - http://www.percona.com/doc/percona-xtradb-cluster/5.5/howtos/cenots_howto.html
• Ubuntu - http://www.percona.com/doc/percona-xtradb-cluster/5.5/howtos/ubuntu_howto.html
• Installing Percona XtraDB Cluster from Binaries -   
  • http://www.percona.com/doc/percona-xtradb-cluster/5.5/installation.html
…

We recently open-sourced our percona-agent and if you check out the source code, you’ll find that it is written in the Go programming language (aka Golang). For those not up to speed, the percona-agent is a real-time client-side agent for Percona Cloud Tools.

Our requirements are quite demanding for our agents. This one is software that works on a real production server, so it must be fast, reliable, lightweight and easy to distribute. Surprisingly enough, binaries compiled by Go fit these characteristics.

There are of course alternatives that we considered. On the scripting side: Perl, Python, PHP, Ruby et al. These are not necessarily fast, and the distribution is also interesting. We have enough experience with …

I was interested to hear about semi-sync replication improvements in MySQL’s 5.7.4 DMR release and decided to check it out.  I previously blogged about poor semi-sync performance and was pretty disappointed from semi-sync’s performance across WAN distances back then, particularly with many client threads.

The Test

The basic environment of these tests was:

• AWS EC2 m3.medium instances
• Master in us-east-1, slave in us-west-1 (~78ms ping RTT)
• CentOS 6.5
• innodb_flush_log_at_trx_commit=1
• sync_binlog=1
• Semi-sync replication plugin installed and enabled.
• GTID’s enabled (except on 5.5)
• sysbench 0.5 update_index.lua test, 60 seconds, 250k table size.
• MySQL 5.7 was …

In my previous post, I blogged about using Percona Server with Docker and have shown you how fast and easy it was to create a virtual environment with just a few commands.

This time I will be showing you how to setup a three-node Percona XtraDB Cluster (PXC) 5.6 on the Docker open-source engine. Just to review Docker… “is an open-source engine that automates the deployment of any application as a lightweight, portable, self-sufficient container that will run virtually anywhere.”

In this case we will make use of a Dockerfile, think of this more like the Vagrantfile, it is a build script with a set of commands automating the creation of a new docker container.

For this case, we will use the …

May 23, 2014 By Severalnines

If you need to deploy a database cluster behind your corporate firewall, on servers with no internet access, then this blog is for you. Most of the installation tutorials out there require servers to have an internet connection, and that would not work very well with companies under strict policies and compliance guidelines. 

Our online Galera Configurator supports deployment without Internet connection for Percona XtraDB Cluster. You would need to prepare a minimum of four hosts (three DB nodes and one management node), generate a Deployment Package from the Configurator and copy it to the ClusterControl host. In this post, we will show you how to deploy Percona XtraDB Cluster 5.5 in an environment without internet connection on CentOS 6.5 (installed with minimal installation). Our setup is …

I’ve had the opportunity to train lots of people on Percona XtraDB Cluster (PXC) over the last few years the product has existed.  This has taken the form of phone calls, emails, blog posts, webinars, and consulting engagements. This doesn’t count all the time I’ve spent grilling Codership on how things actually work.  But it has culminated in the PXC tutorial I have given annually at Percona Live MySQL Conference and Expo in Santa Clara, California for the last two years.  Baron even attended this year and had this say:

“Jay Janssen’s tutorial on Percona …

Percona is glad to announce the release of Percona XtraDB Cluster 5.5.37-25.10 on May 8, 2014. Binaries are available from the downloads area or from our software repositories.

Based on Percona Server 5.5.37-35.0 including all the bug fixes in it, Galera Replicator 2.10 (including fixes in 2.9 and 2.10 milestones) and on wsrep API 25.10 (including fixes in 25.10), Percona XtraDB …

Overview

Percona XtraDB Cluster 5.6 has been GA for several months now and people are thinking more and more about moving from 5.5 to 5.6. Most people don’t want to upgrade all at once, but would prefer a rolling upgrade to avoid downtime and ensure 5.6 is behaving in a stable fashion before putting all of production on it. The official guide to a rolling upgrade can be found in the PXC 5.6 manual. This blog post will attempt to summarize the basic process.

However, there are a few caveats to trying to do a rolling 5.6 upgrade from 5.5:

1. If you mix Galera 2 and Galera 3 nodes, you must set wsrep_provider_options=”socket.checksum=1″ on the Galera 3 nodes for backwards …

Whither your rollback plan?

MySQL 5.6 upgrades are in full swing these days and knowing how to safely upgrade from MySQL 5.5 to 5.6 is important. When upgrading a replication environment, it’s important that you can build a migration plan that safely allows for your upgrade with minimal risk — rollback is often a very important component to this.

For many people this means upgrading slaves first and then the master.  The strategy of an older master replicating to a newer slave is well known and has been supported in MySQL replication for a very long time.  To be specific:  you can have a MySQL 5.6 slave of a 5.5 master and this should work fine until you upgrade your master and/or promote one of the slaves to be the master.

However, there are those of us who like to live on the edge and do …