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.

Load Balancing for PHP and MySQL


Published on

Anybody stepping up from a single MySQL server to any kind of cluster made of MySQL servers (MySQL Cluster, MySQL Replication, home-grown sharding and 3rd party) has to load balance connections. Different approaches are compared to the free and open source PECL mysqlnd_ms PHP mysql plugin: application based, proxy based and driver based. It turns out that a driver based solution makes a very good system architecture. Its fault tolerant, it scales well, it requires no or little application changes and its a natural fit for PHP deployments. And, of course, it works with all PHP MySQL applications running on PHP 5.3 or newer using any of the three PHP MySQL APIs (mysql, mysqli, PDO_MySQL). Check it out.... in the slides and download PECL mysqlnd_ms for a test drive. Even if you don't go for PECL mysqlnd_ms this presentation is helpful as it gives hints on choosing an architecture.

Published in: Technology
  • Be the first to comment

Load Balancing for PHP and MySQL

  1. 1. Ulf Wendel, Oracle PECL/mysqlnd_ms 1.2, 2011 Load Balancing for PHP and MySQL
  2. 2. The speaker says... PECL/mysqlnd_ms is a free and open source plugin for the mysqlnd library. It makes using any kind of MySQL cluster easier. Among others, if offers read-write splitting, load balancing, fail over and service levels. The mysqlnd library ships with PHP as of PHP 5.3. It is a drop-in replacement for the MySQL Client Library (libmysql). Mysqlnd is the default on all platforms since PHP 5.4. All PHP MySQL extensions/APIs can be compiled to use mysqlnd. PECL/mysqlnd_ms is a mostly transparent mysqlnd plugin.
  3. 3. <ul><li>Database load balancing </li></ul><ul><ul><li>Single DBMS is a single point of failure
  4. 4. Single DBMS is hard to scale </li></ul></ul>The load balancing challenge MySQL Server Internet
  5. 5. The speaker says... A single DBMS has no load balancing challenge. But, using a single DBMS is a second best solution. A DBMS failure interrupts service. Scaling vertically by growing hardware capacity has its limits. Use of commodity hardware is not possible. Elastic-fantastic is nothing but a dream for peak loads. Use a cluster, face the load balancing challenge, let MySQL help you with the additional task.
  6. 6. <ul><li>Cluster for scalability and availability </li></ul><ul><ul><li>MySQL Replication: read scale-out
  7. 7. MySQL Cluster: read and write scale-out, 99.999%
  8. 8. MySQL 3 rd party: leveraging MySQL technology </li></ul></ul>Use a MySQL Cluster MySQL Node MySQL Node MySQL Node DBMS Connection Load Balancing
  9. 9. The speaker says... MySQL users are offered a wide range of scale-out solutions to choose from. Including 3 rd party vendors which have discovered the potential of MySQL technology. MySQL Replication drives the web. It stands for asynchronous read scale-out. Node failover recently became easier with client-side global transaction emulation in PECL mysqlnd_ms 1.2 and upcoming server support in MySQL 5.6.4. MySQL Cluster gives 99.999% availability to anybody in need for read and write scale-out. On commodity hardware, of course. Synchronous, of course. Of course, you'll try, won't you?
  10. 10. <ul><li>Simple – 1:1 mapping! </li></ul><ul><ul><li>Requires synchronous cluster
  11. 11. No fault tolerance: node failure = stack failure
  12. 12. Inefficient resource usage: no balancing </li></ul></ul>Whole stack cluster MySQL Node MySQL Node MySQL Node
  13. 13. The speaker says... In a synchronous cluster, for example, if using MySQL Cluster, all nodes have all the data. Thus, every application server could be assigned to one DBMS node. Easy, fast and good for MySQL Cluster but with limits. No good for asynchronous MySQL Replication. Limit: DBMS node failure includes application node failure. Client should have additional fail over logic. Limit: Over- and undercapacity of a DBMS node cannot be compensated. Clients cannot switch to more powerful nodes. Overcapacity of a MySQL node cannot be used by other clients. Different hardware size is ignored.
  14. 14. <ul><li>Free and open source MySQL Proxy </li></ul><ul><ul><li>No application changes, free 3 rd party proxy scripts
  15. 15. MySQL node failure does not stop application server
  16. 16. Good resource usage, dynamic adoption possible </li></ul></ul>Proxy approach - Pro MySQL Node MySQL Node MySQL Node
  17. 17. The speaker says... A transparent MySQL Proxy based solution requires no application changes. Clients connect to the Proxy using MySQL Client Server Protocol, as if the MySQL Proxy was a MySQL Server. Proxy can compensate for DBMS failures. It can react to temporary and permant outages. Proxy can adapt load balancing dynamically. Taking into account node hardware size, current node load, latency, location, … fantasy sets the limits here for self-written or 3 rd party Proxy scripts.
  18. 18. <ul><li>Additional component </li></ul><ul><ul><li>Complex architecture, can be single point of failure
  19. 19. C and Lua are no natural match for PHP lovers
  20. 20. Adds latency: from client to proxy to node </li></ul></ul>Proxy approach - Con MySQL Node MySQL Node MySQL Node
  21. 21. The speaker says... MySQL Proxy is a great performer! But, … MySQL Proxy adds complexity to the stack. MySQL Proxy needs to be managed. MySQL Proxy is build around C and Lua. C and PHP would be a better match for PHP users. Wrongly used, MySQL Proxy becomes a single point of failure. It is single threaded. This bares the risk of tasks (Proxy scripts) blocking each other. But, … MySQL Proxy adds latency. Although, it can be minimized significantly running MySQL Proxy on the App Server to avoid use of TCP/IP between PHP and Proxy.
  22. 22. <ul><li>Client application handles load balancing </li></ul><ul><ul><li>No single point of failure
  23. 23. No additional latency
  24. 24. Highly configurable and adaptive </li></ul></ul>Client-side load balancer - Pro MySQL Node MySQL Node MySQL Node
  25. 25. The speaker says... A client-side approach to the problem is promising, if client applications can be changed. It has most Pro's of the previous approaches. The load balancer is part of the client application. It scales by client and it fails by client. Scalability is given and there is no single point of failure. No additional latency occurs. Load balancing can be adaptive for good resource usage. DBMS node failures do not block clients, fail over is possible.
  26. 26. <ul><li>Client application handles load balancing </li></ul><ul><ul><li>Application must be designed for cluster user
  27. 27. No drop-in solution for existing applications
  28. 28. PHP is stateless: adaptive load balancing is difficult </li></ul></ul>Client-side load balancer - Con MySQL Node MySQL Node MySQL Node
  29. 29. The speaker says... The major downside of a client-side application based solution is the need to change the application. Application changes must be done even for basic cluster use cases. Modifications to source code may not be possible. They may complicate upgrades of standard software. They may cause lots of work thus become expensive. Load balancing is part of PHP thus stateless. This is both a Pro and a Con. It is difficult to hint other clients about node failures. On the other hand, shared nothing is not a bad idea either.
  30. 30. <ul><li>Client-side and driver based: PECL/mysqlnd_ms </li></ul><ul><ul><li>Pro: all previous
  31. 31. Synchronous cluster: no application changes
  32. 32. Asynchronous cluster: no change for basic cases </li></ul></ul>Is driver based the solution? MySQL Node MySQL Node MySQL Node
  33. 33. The speaker says... A driver based client-side solution has all Pro's! Considering load balancing aspect only, no application changes are required. If using MySQL Cluster, a synchronous cluster, no application changes are required. If using MySQL Replication, an asynchronous cluster that needs read-write splitting, the need for application changes is significantly reduced! The PECL mysqlnd_ms installation can be part of the next PHP deployment, done anyway for security considerations. No new procedure. If any issues, simply disable extension.
  34. 34. <ul><li>Client may need to hint Load Balancer </li></ul><ul><ul><li>Transaction boundaries: only API monitored
  35. 35. Read-write splitting edge-cases: may need hints </li></ul></ul>PECL/mysqlnd_ms - Con MySQL Node MySQL Node MySQL Node
  36. 36. The speaker says... PECL/mysqlnd_ms cannot solve all MySQL Replication and MySQL Protocol shortcomings. Load balancing must be disabled during transactions. The start and end of a transaction are detected monitoring API calls. SQL is not monitored. The MySQL Protocol is no help, applications must be careful, eventually hint PECL/mysqlnd_ms. Connections have a state. Read-write splitting can trigger node switches, applications must hint the plugin, if stateful connections are used.
  37. 37. <ul><li>Continiously evolving... </li></ul><ul><ul><li>Works with all PHP MySQL extensions
  38. 38. Mostly transparent drop-in solution
  39. 39. Load Balancing and Fail over
  40. 40. Read-write splitting
  41. 41. Service (consistency) levels
  42. 42. User can control all automatic actions
  43. 43. 70+ pages documentation: hands on and reference
  44. 44. Stable, more test code than C code in the plugin
  45. 45. Dear Java users, MySQL Connnector/J can ... </li></ul></ul>Summary - PECL/mysqlnd_ms
  46. 46. THE END Credits: Andrey Hristov - Contact: