An excellent Q&A Session with insightful details about the PBXT Storage Engine

SPIDER Storage Engine: Database Sharding by Storage Engine by Kentoku SHIBA (ST Global.,Inc) The official conference page is at http://www.mysqlconf.com/mysql2009/public/schedule/detail/6837 Download the presentation file (zip archive) at http://assets.en.oreilly.com/1/event/21/SPIDER%20Storage%20Engine_%20Database%20Sharding%20by%20Storage%20Engine%20Presentation.zip

Presented at the April 2009 Los Angeles MySQL User Group (see http://www.meetup.com/lamysql/calendar/9882984/ for more details) BIO: Andrew Aksyonoff is a Russian geek who created Sphinx back in 2001 and has been working on the code base ever since. Fluent in C++, less so in human speak, but keeps trying. He lives in Russia. TOPIC: Sphinx Just how do you implement keyword search through that 10-million-row InnoDB table? Meet Sphinx, a blazing fast open source engine that makes it a breeze. We'll talk about what it is, how it works, and when and why use it. INTERESTING FACT: Meetup search is powered by Sphinx.

Presented at MySQL Camp 2009 by Ewen Fortune of Percona. XtraDB is a storage engine for MySQL based on the InnoDB storage engine, designed to better scale on modern hardware, and including a variety of other features useful in high performance environments. It is fully backwards compatible, and so can be used as a drop-in replacement for standard InnoDB. XtraDB includes all of InnoDBs robust, reliable ACID-compliant design and advanced MVCC architecture, and builds on that solid foundation with more features, more tunability, more metrics, and more scalability. In particular, it is designed to scale better on many cores, to use memory more efficiently, and to be more convenient and useful. The new features are especially designed to alleviate some of InnoDBs limitations. We will talk about current status of XtraDB and directions of development.

What's new, in a nutshell: http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html Release notes: http://dev.mysql.com/doc/refman/5.1/en/news-5-1-x.html (In the video, it's the page entitled "Changes in release 5.1.x"). And yes, very early on (at about 2 minutes in) I talk about my take on Monty's controversial post at http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51-released.html The slides can be downloaded as a PDF at http://technocation.org/files/doc/2008_12_New51.pdf or in Open Office presentation format at http://technocation.org/files/doc/2008_12_New51.odp

The ScaleDB Storage Engine: Enabling High Performance and Scalability Using Materialized Views and a Shared-Disk Clustering Architecture Moshe Shadmon (ScaleDB) Slides can be downloaded at http://assets.en.oreilly.com/1/event/21/The%20ScaleDB%20Storage%20Engine_%20%20Enabling%20High%20Performance%20and%20Scalability%20Using%20Materialized%20Views%20and%20a%20Shared-Disk%20Clustering%20Architecture%20Presentation.ppt The official conference page is at http://www.mysqlconf.com/mysql2009/public/schedule/detail/7112

Slides are online (and downloadable) at http://www.slideshare.net/Sheeri/scale-db-preso-for-boston-my-sql-meetup-92009 Mike Hogan, CEO of ScaleDB spoke about ScaleDB at the Boston MySQL User Group in September 2009: ScaleDB is a storage engine for MySQL that delivers shared-disk clustering. It has been described as the Oracle RAC of MySQL. Using ScaleDB, you can scale your cluster by simply adding nodes, without partitioning your data. Each node has full read/write capability, eliminating the need for slaves, while delivering cluster-level load balancing. ScaleDB is looking for additional beta testers, sign up at http://www.scaledb.com

"There's a change of behaviour in MySQL 5.1.31 for Row Based Replication, if you have InnoDB transactions that also write to a MyISAM (or other non-transactional engine) table." "the moral of the story. Don't use non-transactional tables in the middle of a transaction. Ever. You will only cause yourself more pain than you can possibly imagine. Instead, move the writes to the non-transactional tables outside of the transaction."

If you are using InnoDB Hot Backup and a recent version of mysqld (at least 5.0.67 or higher, including 5.1.30, though it may be later versions), your backup will run fine and output OK! at the end, as it should.Except for one thing.The binary log file and position do not appear in their rightful place. Here's a snippet of the output from the backup:innobackup: MySQL binlog position: filename 'Warning', position (Code 1287):'TYPE=storage_engine' is deprecated; use 'ENGINE=storage_engine' instead090210 03:55:04 innobackup: innobackup completed OK!That's pretty misleading -- looks like the backup completed OK, but it did not show us the binary log position. What about the "ibbackup_binlog_info" file?[mysql@db3:~] more ibbackup_binlog_info Warning (Code 1287): 'TYPE=storage_engine' is deprecated; use 'ENGINE=storage_engine' instead[mysql@db3:~]Yikes! What happened to the binary log position and file information?Have no fear, it's actually in another file.

Someone asked me what applications were good/bad for MySQL Cluster. As I've now actually had experience with a Cluster setup and a real-life application of it, and dug through the manual, I present a few characteristics of applications that will work with Cluster, and why they are so (so that if you have an application that meets some of the characteristics but not all of them, you can decide whether it's worth it to use Cluster or not).Firstly, I'll state this -- there's actually a very limited application to MySQL cluster. I haven't assessed the disk-based cluster, only the memory-based one, so I don't know what really changes with disk-based. But after you see this list, you certainly will want to re-think your use of disk-based cluster if a lot of the inner workings don't change.The factors are listed below, but the "ruler" I keep in my mind is the fact that MySQL Cluster was developed for telecom applications.  []

MySQL memory handling and memory handling in Falcon

Ann Harrison and Jim Starkey, creator of Falcon, explain the archtecture of the Falcon storage engine.

Brian Aker explains the technology behind the MySQL storage handler interface.

Interaction Between Optimizer and Storage Engine