 Just now Rikki has explained the basic replication architecture, we explained like what are the basic components that are present within MySQL replication, so how exactly replication happens. So, I will directly jump into the latest replication enhancement that we have in MySQL. So, before that this is the safe proper treatment, let's have a look at it. So, first I will see, I will just explain what are the major features that went into MySQL 5.7 delays and briefly explain about each of the features and the importance and then we will have a look at the current WMLstone releases like what are the important features that went in, we will briefly discuss about each of them. And then what is the next roadmap that we have for MySQL replication. So, first we will discuss about online reconfiguration of global ramization. So, everybody use a term called GTRD, what is GTRD? If we see the MySQL traditional replication, all the updates that are happening on the master are returned into a log called binary log in the form of events. So, if we have to locate a particular ram section, we need to go through the file and then we need to identify the starting position of the end position. So, it becomes cumbersome. So, what we have done is, we tried to group the set of events as in when a transaction commits in the EOD engine. We have given a logical number with the transaction that is called as GK. So, what is the use of this global transaction identifier? So, he already explained that he provides a seamless failover mechanism. So, whenever there is a failure, we want to make sure that there is very much less downtime and we can do it with less amount on it. We don't want users to look into the binary loss and go to the final position. So, it should happen automatically. So, this GTI is help for the procedure. So, for example, we have one master and there are two slaves that are getting replicated from this master. In the event of a failure, this GTI is help us to identify which is the slave, which has the latest transactions, which has more number of GTIs updated today. So, you choose the server which has more number of GTIs being executed on it and you promote it as a master. And during the failure also, the slave, when it connects to the new master, all it has to say is, make use of the GKB auto position protocol. So, once you say that auto position is called to work, so it takes care of sending what are the transactions that I have on the slave and then it sends that to the master. So, master says, OK, there are these many transactions, such and such and whatever is missing and the rest of them. So, the failure has mechanism has become very simple with the introduction of GKBs. So, this feature was introduced in 5.636 and then when it was initially introduced, so how it was used, it required that all the servers to be saved and then you have to bring down all the servers and then enable GKBs and all the servers and then bring them up once. So, this requires lot of downtime. So, in production, you really can't do that. So, what we tried is, we wanted users to do it in an online fashion. So, how we can do it? So, when we are configuring this GKBs online, so we can have reads and writes in progress, no need for this to synchronize all the servers and no need to restart them. It works and if there is any problem with the application process, we can read the process there and we can go back and fix it right and up and running how do you run on the GKBs online. So, we do it in a step-by-step process. If we see GKB mode has only two possible cases, either we have GKB mode on or you have GKB mode off. So, when you say on, all the transactions should have a GKB associated thing. If you say off, none of the transactions should have any GKB associated thing. So, how do you switch from one stage to another stage? We cannot do a diet switch. So, we do it in a step-by-step fashion. So, first what we have to do is on all the servers, we set the GKB mode is equal to off one message. So, in this stage, we are letting every server know that okay, we are in anonymous transaction mode, we don't have any GKBs with it and we are doing it in a step-by-step process. So, we are able to accept GKBs transactions, but all the new transactions that are originating on this server will not have any GKB associated. So, we slowly make them use to this GKB. And then the second step is on all the servers, you said GKB mode is equal to on one message. So, with this step, whatever the transaction that is originating on the server will be associated with the GKB, but still we will be able to consume the anonymous transaction services. So, we are in an intermediate stage. It can be like some are anonymous, some are GKBs, but the server won't complain at this stage. So, it will be able to consume it. Once this setup is done, you wait for replication later. Assume that you have executed this particular transaction now. You wait for this to be replicated on all the servers and you wait for it to be consumed. Once it is done, we just set GKB mode equal to on on all the servers. So, now we have enabled GKBs on all the servers. So, there are very nice blocks that are done at first, which explain why we have to do this in step-by-step way. So, you can refer to the blocks all the time. How do we do that? How do we wait? Basically, for example, you have done this GKB mode equal to on on the master. You get the show master status. You execute on it. You identify what is the transaction filing and position where are you executed this. Basically, on all the slaves, all the setup, you wait for all the burners to be consumed by this, till this position filing. Assume that you have executed this step on winlock file one at thousand position. So, you wait on all the servers, each at that you have consumed till this. So, that's a manual process. Yeah. Okay. Next comes locking-based parallelism. So, what is this parallelism? So, if you see on master, there can be several clients that are connected to master and they can be executed, transactions can be executed parallel to master. But when it gets replicated to slave, on the slave side, traditionally, we had only one receiver thread and one uplayer thread. So, all the parallelism that was there on the master was getting lost on the slave. So, the slave was lagging. What we have done is, in our initial versions of MySQL, we have introduced parallelism based on the databases. If two transactions belong to two different databases, then they can be scheduled parallel on the slave. But it requires that your data to be spread across various databases, that limitation on that. Only transactions that belong to different databases can be scheduled parallel, but still we are not achieving a higher throughput today. So, we have come up with locking-based parallelism. So, with that, if we see, what we have done is, we have done a simple experiment where we have simulated X amount of load on master and then we have taken the time to apply those transactions. And we, when the same data was replicated to slave, with the locking-based parallelism, we were able to see that the slave uplayer thread has performed drastically, throughput has gone up. So, earlier the single thread and slave uplayer was very slow, with eight threads, it is able to apply faster than the master. Like, as and when the threads are increasing, the uplayer is able to cope up with the master. It is getting the same performance as the master. So, now the slaves are faster and they are not lagging behind the master. So, how exactly this locking-based parallelism? So, what happens on master is, assume that there are two transactions which are entering the commit stage at same number of times. So, if two transactions are in the transaction sequence, it enters the commit phase at the first line and transaction two has started its commit during step two. But they have not completed the commit process. So, when two transactions are simultaneously at the commit stage, that means they don't have conflicting laws. They have independent laws. So, such transactions which have independent laws are grouped together in the binary law and they are associated with some information. So, this information is sent along with the binary law for the slave and slave, when it sees this group, it thinks that they can be scheduled parallely. They don't have any conflicting laws and it will be applied on the slave parallely. So, we make use of this locking-based parallelism to achieve higher performance. Next comes multi-source replication. We already came to know about the architecture. How the multi-source replication looks like. So, we have one slave which can replicate for multiple masters. So, the best use cases are you can use it for integrated backups and you can do your analytic related work on the integrated slave on the slave. So, it acts as a data hub as well. And this multi-threaded slave is integrated completely with multi-threaded slaves and crash-based slaves. So, when we say it is integrated with multi-threaded slave, let us see how it works. So, this is how, let's have a scenario. There are three masters and they both are, all three of them have only one slave. So, for each replication correction between master and slave, we have a separate sender thread and we have a separate receiver thread and separate uplayer thread. So, all the combination of sender, receiver and uplayer threads, we call it as a channel and each channel can be independently configured. As you get master one, you want only two uplayer threads to be configured. You can say that I want, for the first channel, I want only two uplayer threads. For the second channel, if you want four uplayers, we can configure. So, that way, we can individually monitor and change each of the channels. We can control each of the channels independently. Information about these multi-source applications, uplayers, workers, all are available. For each coordinator related information available in the coordinator performance schema, for each channel specific worker information is available, uplayer status is available, and for each channel, the receiver thread information is available in the connection status table. So, when it comes to the number of sources and the number that we can replicate, actually there is no limit, but still we have put a cap of 256 and each source can be configured separately. So, those are the main features that I wanted to discuss in GA release. So, now we will have a brief look at the current DMR, sorry, the development release. So, what are the enhancements that we have done? So, if we see that MySQL replication has three different formats of replication. One is the statement base one is row base and the other one is mixed format. So, when we are using the row base replication, earlier there was no way for us to know like how far my row base replication event has been updated. For example, you have, for insert we have write rows and for updates we have update event and for delete we have delete event. So, when there is a bulk insert or update going on, we don't know how far the insert or the update has progressed. So, now we provide the information through a performance schema table that is even stages current I mean earlier Maya explained. So, if we vary the table, it shows that, for example, this is a bulk insert scenario. So, there are 200 inserts that have been happening, but at present it has update 98 transactions. 98 rows have been update and still we have to update the remaining set of rows. So, that is a very good improvement with respect to getting to know about the state of row base replication. And the last one is like setting the GKID purge window. So, what is GKID purge window? So, as in when see all the updates that are happening on the master are written to the binary lock. So, we cannot always keep all the binary locks. It will consume most space. So, what happens is we will be purging them from time to time. So, when the binary locks have purged, the set of GKIDs that are present in the binary lock are stored in a variable called GKID purged variable. So, if we have to set this variable, earlier there was a limitation saying the GKID executed should be empty. That is if you have to set a GKID purged variable, you can do it only on a fresh server. If the server has I mean already is up and running, you cannot set this GKID variable. So, what is the basic use case of it? For example, you want to take a backup and you want to restore it on a server which is up and running. Earlier that was not possible, but with this GKID purged variable online setable, we are able to do that. So, how do we set this GKID purged variable? We can set it as different sets or we can set it as with single assignment also. So, I will show example like how to set it. So, for example, let us take two servers. So, both are up and running both how GKID is enabled. What we do is, we are taking a backup on the first master. When we take the backup, so the backup contains all the required data and since we have a copy of the data, we do not require the GKID specific information. So, we know what are the set of GKIDs that were present in the data. We make a mark of the set of GKIDs that have been purged or executed and we store it along with our backup. When we restore the backup on a server 2 which is up and running, what we do is, the previously executed GKIDs will become the set of GKIDs that were purged. So, you can do this now even when the server 2 is up and running or it has GKIDs enabled. Earlier, the server 2 should be a fresh save. So, that is the advantage. So, for example, how we can set it? If we do a select of this GKID purge, remember it is empty. So, we can set it plus syntax. There we say that set GKID purge is equal to transaction 1 and then we can do a select on it and we can add another set to it saying that 1 to 10 we can do a select. That is how all the GKIDs are grouped. So, what is next with respect to MySQL replication? We are trying to improve. When we are planning to integrate more replication-specific data into data dictionaries and we are trying to make it more usable for users and we are trying to provide more instrumented information and performance schema tables and make the administrative commands simpler. And we are still working our best to improve the multithreaded slays of player performance improvement and that is all. So, we are going to go. We would request everybody to download the latest packages from dels.mysql.com and try out our latest lab releases as well. So, please look over to the MySQL documentation for additional information. We always have www.mysql.com where all the blogs of MySQL documentation are available. Any other questions? That's all the time. Is there anything like channel-based certification like MariaDB you are going to add in your roadmap? Yeah, at present we have the distributed and limited global level and it will be, we are working on version of the split filter that will be released. And also the replicate way like DB. That will be also helpful when we are using multi-source application because in some scenarios for example in my case we are having we are having a database for different countries. The database name is same. In MySQL we cannot do it. So, in that case we are using MariaDB for that. It will be very soon available in the version of the split filter. And also because of the GTL it's like the self-GTL approach and that's right. The example Next one This one I cannot understand. The GTL is the first value which you are setting. That should be the UUID of that server right? That cannot be reduced because I mean it's just for an example that I have chosen that way. It's a UUID. Yeah, it should be UUID. Yeah, it's just for example. It should be the server UUID. For channel replication because we are working in the community at least I think we will discuss sometime about MariaDB on the slave which can use different data fix. So, after the presentation I would like to hear for what purpose you are using MariaDB that cannot be done. That is the use case I told you. We are having that we are posted the same product from different countries but the data fix name is same. For example, the data fix name is A and Thailand the same for people in the data fix name is A. When we are doing multi-source and mysteries how can you do it? From this channel you do a real review. For your country who wants to re-read the review? For my country it's not channel based. Once a channel based it is possible. Multi-source is usually multi-source application. Every database is the same. While sitting on a centralized repository they have the same name so there will be a question how you can do this. After Perchana 5th we are working on it. So MerylDB is Focker MySQL so how does it work? MerylDB is Focker MySQL so how does the code work? It has a contribution from the community so they have more added features. They have their own separate repository actually it's started from the main master from MySQL but now they have their separate repository and they are maintaining it. They have different set of features like MySQL is a parent and they have separate child Perchana is one, MerylDB is one. So I mean is it? Is it going this way like this? And there are certain databases which is actually a proprietary like 8 of 2 has been released sometime back Aurora which is not open source but right from the MySQL. So MerylDB is both from Anomaius with Firefix so how does it work? Does MerylDB look at all the new code changes in MySQL? Can I say that? MerylDB can answer that. Do you look at the changes in MerylDB? No. The way I murdered MerylDB is a divergence of the master from MySQL Yeah, they have changed the GTA concept which is in MySQL and MerylDB is totally different. Yeah, right. So there are a lot of differences. MerylDB is MySQL So something which you find in MySQL you cannot find it in MerylDB by itself. I think the simpler things is to do the same. Yeah, the basic things are changed. But we are pushing only. There are a couple of differences actually. They are moving away from 5.5 as we mentioned. They are moving away from 5.5 and MerylDB is their own source code. So the forms are they compatible? Not really. So the one written by one cannot be read by the other? They have some new factorality and you cannot use it in a previous project or any other database. So any other questions before we end this thing? Come on. Okay. Yeah.