One day, while looking into slave lag problem, the idea of MySAR popped into my head and a few hours later I was using its first incarnation. I was able to relate the server’s I/O activity peaks with these lags and in turn, discovered that it was caused by a great number of INSERT statements coming in in waves. It was an encouraging outcome for what was nothing more than a proof of concept.
Welcome to the 164th edition of Log Buffer, the weekly review of database blogs.
After running both InnoDB Hot Backup and Xtrabackup, we have found that there is a measurable but not large difference between the resources that Xtrabackup and InnoDB Hot Backup consume. Here they are.
I will be giving a presentation explaining SHOW ENGINE INNODB STATUS for the Boston MySQL User Group. There is information about foreign keys, transactions, deadlocks and mutexes just waiting to be discovered, and I will show how to decipher the information.
We are often asked to “do a schema diff and create a script that will ‘patch’ one server.”. We like to use the best tool for the job, and while diff is good, I like to use MySQL workbench. The OSS (Community) edition provides all the functionality we need for creating a schema diff and patch. MySQL workbench does both reverse engineering and “forward engineer” alter script for free in the OSS/Community version. Step by step, here’s how to do it:
I spent Friday examining the systems for a more traditional consulting gig. It is a familiar story to many people — the database performance was unacceptable. The company had a few log tables that had huge amounts of inserts and foreign keys, so they used InnoDB. Unfortunately, they also used a GUID as a primary key — varchar(32) and utf8. That’s right — their primary key for many of these tables was 96 bytes long (32 characters * 3 bytes per character), and as an InnoDB table, the primary key is clustered with every other index.
Mark Callaghan posted a good test of the MySQL query cache in different versions. His tests clearly show that in 5.0.44 and 5.0.84 and 5.1.38, there is more query throughput when the query cache is disabled. Mark’s benchmark definitely reinforces that turning on the query cache without any knowledge of your system is a bad idea, and I agree with him on that. But it does not in any way mean that the query cache is always a bad idea. It is important to know how the MySQL query cache works, so I will first explain that, and then explain why Mark’s test is not a very good broad generalization. MySQL’s query cache is not useful all the time, but it can be quite useful!
Welcome, readers, to the 163rd edition of Log Buffer, the weekly review of database blogs, your sieve
Mike Hogan, CEO of ScaleDB spoke at the Boston MySQL User Group in September 2009. The slides and video are available here.
Welcome to the 162nd edition of Log Buffer, the weekly review of database blogs.