Thank you for attending my 22nd July 2016 webinar titled “Top Most Overlooked MySQL Performance Optimizations“. In this blog, I will provide answers to the Q & A for that webinar.

For hardware, which disk raid level do you suggest? Is raid5 suggested performance-wise and data-integrity-wise?
RAID 5 comes with high overhead, as each write turns into a sequence of four physical I/O operations, two reads and two writes. We know that RAID 5s have some write penalty, and it could affect the performance on spindle disks. In most cases, we advise using alternative RAID levels. Use RAID 5 when disk capacity is more important than performance (e.g., archive databases that …

With SQLyog MySQL GUI 12.2.5, JSON comes to SQLyog. This is a new and major thing.  Also, Foreign Key management with NDB tables was added and the user- filter was improved in the User Manager. Additionally, some non-critical GUI bugs were fixed.

Changes as compared to MySQL GUI 12.2.4 include:

Features:

* Added basic support for the JSON datatype as of MySQL 5.7.8+ and MySQL Cluster 7.5.2+. The datatype is now available in the CREATE/ALTER TABLE dialog and JSON data will open in the BLOB-viewer. In the BLOB-viewer we have added validation that content is valid JSON. Also JSON-related keywords and functions are recognized in syntax highlighting and autocomplete. Also please see note at the bottom.
* SQLyog GUI now supports Foreign Key constraints between NDB tables for MySQL Cluster 7.3+.
* It is now possible to filter the users based on a string in the …

With SQLyog MySQL GUI 12.2.5, JSON comes to SQLyog. This is a new and major thing.  Also, Foreign Key management with NDB tables was added and the user- filter was improved in the User Manager. Additionally, some non-critical GUI bugs were fixed.

Changes as compared to MySQL GUI 12.2.4 include:

Features:

* Added basic support for the JSON datatype as of MySQL 5.7.8+ and MySQL Cluster 7.5.2+. The datatype is now available in the CREATE/ALTER TABLE dialog and JSON data will open in the BLOB-viewer. In the BLOB-viewer we have added validation that content is valid JSON. Also JSON-related keywords and functions are recognized in syntax highlighting and autocomplete. Also please see note at the bottom.
* SQLyog GUI now supports Foreign Key constraints between NDB tables for MySQL Cluster 7.3+.
* It is now possible to filter the users based on a string in the …

Storing documents is convenient: no need to define a schema up-front, no downtime for schema changes, no normalization, no slow joins – true or not, you name it. But what about search if you do not know how your data is structured? For example, the famous SFW-construct requires listing the columns to search: SELECT … FROM … WHERE some_column = ‘Jippie’ . Given that JSON data can have no schema how to write a query without knowing any field names, where is SELECT … FROM … WHERE * = ‘Jippie’? JSON_SEARCH() gets you started but there are gaps if you think about it for a minute.

There are many reasons why you may not know the structure of the data you operate on. Maybe, you have gathered documents using different “schema versions” over time, maybe, there is simply no common structure because the data comes from …

At GitHub we use MySQL as our main datastore. While repository data lies in git, metadata is stored in MySQL. This includes Issues, Pull Requests, Comments etc. We also auth against MySQL via a custom git proxy (babeld). To be able to serve under the high load GitHub operates at, we use MySQL replication to scale out read load.

We have different clusters to provide with different types of services, but the single-writer-multiple-readers design applies to them all. Depending on growth of traffic, on application demand, on operational tasks or other constraints, we take replicas in or out of our pools. Depending on workloads some replicas may lag more than others.

Displaying up-to-date data is important. We have tooling that helps us ensure we keep replication lag at a minimum, and typically it doesn’t exceed 1 …

At GitHub we use MySQL as our main datastore. While repository data lies in git, metadata is stored in MySQL. This includes Issues, Pull Requests, Comments etc. We also auth against MySQL via a custom git proxy (babeld). To be able to serve under the high load GitHub operates at, we use MySQL replication to scale out read load.

We have different clusters to provide with different types of services, but the single-writer-multiple-readers design applies to them all. Depending on growth of traffic, on application demand, on operational tasks or other constraints, we take replicas in or out of our pools. Depending on workloads some replicas may lag more than others.

Displaying up-to-date data is important. We have tooling that helps us ensure we keep replication lag at a minimum, and typically it doesn’t exceed 1 …

Percona announces the first release candidate (RC1) in the Percona XtraDB Cluster 5.7 series on August 9, 2016. Binaries are available from the downloads area or our software repositories.

Percona XtraDB Cluster 5.7.12-5rc1-26.16 is based on the following:

• Percona Server 5.7.12
• Galera …

Uber has been in the news for numerous reasons in the past few days. Be it expansion to new countries or selling its China operations to Didi chuxing, Uber is growing exponentially and expanding into newer markets. Recently, Uber also announced a major change – Changing their databases from Postgres to MySQL. While enterprises are constantly checking and trying to find the right fit for their databases, it takes immense research and analysis to decide on THE one.

Each enterprise has their own requirements and it is imperative for the company to decide on the database that suits their needs. This is exactly what Uber did. Uber recently shared a …

I worked on an issue last recently where a query was too slow when executed in MySQL Cluster. The issue was that Cluster has some restrictions when it comes to push down conditions.

As an example of this, consider the following query using the employees sample database. The query takes a look at the average salary based on how many years the employee has been with the company. As the latest hire date in the database is in January 2000, the query uses 1 February 2000 as the reference date.

Initially the query performs like (performance is with two data nodes and all nodes in the same virtual machine on a laptop, so the timings are not necessarily representative of a production system, though the improvements should be repeatable):

mysql> SELECT FLOOR(DATEDIFF('2000-02-01', hire_date)/365) AS LengthOfService,
              COUNT(DISTINCT employees.emp_no) AS NoEmployees, AVG(salary) AS AvgSalary
         FROM salaries …

This post discusses how XtraDB Cluster and Ceph are a good match, and how their combination allows for faster SST and a smaller disk footprint.

My last post was an introduction to Red Hat’s Ceph. As interesting and useful as it was, it wasn’t a practical example. Like most of the readers, I learn about and see the possibilities of technologies by burning my fingers on them. This post dives into a real and novel Ceph use case: handling of the Percona XtraDB Cluster SST operation using Ceph snapshots.

If you are familiar with Percona XtraDB Cluster, you know that a full state snapshot transfer (SST) is required to provision a new cluster node. Similarly, SST can also be triggered when a cluster node happens to have a corrupted …