Download
emmanuel cecchet inria julie marguerite objectweb willy zwaenepoel epfl n.
Skip this Video
Loading SlideShow in 5 Seconds..
: Flexible Database Clustering Middleware PowerPoint Presentation
Download Presentation
: Flexible Database Clustering Middleware

: Flexible Database Clustering Middleware

116 Views Download Presentation
Download Presentation

: Flexible Database Clustering Middleware

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Emmanuel Cecchet – INRIA Julie Marguerite – ObjectWeb Willy Zwaenepoel – EPFL : FlexibleDatabase Clustering Middleware

  2. JDBC JDBC Motivations • Database tier should be • scalable • highly available • without modifying the client application • database vendor independent • on commodity hardware JDBC Internet

  3. Scaling the database tier – Alternative 1 (master-slave) • Cons • failover time on master failure • scalability App. server Master Web frontend Internet

  4. Database Well-known database vendor here Well-known hardware + database vendors here Scaling the database tier – Alternative 2 (SMP) • Cons • Cost • Scalability limit App. server Web frontend Internet

  5. Scaling the database tier – Alternative 3 (shared disks) • Cons • still expensive hardware • availability App. server Disks Database Web frontend Internet Another well-known database vendor

  6. Outline • C-JDBC architecture • High availability • Use cases • Conclusion

  7. C-JDBC controller MySQL database C-JDBC JDBC driver MySQL JDBC driver JVM architectural overview Application server JVM JVM

  8. basic concepts • 2 components • C-JDBC driver • C-JDBC controller • 100% Java implementation • Read-one, Write all approach • Tunable replication • full partitioning • full replication • partial replication JVM

  9. connectmyDB connectlogin, password executeSELECT * FROM t Functional overview

  10. executeINSERT INTO t … Functional overview

  11. Outline • C-JDBC architecture • High availability • Use cases • Conclusion

  12. Failures • No 2 phase-commit • parallel transactions • failed nodes are automatically disabled executeINSERT INTO t …

  13. Restoring a backend • Updates stored in the recovery log • Database dumps associated to checkpoints

  14. Synchronization • Replay missing updates from log

  15. Healed Cluster • Re-enable backend when done

  16. Vertical scalability • Addresses JVM scalability issues • Distributing large number of connections on many backends

  17. Controller replication • Prevent the controller from being a single point of failure • Group communication for controller synchronization

  18. jdbc:cjdbc://node1,node2/myDB Total order reliable multicast Controller replication

  19. Mixing horizontal & vertical scalability

  20. Current limitations • Replication granularity is table • No distributed joins • Network partition with replicated controllers • JDBC only • support of PHP, Perl, ODBC through wrappers or bridges • partial support of JDBC 3.0

  21. Other features • SSL support • Support for heterogeneous databases • SQL monitoring • JMX based administration console • Request player

  22. Outline • C-JDBC architecture • High availability • Use cases • Conclusion

  23. Budget High Availability • High availability infrastructure “on a budget” • Typical eCommercesetup • http://www.budget-ha.com

  24. OpenUSS: University Support System • eLearning • High availability • Portability • Linux, HP-UX, Windows • InterBase, Firebird, PostgreSQL, HypersonicSQL • http://openuss.sourceforge.net

  25. Flood alert system • Disaster recovery • Independent nodes synchronized with C-JDBC • VPN for security issues • http://floodalert.org

  26. Internet emulated users J2EE benchmarking • Large scaleJ2EE clusters • http://jmob.objectweb.org

  27. Outline • C-JDBC architecture • High availability • Use cases • Conclusion

  28. Conclusion • C-JDBC: Flexible Database Clustering Middleware • scalable • highly available • without modifying the client application • database vendor neutral • on commodity hardware • LPGL software hosted by ObjectWeb

  29. Q&A_________Thanks to all users and contributors ... http://c-jdbc.objectweb.org

  30. TPC-W benchmark(Amazon.com) • Nearly linear speedups with the shopping mix

  31. Result cache • Cache contains a list of SQL->ResultSet • Policy defined by queryPattern->Policy • 3 policies • EagerCaching: variable granularities for invalidations • RelaxedCaching: invalidations based on timeout • NoCaching: never cached

  32. Recovery log • All updates are stored in the recovery log • Database dumps associated to checkpoints

  33. Making new checkpoints • Disable one backend to have a coherent snapshot • Mark the new checkpoint entry in the log • Use Octopus to store the dump

  34. Making new checkpoints • Replay missing updates from log

  35. Making new checkpoints • Re-enable backend when done

  36. Handling a backend failure • A node fails! • Automatically disabled but should be fixed or changed by administrator

  37. Fault tolerant recovery log UPDATE statement