MySQL Conference & Expo attendees will have the opportunity to enter a drawing for cool prizes by having an expo hall passport brochure stamped at each participating sponsor and exhibitor booth.
Once attendees have obtained all "stamps" they will be entered into the drawing and eligible to win one of several prizes.
…

So you're running dedicated MySQL Linux box with plenty of memory, so the good question arises if you should have swap file enabled or disable it ? I've seen production successfully running on boxes both with and without swap file so it is not the question of you must do it this or that way but rather understanding advantages of both approaches.

I also would like to hear what you do yourself, and why

The rationale behind disabling swap is what there is nothing you want to swap out on such box anyway and if you disable swap file kernel will not swap and possibly will be able to manage memory smarter knowing it does not need to look for pages to swap out or balance memory for reducing a cache or swapping something out.

And indeed if you run with swap disabled you would not have the issue of swapping happening on the box as there is just nowhere to swap.

So what is about enabled …

Over-the-Top Tales from the Trenches.
Motto: Bringing order to the chaos of every day DBA life.

So you have got your nice MySQL Master-Slave replication pair setup. Everything is sweet, then the master dies/restarts or you have a slightly extended network outage.

Your monitoring software (in our case Avail) fires off a page and you are rudely interrupted from reading the Pythian blog.

These real world interruptions, what can I say… it pays the bills.

Anyway being the rounded DBA or enlightened DBA as Babette would say, you are capable of handling any type of database. You log into the machine and check out why the slave threw an error or if your monitoring is slow, why the slave is lagging by 2 hours.

You run SHOW SLAVE STATUS\G

mysql> show slave status \G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event …

Computer Sweden has a couple of nice article on OpenSource, GlassFish and MySQL.

If I were Sun, I would be tempted to have this next MySQL User Conference be the last one, and replace it with the "Open Source Database" conference, and have it be about MySQL, Postgress, JavaDB, and such stuff.

I think Brian is right with his The Death of Replication story.... replication is very useful for many cases, but RDBMS (commercial and FLOSS) have done a fairly dismal job at getting multiple writers to scale decently economically. And modern companies just don't have piles of cash to throw at this, nor does that really scale on the web scene (speed of deployment, etc).

In this context, I'm not sure the new memory based MySQL storage engines coming out are so relevant, they might be fixing the wrong thing in the wrong place. They'll have their place for now, but it's not moving us forward really.

What needs to be fixed is distributed writes. And economically!

Brian Aker writes in his "PostgreSQL to scale to 1 billion users" post:
Backup is irrelevant for those of you who care about this discussion. LVM/ZFS snapshots are the rule of the land.

While I agree with most of Brian's statements in the article, I respectfully disagree with the statement above, especially the bolded part. Copy-on-write snapshots are EVIL for very large databases operating in a high I/O environment and backup, by no means, is entirely irrelevant. Please correct me if I am wrong but it is my understanding that both LVM and ZFS implement copy-on-write snapshots. Backup may be irrelevant for most sites but not for us.

If, however, by "irrelevant" Brian meant that not important in choosing one database over another, I can agree with that. Why? Because no one benchmarks …

I spent my Sunday working on my three presentations that I will be presenting at the upcoming MySQL Conference. About two hours ago, as I was reviewing my stuff, I told my lovely wife that I may talk in my sessions how replication for read scalability no longer makes sense in high traffic environments. I told her, I am probably going to vote in favor of investing in memcached vs read slaves for scaling reads.

Believe it, or not, she hammered me with all sorts of questions. I spent some time answering her questions. I scanned my brain to gather more evidence to support myself including that at work we are moving and staying away from replication as much as possible.

Then, I got busy writing the post about Facebook using MySQL replication to update Memcached. After publishing the post, I checked Planet MySQL and found …

A number of months ago, possibly a year ago, I wrote an internal letter to the MySQL internal discuss list with the title of "The Death of Read Replication". Ever since then I've been getting pinged internally to publish my thoughts on this externally.

Here goes :)

Read replication is going to be in use for many years into the future. There are plenty of reasons to use it, and plenty of setups where it will make sense.

All of the scripting, management daemons, and ease of use scenarios will not solve its problems though, and I am finding that users have either moved away from it, or more often, have reduced their need for it.

A few reasons:
Latency is painful to manage.
Lots of servers means more head count (both disks and in numbers of people to manage it)
In web usage, the rule of thumb is to keep your query number under 7, for this reason you try make more out of …

Faced with the challenge "to figure out a way for memcached servers to replicate data concurrently with the MySQL databases," across the country, Facebook came up with a clever solution of "embedding extra information in to the MySQL replication stream that allows [Facebook] to properly update memcached [servers] in Virginia."

This is very smart! I am curious about how they implemented this. I wonder if by "replication stream" they are just referring to binary logs. The article didn't mention whether they hacked MySQL to do synchronous replication as well, like Google. That would be really neat: synchronous replication that updates memcached.

Synchronous or not, the idea is still uber cool and I would love to see more …