Quite recently ProxySQL has changed the way it names new releases. To avoid confusion we’d like to go over it a bit. In the past, we had two branches: 1.4.x and 2.0.x where new features were added mostly to 2.0 and 1.4 was the old stable release. Now the way the naming works is major.minor.patch, so 2 is the major version and currently we have 2.2.0 as the current stable release. Let’s take a look at what the recent (as in couple of months) releases brought us.
ProxySQL 2.1.x
ProxySQL 2.1.0 was a major release when it comes to features added to it. The main one, definitely, is an introduction of integral Prometheus exporters, which means that there is no need anymore to use external scripts to scrap ProxySQL metrics and push them to the time-series database. Those metrics can be used with any external tool although a Grafana dashboard maintained by the ProxySQL team is available for use, ensuring that you will have all the most important metrics available.
Further changes were made to the ProxySQL cluster, a feature that makes it possible to cluster several ProxySQL instances and keep them in sync regarding the configuration. This is quite an important feature for any large-scale deployment as keeping tens of ProxySQL nodes in sync may be quite difficult otherwise. More metrics are now synced across the cluster, it is also possible to now to use SSL for the intra-cluster communication, ensuring that the data distributed across the cluster is properly encrypted and shielded from any kind of network sniffing.
On top of that, multiple improvements and optimizations were added, reducing the memory footprint and improving the performance of ProxySQL.
ProxySQL 2.1.1 is a patch release but it also comes with some new, fresh features. One of them is the improvement in dealing with prepared statements, where up to this point results had to be received by ProxySQL in one go. Starting from ProxySQL 2.1.1 those results can be buffered on the proxy’s side.
Additional change related to prepared statements, which ProxySQL 2.1.0 has introduced, is the routing. Prepared statements consist of two parts - prepare, where the statement is prepared, and execute, when it is actually executed. In the previous ProxySQL versions the target server was determined based on the PREPARE statement. It was routed to one of the backend servers and that server was also used to EXECUTE the statement. Starting from 2.1.0 ProxySQL will also route EXECUTE as per the query rules.
ProxySQL 2.2.x
ProxySQL 2.2.0 is the most recent version of ProxySQL at the time when this blog was being written. It is a minor release in the 2.x branch. It consists mostly of bug fixes but it also further improves prepared statements handling. To be precise, it adds support to process query annotations in prepared statements. Query annotations are the comments within the query:
SELECT /* Some text that is useful for some reason */ some_column FROM some_table;
which can be used to tag it or pass some information to the client or to a load balancer that can parse MySQL protocol. Such annotations may as well be used to pass index hints to the MySQL.
It is great to see ProxySQL developing. ClusterControl uses ProxySQL as one of the supported load balancers to enable our customers to build highly available and scalable architectures for their database clusters. For ProxySQL ClusterControl comes with full management over the dedicated UI, including adding new servers, importing users, deploying new ProxySQL instances and much more. If you would like to give ProxySQL a try using ClusterControl, you can download a trial version of ClusterControl directly from the Severalnines website. The trial license will allow you to use all of the features ClusterControl comes with, including database management, deployment, scaling, high availability, backups, monitoring and many more.