Introduction

This article describes the InnoDB redundant row format. If you are new to InnoDB code base (a new developer starting to work with InnoDB), then this article is for you. I'll explain the row format by making use of a gdb session. An overview of the article is given below:

• Create a simple table and populate few rows.
• Access the page that contains the rows inserted.
• Access a couple of rows and explain its format.
• Give summary of redundant row format.
• Useful gdb commands to analyse the InnoDB rows.
• Look at a GNU Emacs Lisp function to traverse rows in an InnoDB index page.

To get the most out of this article, the reader is expected to repeat the gdb session as described here.

The Schema

Consider the following SQL statements to produce the schema:

CREATE TABLE t1 (f1 int unsigned) row_format=redundant …

It’s common wisdom that large-scale database systems require distributing the data across machines. But what seems to be missing in a lot of discussions is distributing the query processing too. By this I mean the actual computation that’s performed on the data.

I just had a conversation with Peter Zaitsev yesterday that helped make concrete some thoughts I’ve been having about Cassandra for a while. Because Cassandra doesn’t allow you to really do any computation in the data (aggregating, evaluating expressions, and so on), if you’re going to use it for truly Big data, you’re going to fetch enormous amounts of data across the network. Sure, you’re distributing the storage and retrieval across many machines — but you’re locating your data far from your processing. You have a distant low-level key-value store, in essence, and you have to write a database wrapper on top of it if you’re going to use it for anything …

We have the pleasure to announce that the next MySQL mini-seminar in Trondheim will be held on October 17 15:00-18:00. This time, MySQL Monitoring and performance schema evangelist Mark Leith will visit us. The agenda will be similar to last mini-seminar:

• Presentation: MySQL monitoring and performance Schema, by Mark Leith
• Q&A, discussions
• Suggestions for presentations on future seminars
• Food and mingling

For more info, see the registration page.

Don't miss this opportunity to meet experts, developers and other MySQL users.

Ayer por la tarde se hizo la 2ª reunión de Madrid MySQL User Group. Para todos los que están en Madrid o cerca, os animo a ir, a compartir experiencias, dudas, cuestiones, etc. alrededor del tema “MySQL”. No tengais miedo!

Si os apetece apuntaros al siguiente (fecha pendiente por ahora), mirad a ver http://www.meetup.com/Madrid-MySQL-users-group/.

Ánimo.

Ayer por la tarde se hizo la 2ª reunión de Madrid MySQL User Group. Para todos los que están en Madrid o cerca, os animo a ir, a compartir experiencias, dudas, cuestiones, etc. alrededor del tema “MySQL”. No tengais miedo!

Si os apetece apuntaros al siguiente (fecha pendiente por ahora), mirad a ver http://www.meetup.com/Madrid-MySQL-users-group/.

Ánimo.

Being able to configure slaves to be crash-safe is one of the major improvements of MySQL 5.6 with regards to replication. However we noticed confusion on how to enable this feature correctly, so let’s clarify how it should be done.

In short

1. Stop MySQL on slave
2. Add relay_log_info_repository = TABLE and relay_log_recovery = ON in my.cnf
3. Restart MySQL and relax

The gory details

To fully understand why you should change the above settings if you want crash-safe slaves, let’s first look at the reasons why replication can break when a slave crashes.

On a slave, replication involves 2 threads: the IO thread which copies the binary log of the master to a local copy called the relay log and the SQL thread which then executes the queries written in the relay log. The current position of each thread is stored in a file: master.info for the IO thread …

So we all know that when troubleshooting MySQL crashes or any other processes in that regard, we simply enable core files to be dumped when the appropriate signal it triggered. To get the best results, we’d set the core file size limit everywhere to unlimited and be done with it, but what if you want to limit that to a certain size? I stumble to a small confusion lately when doing this for MySQL, so let me share quickly.

First, for MySQL, mysqld_safe would use ulimit to set the core-file-size value you pass to it. Now remember according to the manual, this value should be in blocks (some documentation says its in chunks of 1024 bytes). However, according to my experience on CentOS 6, this is the physical block size of the device where your core_pattern is pointed to.

[root@centos6 ~]# ulimit -a
...
core file size          (blocks, -c) 0

[root@centos6 ~]# cat /proc/sys/kernel/core_pattern
/var/tmp/core

[root@centos6 ~]# blockdev …

Join me Wednesday, September 18 at 10 a.m. PDT for an hour-long webinar where I will introduce the basic concepts behind column store technology. The webinar’s title is: “Introduction to open source column stores.”

What will be discussed?

This webinar will talk about Infobright, LucidDB, MonetDB, Hadoop (Impala) and other column stores

• I will compare features between major column stores (both open and closed source).
• Some benchmarks will be used to demonstrate the basic performance characteristics of the open source column stores.
• There will be a question and answer session to ask me anything you like about column stores (you can also ask in the …

Want to prove your expertise with MySQL? Why not get certified.

Oracle has just announced the release of the new MySQL Certification Path including the:

• Oracle Certified Professional, MySQL 5.6 Developer (OCP)
• Oracle Certified Professional, MySQL 5.6 Database Administrator (OCP)

You can register for these certification exams from today. Learn more about these certifications on the Oracle University blog.

Successful candidates will require a strong MySQL experience. Although …

There are multiple ways to backup a MySQL database. Some are more painful than others. In this two part blog we are going to discuss why the new hot backup system in TokuDB is special amidst the existing solutions. First let’s look at existing backup solutions for MySQL and InnoDB.

Let’s start with the most obvious, and possibly painful, way to make a backup of MySQL: a manual copy of the MySQL data directory.

Coarse Copy

The copying itself isn’t the painful part; any DBA worth their salt can copy a directory. Guaranteeing what comes out the other end, however, is difficult. In other words, what will the state of each table in each database look like when the backup is complete? It turns out, without additional help, we don’t know!

If you think about the dynamic state of a database, and the serial copying of the same database files from one space to another, some questions may start to …