 I work for MariaDB Corporation. So, in the legacy altar, how the altars are going to be is currently handled this. So, whenever we execute the altar on a master or source, it will be executed or executed fully on the master first. Once the execution completed, then only it will be returned to the bin logs and it will be flown to relay logs and it applied on the slave and again it will be executed on the slave through the slave SQL thread. So, during that period we may face the replication SQL thread will block the replication for that time. So, during that time we will be facing the replication lag and delay in the replication. So, when you have multiple slaves, multiple replicas for your master, you will be facing replication lag for on most of your replicas, you do not get the real time data. So, to avoid this in current situation, we are mostly using lots of tools like PTO, Percona online schema change and then even GitHub has one tool called GHOST and Facebook also has its own tool. There are multiple tools available in the community. So, like always MariaDB comes up with some innovative method to solve this issue, to handle this and reduce the replication lag. So, how MariaDB is trying to solve this is, so whenever we start executing an alter table on a source, it will be divided into two bin log, in the bin log events it will be divided into two steps. So, like how we handle the XA transactions like XA prepare and XA commit or rollback. So, how we handle that in the replication, the same method we are implementing here. So, every alter has a two events like start alter and then a commit or rollback alter command in the bin logs. So, when the alter is started executed on the master, immediately when immediately there is a start alter event or return to the binary logs and send to the slave at the same time. So, in the slave, the requirement in the replica is you need to have a parallel replication. So, once your event was sent to the replica, immediately there is one more SQL thread which applies start, start executing the start alter command. So, it would not block the replication for that time. Once the alter is completed on the master side, there will be an event called commit alter will be sent to, will be logged in bin log and send to the replica. So, once the commit alter is received on the replica, immediately the commit alter command will be applied and then the table structure will be changed in the replica until that time you cannot see the table structural changes in the replica until you receive a commit. In case if your alter fails, you will get a rollback event on the bin log and the the alter command will be rolled back on the replica. So, on the next few slides, I am going to see the implementation details, how it was implemented in MariaDB. So, for this we have a variable called bin log alter two phase which was introduced in introduced from MariaDB 10.8.1 onwards. So, in the master end, we just need to set this variable before running the alter. So, once we set this variable and execute the alter on the master, the behavior on the alter on the master does not have any changes only in the bin log we can able to see the start alter or commit alter events. So, once the alter got a lock and started executing immediately the for example, this is one of the event for a successful alter and commit in the MariaDB. So, immediately the bin log will get a start alter start alter start alter event on the bin log that will be sent to master and in the master this this alter will will started executing without blocking the SQL threads. So, those who are not familiar with the GTAD implementation in MariaDB, the GTAD implementation in MariaDB is little bit different. We use we use go we use domain ID and then sour ID and then sequence this three variable which you are seeing we are like GTAD 1 dash 1000 dash 784. So, one is the one is the domain ID 1000 is the sour ID 784 is the sequence. So, for the start alter for the start alter you will get the event with the GTAD plus start alter in the bin logs and then the the real alter command will be logged in the binary logs. When you get a commit alter commit alter you in the same binary logs you will get the you will get a new GTAD sequence as well as you will see you will see the ID for which which sequence it needs to apply. For example, in this case you can see the above the GTAD sequence is 784. So, in the commit alter you can able to see the commit alter ID equal to 784 this means this this commit is for the event which was executed for 784. So, once once the commit once the commit commit event was executed on the binary log then only you can able to see the changed table structure on on the replicas. So, what happens in between the when the in when when you are executing the alter command on the master you cancelled the you cancelled or it got failed what will happen on that case there will be a rollback event. So, in this case the star you will get a start alter command and it will it will started a started the alter on the slave. So, once you receive a signal from a master like it is it got failed or it got cancelled due to some reason immediately in the master binary log you will get a rollback event. So, that rollback event will be sent to slave and that alter will be rolled back. So, this all this all steps will be done in a background without no without knowing to the users. So, this is the implementation steps for lack free alters in MariaDB currently currently it is it started with 10.8. So, still it is it is in a development development stage. So, still there are lots of improvements or suggestions from the community is always welcome and then like already Daniel mentioned about this the MariaDB bin log current from 10.8 onwards either the MariaDB bin log is aware about the GTIDs. So, this start position stop position options are already available in MariaDB bin log utility, but previously we can able to we can able to pass the log positions in this variables, but now onwards you can able to pass the GTIDs for a start position and stop positions as well as you can the MariaDB bin log utility is more aware of the GTID strict mode as well. So, when you are applying applying your binary logs on any other server you can still enable your enable the GTID strict mode as well as and then if you use the verbose the 3 V symbol you will get a warning for out of order transactions. So, which we usually encounter when the replica there is some writes happened on replica and then the when the strict mode is enabled the usually replication broken replication breaks with this error out of order sequence. And then there are few futures about MariaDB comparing with the MySQL what are what makes different MariaDB. So, we have a audit plugin and then the system versioning table which which Daniel already showed and we have our Oracle compatibility mode as well. So, you can still create your procedures stored procedures functions triggers similar to Oracle, Oracle syntaxes and then spider storage engine which is which is very useful when you look for some shading you can shad your shad your tables using the spider storage engine and then sequence. Sequence is also one of the one of the options available in MariaDB not in MySQL and then the hot backup like Maria backup Maria backup this is a fork of Perkonos extra backup. So, these are the few additional futures available on MariaDB compared to MySQL. Yeah, that's it for me. Thank you. So, any questions sorry any questions? Okay, a couple of them. I will start. Okay. Hi, can you elaborate a little bit more about the spider storage engine like you know for example what how do you partition is it based on hash is it based on some other you know methods? Yeah, you can you can choose your partitioning method. Yeah, custom. So, I have a quick question. So, with this with this two phase ultra table that you have seems like you're moving away from this MySQL and Oracle atomic DDL. Does this mean that there's effort trying to support transactional DDL over the case where you could maybe have multiple DDLs and even DMLs that could get rolled back together or do you see that never happening? It's just a question of your opinion. Yeah, I understand. Transactional DDLs? No, for now I think even in our community there is one MDAO. Yeah, I think it's a little bit too far off. You know it's a start to make things smoother as case A, but yeah it's a big effort and I you know how it's implemented in Postgres and and that kind of thing and the tuples but yeah it's a big effort. This is the beginning for implementing transactional DDLs. Yeah, okay. My question if you start a altered transaction on the master in a two-phase thing and the master just totally gets killed and you restart it, does that mean the slave thread continues on and he's just waiting for a commit that never happens? Yeah, that is the current behavior. Yeah, so you just need to manually kill off the thread on the side? Yeah, so it's endlessly wait for the commit. Next question. All right, is there any more? So I have one more question that I've written down. I noticed in your diagram you had the fact that before this change you'd run the altar table would run on the would run on the source and then it would run on the replica and it would block replication. Does that mean that altar tables are logically replicated that you don't have some sort of physical replication of them or I mean you give just what? So it is a statement. Okay. Yeah, it is a statement. Whatever you agreed on the DDLs are replicated as a statement based in MariaDB and MySQL. Right. Okay, I was just curious. Yeah. Okay. All right. Any other questions? Is there a way to like pause and resume the altar operation? No, for now, no, there is no way. All right. Any other questions? Well, in that case, I want to thank you very much. Thank you. Interesting presentation and enjoy it very much. Thank you. Thanks.