 And I'm presenting here, basically, some basis of replication and some mixes that you can do with other replication setups, basically, and some migrations that you need or you want to do, how to do them. So mix and match is synchronous and for replication for advanced replication setups. So yeah, you can trust me. You can trust me, right? And honestly, I'm talking about migrations and stuff, but I'm not a DBA, I'm a developer. So sorry if I make some mistake. Support people, don't kill me, please. So basically, I will start with some background on replication and then some mixed setups and how to do some migrations. And starting from the very basic. In the beginning, there was a synchronous replication, so everyone knows this, right? You have a master, you write to the master, the master generates events that go to the bin log, these events go to slaves. Slaves are a synchronous and ideally, you want slaves to backup your data or to scale your reads. So writes go to the master, reads go to the slaves and you can read stale data on the slaves. So that's it. And then on 5.5, it was introduced as a synchronous replication. So basically, it's the same setup. You write to the master, you read from the slaves, the difference is that when you write to the master, you can wait for the slaves to acknowledge you. So ideally, the master will only commit, if some of the slaves are all the slaves, you can configure it, acknowledge that they cued some data or they are committing the data. So you still have master slave, but now, when you commit on a master, you know that the data will get on the slave. It's a cost that you can choose to have on writes, so your reads will be more synchronous. Also, early 5.7 GA, we had a multi-source replication. So multi-source verification added to the slave, the notional channel. And the channel is basically a connection to a master. And a slave can have several channels. So a slave can receive information for several masters. There is no conflict resolution. If you use this, we assume you know what you are doing. So basically, you can use this for aggregation or backup in several masters at the same time, stuff like that. And again, writes goes to the master, reads goes to the slaves, so business as usual. And finally, we now release SGA group replication. So on the group replication, you have notion of multi-master. Even you have configured it as a single master with secondary masters. But basically, there is a group where every transaction that you send to the group is totally ordered and received in every server at the same time, at the same logical time. So you can choose to write to several members at the same time. And basically, this is a distributed state machine. So everyone starts with the same state. Everyone receives the same information, so everyone does the same decisions. So we use that. Like Vitor was talking about sophistication. S sophistication uses that information to know what is concurrent and what is not. So ideally, you have conflict resolution on multi-master. Or you can choose it to have on primary master. And the same slide that our friend you presented, group replication. Group replication everywhere with automatic distributed recovery, conflict detection, and group membership. With automatic failover and fault tolerance. And you can write everywhere. And if your primary dies, the group automatically will choose a new primary. So you don't have to be concerned with that. And if a node suddenly dies, it's kicked out of the group. So you don't have to worry about that as well. So this is group replication. And we release it and you look it. OK, but can I mix it with the other group application solutions? Of course. So basic scenarios. So group replication is limited to nine members. But maybe you want to scale out to light cooking to 100 slaves. You can still do it. You can have a group with several masters. Either it is multi-master or single master, it doesn't matter. You can still replicate from the group and have asynchronous slaves. So you can scale out reads or do backups on cheap hardware, whatever you want. So you can read from the slaves. And the group will have automatic failover, right? If one of those guys dies, the group will adjust and pick a new primary. If you have that configured, slaves, not so much. So if you are replicated from one of those masters and your master dies, then you have to reconfigure the slave to connect to another master. At least now, let's see what the future brings also on this field. Then you can also do some stuff like data aggregation from different groups. No one stops you from having a multi-storey application from different groups. So you basically have an external slave that will be configured to have two channels and replicate from two groups. And again, you can use these for data aggregation, to do some backup on cheap hardware, stuff like that. More advanced setups include this, that is a common use case that we see. You have multiple data centers or regions. And basically, you have active groups on each data center. But you still want to replicate from one group to the other. As Victor said, it's not optimized yet. But you can have a group that spans multi-data centers. But we don't advise it because it's not optimized yet. But you can still replicate from one data center to the other in a circular manner. So you just connect one master from one data center to another and vice versa. You can use one pair of masters. I use two pairs here because if one of the master dies, then only one of the directions of replication is dead. The other is still working. And it's still a synchronous replication. But if you have different workloads or different users in different data centers, maybe you don't care that much in that delay. Maybe you can still control something. And for scenarios, maybe you have another scenario that you can't beat me or to the team and ask us if we ever thought of them or if we advise them or are against them. And now about migration. So the simplest case, right? I have a master slave set up. How do I go to multi-master if I want to? So here, what I did is that I have a multi-master slave set up with rights to the master, rights to the slave. And I choose to add a new member that is a slave to M1. And I start a group on it. I could also do this picking up a slave and starting group replication on a slave. It will be identical. But maybe you don't want that because to not disrupt the current set up. So you can have a new member start group replication on it, start replicating. And when M2 catch up to M1, you can start migrating other slaves to the group. And in a sense, the group is also a slave in itself. So as M2 is replicating from M1, it's disseminating the updates to the group. So S2 is also a slave in the group. So you can start migrating rights to the group. And basically, you also migrate another slave. And then you have this point here where basically when you see that the group catch up to M1, you cut the rights to M1. You wait for those rights to be replicated to M2. And then you just migrate the rights to M2. And now, you have an extra server that you can also add to the group. And it's there. So now you have a group. And you can still use it in master slave mode, right? If you use the primary configuration with scanners, or you can have a multi-master group if you want. Another use case, a stranger use case, but still interesting is I have different applications in different servers. Maybe I want to, maybe it's different charts and I want to aggregate the data. Or maybe it's several applications that I want to make a chain. But I don't want to spend that many servers on it. So I will just add these two applications to the same group, or something like that. So how do I do this? Basically, you start replicating from M1 into M2. And your application is still running, right? M2 will have to deal with a plate from M1 also with its old flow, right? So maybe that's a factor of decision between M1 and M2. And basically, you start a group on M2. We add a new server here that maybe people don't want to, but for two reasons. First, Quorum. So a group of two is always dangerous because of split frames. But also because there is a point in time where you will have to cut the rights to M1. And at that point in time, if you have application right to M1 and application right into M2, at that point in time, if you have only one server, then one server will have to serve two applications. So maybe you don't want that. So I add M3 to the group as well. M3 will catch to M2. And now you migrate the rights to the group. So M2 is supposed to have all the information from M1. So you take the rights from M1 and you put it on M2. And then you can also write to M3. Write and write of course. And then you join back M1. Maybe you want to do some provisioning of the data because M2 has all the data that M1 has, but M1 is lacking all the data of M2, right? So maybe you want to do some provisioning first from M1 and basically you add it back to the group. And now you have either several applications in a group with automatic failover or you have now two shards that are now one. And you can also do this in another way, but you can leverage a multi-source application and just add the aggregation with a slave. Start the group on the slave, add M2 to that group, and then do the same thing. So basically when S and M2 catch up to the load on M1, so S and M2 also have the data from M1, you can migrate the rights from M1 to the group. And now you also have a group with three members with all the data from M1 and M2. So maybe you try the application and it was not for you and you want to migrate back. This is a simple scenario, but still one that we must include. So basically you have a group, maybe it's primary master or multi-master, it doesn't matter. What you have to do is just, you stop group replication in one member, you configure it to be a slave of M1, so you still get the rights from M1. You go to member two, we'll stop group replication, you make it the slave of M1 and now you have master slave, right? And basically you read to the slaves, you write to the master business as usual. I guess I finished earlier, but that's it. We've built group replication based on many of the technologies that we already have. So yes, we have group communication, where for example recovery on group replication is based on master's slave. It's basically a channel that is created on group replication to master's slave. So you can join many of these things. You can do whatever you want, you can have slaves into groups, groups into slaves, multi-sorts, whatever. SimiSync is, well, we don't know how SimiSync will come into this picture, but you can try it or not. I don't know if you advise that, maybe we don't advise that, but maybe we'll try that in the future. So basically we are GA, so you can download our packages from the website. Documentation is also there, maybe we are improving it, and there is our blogs on MySQLIavailability.com with all the new stuff that we are developing, so we have a long path to go. So here is my dolphin that Fred all loves, and I'm on Twitter, I don't tweet that much, but you can reach me there, I will respond to you, I guess. And thank you. If you have any questions, I'd leave so. What setup? For example, master's slave to multi-master. Why do you have to, oh yeah, not migrations, yeah. Yes, because you never mess with the master, right? Yes, there can be some seconds of some time here, so. But yeah, that second, so yes, you have to be careful here. Basically here you have to wait for a moment where your group is really, really close to the master. When the group is really, really close to the master, then you have seconds of some time, maybe. Yes, because the member did not fail, the member choose to leave. When the member choose to leave, there is no split-friend scenario, because the group knows that he left. Yes, much. Vitor was talking about that earlier, so if you have a group, maybe you have two members in one data center and another member in the other, these two guys can, when you write to these guys, these guys have the quorum, so they don't need to wait to this guy. But eventually the group has to, you can only send that much message until it tests to catch up with this guy here. This guy here eventually will be a source of content. So that's the thing we have to improve in the future. It will say I'm not available. We are improving that. Again, he has a problem with some issues with that, because nowadays we've locked, basically. Instead of having two pairs, you have this guy also connects to another and another, and this guy... Yes, you... Yeah, only one way. Yes, you can connect all the masters to all the master, basically, with master sleep. You can do that, because then the GTID's mechanism will skip all redundancy. Yeah, you can do it. You can connect to more than one master. These are different groups. Each one has... That's all.