Here at PlanetScale, we provide fully-managed, cloud-hosted Vitess clusters to our customers.
If you missed the previous videos, definitely go check those out. As we saw, Vitess is SUPER powerful, but there’s also a lot of associated complexity with setting it up, configuring, managing, and monitoring a real production database.
When you are using Vitess at large-scale and for real world applications, there’s a bunch of additional things to consider. What do we do when an instance goes down? How do we handle spinning up new nodes when we need to do more sharding? How do we get deep insights into what our cluster is doing? Who is going to be on call when something goes wrong?
Thankfully, there’s PlanetScale. If you want a managed, highly scalable MySQL solution backed by Vitess, PlanetScale is the place to be.
Whenever you create a new Base plan database, you actually get 3 instances of MySQL running on three separate servers in a Vitess cluster. Each of these three instances have an attached Vitess process called a VTTablet, which are responsible for managing the instances. You also get 3 VTGates (which our UI calls “load balancers”). When using PlanetScale, we also have infrastructure that automatically distributes the load across VTgates (or chooses the most appropriate one) so you don’t have to think about which one you are connecting to - just connect!
In a matter of seconds / minutes, you can have a fully-fledged Vitess database cluster up and running in the cloud, ready to be connected to and start powering your application.
With PlanetScale, we set up each of these three MySQL servers in separate availability zones, to help minimize the chance of multiple servers having problems at the same time. In reality it’s a bit more complicated, but you can basically think of an AZ as a separate building of servers. When your three servers are spread across multiple buildings, this makes it much less likely that all three of them would go out at the same time due to something like a hardware failure. The three VTGates are also spread across 3 AZs, making for a resilient setup to adverse conditions.
As much as we’d like to think servers in the cloud are bulletproof, they are not. Sometimes things happen - power outages, extreme weather, and hardware failures can all lead to a database server experiencing downtime. Vitess solves this problem by utilizing automated failover to achieve high availability. Vitess continually monitors the health of these three MySQL instances. If it detects a problem with the primary, it automatically switches over the primary role to one of the replicas (known as automatic failover) and then spins up a new server to take its place. Altogether, this leads to a server with extremely good uptime metrics, which for many businesses is mission-critical. A problem with the database can mean lost $, and we help you avoid that.
With Vitess, you can specify whether you want your connection to be routed to a primary, or alternatively by a replica by using the @replica keyword in your DB connection string or USE @replica as a statement. This works with PlanetScale, though we recently introduced an even more powerful method: Global Replica Credentials. With these, you can create username/password combinations that specifically target either a primary or a replica. With PlanetSscale Global Network, this can automatically target the nearest replica and / or do load balancing across your replicas as it sees fit.
With our global network infrastructure, we have nodes set up all over the world to handle incoming MySQL database connections. When you connect to PlanetScale, you are actually connecting to one of our edge nodes. Then, the edge nodes use network infrastructure and protocols that are faster and more reliable than a typical MySQL connection to connect to the VTGate, and then eventually to MySQL itself. This makes for fast and reliable connection handling to your database. If you can’t connect to MySQL, what use is it?
With PlanetScale, you can also easily spin up additional database branches (running as separate instances), so rather than paying for an additional dev database, you get this as a built-in feature on PlanetScale. To do something like this on, say, amazon RDS or aurora, you’d need to spin up multiple instances for primary, replication, and staging environments.
You can use branches for development work, and then use our deploy request workflow to merge these branches back into production when ready.
If your application starts to get super high demand, you may even reach a point where sharding is necessary. For our enterprise customers, we also spin up and manage sharded databases. This means your database can grow with you, whether you’re running a small application, or one with millions of users per day. You can start small, and grow to any scale with PlanetScale.
Lastly, we can’t forget about backups. With PlanetScale, we automatically capture and validate a backup of your database every 12 hours. We even give you the ability to restore backups to separate branches if you want to trial-run a backup restoration.
PlanetScale also can handle MySQL version upgrades. When it’s time to upgrade, a backup is taken of your database, and then each node within your cluster is individually upgraded, one at a time. If a problem is detected with the first upgrade, the operation can be canceled, and if successful it proceeds. Either way, the upgrade process is zero-downtime from the connecting application’s perspective.
We are THE go-to company for hosting Vitess-powered databases, and are trusted by 1000s of organizations both big and small to keep their database up, running, and performant. If you’re interested in taking PlanetScale for a spin, sign up and get started immediately.