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.
For most
...moreVitess can run in virtual machines on AWS, Azure, and GCP or in Kubernetes on those platforms. Vitess can run in two different manners on those platforms using either Kubernetes on virtual machines or using cloud Kubernetes managed service in AWS EKS,
...moreVitess can run on bare metal, virtual machines, and kubernetes. It also doesn’t matter if your preference is for on-premises or in the cloud as Vitess can accommodate either option.
...moreVitess runs on a lot of different options. Kubernetes is only one of the available options. Vitess can also be run on AWS, GCP and bare metal configurations.
...moreThe Vitess Operator is open source and is on GitHub. You can see the repository for information on licensing and contribution.
The Vitess Operator automates the management and maintenance work of Vitess on Kubernetes by automating the tasks below:
Deploy
...moreCPU
Vitess components (excluding the underlying MySQL server) tend to be CPU-bound processes. It is recommended to:
Allocate 2-4 CPU cores for each VTGate server. And allocate the same number of cores for VTTablet as with MySQLd. If you are provisioning
...moreReparenting is the process of changing a shard’s primary tablet from one host to another or changing a replica tablet to have a different primary. Reparenting can be initiated manually or it can occur automatically in response to particular database
...more