We made new binaries for MySQL 5.0.67 build 7 which include patches we recently announced. The -percona release includes: PLAIN TEXT CODE: | innodb_check_defrag.patch | Session status to check fragmentation of the last InnoDB scan | 1.0 | Percona <info@percona.com> | GPL | The names are Innodb_scan_* | | userstatsv2.patch | SHOW USER/TABLE/INDEX statistics | V2 | Google | GPL | Added INFORMATION_SCHEMA.*_STATISTICS | | show_patches.patch | SHOW PATCHES | 1.0 | Jeremy Cole | ...

After some pause we are going to announce bunch of patches we made and ported for last period. Ported patches (ported from Google V2 patch): - innodb_fsync_source.patch - Show information about callers of fsync, more info - innodb_io_tune.patch - Port of two patches InnodbIOTune and InnodbAsync, more info - innodb_extra_status.patch - Show more information about InnoDB internals in SHOW STATUS, more Our patches (thanks Yasufumi!) - innodb_check_defrag.patch, Show how sequential was execution of query, more ...

Today was epoch day in American history. Maybe even most important day this year, but it's not what I'd like to write about here. What does it mean for US citizens and all other people around the world? We know, but what does it mean for us - IT professionals and/or internet portals serving news for end users? Increased number of requests to webservers, high network utilization, and huge number of queries against your databases ...

There is patch from Google to improve SMP performance , but for some workloads it showed for us reverse scalability. E.g. update_key benchmark from sysbench. There are also results with Yasufumi's rw_locks (http://bugs.mysql...) Threads Standard InnoDB Google smpfix Yasufumi rw_lock 1 9700.28 10601.96 9432.44 2 14355.66 16673.31 12783.58 4 16104.20 2669.39 6308.92 8 18507.55 780.22 1854.43 16 16178.09 842.73 1601.05 32 12337.50 2028.89 3274.13 64 7801.18 1911.94 4043.85 results are in tps, more are better ...

OurDeltaというプロジェクトが発足した。http://ourdelta.org/OurDeltaはMySQLに携わっているサードパーティ企業（連合）が主催しているプロジェクトであり、その主たる配布物はMySQLのブランチ（機能拡張版）で、MySQLコミュニティの間では話題沸騰中のプロジェクトである。OurDeltaの初版はMySQL 5.0.67に対して、PerconaのパッチとSphyinxストレージエンジン（全文検索改良版）を搭載したもで、それほど大胆な改造が行われているわけではない。なので、ブランチというと大げさかも知れないが、GPL版のMySQLを元にしたプロジェクト（派生ソフトウェア）の名前である。Perconaとは、MySQL Performance Blogを書いているPeter Zaidev氏（通称PZ）が運営する会社である。PZ氏は元々MySQLのサポートエンジニアであり、会社を辞めてからMySQL Performance Blogを書き始め、それが非常に人気を博すようになり、Perconaという会社を立ち上げた。Perconaはコンサルティングやサポートを提供している。Perconaのパッチを適用すると、特定の条件下、特に高負荷時において、なんと性能が向上するらしい？！その効果はMySQL Performance Blogでも触れられているので興味のある人は覗いてみて欲しい。そして、OurDeltaを試してみるといいだろう。Perconaパッチでは特にInnoDBまわりの改善が行われているようだ。パッチというからにはもちろん自前でMySQLサーバに適用することも可能であるし、MySQLの本流に取り込まれるのでは？という期待を持たれるかも知れないが、パッチ自身はGPLであるため、MySQLの本流へ取り込まれることはない。何故ならば、MySQLはデュアルライセンスだからである。MySQLサーバのライセンスは2種類あり、一つはGPLなので競合しないが、もう一つは商用（OEM向け）ライセンスなのでGPLライセンスのソフトウェアを取り込むことが出来ないのである。残念！じゃあみんなOurDeltaを使えばいいじゃないか？！と思うかも知れないが、それは早計である。そもそもパッチの利点を享受できるような極端に高負荷な状況はそうそう発生するものではないし、ソフトウェアの価値は性能だけで決まるものではないからである。安定性やサポートだって大事なんだよ！！と声を大にして言うオトコなのである。（だってサポートエンジニアだもの。みつヲ。）そして高性能版MySQLといえばDrizzleを忘れてはならない。Drizzleは抜本的なMySQLの改造であるので、OurDeltaより高性能になる可能性が非常に高い。ただしDrizzleはまだまだ開発中である上に実験的なプロジェクトであるため、本番環境でガンガン使えるようになるにはまだ少し時間が掛かるだろう。が、今後のリリースやベンチマークが非常に楽しみである。また、本気で膨大なトラフィックを捌かなければいけないような状況なら、MySQL Clusterという選択肢があるのを忘れてはならない。複数のサーバホストで負荷分散するMySQL Clusterは、単一のホストで動作するInnoDBでは到達できない性能を発揮するのである。そして、リオーグ（前回参照）を実装したバージョンがリリースされた暁には、負荷の増加にあわせて動的にノードを拡張できるのである。色々とOurDeltaに対する反対意見も述べてしまったが、OurDeltaのようなプロジェクトの登場はMySQLのコミュニティが拡大したひとつの兆候、いや・・・むしろ象徴であると思う。Sun/MySQLとPerconaはパートナー関係ではないのでビジネス上はライバルとなるが、OurDeltaによりさらにMySQLのコミュニティが広がれば両者にとってメリットになるだろう。ビジネスはゼロサムゲームではないのである。なのでOurDeltaの登場は歓迎したい。ビバ！！GPL！！

photo by: ikegami I’ve been too busy to blog lately, and for that I apologize. But here’s a quicky detailing the technologies (internet related and not) I’m excited about right now: Drizzle. For years now, I’ve felt that MySQL has been doing in a direction in opposition to my use case. Stored procedures, views, etc etc have added bloat and complexity without offering me anything useful. Turns out I’m not alone - and thus Drizzle ...

Ever since Peter over at Percona wrote about MySQL and swap, I’ve been meaning to write this post. But after I saw Dathan Pattishall’s post on the subject, I knew I’d better actually do it. There’s a nasty problem with Linux 2.6 even when you have a ton of RAM. No matter what you do, including setting /proc/sys/vm/swappiness = 0, your OS is going to prefer swapping stuff out rather than freeing up system cache. ...