 Hello, my name is Vinay Jusri and I'm the CEO of several Nines and this is a quick talk on the high availability database architecture for next cloud. So we basically the next cloud database it stores everything apart from the binary files right so anything around metadata users what files there are. You know what what tokens you have used anything from file history, all the activities recorded in the database so it is a pretty important database. So why should you cluster your database. Well, it's low database, it will slow down next cloud right that's the big problem so imagine loading a file list that takes more than half a minute right this will be frustrating for your users, and that happens if your database is slow. So if you have users, if you have more users, it means you will have more activity on the database, because there's a considerable amount of activity being locked for each user. So every time you add a new file you share a file. And we've, we've, you know, other users you set permissions, even if you move files between locations or if you take a directory and move it to another location. There's a lot of updates that that actually happens in the database. And also, all the desktop clients are continuously pinging the database for updates. So the database needs to scale. Right. And the other thing is data integrity. Now imagine if your database is corrupted, the, the actual client, you know, the, the desktop client, when you when you basically, you know, boot it up. The synchronization client might think, Oh, there are no databases right because it's empty. So actually it might delete your local copy of files right so so there are a number of these edge cases where you could run into trouble. And now obviously, you know it is it is possible to rebuild metadata from files, but it works for file systems not if you're using object storage. So eventually, I mean, you know, you come to the conclusion that if you have no database, then there is no next cloud, right. You can access your local desktop files, but you can share you can collaborate and, and obviously, yeah, this is a problem. So high availability. There's a lot of dependency on the database when it comes to the availability of the next cloud platform. So what does the architecture looks like on top you have your multiple instances of the, you know, of your next cloud instances. And basically you're talking to the database through a proxy layer. Now, it is possible to have things like a proxy or, you know, max scale is the one that's actually recommended in the documentation. We actually would like to, you know, put forward proxy SQL, which is a, which is a nice proxy that also works quite well. And you have an active proxy SQL and a backup proxy SQL. And basically you have keep alive the running on both of these hosts, and keep alive the managers a virtual IP. And that IP is floated to the backup instance in case the active proxy SQL dies. Right. Now, then it goes to the database cluster. Now what is MariaDB cluster. And most people know how basically, you know, single instance MariaDB works right it's it's one single instance, and then you have a master slave setup. Now MariaDB cluster is a is a way of actually synchronizing multiple MariaDB databases, right across multiple nodes. So in this case, we have three nodes in the cluster, right. And all these have exactly the same data. So as you see here, this RW, it means read write. So basically we're writing, we're reading and writing from one of the nodes, and the other two nodes, which are actually read they have exactly the same data. So you could actually send right no right requests to all the nodes, but we found that this could bring problems in terms of deadlocks within the era, right. So you don't want to have contention between the nodes when, when, when, when, for example, the same rows are updated across multiple posts. So this is why we recommend that you actually send your right traffic to one of the nodes and then you read from the other nodes. And, and this this is this can be done very easily through process equal, right. And then you have something called in really be asynchronous slave. Basically, we are decoupling one of the nodes from the from the cluster. And this is because the cluster is as fast as the slowest node. Right. So if, for example, you run a heavy backup, or you run a lot of reporting on one of the gallery nodes, that node will slow down and that will actually, you know, propagate to the other, to the other nodes in terms of slowing down the rest of the cluster. And you don't want that right so so basically having an asynchronous slave which is decoupled from from from the gallery cluster helps you. And then obviously you have cluster control. So cluster control is what actually you know what you can use to to set it up and to basically manage this setup. Now why management obviously there's a lot of talk in the community about, you know, GDPR and making sure we have data privacy and, and, and, you know, data protection and, and, and, you know, things like that. So, so the database is something that's important in terms of management. So data security, and making sure you encrypt your data access control, who has access to the database who can do what right backup and retention and monitoring upgrades to make sure you don't have old software lying around. These are all important things. And finally, we have two other talks from, from my colleagues at several lines. One of them is about failure with databases, right, your MariaDB cluster will fail and why this is done by Christoph. Then the other one is tip to drive MariaDB cluster performance. That's it. Thank you. Bye for now.