I gots to know…

Big web companies who use MySQL – what isolation level(s) do you use? Do you take the default? Do you think about it at all? How about if you use, eg, memcached, what there? And, does your code think about optimistic or pessimistic locking?

I’ve been reading up on isolation levels after seeing Peter Bailis’
http://www.bailis.org/blog/understanding-weak-isolation-is-a-serious-problem/
(thanks to Mark Callaghan for re-tweeting about it).

I’m learning things…  here’s one for today –

I always thought that the “repeatable” in repeatable read applied to the data in general. Meaning that a query run twice in a transaction would “repeat” the same results. I guess it actually is supposed to apply to records?  Ie, other transactions’ updates to an …

On Thursday I’ll be hosting a webinar explaining how you can get the best from the NoSQL world while still getting all of the benefits of a proven RDBMS. As always the webinar is free but please register here.

Even if you can’t join the live webinar, it’s worth registering as you’ll be emailed a link to the replay as soon as it’s available.

Abstract

There’s a lot of excitement about NoSQL data stores, with the promise of simple access patterns, flexible schemas, scalability, and high availability. The downside comes in the form of losing ACID transactions, consistency, flexible queries, and data integrity checks. What if you could have the best of both worlds? Join this webinar to learn how MySQL …

MySQL Statement Digests are a feature originally introduced as part of the MySQL Performance Schema in MySQL 5.6 to aggregate statement statistics based on the normalized statements executed within the server (for additional info, see here).

Digest calculations are done based on the tokens found in the statement text. The length to which these tokens were considered for the digest calculation was previously fixed at 1024 bytes. Which meant that while reading the tokens, once 1024 bytes were read from statement’s token stream, only that many tokens were considered when generating the …

Percona Toolkit is one of our most mature open source applications. Derived from Maatkit and Aspersa, Percona Toolkit has evolved significantly over the years. The software now contains 32 tools, over 4,000 tests, and has been downloaded over 250,000 times. Anyone who manages a database – from DBAs to system administrators to even software developers – benefits from Percona Toolkit’s ability to perform a variety of MySQL server and system tasks that are too difficult or complex to perform manually.

We continue to make Percona Toolkit better each month. Over the last 9 months alone Percona has had 6 releases and resolved nearly 50 issues.

…

My former boss, Marten Mickos, has created an excellent new resources for early stage founders, managers and execs called www.Schoolofherring.com. Each post has a short write up and often a 2-3 minute video covering a topic such as giving feedback, Peter Drucker's principles of good management, what it takes to build an effective team, hiring for strength etc. Some of these topics are very practical, like how to send good email, others are more thought-provoking, such as the notion that …

The setup_actors table in MySQL Performance Schema can be used to specify what users and hosts one wants to have instrumentation enabled for. By default, connections from all users and hosts are instrumented:

mysql> select * from performance_schema.setup_actors;
+------+------+------+
| HOST | USER | ROLE |
+------+------+------+
| %    | %    | %    |
+------+------+------+
1 row in set (0.00 sec)

You can then use standard SQL against this setup_actors table in order to specify what users and hosts you want to have instrumentation enabled for.

But what about the case where you want to enable instrumentation for everyone except the …

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 …

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.

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 …

MongoDB 3.0 was recently released. Instead of focusing on what’s new – that is so easy to find, let’s rather talk about something that has not changed a lot since the early MongoDB days. This topic is sharding and most specifically: how to choose a good sharding key. Note that most of the discussion will also apply to MySQL, so if you are more interested in sharding than in MongoDB, it could still be worth reading.

When do you want to shard?

In general sharding is recommended with MongoDB as soon as any of these conditions is met:

• #1: A single server can no longer handle the write workload.
• #2: The working set no longer fits in memory.
• #3: The dataset is too large to easily fit in a single server.

Note that #1 and #2 are by far the most common reason why people need sharding. Also note that in the MySQL world, #2 does not imply that you need sharding.

…