 Hello everyone, my name is Krzysztof Książak. I'm director of support at several lines. And in this very quick talk, I would like to go over the cases why your MariaDB cluster will crash. So first of all, I want you to assume that this will happen. The crash will happen. It helps to assume that because then you can focus on the planning, how you will deal with the issue rather than considering if it will happen, how probably it is. I mean, it will at some point in time, it just will. And there are a couple of typical issues that may break your cluster. Those are the network issues, hardware issues and the issues triggered by the user. So network issues. MariaDB cluster as every Galera cluster is strictly tied to network. It's just a bunch of nodes connected over the network. So the data is being replicated over the network. The intro cluster communication goes over the network. So basically like hard bits, like the quantum calculation, everything goes through the network. So if the network goes down, nodes cannot communicate and the cluster fails. Therefore, the network partitioning is pretty much the most common case where Galera crashes. So we're talking here about situation where you have multiple nodes, three, five, seven, nine, whatever. And then the majority of them loses the communication with the rest of the cluster. This makes it, you know, this turns the cluster into non-primary state. It loses the quorum and it sees to operate. So it stops executing any kind of queries. And this is mostly because to protect the data consistency. But technically speaking, cluster is down. It's pre-brain, another problem. So we're talking here about a situation where you have a cluster, which is due to network issues spring into two parts, for example. And both of those parts are working. Both of them are executing queries. As you can imagine, it's quite bad for the data consistency. To be speaking, it shouldn't happen because of this non-primary state, because of those both precautions. But we are talking about software. So even if it's unlikely, it still may happen, right? Bucks, rice conditions, this something may just trigger this. Also, MariaDB cluster by default is quite well configured for the local network. But if you want to use it like in a geographically distributed cluster, then you need to account for higher latency, you know, distance, you need to account for the links that are not as stable as the local network. And basically probably want to do add some tuning just to make sure that your habits, that your health checks are not timing out because of the network issues rather than the note health issues. Hardware, so there's always hardware somewhere, how no matter how you hide it behind the scenes. And hardware can break, there are physical parts like CPU, memory, disk power supply, network controllers, whatever. They just may break. If you have access to the hardware, then you can apply some redundancy on the hardware level. If not, which is well quite common these days, you probably want to account for note crashes on a higher level, like would add maybe instead of three notes, the five notes in your MariaDB cluster. Also, network, you know, CPU, disk saturation, you know, you can run out of resources and note which run out of resources is typically slow note. Then it may not be able to respond in timely manner for the health checks within the MariaDB cluster. And such note can be evicted from the cluster. So you want to be aware of this kind of situation, you want to have a proper monitoring and alerting that you just alert you, okay, your note is running out of CPU and you probably want to do something about it. Users, they can break the cluster as well. So everyone with the access to the database has the potential to crash it or impact its operations. So developers, they can run schema changes. Well, I mean, for next call, maybe that's not that common, but it still may happen that you want to run some alters to create some indexes. And by default, running alter on MariaDB cluster just stops the cluster for every kind of operation until the alter completes. So you should probably use some tools like PT-online schema change instead rather than running the alters directly. Also, you may want to write all of the notes in MariaDB cluster, but you shouldn't. It's better, it's more stable, it's less contention when you use one writer in a cluster. You can apply this, you can configure load balancers to do this. Also, you know, the generic configuration, like there are a couple of different elements in MariaDB cluster, SSD, for example, is a process to recover the note, to transfer the data from the cluster to the failed note. It can be misconfigured and recovery may not happen. Even just simple configuration setting, if mistype, like mistype some variable in MariaDB configuration file, it may trigger MariaDB just not to start at all, right, after the restart. So you should be looking for logs, you should be looking just to check out what kind of issues are there, maybe there are clues how to, typically there are clues how to recover from such a problem. So there are two more talks from CyberNines. Vinay Joceri, CyberNines CEO has a talk on high ability database architecture for next cloud. And my colleague Ashraf Sharif has a workshop on tips to drive MariaDB cluster performance for next cloud. Thank you very much for listening.