Upgrading MySQL

Upgrading MySQL is a task that is almost inevitable if you have been managing a MySQL installation for any length of time. To accomplish that task, we have provided a utility and documentation to upgrade from one version of MySQL to another. The general recommendation is to perform the upgrade by stepping from one major release to the next, without skipping an intermediate major release. For example, if you are at 5.1.73, and you want to go to 5.6.24, the safest and recommended method is to upgrade from 5.1.73 to 5.5.43 (the latest 5.5 release at the time of this writing), and then upgrade from 5.5.43 to 5.6.24 (or any version of 5.6). This allows the …

Madrid MySQL Users Group is having a Meetup this afternoon, Wednesday, 13th May at 19:00. I will be presenting (in Spanish) a quick summary of Percona Toolkit and also offering a summary of the new features in MySQL 5.7 as the release candidate has been announced and we don’t expect new functionality. This is also … Continue reading MMUG12: Talk about Percona Toolkit and the new features of MySQL 5.7

The post MMUG12: Talk about Percona Toolkit and the new features of MySQL 5.7 first appeared on Simon J Mudd's Blog.

We have released two free tools that will help MySQL and PostgreSQL DBAs understand the queries their database servers execute. As you probably know, we have spent nearly 3 years building the most advanced and efficient network traffic capture and decoding tools for MySQL and PostgreSQL. With the release of these free tools, we’re placing all the power of our traffic analysis libraries in your hands.

In our initial release, the tools sniff the network traffic and print out queries, with microsecond-resolution timing information, in a format that pt-query-digest understands natively. This means you can just pipe the tools into pt-query-digest and you’ll get a report of top queries by time. If you’re not familiar with pt-query-digest, it’s a powerful and flexible query analysis tool.

Here’s a quickstart, assuming you’re using …

VividCortex’s network traffic analyzer tool for MySQL is an easy-to-use way to gain insight into your server’s activity. Built for MySQL servers running on Linux operating systems, it is a non-intrusive, safe way to understand your query workload.

This commandline tool captures TCP traffic on your server and decodes the protocol. It decodes and times queries, and outputs them in a standard log format. You can use standard log analysis tools such as Percona Toolkit’s pt-query-digest to analyze the output and build insight into queries and server performance.

The tool is built on VividCortex’s advanced network traffic capture technology and is also a safe way to assess how VividCortex’s agents will behave on your systems. It is a thin wrapper around our TCP and MySQL decoding libraries. It does nothing but decode and print, and makes no attempt to communicate with the Internet or anything else. It’s secure and private to …

VividCortex’s network traffic analyzer tool for PostgreSQL is an easy-to-use way to gain insight into your server’s activity. Built for PostgreSQL servers running on Linux operating systems, it is a non-intrusive, safe way to understand your query workload.

This commandline tool captures TCP traffic on your server and decodes the protocol. It decodes and times queries, and outputs them in a standard log format. You can use standard log analysis tools such as Percona Toolkit’s pt-query-digest to analyze the output and build insight into queries and server performance.

The tool is built on VividCortex’s advanced network traffic capture technology and is also a safe way to assess how VividCortex’s agents will behave on your systems. It is a thin wrapper around our TCP and PostgreSQL decoding libraries. It does nothing but decode and print, and makes no attempt to communicate with the Internet or anything else. It’s secure …

By Erkan Yanar

In the previous article of this series, we described how to run a multi-node Galera Cluster on a single Docker host.

In this article, we will describe how to deploy Galera Cluster over multiple Docker hosts.

By design, Docker containers are reachable using port-forwarded TCP ports only, even if the containers have IP addresses. So we will set up port forwarding for all TCP ports that are required for Galera to operate.

The following TCP port are used by Galera:

• 3306-MySQL port
• 4567-Galera Cluster
• 4568-IST port
• 4444-SST port

Before we start, we need to stop enforcing AppArmor for Docker:

$ aa-complain /etc/apparmor.d/docker

Building a multi-node cluster using the default ports

Building a multi-node cluster using the default ports is not complicated. Besides mapping the ports 1:1, we also need to set …

Around 18 months ago, we launched the first MySQL Linux package repos, marking an important milestone in our efforts to modernize and improve the way we package and deliver MySQL products to our user community. MySQL product development had gone through radical improvements in terms of quality, dependability and sheer output, but the way we […]

Today, we’re excited to announce our first step towards dockerizing our products. Please welcome the official ClusterControl Docker image, available on Docker Registry Hub. This will allow you to evaluate ClusterControl with a couple of commands:

$ docker pull severalnines/clustercontrol

The Docker image comes with ClusterControl installed and configured with all of its components, so you can immediately use it to manage and monitor your existing databases. Supported database servers/clusters:

• Galera Cluster for MySQL
• Percona XtraDB Cluster
• MariaDB Galera Cluster
• MySQL replication
• MySQL single instance
• MongoDB/TokuMX Replica Set
• PostgreSQL single instance

…

[…] a multisource replication scenario: 10 masters, 1 slave. […]

One of the cool new features in 5.7 Release Candidate is Multi Source Replication, as I previously looked into in 5.7.5 DMR.

I’ve had more and more people like the idea of this, so here’s a quick set-up as to what’s needed and how it could work.

1. Prepare master environments.
2. Prepare 40 masters for replication.
3. Create slave.
4. Insert data into the Masters.

* I originally tried running 50 mysql’s but I just ran out of resources on my old pc, so it’s at 40.

* The real key behind this scenario is that each of the masters has a unique centre_code that is implicitly inserted via the app & users at that site. i.e. no other site will want to modify any data that was entered from that site, e.g. call centre reclaims dept for specific areas / regions, CNC …