Amazon EBS volumes come with a very cool feature called "lazy loading". In a nutshell: if a volume is created from an existing snapshot, it can become available almost immediately without waiting for all data to be restored. This allows for extremely fast provisioning of large data sets as long as you don't explicitly require the entire data set to be present before you start using it.
When an EBS volume is restored from snapshot, its blocks are fetched from Amazon S3. It happens either lazily in the background or explicitly on demand (think of a pagefault-like mechanism) and of course, fetching pieces of data from Amazon S3 is going to be one-two orders of magnitude slower than reading blocks directly from a volume.
In this short article, I will try to give you an idea of how this may impact the crash recovery time of your MySQL databases. Why talk about this? Depending on the workload and data set layout, crash recovery of a MySQL …

It goes without saying that crash recovery of busy MySQL servers (and many other RDBMS for that matter) is not an extremely quick process. In MySQL context, one of the worst case scenarios is when the server is used for multi-tenant application hosting i.e. when the MySQL instance contains hundreds or thousands of schemas and (tens/hundreds of) thousands of tablespaces. In such scenario, the server may spend a considerable amount of time in the tablespace discovery phase, during which MySQL builds a mapping between tablespace IDs and names of actual tablespace files on disk.
MySQL 5.7 promises to put an end to tablespace discovery. The documentation lists the following improvements introduced in versions 5.7.5 and up:

• Elimination of file system scans prior to redo log application. The MLOG_FILE_NAME redo log …

Previous episodes:

• MySQL-Docker operations. - Part 1: Getting started with MySQL in Docker.
• MySQL-Docker operations. - Part 2: Customizing MySQL in Docker.
• MySQL-Docker operations. - Part 3: MySQL replication in Docker.

We're going to explore the choices and the differences between various types of deployments. We will consider four use cases:

1. [Friendly]: Testing an application on a server where a different version of the same application is already installed (examples: a Python app requiring many …

The MySQL family has grown with the introduction of the Router, which brings high-availability and Fabric integration to all MySQL clients independently of any specific connector support for them. This blog focuses on the throughput of the Connection Routing plugin for Router and evaluates the overhead it may bring to application performance compared to direct connection.…

With MySQL 5.7 becoming GA it’s a good time to highlight how much performance has improved in replication since the 5.6 era. A previous blog post focused on the performance of the multi-threaded slave applier and on this one the target is the semi-synchronous replication plug-in (SemiSYNC), whose performance has improved greatly.…

Now that MySQL 5.7 has become GA it’s a good time to highlight how much performance has improved in replication since the 5.6 era. This blog post will focus on the performance of the multi-threaded slave applier (MTS), and about it’s scalability in particular.…

Docker is one of the fastest growing trends in IT. It allows fast deployment of services and applications on a Linux machine (and, with some limits, on other operating systems). Compared to other methods of deploying databases, such as virtual machines or application isolation, it offers faster operations and better performance.
Many people, surprised by the sudden advance of this technology, keep asking What is Docker? And why you should use it?
I will write soon an article with a deep comparison of the three methods (VM, container, sandbox), but for now, we should be satisfied with a few basic facts:

• Docker is a Linux container. It deploys every application as a series of binary …

When you have read my previous blog post about MariaDB 10.1 GA performance, you have probably wondered why I didn’t include any numbers for MySQL 5.7. There are two reasons: first MySQL wasn’t GA at that time and secondly MySQL is not running stable on Power8. Today I will come up with a comparison benchmark. […]

The post MariaDB 10.1 and MySQL 5.7 performance on commodity hardware appeared first on MariaDB.org.

MariaDB TokuDB benchmark on FusionIO ,Compare TokuDB and InnoDB engines.

read: TokuDB_benchmark

MariaDB 10.1 not only contains tons of new features, it has also been polished to deliver top performance. The biggest improvement has been achieved for scalability on massively multithreaded hardware.

The following numbers show the throughput for a simplified sysbench OLTP benchmark on MariaDB-10.1.8 compared to MariaDB-10.0.21: