 Hello. Today we'll be talking about VITES. We'll give you a brief introduction, and we'll also give you a few demos that cover some of the new features that we have recently developed. I'm Sugus Sugumaran, I'm co-creator of VITES and also CTO at PlanetScale, and I'm joined with Deethi Sigheridi, who is lead maintainer at VITES and also software engineer at PlanetScale. What is VITES? VITES was initially developed as my SQL scaling solution at YouTube, but it has evolved into a cloud-native database. VITES is a CNCF graduated project. It was donated by Google to CNCF in January of 2018 as an incubating project, and it graduated from CNCF in November of 2019. It was the eighth project to graduate from CNCF and the first storage project. What do we mean when we say that VITES is a cloud-native database? Stateless storage in Kubernetes is not an easy problem to solve, but VITES had a head start because it had been built to work in Borg which was the precursor to Kubernetes at Google. Because of that, VITES was ready to run in Kubernetes even before a version 1.0 of Kubernetes. Some of the features in VITES that made this possible are the way in which VITES runs my SQL instances in our primary replica configuration so that when there are events like a pod deletion, if Kubernetes decides to kill a pod, then you can fail over to a replica without any disruption to the traffic. The other feature of VITES that we want to highlight is its scalability. VITES is massively scalable and we have not so far hit the limits of how much you can scale it. As long as you keep adding hardware, there are VITES implementations which are running literally millions of queries per second with no problems. VITES is also highly available and this is a result of the primary replica configuration in which VITES clusters typically run, and the seamless way in which you can fail over from a primary to a replica in case of unexpected downtime. VITES is right now my SQL compatible. It runs against any my SQL flavor, community, enterprise, Percona, MariaDB, etc. It does not work with Postgres as of now. VITES serves millions of queries per second in production at various companies. Some of the biggest users of VITES are JD.com and Slack, and they both have very high traffic instances. JD is the largest Chinese retailer, which means that it is the largest online retailer in the world, and Slack, as most of you know, is a collaboration tool that is serving many, many large enterprises. Some of the VITES users run it on their own hardware. Many of them run it in the cloud and some of them run it in Kubernetes, and VITES can run in any of those configurations. Let's cover a few key concepts in VITES. The first one is key space. In traditional database architecture, people usually have a monolithic database. In VITES, you break that monolithic database into segments, each of which is called a key space. And a key space can itself consist of multiple individual databases, but it is a logical database, and a VITES cluster can contain multiple key spaces, so multiple logical databases, each of which may contain more than one physical database. The next concept we should understand is that of shard. A shard is pretty much the smaller component of key space. So key space, if you think of it as a logical database, a shard is the way you split up tables in that logical database across individual MySQL instances in order to get the scalability that people are looking for. VITES all depends on a topology server, a distributed key value store that serves as a central location for VITES components to discover each other. Let's look at the VITES architecture. In this picture, we are showing n shards, and all of these shards together comprise a key space or a logical database, and it consists of multiple physical databases. And for each of those physical databases, we run a component called a VT tablet, which takes over the management of those physical databases in terms of doing backup restores and providing protection against unanticipated queries that might overload the database and things like that. Traffic to the VITES cluster is routed through another component called VTGate. This serves as a gateway to the cluster and applications talk to VTGate, which then decides where to route individual queries. VTGate speaks the MySQL protocol, which means that applications can interact with it as if it were a single MySQL instance and it provides the logical single database view that VITES gives you across the shards. There is also a control component called VTCTLD, and this is a daemon process that can be used to manage the cluster and serves as an entry point to various cluster management functions. Next up, we will show you demos of some interesting things, features, new or otherwise in VITES. We'll start with showcasing the MySQL compatibility and then move on to V-replication, online schema changes and automatic failovers. Hi, this is Arshit and Andres, and we want to talk to you about MySQL compatibility. We believe that the test provides a valuable illusion for its users. It's the illusion of a single database when in reality your data might be spread out across multiple verification clusters. It's the illusion of working directly with MySQL Find7 when in reality you're connected to a code service. Finally, it does make it seem like you have a dedicated connection to your database when in reality your queries are being sent through a connection pool and where two queries can end up on different servers. This illusion has to work with many different systems. It has to convince your connection libraries that you use to connect directly to your database to send your queries. These libraries often send some preamble and follow-up queries and expect them to answer in very specific ways. It has to work with object relational mappers, tools that translate from the objects and structures you're working with in your whole signage to complicated SQL queries that the test has to be able to understand in one. We also want your old code to work with the test, not just the new projects. Forcing our users to have to change old SQL queries is not a good idea if we want happy users. Lastly, we want you to be able to use an application that works well with MySQL and make it scale by placing the tests in front of MySQL. When we started working with this project in last spring, we quickly picked the word process, the thing that we were aiming to support. Here we have our newly installed MySQL cluster and we have a test in front of it and we are configuring WordPress to talk first directly to the backing MySQL cluster. We have installed it, we now are able to just write the little blur and a new blog post about the other incoming the test 8.0 release. Here's the blog post published. And we can see here in the status page for me to get that no queries are coming in. If we now change the connection port, so instead of talking with the backing MySQL, we talk with the test. We go back to the WordPress admin page. Here we can see that queries are starting to trickle in. We can list existing pages and it seems to work pretty seamlessly. Now I want to talk about what the test does behind the scene to create this illusion. Here I had a setup where the top pane shows the queries done executing against the test. And in the bottom pane, you can see the queries being received by the DT gate and the queries that DT gate sends to the tablet. Now, if we're dealing with a lot of data, we don't want to see all of it in one go. So we're going to use limits. That's going to show us the data, but we're sure showing a lot of data and you want to provide pagination. You want to know what the full number would be. SQL called found rows test plan. It provides the data with the limit, but it returns found rows as if you had run the query without the limit. To implement this, what we had to do was to store this value in the DT gate session. So when we evaluate the found rows, we never send anything to the tablet, which might be an entirely different tablet. So we wouldn't have this information anyway. The last piece of the illusion that I want to show here is user defined variables. This is something that lives in the session states on MySQL and because we can't trust which MySQL will end up in, we had to do the same thing. Copy these values into the session state of the DT gate level and provide it to the tablet when necessary or evaluate it directly when we can. Here's an example of us having to send down the information in form of a parametrized query to the tablet. Hello, in the short demo, we go over a migration workflow. Early adopters often used to try with tests in production. We show how to move tables from your existing setup to serve them using with tests with the replications, move tables. Let me see how easy it is to roll back to your existing setup. Let's get to the demo. So this is the data we have in our current server. We first start all the witness components that are needed. The topology, VCTLD and VTKT. Now we start the unmanaged tablet, which is just a tablet proxy, which points to the existing database server. Once that is done, we start the witness cluster with three tables which are in your database. We start three tablets. One will be the master, the other replica and the third is the real one. The tablets are started. We have two on this, the master. And now we can initiate the V-replication workflow called move tables, which lets you move a number of tables from a source. So commerce is what we call the existing database. That's the key space. Customer was the new witness cluster and we copied over customer and C order from commerce to customer. You can see here, the VDIF command shows you that all the tables have been copied. It's a very small table, so it's happened really quickly. And you can look at the metadata of V-replication. It shows you which position it's running at. It's syncing currently from commerce to customer. At this point, your existing database is still contains all the data. It's where the app is pointing to. And you can see when you insert into the your existing database, it gets synced and the target still has the new row that you created. Now we start switching over to the witness cluster. We switch reads or read only on replica. And then finally, we switch over the writes, which is all traffic from your app is going to the witness cluster. Note that we are still running a reverse replication at this point when we switch writes, keeping your original existing database server in sync with the witness cluster. We can look at this by looking at the reverse workflow that is automatically created by witness. And you can see that the position is in sync. We insert some rows into the target, which is the witness cluster. And you will see that read application, the reverse replication has kept it in sync. The GT IDs will increase by 10, which is the number of rows that we inserted through VT gate, five in C order and five in customer. So which means your existing server has all the data and you can switch back to it at any time. Let's initiate the switch back. So to do this, to switch back, we do the reverse, which reads back to your existing database. And then we switch writes, in which case now the app is pointing to your existing database, witness cluster is just there in the back down. It is still, the forward replication is still running. So if you, the app is now inserting data into the existing database, the witness cluster still is kept in sync. You see that here? We insert a row into your existing server and then we confirm that our target has moved forward that is the witness cluster is in sync. Read application can also be used for applications, such as flexible, resharding, change data capture, materialized views, anonymization and aggregation. It has proven itself at scale in several massive high performance production setups with huge databases serving very high QPS. Thank you. Hello, my name is Shlomi Gerach. I'm an engineer at PlanetScale and today I'd like to present online DDL, a new experimental feature in Vitesse 8.0, which comes to solve the issue of schema migrations and of the fact that an altar table in large busy systems takes the power out of the developer's hands. With my skill on large and busy systems, an altar table is a risky operation. It is blocking. If not on the primary, then on the replicas, it will create replication lag. It is resource-related. It can consume so much IO that your environment is unable to serve production traffic. It is unalatable and uninterruptible. You can't expect to know what the status is or hit control, see and expect things to just come back the way they were. Workarounds exist in the form of external tools like Ghost, Petey Online Schema Change or Facebook's Online Schema Change. These are tools that require operational knowledge from the engineer. They need to run in the production environment. They need to know. They need to get the identities of the affected service. They need service discovery. They can do throttling, but they need to understand how to do throttling, which service to throttle by. What does the environment look like? So the usage of these tools, although popular requires an operational domain knowledge that some engineers do not have and therefore the engineers need to relay the schema migration operation into the hands of VBAs who will most commonly run these migrations manually. The situation is undesired and this is why VTES is happy to present a new syntax for online DDL and alter with Ghost table, alter with Petey Online Schema Change table, putting the power back into the developer's hands and abstracting away all of the complexity of running schema migrations. Let's look at a quick demo. For starters, we're now logged in into VTES. We have this simple table called eggs. It's populated with a few rows. It's actually only sharded environment with four shards. But when I select from the table, it makes the appearance of just a normal monolithic table. I'm going to begin with the normal alter table. That's a blocking operation in production. I wouldn't run that. That could take minutes, hours or days to run. But of course, here on this very small table, it returns instantly. Already, we see that VTES is very useful to us here because it abstracts away the need to know what are the affected shards. How many shards are there for this table? Who are the primary service for these tables? This is something that VTES already is aware of and abstracts away. But again, this schema migration is blocking. And therefore, we introduce this new syntax. Alter with ghost, table, eggs, modify int, et cetera, et cetera. And the first thing we note is that we get back this job description, job ID, which we will use later on to track. We'll be able to use this value to control immigration, audit immigration, cancel it or retry it. Now, the next thing we see is that the table has not yet been migrated. That's because this operation goes asynchronous and offline. VTES becomes the owner of the scheduling of this migration. In fact, every shard in itself owns the scheduling of the migration. It can take place in the next minute or in the next hour, depending on whether there is other running migrations. At long last, we will see that the migration is successful. We can see that the schema change has been altered. Of course, tracking the progress of immigration by show create table, show create table is undesired and VTES offers us an interface to look into the status of running migrations. The same interface allows us to control, cancel, throttle, and terminate or retry running migrations. There's a lot more to this and please look at the documentation and release notes for VTES 8.0. Thank you so much. Hello, everyone. I'm going to give you a very quick demo of the orchestrator, which is actually a new component of VTES. VTES has previously had what we call as planned failovers, which means that if you plan to deploy software or if a pod goes down and it gets an event, VTES automatically performs failovers where it changes the current master and fails over and promotes another replica as the new master. But operating VTES in that level won't give you this huge high availability that people get with it. Usually what they do for that is they integrate another component called the orchestrator authored by Shlomi Noach, which is a popular tool for MySQL. And VTES works as an external integration with that orchestrator. What we have now done is forked that orchestrator and made it a core component of VTES, which means that this new orchestrator called VTARC actually works hand in hand with the VTES topology can understand all those components. And therefore the integration is tighter and a lot smoother. So here I'm going to give you an example of that orchestrator and the things it can do. So I have a cluster here, which is a single, which is an unsharded key space. And in this key space, I have a master and four replicas of which one is not an eligible master. And now that I have, now that I've also brought up the orchestrator which is running and the orchestrator also has the same view of the topology except if it actually has a better UI, you can see that it's now beautifully graphically represented and shows how things are connected. But what you can do here, for example, is I can go to VTES and say do a plant reparent, which is failover from the master from 100 to let us say 101. So I say do a reparent. So as soon as you do a reparent, then what VTES has done, it has performed a failover. But as soon as it does a failover, the orchestrator notices that it has happened and adjusts something that see, now 111 is the new master. So they are both in agreement. But you could also go to the orchestrator and say, hey, you do the failover for me instead of asking VTCTLD to do it. And that can also happen. Like for example, I'll say promote 17101 as master and orchestrator is a nice drag and drop UI. You can say, hey, do you really want to make 101 the master? Yes, I want to make 101 the master and the orchestrator performs that act. And if you go look at VTES, it actually should have updated 17101 and the orchestrator will soon refresh its screen to show that it's the case. But what can orchestrator do is if MySQL crashes underneath, it can actually detect it and proactively perform failover. So I'm going to do that. I'm going to bring down 101 to show you which is my down 101. So as soon as I go down, you will see that this is the log of the orchestrator. After a few seconds, it'll notice that something is off and it says, okay, I'm going to perform some functions. These are, I'm running it in post mode. But if you refresh here, 101 was the previous master. And now if you see it says, hey, I have now promoted 100 as a master because 101 is down. What I can now do is go back and bring that 101 and just waiting for the shutdown to finish. And if you see here, do the refresh, you should see that 100 is now master. 101 is actually down. If I click on the status, it'll say it is down. So now I'm going to bring back 101. And as soon as I bring up 101, I can go to orchestrator. It'll say, hey, 101 is back up and it looks like everything is fine. I'm going to now point it back at the new master. So the way orchestrator works is it works in this thing called the desired state. Any component is not in the correct state. It goes and fixes it. So it makes this entire cluster self-healing even, but then it's beyond just looking at the state. It's also looking at whether something is able to serve traffic or not. This component of orchestrator will soon be available as a operator component. So in the operator, there is actually this pull request which should be submitted by the time you see this video. If not, it is pull request number 130 and you should be able to build off of this OC1 initial branch. And once it is there, you should be able to use the new VITS operator to deploy this orchestrator. And there is a sample YAML that I've submitted here which will, there's a sample YAML which is under the operator example, but it's called orcluster.yaml. And you can look at it to see this section which is the VITS orchestrator. And that should show you how to set up the orchestrator for your cluster. Thank you very much. We invite you to visit us on the web at the website, VITS.io, where you can learn more about VITS. Do join us on Slack. We have a very vibrant and welcoming Slack community. You can also find us on GitHub or talk to us via Twitter. And we'll take questions next.