If 40,000 tickets for a high-demand concert went on sale at noon today, Ticketmaster could accept all the orders and sell out the venue by 12:03 P.M.
That’s one smooth-running, high-availability box office.
I mentioned in my previous post that Ticketmaster has used SharePlex for master replication of its Oracle databases since 2002. In particular, the company credits the response time and efficient technical support behind SharePlex for helping it avoid lengthy outages and costly revenue loss.
It also takes architectural prowess to maintain the records of 200 million customers worldwide while keeping agile enough to process up to 15,000 tickets per minute. In this post I’ll describe the Oracle-SharePlex replication scheme behind that high availability and high reliability, as outlined by Andrew Yee, Ticketmaster’s database architect.
Master replication
The conventional wisdom is to start out simple and add complexity as you become more familiar with a database replication product. But Ticketmaster knew that it wanted to get to master replication as soon as possible, and the SharePlex Technical Services team gave it a sense of confidence. So from its initial implementation of SharePlex in 2002, it started with a four-way, master-to-master replication scheme (“1” in the image below).
The company’s objective was to make the transactional data in its four data centers highly available and redundant, with the option of scaling. It built a database in each center then replicated among them. The scheme with Oracle and SharePlex allows slaves to have more than one master. It also offers basic or customizable conflict resolution, a priority with multiple masters.
Next (2), Ticketmaster added a reporting server (Slave D) using SharePlex. That let the business run reports on real-time data without affecting transaction databases.
Over time, other groups in the company became interested in the data on the reporting server. Ticketmaster built additional master replication environments (3 and 4) and replicated them into the reporting database using SharePlex.
On-demand webcast: How Ticketmaster Depends on SharePlex for Reliable Database Replication
Ticketmaster uses SharePlex for reporting, database migrations, disaster recovery and database upgrades. SharePlex enables read-write everywhere for high availability, so each of the databases in Ticketmaster’s master replication scheme is processing transactions, not sitting idle as a failover database.
We’ve released an on-demand webcast called How Ticketmaster Depends on SharePlex for Reliable Database Replication, presented by Andrew Yee. Watch it for more insights into Ticketmaster’s architecture, priorities and replication scheme, and look for ideas you can implement in your Oracle environment.
