Last month I performed a review of the Percona Operator for MySQL Server which is still Alpha.  That operator is based on Percona Server for MySQL and uses standard asynchronous replication, with the option to activate semi-synchronous replication to gain higher levels of data consistency between nodes. 

The whole solution is composed as:

Additionally, Orchestrator (https://github.com/openark/orchestrator) is used to manage the topology and the settings to enable on the replica nodes, the semi-synchronous flag if required. While we have not too much to say when using standard Asynchronous replication, I want to write a few words on the needs …

The Vitess maintainers are pleased to announce the general availability of Vitess 13. Major Themes # In this release, Vitess maintainers have made significant progress in several areas, including query serving and cluster management. Compatibility # This release comes with major compatibility improvements. We added support for a large number of character sets and improved our evaluation engine to perform more evaluations at the VTGate level. Gen4 planner is no longer experimental and we have used it to add support for a number of previously unsupported complex queries.

The Vitess maintainers are pleased to announce the general availability of Vitess 13. Major Themes # In this release, Vitess maintainers have made significant progress in several areas, including query serving and cluster management. Compatibility # This release comes with major compatibility improvements. We added support for a large number of character sets and improved our evaluation engine to perform more evaluations at the VTGate level. Gen4 planner is no longer experimental and we have used it to add support for a number of previously unsupported complex queries.

We have a quickstart guide for how to install Percona Distribution for MySQL Operator on minikube. Installing the minimal version works well as it is described in the guide. After that, we will have one HAproxy and one Percona XtraDB Cluster (PXC) node to work with.

Minikube provides Kubernetes locally. One can try using the provided local k8s to try the more advanced scenarios such as the one described here.

Following that guide, everything works well, until we get to the part of deploying a cluster with

deploy/cr.yaml

Even after that, things seemingly work.

$ kubectl get pods
NAME READY STATUS RESTARTS …

On behalf of the Vitess maintainers, I am pleased to announce the general availability of Vitess 12. Major Themes # In this release, Vitess Maintainers have made significant progress in several areas, including Gen4 planner, VTAdmin, and other improvements. Please take a moment to review the Release Notes. Please read them carefully and report any issues via GitHub. Gen4 Planner # The newest version of the query planner, Gen4, becomes an experimental feature as part of this release.

There are plenty of ways to run ProxySQL in Kubernetes (K8S). For example, we can deploy sidecar containers on the application pods, or run a dedicated ProxySQL service with its own pods.

We are going to discuss the latter approach, which is more likely to be used when dealing with a large number of application pods. Remember each ProxySQL instance runs a number of checks against the database backends. These checks monitor things like server-status and replication lag. Having too many proxies can cause significant overhead.

Creating a Cluster

For the purpose of this example, I am going to deploy a test cluster in GKE. We need to follow these steps:

1. Create a cluster

gcloud container clusters create ivan-cluster --preemptible --project my-project --zone us-central1-c --machine-type n2-standard-4 --num-nodes=3

2. Configure command-line access

gcloud …

On behalf of the Vitess maintainers, I am pleased to announce the general availability of Vitess 11. Major Themes # In this release, Vitess Maintainers have made significant progress in several areas, including Benchmarking, VTAdmin, Schema Tracking, Online DDL, and Performance improvements. While Schema Tracking is experimental, we’re very excited to have Gen4 planner evolving as well. Please take a moment to review the Release Notes. Please read them carefully and report any issues via GitHub.

The practice of running databases in containers continues to grow in popularity.  As a Technical Account Manager at Percona, I get asked regularly about our Percona Distribution for MySQL Operator.  Additionally, I’m asked what I’m seeing in the industry in terms of adoption.  In most cases, the questions stem around new deployments.  Our DBaaS tool (currently in Technical Preview) makes launching a new cluster in a Kubernetes deployment trivial.  

Once the operator completes and verifies the setup, the UI displays the endpoint and credentials and you are on your way.  Voila!  You now have a cluster, behind a load balancer, that you can access from within your k8s cluster or …

In the previous release of our Percona Distribution for MySQL Operator, we implemented one interesting feature, which can be seen as “self-healing”: https://jira.percona.com/browse/K8SPXC-564.

I do not think it got enough attention, so I want to write more about this.

As it is well known, a 3-node cluster can survive a crash of one node (or pod, in Kubernetes terminology), and this case is very well handled by itself. However, if there is a problem with 2 nodes at the same time, this scenario is problematic for Percona XtraDB Cluster. Let’s see why this is a problem.

First, let’s review if the first node goes offline:

In this case, the cluster can continue work, because Node 1 and Node 2 figure out …

On behalf of the Vitess maintainers, I am pleased to announce the general availability of Vitess 10. Major Themes # In this release, Vitess Maintainers have continued to focus on compatibility. It is still the most critical component of Vitess being part of the MySQL ecosystem. We have also started working on benchmarking and performance optimizations. These improvements have given us a clear vision of which areas of Vitess can be improved in terms of performance.