Distributed MySQL with Vitess

Ubiquitous

Made for the Cloud

Applications designed for the cloud today generally trigger certain expectations on the part of the user community. One assumption, for example, is that cloud-ready applications offer extensive interfaces out of the box for debugging and, more specifically, for analyzing performance. Vitess is no exception, and the developers of the software deliver. Vitess keeps elaborate records of practically everything it does at runtime, and it offers the possibility of parsing the data over standardized interfaces, which then benefits services such as Prometheus (Figure 4), for which Vitess even provides a native interface out of the box.

Figure 4: MySQL can only be integrated into Prometheus with its own exporter, as shown in this example. Vitess, on the other hand, comes with its own interface for Prometheus along with a dashboard for Grafana.© Percona

The service's data collection capability is not limited to individual applications like VTGate. Extensive metrics data also can be squeezed out of the individual VTTablets, allowing for classic event monitoring in addition to comprehensive performance monitoring. From the administrator's point of view, the most important thing is to find a healthy monitoring balance – precisely because Vitess is implicitly redundant and offers certain self-healing capabilities. It no longer seems appropriate to drag the administrator out of bed at 3:00am on Saturday because a MySQL instance in a cluster of 20 Vitess nodes has died. Vitess will eventually recover all missing replicas of shards automatically, and in a short time, within the set recovery values.

However, the situation is different for central components: If a load balancer upstream of several VTGate instances fails, access to the database will eventually fail, triggering the need for manual intervention by the administrator.

Performance monitoring is likely to be almost more useful than event monitoring for Vitess admins in everyday life. After all, databases play a central role in many setups, with their performance regularly tipping the scales for the overall performance of an environment. This performance can be meticulously monitored down to the level of individual queries by reference to the logged metrics data. Vitess can do far more than MySQL, for example, out of the box.

Conclusions

The idea of re-implementing a part of MySQL on the basis of a different architecture understandably triggers skepticism among many, and particularly so with Vitess because the solution ultimately still needs a real MySQL instance in the background, acting as a back end for the VTTablet services.

Any doubts, however, are completely blown away on closer inspection. Unlike first-generation database replication solutions such as Galera, Vitess takes a far more comprehensive approach that translates to better performance, stronger redundancy, greater visibility of the details (e.g., in performance monitoring), and a far more pleasant user experience, all told.

Vitess as a state-of-the-art solution naturally also offers perfect Kubernetes integration and can be rolled out directly in a cluster with the Kubernetes Helm package manager, for example (Figure 5). In any case, anyone looking for a scalable database for the cloud should have Vitess on their radar.