Luis Soares, Senior Software Development Director and the "face" of all things MySQL replication, drops by to enlighten us about group replication and its different uses in the MySQL ecosystem. --------------------------------------------------------- Episode Transcript: http://insidemysql.libsyn.com/mastering-mysql-group-replication Mastering MySQL Group Replication 00;00;00;00 - 00;00;31;20 Welcome to Inside MySQL: Sakila Speaks, a podcast dedicated to all things MySQL. We bring you the latest news from the MySQL team, MySQL product updates, and insightful interviews with members of the MySQL community. Sit back and enjoy as your hosts bring you the latest updates on your favorite open-source database. Let's get started. 00;00;31;23 - 00;00;58;27 Welcome to Inside MySQL: Sakila Speaks. I'm leFred and I'm Scott Stroz. Today we are joined by Luis Soares. Hi, Luis. Hello. Hi. So, you are the MySQL replication team lead. You are responsible for the MySQL binary Logs replication related code base and MySQL bin lock tool. Yeah, that's correct. I'm happy to lead a bunch of very great people, very knowledgeable people. 00;00;58;27 - 00;01;22;22 So that thing comes easy. So, we all know you as the face of all things application in MySQL and this is why you are also the responsible of HA, point in time recovery and channels in MySQL HeatWave. So, for HA, we decided to eat our own dog food and am I correct HA in MySQL HeatWave is also using group replication isn't it? 00;01;22;24 - 00;01;52;10 Yeah. So along with the other OCI technology, we use group replication under the hood to build the fault tolerant DB system in in the MySQL HeatWave database service when deployed in single primary mode. By the way, a "DB System” for those that are wondering what it is it's the abstraction that captures all these things that are managed by the service on behalf of the user. 00;01;52;12 - 00;02;22;19 Like setting up replication, keeping everything running perfectly fine. Orchestration, orchestrating all these things related to backups and so on and so forth. In terms of how businesses can benefit, what are some of the benefits of using group replication. In the MySQL HeatWave services, there's the DB system. That's what users relate to. And under the hood we have group replication to provide fault full tolerance, right? 00;02;22;21 - 00;02;51;09 Group replication at its core relies on a quorum to commit a transaction and therefore if the primary server fails within the cluster, there is this guarantee that it's if there is a survive, there's a majority surviving this failure event, then the changes that have been produced so far will continue to be in the cluster, right? So, in other words, the data is preserved. 00;02;51;12 - 00;03;34;13 If there is a surviving majority in the event of a failure. The act of switching over the application when a failure happens is also relatively fast, because if there's a failure, there's a standby in the cluster ready to take over. So, we call that a secondary. So, usually, the time is relatively fast. So just for clarification, when you say as long as a majority of the nodes are unaffected, so you're saying like if there is a 5 node cluster and two of the nodes go down, then the transaction is still going to be committed, correct? 00;03;34;15 - 00;04;05;27 Yeah. In group replication, it happens like that, right? As long as you have the majority surviving the failure, the change will be carried on forward. Right. In which case in the MySQL HeatWave service clusters typically have three nodes primary and two secondaries. And so that's how it works. I think also it's because as we are operating this, when we have one failure, our guys can jump in directly and fix everything. 00;04;05;27 - 00;04;31;13 So, we don't need to have too many nodes there either, I guess, right? Yeah, it's I think so. It's a combination of automation and sometimes manual work. Right. So, since your team Luis is operating all the clusters in MySQL HeatWave service did group application got some improvement related to that? Yeah. I mean over the years group replication has been always evolving, right? 00;04;31;13 - 00;05;20;28 And with this with a need to power a cloud service, of course group application had to be...well it had to keep up with that right with that task or with the requirements for that task. And therefore there's has been a lot of enhancements to observability, especially with, especially with memory, more memory, implementation. So, I think over the years, if you look back into what are the replication performance schema tables, what are the replication related stages, variables and so on, you'll see an increase of, of things that have been instrumented and exposed through new columns in performance schema tables or new stages variables. 00;05;20;28 - 00;05;51;10 That's these things are extremely useful when you're when you're running things at scale. ...
