Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Scaling to Meet Application Demand

499 views

Published on

Building Databases for Multi-Tenant Applications - Large scale applications require sharding to keep up with increased traffic. The simplest and most flexible way to shard is at the schema level. This talk will explain the basics of Tungsten Replicator, installing bi-directional replication between database servers, options for global deployment and best practices when you start sharding. For more information on Tungsen Replicator, visit http://code.google.com/p/tungsten-replicator/.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Scaling to Meet Application Demand

  1. 1. Scaling to Meet Application Demand Jeff Mace©Continuent 2012
  2. 2. Agenda • MySQL vs Tungsten Replication • Simple Replication with demo • Advanced Replication • Best Practices©Continuent 2012 2
  3. 3. Tungsten Replication • Compatible with MySQL 5.0+ • Compatible with most MySQL branches • Crash safe if you use InnoDB • Replicate between different versions • Replicate from multiple masters into one server • Filter replication traffic in real time©Continuent 2012 3
  4. 4. MySQL Replication Master DB Binary Log Relay Log SQL Slave DB Tungsten Replication Binary Log Extractor Transactio Transactio Applier n History n History Master DB Slave DB©Continuent 2012 4
  5. 5. I have a great idea for a website! • Rapid prototype ha-proxy • Load-balanced web servers • Single database server • Single schema design Master DB©Continuent 2012 5
  6. 6. But what if something goes wrong? • Stand-by slave ha-proxy • Can write to it if the first server fails • Extremely difficult to restore the primary master Master DB Slave DB©Continuent 2012 6
  7. 7. Simplifying the restore process • Replication position ha-proxy automatically saved in backups • Ensure all writes have been made on the slave before switching to it Master DB Standby Master©Continuent 2012 7
  8. 8. Installation - db1 tools/tungsten-installer --master-slave --home-directory=/opt/continuent --hosts=db1 --master-host=db1 --service-name=alpha ... /opt/continuent/tungsten/tools/configure-service -C --role=slave --master-thl-host=db2 --datasource=db1 --service-type=remote©Continuent 2012 8
  9. 9. Installation - db2 tools/tungsten-installer --master-slave --home-directory=/opt/continuent --hosts=db2 --master-host=db2 --service-name=bravo ... /opt/continuent/tungsten/tools/configure-service -C --role=slave --master-thl-host=db1 --datasource=db2 --service-type=remote©Continuent 2012 9
  10. 10. Demo©Continuent 2012 10
  11. 11. I need more than two servers Master DB Master DB What if this link fails? Master DB©Continuent 2012 11
  12. 12. The safer way to add servers all-masters star-schema©Continuent 2012 12
  13. 13. How do I avoid conflicting updates? • Writes to many servers can cause conflicts • Identify a master server for each schema • All updates are made to that server • Replication propagates the changes to remaining servers • Reads must be made from the master server©Continuent 2012 13
  14. 14. Supporting Application Growth • Optimize MySQL • Utilize replicas for read-scaling • Implement sharding for write-scaling • Plan for failover • Monitor everything©Continuent 2012 14
  15. 15. Planning for Sharded Databases • Build your application to be shard-aware • Don’t use foreign keys that cross schemas • Minimize DML statements that use multiple schemas • Set the schema via the ‘use’ command • Build a fan-in server for reporting©Continuent 2012 15
  16. 16. Fan-In Replication©Continuent 2012 16
  17. 17. Identifying Shards • Find a logical, or convenient, boundary between groups of users • Balance individual shard size with the overall number of shards • If necessary, utilize a single schema to assign a shard ID to each user • Alphabetic distribution is not guaranteed to be even©Continuent 2012 17
  18. 18. From Replication to Managing Data • Tungsten Replicator moves data • It does not ensure databases are: • Protected from failures • Easy to administer • Fully utilized • To manage data you need cluster management©Continuent 2012 18
  19. 19. What did we learn? • Replication is important to ensure availability • Some topologies over greater stability • Sharding provides the flexibility to implement many replication topologies • Growth is supported by proper planning©Continuent 2012 19
  20. 20. Jeff Mace jeff.mace@continuent.com 560 S. Winchester Blvd. Suite 500 San Jose, CA 95128 Tel (866) 998-3642 Fax (408) 668-1009 http://www.continuent.com http://code.google.com/p/tungsten-replicator©Continuent 2012 20

×