In developing MySQL Server and MySQL Cluster we use four types of testing.
We use unit testing, we use functional testing, we use system testing and
we use benchmark testing.

For the unit tests and functional tests we use the MTR test framework. This
is dealing with most issues of how to use SQL to query the MySQL database
engine.

For system testing the InnoDB team has a test framework that is used to ensure
that InnoDB will survive crashes of many sorts. In a similar fashion MySQL
Cluster uses the autotest framework that I described in an earlier blog:
Link to earlier blog.

For benchmark testing we have a few frameworks, I am going to describe the one
that I use on a regular basis. This framework can be downloaded from:
…

The performance of a Galera cluster is strongly connected to the performance of MySQL. Galera only supports the InnoDB storage engine, it is therefore important to have an insight into how InnoDB operates – what metrics we can rely on and what kind of issues we might face. In this blog post, we will give you a tour of some of the InnoDB internals. Note that we covered Galera monitoring and host/OS monitoring in previous blogs.

For starters, we’d like to emphasize this is by no means comprehensive guide. Some details will not be mentioned here …

Introduction

MySQL Enterprise Backup 3.12.0 (MEB) introduces a new feature for restoring an InnoDB table from a backup. Now it is possible to rename the table during restore. This is useful when the user wants to restore a table from a backup without overwriting the existing version of the table in the database.

The following example illustrates how the renaming feature could be used.  Suppose that the DBA has deleted three rows from a table T1 by mistake and he now wishes to get them back from a backup. He wants to leave the database online and to restore the 3 deleted rows from a TTS backup (a backup created with the --use-tts option) that contains the table T1.  He can do this with this feature in three steps:

1. He restores with MEB the table T1 from a TTS backup renaming it to T2.
   
   
2. He uses MySQL client to issue SQL statements to …

Your commands use "--backup-image=-" without redirecting standard output (on backup) or input (on restore), so in ordinary Unix/Linux convention the backup image would be written to (read from) your screen.
I strongly doubt this will work at all, you better specify a true file name.
If, however, "mysqlbackup" does not assign the meaning "standard output / input" to the name '-', you have silently shown what I consider a bug.

Explaining and providing solutions of MySQL error 1449: The user specified as a definer does not exist using SQL SECURITY INVOKER and DEFINER.

The post How to fix definer does not exist error 1449 MySQL first appeared on Change Is Inevitable.

This webinar provides a better understanding of how MySQL and its storage engines use indexes, as well as how you can improve performance with basic and advanced index optimizations.

The slide deck from the webinar is embedded below, and you can also register for a recording here.

A student posed the question about why table names are case sensitive. That’s because case sensitive table names are the default installation, as qualified in the MySQL documentation. You can verify that with the following query:

SELECT CASE
         WHEN @@lower_case_table_names = 1 THEN
           'Case insensitive tables'
         ELSE
           'Case sensitive tables.'
         END AS "Table Name Status";

The default value returned on Linux is:

+------------------------+
| Table Name Status      |
+------------------------+
| Case sensitive tables. |
+------------------------+
1 row in set (0.00 sec)

The default value for the lower_case_table_names value on the Windows OS is 1 not …

On March 10, 2015, we released MySQL-5.7.6 and among many other things it includes  …

Cross-posted on Google Cloud Platform Blog.

Your new website is growing exponentially. After a few rounds of high fives, you start scaling to meet this unexpected demand. While you can always add more front-end servers, eventually your database becomes a bottleneck, which leads you to . . .

• Add more replicas for better read throughput and data durability
• Introduce sharding to scale your write throughput and let your data set grow beyond a single machine
• Create separate replica pools for batch jobs and backups, to isolate them from live traffic
• Clone the whole deployment into multiple datacenters worldwide for disaster recovery and lower latency

At YouTube, we went on that  …

Cross-posted on Google Cloud Platform Blog. Your new website is growing exponentially. After a few rounds of high fives, you start scaling to meet this unexpected demand. While you can always add more front-end servers, eventually your database becomes a bottleneck, which leads you to... Add more replicas for better read throughput and data durability Introduce sharding to scale your write throughput and let your data set grow beyond a single machine Create separate replica pools for batch jobs and backups, to isolate them from live traffic Clone the whole deployment into multiple datacenters worldwide for disaster recovery and lower latency At YouTube, we went on thatjourney as we scaled our MySQL deployment, which today handles the metadata for billions of daily video views and 300 hours of new video uploads per minute.