

Diary of a Paranoid MySQL Upgrade - 250GB database to 5.x - whalesalad
https://blogs.secondlife.com/community/technology/blog/2010/01/11/diary-of-a-paranoid-mysql-upgrade

======
ajross
Interesting enough. But honestly all I took away from it was that Second Life
(all of it?!) fits on a laptop drive.

Storage estimation is a mind bender in the modern world.

------
skorgu
> We also used the maatkit tools to verify replication integrity. I hooked up
> a 5.0.84 slave to a 4.1 master, replayed 24 hours worth of logs, and ran mk-
> table-checksum/mk-table-sync on the whole thing as a consistency check.
> _Unfortunately, the consistency check showed that the slave and master had
> slightly inconsistent data after only a few hours. Doubly-unfortunately,
> these inconsistencies were not unique to the test scenario; we also see them
> in replication between 4.1- >4.1, 4.1->5.0, and 5.0->5.0._ This is probably
> a topic for another blog post; for now, suffice it to say, I verified that
> the upgrade was not going to introduce any _new_ bugs, and left it alone.a1

Emph. mine.

~~~
seiji
That's mysql "replication" for you. Sure it'll send data back and forth, but
it does not guarantee your database replica pairs have the same data.

------
slackerIII
I wonder if dropping in a few SSDs would have fixed all their perf problems
without having to spend that much time investigating it.

~~~
Confusion
What makes you think their DAS doesn't contain SSD's?

------
gaius
_this time, we needed to know for damn sure that our shiny new db was as fast
or faster than the older one. Not faster in some abstract sense, but
verifiably faster_ * with our query set *

This is presented as a great insight, but I have here a book, _Scaling Oracle
8i_ by James Morle from a decade ago that covers it, and people were doing
this sort of thing 20 years before that!

So Linden Labs problem #1 is inexperienced DBAs, no wonder they made such a
mess of it.

