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: , , , ,

Related posts:

  1. MySQL synchronous replication in practice with Galera by Oli Sennhauser
  2. Building simple & complex replication clusters with Tungsten Replicator by Giuseppe Maxia
  3. MySQL HA reloaded by Ivan Zoratti
  4. Replication features of 2011 by Sergey Petrunia
  5. New MySQL 5.6 Features by Oli Sennhauser