Ticketmaster thrives on MySQL Replication
Even though the conference is long over, I still have unpublished notes sitting on my ~/Desktop, and it only makes sense that I clean it out. These are notes from Ed Presz’s session, titled For Ticketmaster, MySQL Replication is the Ticket! They are as always, pretty raw.
We were all given a handout, which was some corporate spiel, which contained a lot of information about hiring. Their mission is to “sell more tickets better than anyone in the event business, worldwide”.
I found it impressive to note that Ticketmaster managed last year’s Melbourne Commonwealth ticket sales. I guess, even more impressive is that for next year’s Beijing Olympics, Ticketmaster ran a ticket lottery, and 17,843 seat tickets were sold in 75 seconds!
MySQL 4.0.18 is currently used, and they plan to upgrade to MySQL 5.0.27 in 2007 – difference in the join syntax between 4 & 5 was a blocker. Reference was made to mysql#13551.
They use InnoDB, for its row-level locking, referential integrity, transaction support. The average size of the “event” database is ~20GB, with around ~230 tables. Rely heavily on MySQL replication. At any one time there are between 100,000 – 130,000 visible events!
MyISAM tables for full-text searching (InnoDB doesn’t do this yet) and LiveDaily. Using vBulletin, MyISAM performs better too.
One-way replication is very fast. No/minimal performance hit on MySQL master. Its real easy to add slaves. Dual masters, a farm of slaves (4) [cluster], then 4 more slaves of those slaves. Then they send all traffic to the lower level slaves.
Think through your architecture, since there is no multi-master replication. A slave can only have one master. Setup two instances of MySQL on MySQL_Server_1 listening on different ports (but this is not what they use). They use Bi-Directional replication (multi-master, circular, dual-master). Replicating from the UK to the US. They use UTF-8 and UTC time on the servers.
innodb_flush_log_at_trx_commit=0 – resulted in huge performance improvement with MySQL replication. However its not writing to disk at each commit, so you can lose 1 second of insert/update/delete values in the event of a crash. Mitigated the risk because there are so many slaves.
Technorati Tags: mysql, mysqlconf, mysqlconf07, ticketmaster, replication
