Home
MySQL Users Conference

Keynotes

Miguel deIcaza, El Mono

This guy is fun but totally out of our field. He was energetic and showed off the fancy fancy desktop apps they're developing in Mono, iFolder, F-Spot etc.

The most interesting facet of this is the way so many languages can be complied down to run in the .NET/Mono VM. Hopefully Parrot does this in a way that doesn't make us sick.

Someone from Google

His point was that the web is big becuase of it's simplicity, stupidity, and scalability. He called upon the open source devs to drop all this fancy transactions, views, and other centralized logic development and emulate the web.

He suggests a super-standardized transport protocol for database client-server communication (like HTTP) that allows any client to talk to any database. He envisions something like RSS handling this, with queries being very simple and natural language, and tuples coming back as RSS records.

Obviously, this is a grand idea, but if such a protocol were available, it would become us to offer clients their data in this format.

MySQL Development Model

This block was low-interest, and I originally choose a "3 ways to develop apps" session, but it turned out to be the Dell vendors selling blades and recomending that we turn REGISTER_GLOBALS on "just for the example app". So obviously, it would be a great example.

This session is mostly academically interesting, talking about how MySQL manages their global dev team.

Communication tools - IRC, email for 90% and a little VoIP. They try to lower the language barrier by focusing on typed communication, but the heavily multi-cultural nature of the company can impede.

Their hiring is done by word of mouth, and straight from the community. Usually they interview by having people submit patches to the actual open-source code.

All features get split into "Flagship" and "Rolling". Flagships are committed to, and have hard development deadlines and guarantees. Rolling are committed if they are ready when the release goes into beta. Customers can pay to have Rolling features upgraded to Flagship.

There is a worklog that contains project and task definitions. Design meetings are called as needed - usually over IRC.

Every dev lead runs their only monthly scrum, and track tasks in weekly chunks via IRC. BitKeeper for source control and a wiki for internal info and docs.

Monty and Brian do pretty much all top-level code review, but they feel this might need to be expanded. Monty checks everly line of code at the server level and frequently sends things back.

They run an Alpha Beta Gamma release cycle. Alpha - we will not have all the feature, but some of it. There will be documentation. Beta - All the features are completed, but possible bugs. Gamma - no known crash or corruption bugs.

QA - internal testers, smoketests, and stability testing. External testers hired to hammer it. And Community of course, who do better than anything else.

Replication and Backups Features and Future

Todays replication writes out a binlog, reads it back in and sends it to the slave. Slave reads it and inserts it.

5.1 introduces multiple sources - all the masters push onto one slave. Then, write a view that pulls replicated data together. Fancy. THis also makes automated star clusters possible.

Replacing the vulnerable masterinfo file with a table in the mysql database

Grid clustering too - score! Make all servers aware of each other and have one big giant writing cluster. This still requires setting an offset on your autoincrements and primary keys, though

5.1 implements full-on transaction must be committed across all hosts.

Row based replication too - don't quite understand what this does.

5.1 allows storage engines to push entries up to the server binlog so that you can failover masters.

better control of slaves and masters, stopping broken things, etc. You can command slaves to stop at all the exact same point, and switch to a new master. Also, elections and self-healing clusters, these are in 5.2.

5.1 introduces mysqlbackup, which is strictly online. Universal, backs up every storage engine. Scriptable, gui-able. Choose which databases/tables

Disaster Recovery with MySQL

Do practice recoveries! how can you know otherwise?

Pay close attention to available space.

SQL dumps are cumbersome for lots of data, must lock the databases. This is true for copying the files too. SQL dumps, though can recover individual rows easily.

use mysqlbinlog to pull certain sets of info out of a binlog, for recovering to particular points in time.

Lots of info here on dealing with stack traces and core dumps.

The real point of this was "practice your backups"

Real World Scalability

most important - think horizontal

benchmark with very slow clients, because transferring data uses up the child's time. Also, pay attention to how many not now fast. Use loads that are realistic

Vertical scaling: bigger servers. This is too expensive, and not as effective anyway

Never have "the server" for any purpose. Make sure anything can run on more than one server.

Strong reccomendation to denormailze lots of data for quick lookups.