 So, Assen, may I ask you to come on stage? So, the next lightning talk is Don't Fall Off The Cloud. That's a very interesting title, Assen. Give me a second. Hello. Good afternoon. My name is Assen from MariaDB. We had some magic today already, so now I'm here to tell you a story. A story with a fairytale beginning, with some high drama and with happy ending. So, in the beginning, in the beginning, there was Next Cloud, and there was MariaDB, and there were happy users. And what happy users do? They drag in more users who want to be happy. So, you get more users and more users, until one day, things become sluggish. You start to investigate your system and it turns out it's the database. It just can't cope with your load anymore. What do you do? Well, eventually you can get a crash. Everything goes down. Who's going to save me? Well, maybe high availability. Maybe I can avoid this. Maybe I can no longer do my maintenance on Saturday night and go out for a beer. Drama. So, the first solution. Why not use replication? We'll get a replica. It will be a standby for us. If something goes wrong with the server, we'll have a spare system ready to run. Looks like an end solution. But you spend money, you pay for something, which is just your peace of mind. And then your manager comes in and says, hey, I want efficiency, yeah, and I don't get efficiency this way. So, you need a different solution. What about using load balancing? Sounds very nice. You'll be using both of your systems at the same time. But a problem, your client's software, it just uses some standard database connector. It doesn't support fancy stuff like automatic read, write, splitting and things like this. You need to work more in order to make it work. Then you get the bright idea. You hear about something called a SQL load balancer, something that can balance SQL statements, maybe like Proxy SQL. You put it in, you feel very proud. Everything seems to work. Finally, you've nailed it. Is this the happy end? No, not yet. Because one day, people start to complain. They open the document and suddenly they didn't get the newest version of the document. They put something in the chat and this message disappears. They check a thread and they don't see the last post in there. What's the problem? Is NextCloud suddenly buggy? Who's to blame? Here it is. Here's the culprit. It's named Cozal Read Failure. If you haven't heard this, Cozal Read is when you write something to a cluster database and immediately read it back before it was able to replicate. So what do we do about it? Is this the end of our story? Should we just forget about everything and go back to a single server with late night maintenance and all of the headache? No, Max Scale comes to your rescue. Max Scale is a dedicated tool, a Swiss Army knife of a kind created by MariaDB for clustered MariaDB databases. It can be your database firewall. It can give you denial of services protection. It can do load balancing for you. It can do data masking for you. It can do active topology management for you. Have you played Lego? If yes, then you're going to love Max Scale because Max Scale is like Lego. Max Scale is a flow processor that you can use the building blocks to build the exact pipelines you want to have there. So Max Scale sits between the application on the left and the database service on the right and it understands everything they say to each other. It can actively monitor, it can take preemptive action and it can also influence the topology all the way to rearranging it the way it should be. So how does Max Scale help with Cozoreed? Max Scale actively tracks the state of each replica using something that we call a global transaction ID. And with the help of this, it always knows whether a particular replica is synchronized all the way up to the moment that is necessary to fulfill the next request. If there is a replica, great, it's going to forward the query there. If there isn't a replica, it's going to either wait for a little bit or it can send it directly to the primary node. You have different strategies available and you are in control to decide what's going to happen. But this is not all that you can get out of Max Scale. With Max Scale, you get automatically read write split for the best possible utilization of your resources. You get adaptive replica selection strategies, at least four of them. So depending on where your servers are, you can choose the one that works the best for you. And finally, you get topology management, active topology management and zero interruption failover. Have you been waking up late night in order to do a database failover? Well, now you can sleep nice because Max Scale sitting between the client and the service as a single connection endpoint does constant monitoring of what's happening on the backend. And by doing this, it knows if and when your main node fails. And when this happens, it does a lot of stuff in zero time. It finds which is the best replica to promote. It does this promotion. It rejoins all the remaining nodes to this replica. It then recreates all the sessions that were present on the failed node. And then it replace all the ongoing transaction. And in the line with the magic that we saw, this is pure magic because no DBA can do this for you. And last but not least, when your failed node gets resurrected, Max Scale is simply going to join it back into the cluster as an ordinary replica. Wow. Feeling intrigued? Interested? Having questions? Come to us. We're here to tell you a lot more about Max Scale and MariaDB and clustering for the enterprise next cloud. Thank you. Thank you, Alson. Thank you, Alson.