Hello everyone. My name is Philip Stof and I work for Codership, the company behind Galera Cluster. And what I'm going to talk about is a few features of Galera Cluster that are very useful for open stack. And hopefully we will give you some interesting thoughts to think about. So first of all, what is Galera? Galera is a multi-master application system for MySQL where multiple MySQL servers replicate together and have a full copy of the database. So it is fully master master, fully active active. And each transaction is replicated to all the nodes in the cluster as it is committed. So you have full data redundancy and the ability to execute updates on every node. So it is MySQL in a sense that it replicates the InnoDB storage engine, meaning that all the knowledge that you have about InnoDB still holds. All the optimization advice about InnoDB and how to tune the queries. All of this remains the same with Galera. And it is also compatible with all the existing MySQL clients and tools that you may be using. For example, backups can still be taken with extra backup. And Galera comes in different flavors. So if you want the MySQL community addition plus Galera replication, you can get Galera Cluster. If you want Percona server plus Galera replication, you can get Percona X3DB cluster. And if you are using MariaDB, you can get the MariaDB cluster, which again includes the same replication technology. All those products are fully open source and all have excellent support. So you have the ability to have clustered replication on top of whichever MySQL flavor you feel most comfortable with. And the underlying replication behaves the same. Galera is flexible because you can have it single master or multi master. All updates can go to any node in the cluster. But if you feel more comfortably with single master setups, you can have that. And there is no need to change anything in your application. If the application expects a single master, then it will continue to run. Yet you can direct transactions to any of your nodes. And if your master goes down, you can pick any other node and continue to execute transactions against it. It is scalable. We have people using Galera with dozen nodes. And you can have nodes in multiple data centers and you can have multiple nodes per data center. I'm going to talk later about the geo distribution aspect of it. And you can also combine Galera cluster and Galera replication with standard MySQL replication. Galera can be a master or can be a slave for your standard MySQL replication. So you can combine Galera with your existing replication topology in order to try it out. And you can take data out of Galera and put it in a warehouse or take a backup of it using standard replication. Galera can be used as a backend database for the OpenStack services. This is actually widely used in production. What if OpenStack vendors use that and what if large clouds use that so you can have Galera instead of a single node MySQL for all your backend OpenStack services. Last, in Paris, J-Pipes made a talk about how to best position your Galera servers and how to best spread the load. It's on the web. It's very interesting to view. And it is also possible to have geo-distributed databases for your Keystone and Glance. So it is possible to share one Keystone database across multiple regions using Galera. And it is used by major companies that have large OpenStack installations and you get it from vendors from Mirantis, Red Hat and others. So the question is what else can you do with Galera except have it provide high availability for your OpenStack installation. And there are two things that I want to talk about today. One is how to use geo-distribution and what benefits it provides. And how you can actually provide Galera cluster as a databases of service to your users so that they can take advantage of high availability for themselves. So first, a bit about geo-distribution. Imagine that you have a node in Vancouver and a node in New York. With Galera it is possible to have a multi-master application across continents, across coasts without any issues. So such setups are actually in production. And the product contains a lot of optimizations related to geo-distribution. So for example, when it comes to latency, we do minimize the actual latency that is incurred. Of course it is not possible to go faster than the speed of light. But the replication protocol takes care of not doing unnecessary round trips. So in fact the replication penalty is small. And it is also incurred only when the transaction is committed. So you do not have the nodes constantly communicating for every single thing. The number of messages that are exchanged across data centers is kept to a minimum. And it is possible to have very small slave-lack. And for important transactions it is possible to eliminate slave-lack entirely on a per transaction basis. So if you have some important data, you can set it up so that a right that you do on one of your data centers gets immediately replicated to the other one and any reads reflect the most up-to-date state of the database. So from the application standpoint it is possible to have no slave-lack whatsoever. Any read that you make can be forced to be up-to-date. And you can relax this a little bit if you can tolerate some slave-lack for the sake of performance. You can have more transactions in flight in your geo-distributed environment at any time. We also have quite a few optimizations to reduce cross-data center traffic. In particular, if you have a setup like this, imagine that your business in Vancouver has grown considerably. So now you have the need to have three nodes on the west coast. The protocol is such that the traffic between the two data centers will be kept to a minimum. So if you have a transaction, for example, committing code node number four, it is going to be replicated only once to node number one. And vice-versa, if you have a transaction committing on node one, it does not have to be replicated three times to the other data center. So the latency penalty is not incurred three times and the data is not shipped three times across the wide area network. And if you want to add another node, for example, node five on the Vancouver side, this node will take the snapshot of the original database again from your Vancouver data center. There will be no cross-data center traffic if the data is available locally. And we also provide SSL encryption for the communication between data centers and this brings in compression as well. And finally we have automatic eviction of unreliable nodes. So for example, if in this case your node number one is misbehaving but not fully down and not fully up because of some network problem, it will temporarily be removed from the cluster so that the rest of the nodes can continue to process writes, which helps with any network issues across wide area networks. When the network issue is resolved, node one can be brought back up and it will synchronize with the rest of the nodes. And why is that useful? Why do you need to care about geo-distribution? First reason is that you get a global single view of your global data. It is no longer one server replicating with another server, but now you have a single cluster with a single view of the data. So it's no longer a question of did I replicate correctly? Did I ship my data from one data center to the other? It is one and the same data everywhere. And again, the lag for having this consistency is as small as theoretically possible. And you can direct all your read queries to a local node. So for a typical workload that has a lot of reads and not that many writes, there will be no latency penalty for reads at all. And for writes it will only be on commit. And finally you get increased redundancy. Now your database is globally replicated. So it is not a single availability zone, but even more secure than that. And sometimes putting stuff in different availability zones but within one and one and the same data center does not seem to provide full redundancy. Outages have been seen that affect multiple availability zones. But with the geodistributed database you are raising the bar higher. Now you basically have to have a failure affecting more than one data center for your database to become unavailable. And if you have three or more data centers, as long as at least one of them is operational, you can continue to write to your database. So now we are talking about tectonic levels of reliability here. And the other thing that I wanted to talk about and demonstrate a bit is how you can provide Galera as a service to the users of your cloud. Because they would also benefit from having redundancy. And as an administrator you also benefit from using Galera cluster in place of standard MySQL application for your users. So what are the benefits for administrators? First and foremost it is the simplified failover. When one of your notes fails in a Galera cluster you can just flip and start executing writes and reads to any other note. There is no external failover process to follow.  This happens all automatically and all inside the product. The only thing that you need to do is have your load balancers directly in traffic away from the failed note. There are no SQL commands to issue to stop the replica or to make a replica master or any of that. All of this happens internally and automatically. Also adding new notes is very simple. It is all handled internally. Sending the data for the new note to be started up happens inside Galera so you don't have to take a snapshot of your existing database and ship it to the new server to start it up. All of that is taken care of for you. And it is also possible to use both existing monitoring tools and Galera where tools to monitor your cluster. Galera is configured entirely using MySQL command line options and it provides counters and status variables that you can plug into your existing monitoring infrastructure. So there is no need to have any additional monitoring tools to make sure that your cluster is running correctly. And another benefit for administrators is the ability to have backups in various ways. Some of them are taken from MySQL. You can use extra backup MySQL dump, you name it, to replicate your stuff and backup your stuff but you can also use a dedicated Galera note for backup purposes which gives you additional flexibility as to where your backup will be, how often you can take it, things like that. If you have a dedicated note for backup then your existing notes are less disrupted by taking the backup and the IO operations that backing up may require. And to have benefits for end users there is no longer need to do read-write splitting because every note can accept reads and writes. Instead of trying to engineer the application around splitting reads and writes and sending the reads to the replicas you can just concentrate on having proper transactional behavior, just have nicely formed transactions and the Galera takes care of the rest. And also with MariaDB 10.1 you get Galera out of the box so you can start with a single note cluster and expand without having to reinstall any packages. You can start even with MariaDB that has no clustering at all and if you feel the need to add a second or a third note you can do this using your existing MariaDB packages. And there is no need to think for master's primary secondaries the cluster is one and the same logical thing. So how do you give those capabilities to your users? Galera can be deployed in various ways. You can use commercial products like cluster control by several nines. You can use Ansible and Chef scripts which are available on GitHub by various parties and since it is configured entirely using MySQL My.cnf you can use any tool you want that would work for MySQL to start Galera clusters. We also hope to see Trove support very soon and you can also use juju charms to start up your clusters. And what is juju is a technology to deploy entirely formed clusters of applications and then connect them to other deployed products. For example if you start a Galera cluster with juju then you can link this deployment to for example a media week deployment that is also started with juju and they will connect to each other internally without you having to configure anything. It all happens inside the tool. So what we do here is first we provide the root password and an SSD password which is like the shared secret that nodes use to connect to each other. And then with juju deploy we take the required files from Bazar, from the juju charm which is a package definition of what a Galera cluster needs to do in order to start a cluster. So with this single command line you basically get all of the things that you need and your first server will be started and trending. So here we have on top the virtual machines. The first one is used by juju but the second one where you see pending is the virtual machine that juju started for us when we did juju deploy in order to install the first Galera cluster node. And after it is done you see that you have a started virtual machine and a started Galera cluster and it has an IP and you can connect to it. And then comes the interesting part. If you do juju add you need Galera it will start the second node for you and automatically connect it to the first one to form a cluster. All of that happens internally and so when you do juju status you see that now your Galera cluster has two separate nodes and they are a single cluster and now you can either connect to them and use them as a MySQL server or you can add additional juju charm like media wiki for example and tell it to connect to this instance of Galera and internally they will negotiate whatever is needed for the two products to connect. And here we run the MySQL client and we see that our cluster size is two. If we repeat the add unit operation several times we will get even more clusters in our I mean sorry even more nodes in our cluster just with a single command. And then you get the IP and with juju expose you open the IP to the outside world and here you have a function in cluster with just a few commands and just two lines in a configuration file everything else is in the bazaar repository automatically downloaded and configured for you. Thank you. Any questions? Yeah? Well, if you take a backup as long as the node on which you're taking the backup does not slow down considerably the cluster will continue to function. Yes, yes there is. So the node gets temporarily desynchronized from the cluster you can take a backup, you can shut it down and then you can have it rejoin the cluster, yes. Which implies that on your load balancer you should also remove this node from the rotation. And we have Galera where proxy called MaxScale which would be able to do that for you. MaxScale by MariaDB. Any other questions? Thank you very much.