I was just talking to someone who backs up their MySQL servers once a day with mysqldump, and I said in a catastrophe, you’re going to have to reload from a backup; that’s some amount of downtime, plus up to a day of lost data. And they said “We can just promote a replica, we’ve done it before. It works fine.” Granted, in some/many cases, this is fine. There are all sorts of caveats – for example, you either know that your slave has the same data as the master or you don’t care.

I wish I could say

        printf("%*.16xs", n, p);

where n is a size_t and p is a void*, and it would output n bytes as hex.


And I want to be able to say

        printf("%*qs", n, p);

and it would output n bytes as a C-style backslash quoted string.


Yes, I can write functions that do all this, but I have to worry about buffers, allocate buffer space, and so forth. Plus its a lot of noise and clutter, for just outputing potentially unprintable strings, often just for logging and debugging.

Mark has found Double sysbench throughput with TCMalloc with is quite amazing.

In Drizzle, if TCMalloc is present, we’ve linked it in (and on Solaris, mtmalloc) for years now. well…. Drizzle years, which are rather like dog years.

Like a few other folks, I decided to play with iiBench and see how fast I could insert 1B rows into an indexed InnoDB table. Mark Callaghan published  an excellent writeup of the theoretical and practical limits when index size >> buffer pool... but I bent the rules a bit ;)
The platform I ran iiBench on has four dual-core Xeon 3.2Ghz, internal 10k RPM 8 disk RAID 10, and 128GB of RAM. That's a lot, I know, but it was built precisely to avoid InnoDB's performance drop when an index does not fit in memory. It took just 22 hours to run a single iiBench process and 10 hours to run four processes in parallel (each doing 250m rows)! This was achieved without modifications to the iiBench code, using standard MySQL 5.1.30 binaries, the following …

Dear Lazyweb,

So, I’ve been in Chicago for a week teaching a beginner and an intermediate course on using and administering Linux machines. This week, I’ll teach an intermediate and an advanced course on Linux, and the advanced course will cover profiling and debugging. The main tools I’m covering will be valgrind and oprofile, though I’ll be going over lots of other stuff, like iostat, vmstat, strace, what’s under /proc, and some more basic stuff like sending signals and the like.

So what makes me a bit nervous is, being that the advanced students are mostly CS-degree-holding system developers, they’ll probably be expecting me to know very low-level details of how things are implemented at  the system/kernel level. I’d love to know more about that myself, and actively try to increase my knowledge in that area! Alas, most of my experience with low-level …

InnoDB allows you to dump information on its internal data dictionary out to stderr, by creating specific InnoDB monitor tables. Specifically the innodb_table_monitor and innodb_tablespace_monitor tables. This is covered to a limited extent in the MySQL Reference Manual at http://dev.mysql.com/doc/refman/5.0/en/innodb-monitor.html, however not to any great detail.

In the following I’ll use output created via these tables based upon the sample “sakila” database, and give details on how to attempt to correlate the information between the different outputs.

The output of SHOW INNODB STATUS is the output of the InnoDB Monitor, which is different than both the InnoDB Tablespace Monitor and the Innodb Table Monitor. You can also cause this information to be …

While developing mysql-proxy I sometimes have to step-by-step refactoring that usually result in unstable code for a while until the unit-tests are happy again.

When a unit-test fails I usually use gdb as a wrapper and let it create a stack-trace for me:

$ gdb --command=backtrace.gdb --args /path/to/my/testcase

The --command option is used to automate gdb:

run
thread apply all bt
quit

If the test finishes successfully, gdb will just quit, but on error we will get a nice, all-threads stack-trace.

In the end it looks like:

$ gdb --command=backtrace.gdb --args .../tests/unit/t_network_io
...
Program received signal SIGINT, Interrupt.
0x909f43ae in __semwait_signal ()

Thread 2 (process 49948 thread 0x1003):
#0  0x90a1d906 in kevent ()
#1  0x0006ee40 in kq_dispatch ()
#2  0x00062b26 in event_base_loop ()
#3  0x0000781a in mock_server (_udata=0x907dd0) …

This Thursday, we're continuing our series of sessions on MySQL performance measuring and improvements with Richard Smith's presentation titled Scalability by Design - Coding for Systems With Large CPU Counts. Richard works in the Performance and Applications Engineering department at Sun Microsystems, so again, expect to get some deep insights into the inner workings of the MySQL Server.

Richard is based in Australia, so note that this session will take place in the morning (Europe) or evening (APAC), respectively.

For MySQL University sessions, point your browser to this page. You need a browser with a working Flash plugin. …

These days I'm working with a customer who has an application based entirely on stored routines on MySQL side. Even though I haven't worked much with stored procedures, I though it's going to be a piece of cake. In the end - it was, but there's a catch.

My initial idea was - I'll just analyze queries in the slow query log generated by our mysql build running with long_query_time=0, get the slowest ones and work on them. It wasn't really all the way I expected..

For a showcase I have created a function "whatstheweatherlike". Let's call it and see what shows up in the slow query log:

PLAIN TEXT SQL:

1. mysql> SELECT whatstheweatherlike(5);
2. +----------------------------------------------------------+
3. | …

About one year ago, 400 MySQL employees were in Orlando, FL, for their company meeting. Their main worry was how to improve the business in view of the inevitable IPO that was coming soon. Nobody knew when, but there was expectation for Mårten Mickos keynote, on January 16, 2008, at 8:00. Possibly, everybody thought, he will announce a date for going public.

And public we went, but not the way we thought.

The evening before, I was among a group of about 25 people who were summoned to Mårten's suite, without a specific reason. At about 10pm, Mårten announced the $1B news, and for many of us there are only fuzzy memories after that. We weren't allowed to leave the suite before signing a NDA, to keep the news quiet until the following day at 8am.

Thus, having slept very little, with conflicting thoughts, I met my co-workers, and I couldn't tell anyone what was about to happen. We lined up for the keynote hall to open, and …