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.

1. Ulf Wendel, Oracle PECL/mysqlnd_ms 1.2, 2011 Load Balancing for PHP and MySQL

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 php.net 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.

4. Single DBMS is hard to scale The load balancing challenge MySQL Server Internet

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.

7. MySQL Cluster: read and write scale-out, 99.999%

8. MySQL 3 rd party: leveraging MySQL technology Use a MySQL Cluster MySQL Node MySQL Node MySQL Node DBMS Connection Load Balancing

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?

11. No fault tolerance: node failure = stack failure

12. Inefficient resource usage: no balancing Whole stack cluster MySQL Node MySQL Node MySQL Node

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.

15. MySQL node failure does not stop application server

16. Good resource usage, dynamic adoption possible Proxy approach - Pro MySQL Node MySQL Node MySQL Node

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.

19. C and Lua are no natural match for PHP lovers

20. Adds latency: from client to proxy to node Proxy approach - Con MySQL Node MySQL Node MySQL Node

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.

23. No additional latency

24. Highly configurable and adaptive Client-side load balancer - Pro MySQL Node MySQL Node MySQL Node

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.

27. No drop-in solution for existing applications

28. PHP is stateless: adaptive load balancing is difficult Client-side load balancer - Con MySQL Node MySQL Node MySQL Node

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.

31. Synchronous cluster: no application changes

32. Asynchronous cluster: no change for basic cases Is driver based the solution? MySQL Node MySQL Node MySQL Node

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.

35. Read-write splitting edge-cases: may need hints PECL/mysqlnd_ms - Con MySQL Node MySQL Node MySQL Node

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.

38. Mostly transparent drop-in solution

39. Load Balancing and Fail over

40. Read-write splitting

41. Service (consistency) levels

42. User can control all automatic actions

43. 70+ pages documentation: hands on and reference

44. Stable, more test code than C code in the plugin

45. Dear Java users, MySQL Connnector/J can ... Summary - PECL/mysqlnd_ms

46. THE END Credits: Andrey Hristov - Contact: ulf.wendel@oracle.com