我的书签
添加书签
移除书签ProxySQL has been built with a few key design choices in mind.
Maximum uptime
Since ProxySQL is a proxy, it's expected to be up there as close to 100% ofthe time as possible. This means that we should be handling differently theusual suspects when it comes to downtime:
- configuration changes. This is usually done by changing the configurationfile and restarting the daemon. In ProxySQL, by design, the user is able tomodify most configuration variables through the admin interface, withouthaving to restart the server. Example things that can be modified at runtime:
- interfaces on which ProxySQL is listening
- backend servers to which ProxySQL is connecting
- timeouts for the different operations performed by ProxySQL
- crashes. ProxySQL has an extensive suite of integration tests that areran using Docker, to ensure that it does not crash. Also, each major releaseis performance-tested using sysbench, and memory-leak tested using valgrind.In addition to this, an angel process has been implemented that monitors andrestarts ProxySQL when needed, in order to keep downtimes to a minimum, if theyend up occuring.
Maximum scalability
There are several key scenarios that we wanted to run as fast as possible wheninteracting with ProxySQL:
- time to complete a new MySQL connection to it: this is why ProxySQL has apool of threads all waiting via the system call
accept()to receive a newconnection. Because of this, the probability of the new TCP connection of beingestablished faster is increased - time to connect to a MySQL backend: this is why ProxySQL has a backendconnection pool in which it keeps some idle connections alive to the backendservers, according to the configuration. When it needs to send a packet tothose servers, most of the time the connection is already open
- multi-core scalability: ProxySQL has a multi-threaded design where all threadsdo the same thing (marshal messages back and forth between the backend serversand the MySQL client connections), and our tests show that it scales very wellwith the number of cores.
Cascade possibilities
ProxySQL can be cascaded to as many layers as required. For example, one commonscenario is to have a ProxySQL instance as close to the servers running theapplication as possible, pointing to another middle layer cluster of ProxySQLservers that routes all traffic to a farm of backend MySQL servers.
A -> P1 ——-> {P2, P3, P4 ..} ———> {B1, B2, B3, ..}
The advantage in this case is that it is completely fault tolerant with respectto the MySQL access, given that the app is not a single point of failure. Thereis no modification needed at the application level for the application toconnect to a cluster of proxies instead of a single one. If any proxy from themiddle layer fails, the P1 proxy will detect that and will route traffic throughthe other ones. If any of the backends B1, B2, B3, … fails, then the middlelayer proxies will take care of the job in a way that is transparent to P1.
