{"id":562,"date":"2007-06-05T00:07:52","date_gmt":"2007-06-05T05:07:52","guid":{"rendered":"http:\/\/www.bytebot.net\/blog\/archives\/2007\/06\/05\/ticketmaster-thrives-on-mysql-replication"},"modified":"2007-06-05T00:07:55","modified_gmt":"2007-06-05T05:07:55","slug":"ticketmaster-thrives-on-mysql-replication","status":"publish","type":"post","link":"http:\/\/www.bytebot.net\/blog\/archives\/2007\/06\/05\/ticketmaster-thrives-on-mysql-replication","title":{"rendered":"Ticketmaster thrives on MySQL Replication"},"content":{"rendered":"

Even though the conference<\/a> 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!<\/a> They are as always, pretty raw.<\/p>\n

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”.<\/p>\n

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<\/i>, and 17,843 seat tickets were sold in 75 seconds!<\/p>\n

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<\/a>.<\/p>\n

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!<\/p>\n

MyISAM tables for full-text searching (InnoDB doesn’t do this yet) and LiveDaily<\/a>. Using vBulletin, MyISAM performs better too.<\/p>\n

One-way replication is very fast. No\/minimal performance hit on MySQL master. Its real<\/b> 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.<\/p>\n

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.<\/p>\n

innodb_flush_log_at_trx_commit=0<\/tt> – 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.<\/p>\n

Technorati Tags: mysql<\/a>, mysqlconf<\/a>, mysqlconf07<\/a>, ticketmaster<\/a>, replication<\/a><\/p>\n

Share this:<\/h3>