A highly available Vitess cluster requires the following components:
- 2 VTGate Servers
- A redundant Topology Service (i.e. 3 etcd servers)
- 3 MySQL Servers with semi-sync replication enabled
- 3 VTTablet processes
- A Vtctld process
It is common practice to locate the VTTablet process and MySQL Servers on the same host, and Vitess uses the terminology tablet to refer to both. The topology service in Vitess is pluggable, and you can use an existing etcd, ZooKeeper or Consul cluster to reduce the footprint required to deploy Vitess.
For development environments, it is possible to deploy with 1 of each of these components. See
101_initial_cluster.sh from the Run Vitess Locally guide for an example.
Vitess components (excluding the
mysqld server) tend to be CPU-bound processes. They use disk space for storing their logs, but do not store any intermediate results on disk, and tend not to be disk IO bound. It is recommended to allocate 2-4 cores for each VTGate server, and the same number of cores for VTTablet as with
mysqld. If you are provisioning for a new workload, we recommend projecting that
mysqld will require 1 core per 1500 QPS. Workloads with well optimized queries should be able to achieve greater than this.
The memory requirements for VTGate and VTTablet servers will depend on QPS and result size, but a typical rule of thumb is to provision a baseline of 1GB per core.
The impact of network latency can be a major factor when migrating from MySQL to Vitess. A simple rule of thumb is to estimate 2ms of round trip latency added to each query. On the application side, if a significant time is spent making database calls, then you may have to run additional threads or workers to compensate for the delay, which may result in additional memory requirements.
Planning Shard Size
Vitess recommends provisioning shard sizes to approximately 250GB. This is not a hard-limit, and is driven primarily by the recovery time should an instance fail. With 250GB a full-recovery from backup is expected within less than 15 minutes.
Running Multiple Tablets Per Server
Vitess encourages running multiple tablets (shards) per physical server. Typically the best way to do this is with Kubernetes, but
mysqlctl also supports launching and managing multiple tablet servers if required.
Assuming tablets are kept to the recommended size of 250GB, they will require 2-4 cores for
mysqld plus 2-4 cores for the VTTablet process.
Topology Service Provisioning
By design, Vitess tries to contact the topology service as little as possible. For estimating provisioning, you can typically use the minimum requirements recommended by your preferred Topology Service.
Before running Vitess in production, please make yourself comfortable first with the different operations. We recommend to go through the following scenarios on a non-production system.
Here is a short list of all the basic workflows Vitess supports: