MySQL Performance Blog

For long time as main backup solution for MySQL on Linux we have been using LVM snapshots. Performance concerns from performance critical envinronment caused us to do LVM performance research which showed horrible results forcing us to look at more performing alternatives.

Innodb Hot Backup is a good working solution but it is not Open Source and so we can’t ensure it will support all XtraDB features – extra undo slots, rollback segments etc.

After considering all alternatives we decided to develop Percona Xtrabackup tool, which will use same backup approach as InnoDB Hot Backup, that is taking online copy of InnoDB table files and transactional logs. This is going to be fully OpenSource, GPL licensed backup solution for MySQL (MyISAM and InnoDB for now).

We gathered basic ideas here http://www.percona.com/docs/wiki/percona-xtrabackup:start, and for the first stage it will be just full backup of files. For next stages we are looking to implement advanced functionality like incremental backup (copy only changes from last backup),table-level backup (copy only specified tables), streaming and parallel copying. Source code will be posted to Xtrabackup Launchpad project (https://launchpad.net/percona-xtrabackup/)

We call for more ideas you would like to see implemented (please leave them in comments). We got sponsorship for the base implementation work, but we’re still looking for sponsorship for additional features, contact us http://www.percona.com/contacts.html if you are interested. Percona will also significantly invest in this project.

Percona is hiring. We’ve added several experts recently and we’re growing at a fast but sustainable pace. The demand for our services is strong, and we have openings for more experts in the next couple of months.

Let me explain a little about what we’re looking for at the moment. While we do have a career path for less experienced people, right now we are looking for people who are top-level, senior experts in LAMP/Open-Source performance and scalability. Most of our work involves MySQL (at least peripherally, usually centrally) but not all of it; and we are looking for a PostgreSQL expert as well as systems administration and operations skills. If you’re also an expert in a related technology (e.g. Hadoop, popular cloud platforms, or some other component that you might expect to see at the Percona Performance Conference) we’d like to talk with you.

[read more...]

I vaguely recall a couple of blog posts recently asking something like “what’s the formula to compute mysqld’s worst-case maximum memory usage?” Various formulas are in wide use, but none of them is fully correct. Here’s why: you can’t write an equation for it.

[read more...]

One of InnoDB’s features is that memory allocated for internal tables definitions is not limited and may grow indefinitely. You may not notice it if you have an usual application with say 100-1000 tables. But for hosting providers and for user oriented applications ( each user has dedicated database / table) it is disaster. For 100.000+ tables InnoDB is consuming gigabytes of memory, keeping definition in memory all time after table was once opened. Only way to cleanup memory is to drop table or restart mysqld – I can’t say this is good solution, so we made patch which allows to restrict memory dedicated for data dictionary.

Patch was made by request of our customer Vertical Response and released under GPL, so you can download it there http://mysqlperformanceblog.com/files/patches/innodb_dict_size_limit_standalone.patch. Currently patch is on testing stage, but later will be included into our releases. To limit memory we introduce new variable innodb_dict_size_limit (in bytes).

Some internals: There is already implemented in InnoDB LRU-based algorithm to keep only recent table entries, but it was not used by reason that InnoDB has to know if table is used or not on MySQL level. We made it by checking MySQL table_cache. If table is placed in table_cache we consider it as used, if not – we can delete it from InnoDB data dictionary. So there is the trick – if you have big enough table_cache, memory consumed by data dictionary may exceed innodb_dict_size_limit, as we can’t delete any table entry from it.

To finalize this post small marketing message – if you faced bug or problem which exists for long time and is not going to be solved by MySQL / InnoDB – contact us regarding Custom MySQL Development.

Introduction
When people think about Percona’s microslow patch immediately a question arises how much logging impacts on performance. When we do performance audit often we log every query to find not only slow queries. A query may take less than a second to execute, but a huge number of such queries may significantly load a server. On one hand logging causes sequential writes which can’t impair performance much, on other hand when every query is logged there is a plenty of write operations and obviously performance suffers. Let’s investigate how much.

[read more...]

Here is nice gotcha which I’ve seen many times and which can cause just a minefield for many reasons.
Lets say you had a system storing articles and you use article_id as unsigned int. As the time goes and you see you may get over 4 billions of articles you change the type for article_id to bigint unsigned but forget linked tables.
[read more...]

In many cases I speculate how things should work based on what they do and in number of cases this lead me forming too good impression about technology and when running in completely unanticipated bug or performance bottleneck. This is exactly the case with LVM

Number of customers have reported the LVM gives very high penalty when snapshots are enabled (leave along if you try to run backup at this time) and so I decided to look into it.

I used sysbench fileio test as our concern is general IO performance in this case – it is not something MySQL related.
[read more...]

All of us here at Percona warmly invite you to Percona Performance Conference 2009 on April 22 and 23, 2009 in the Hyatt Regency in Santa Clara, California. The theme for the conference is Performance Is Everything. This conference is about application performance overall, not just databases. Attendance is free of charge for everyone. Experts in many types of technologies — databases, search, cloud computing, massively parallel computing, client-side optimization — will present their real-life experience.

[read more...]

The problem with broken group commit was discusses many times, bug report was reported 3.5 years ago and still not fixed in MySQL 5.0/5.1 (and most likely will not be in MySQL 5.1). Although the rough truth is this bug is very hard (if possible) to fix properly. In short words if you enable replication (log-bin) on server without BBU (battery backup unit) your InnoDB write performance in concurrent load drops down significantly.
We wrote also about it before, see “Group commit and real fsync” and “Group commit and XA“.
[read more...]

One of my favorite MySQL configurations for high availability is master-master replication, which is just like normal master-slave replication except that you can fail over in both directions. Aside from MySQL Cluster, which is more special-purpose, this is probably the best general-purpose way to get fast failover and a bunch of other benefits (non-blocking ALTER TABLE, for example).

The benefit is that you have another server with all the same data, up and running, ready to serve queries. In theory, it’s a truly hot standby (stay with me — that’s not really guaranteed). You don’t get this with shared storage or DRBD, although those provide stronger guarantees against data loss if mysqld crashes. And you can use the standby (passive) master for serving some SELECT queries, taking backups, etc as usual. However, if you do this you actually compromise your high-availability plan a little, because you can mask the lack of capacity that will result when one of the servers is down and you have to rely on just one server to keep everything on its feet.

[read more...]