When I moved to the UK from Italy, now more than eight years ago, people asked me all the time "Why did you leave such a sunny place like Italy to move to England?". Well, first of all, the south east of England is not that bad. There is a decent number of sunny days in a year and the bright sky of a breezy morning is just fantastic. Second, my home town is Milan, in the middle of the Po valley, with foggy winters and humid summers, with temperatures between -15C and +38C over the year. And there is another point: no wind and no much rain, hence pollution. In Milan the pollution is so awful that almost one third of the working days in a year private cars cannot be used within the city, in the attempt of reducing emissions. When I was a child, my mum used to put a PVC cover over the washing line to avoid that clean clothes would get immediately dirty.

It is a long introduction, but it is probably worth it, because it fits almost …

Quite frequently I see customers looking at recovery as on ability to restore data from backup which can be far from being enough to restore the whole system to operating state, especially for complex systems.

Instead of looking just at data restore process you better look at the whole process which is required to bring system to the working state, including data consistency requirements and times. This has to be considered for different data loss scenarios which may happen.

Let us look at simple example - a master with 1TB of database size replicating to 50 servers in 5 different Data Centers via single Replication Relay server in each. Forget the single point of failure for the second and just think what problems we may have to deal with.

First lets look at the master. What may happen to it ? We can have Master having soft crash in which case it will be unavailable for some time but we can get all the …

Have you ever seen the replication stopped with message like this:

Last_Error: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.

This is relay relay log corruption and you can check details in the MySQL Error log file. The error message describes few reasons and indeed because there is little validation (ie no checksums) in the replication there are multiple reasons for bad event to show up in relay logs.

Really this is only one of various error messages you could see if relay log corrupted. You …

My post about contributing to Drizzle somehow ended up with a very old posting date to MySQL Planet.MySQL DBA & Programming Blog by Mark Schoonover

Let me begin by saying “I am so not a gadget guy.” I don’t have an iPhone. Heck, I didn’t have a cellphone at all until April when I joined Percona as a consultant. I don’t ooh and aah over other people’s gadgets most of the time. I don’t have, you know, that kind of envy. I’m sure you see where this is going: I got a gadget and I think it’s really cool.

Anyway, my wife and I have a bunch of computers (desktops and laptops) and we had been feeling the pain for a long time: the files were only on one computer, and we wanted them available. I built a file server and then realized that it was going to be really expensive in terms of power alone, so I went back to USB drives for backups, and kept thinking about it.

After a long time I …

Not really, it's about 90 degrees out and sunny here near San Diego. For a couple of years, I've been looking around to volunteer on an OSS project, and Drizzle really fits the bill. I've used MySQL for years, and have done some community support as well. I've been wanting to gain greater experience in technical writing, so Drizzle is the perfect project.

I'll be working on development & user documentation, and the weekly Drizzle Report. The Drizzle Report is a weekly synopsis on development and other progress to be posted on my blog Sunday evenings.

Be sure to check out the Drizzle Wiki. Launchpad is the home of the Drizzle project.

MySQL DBA & Programming Blog by Mark Schoonover

Not really, it's about 90 degrees out and sunny here near San Diego. For a couple of years, I've been looking around to volunteer on an OSS project, and Drizzle really fits the bill. I've used MySQL for years, and have done some community support as well. I've been wanting to gain greater experience in technical writing, so Drizzle is the perfect project.

I'll be working on development & user documentation, and the weekly Drizzle Report. The Drizzle Report is a weekly synopsis on development and other progress to be posted on my blog Sunday evenings.

Be sure to check out the Drizzle Wiki. Launchpad is the home of the Drizzle project.

MySQL DBA & Programming Blog by Mark Schoonover

Lets face it, when it comes to storage engines, performance is everything. But then again, so is stability and data integrity!

So as a developer of an engine, which should you concentrate on first: performance, stability or data integrity?

I know there are not many that have to deal with this stuff, but here is my advice anyway: go for performance first.

The reason is simple, significant performance tuning can have a serious affect on both stability and data integrity. And this means you need to repeat a lot of the debugging and testing you did before.

For example one of the optimizations I made for 1.0.04 required a number of changes to the index cache. One thing was to make the LRU (least recently used) list global, it was segment based before. During the change I copy-pasted a "lru" pointer instead of a "mru" pointer :(

The result was not a crash, but the engine …

Inspired by http://blogs.sun.com/thava/entry/dump_mysql_frm_file_header I jumped into http://forge.mysql.com/wiki/MySQL_Internals_File_Formats and tried to write a decoder for the .frm files. Sadly the internals document is missing all the interesting parts.

So it was time to get the hands dirty and get into the code ... it got really dirty. But I found a little gem in there.

If you are interested take a look at open_binary_frm() or create_frm() in sql/table.cc or mysql_create_frm() in sql/unireg.cc. It has all the glory. You may have to wipe off the dust a bit has this code is (I bet) as old as MySQL is.

.frm-files are from a time when Monty wrote Unireg …

Many people have asked (via IM, email, Twitter) how my new job is going, what craigslist is like, etc. So here are a few thoughts about my first two weeks in the new job.

The Commute

Despite what folks said in the comments of my little announcement, the commute really isn't that bad. Taking I-280 from Willow Glen (San Jose) up to near Golden Gate Park is about 55 minutes from pulling out of the garage to parking in San Francisco. And I've been able to find parking on Lincoln each time I've gone up--usually within 4-6 blocks from the office.

So 55 minutes of driving plus about 10 minutes of walking (which is good for me anyway) is very manageable if you're not doing it every day. If I did, I'd be less up-beat about it, I'm sure.

Having said that, I am going to experiment with the mass transit options as well. I'd …