 Hi everyone, I'm here today to share with you some developments we've made in my SQL regarding the safety of the replication stream and how to protect data that is being replicated. So, what is exactly the problem we are trying to solve? So, usually a slave just applies the events that the master sends despite the content. It doesn't check for privilege, nothing. So, we just want to mirror the data that is on the master and put it on the slave. So, this is fine in most cases, but after we added a multi-social replication, we added a bunch of new use cases, like we could use this for data aggregation or data consolidation. So, we have a lot of data from different servers to be replicated into the same slave. So, at this point, we have big organizations that have multiple data entry points and they need to aggregate this data and consolidate it into a single database, for instance. And since the slave doesn't have any tools to enforce rules on the data, this may break what you are trying to do. So, basically, we try to implement a set of options and features that could make the slave protect himself. So, we needed to ensure that data is being encrypted, both on the wire and on the disk, that DML and DDL statement-level privileges can be enforced on the slave, so that if I don't want data to be deleted from a table ever, I do not accept a delete statement. And that the differences between the servers configuration, the master's configuration, do not clash while we are consolidating and aggregating the data. So, how can we accomplish this? So, basically, we use a set of options. The first one is we should use always encrypted channels. So, we should turn on the SSL encryption and always use deleted supported versions of the TLS and SSL. So, this has been around for quite some time. Also, we should always use encryption on the binary log and on the relay log. Even if we try to, at an organizational level, try to say the master should not replicate sensitive data and whatnot, that could still happen. So, we should comply with data privacy laws. So, we should turn on the bin log encryption, actually. So, we can do it in three ways. Parameters, when we run the MySQL D, we can just set it globally in MySQL shell and persist it or add the configuration to the config file. We can always use a performance scheme to check if our encryption is on and properly configured. So, a third step is to only allow for role-based replication. So, allowing specific replication makes us reexecute the statements on the slave side. And this can be a problem, especially if we are trying to impose data-level rules that can be overcome with significant replication. A few examples like stop procedures or functions or the loaded data event and command, which makes us write the whole file into this and then execute it. If we use role-based replication, this doesn't happen. We do not reexecute anything. We just apply the rules and the data changes. So, how can we accomplish this? So, we added a new option to ChangeMaster. So, you can actually do this per channel. So, you can have some masters you trust more that you may not use it. So, we just use the option and just use it one and then on this stream, the slave will only accept events that are in role-format. So, the slave does not filter out statement-based replication. So, if a statement is received, if an event is received in segment-format, the replication will stop and an error will be logged. We can check the value of the option again using performance schema. So, we can check it. Next step. So, we have an option in MySQL. It's called SQL Require Parametric Key, where we enforce that a table needs to have a parametric key. So, when we are replicating data from master to slave, usually the default behavior is that the slave will just set the value for the session, for the player session that comes from the master. So, if the master is running with SQL Parametric Key to one, the slave will set it to one and then apply, apply, apply. What this makes is that different masters may have different configurations. And if we are replicating to the same slave, it may happen that we have distinct behaviors and we are not being able to say, on the slave, I require this or I do not really require this. So, we introduced this new option. If we set it to one, the slave just disregards what comes from the master and will always check for a parametric key. If it's too off, the opposite behavior. So, the slave will just disregard what comes from the master and will not check. So, we should, if we are trying to protect our slave, we should always put it on all channels to one value or the other value. There is a search value for the option which is stream, which is the current behavior. So, if it's set to stream, we are not protecting anything. So, just on and off. Sorry? If the option is stream, we just set it, it's the current behavior. So, the slave sets the option for the session. That comes from the master. If it doesn't come in the event stream, it's not an issue. Yes? Okay. So, again, we can use the performance scheme to check the value on our option. And finally, the final step. We can start using the replication applier. We can enforce the replication applier to run within a given user security context. This means that the applier will actually do previous checks on every event that comes over the wire. So, this is, to set it up is quite simple. We just create a user. We need to grant this new privilege to the user because we are saying that we are allowing the user to be used as the context for the slave applier. Then we can grant whatever set of privileges we need. So, if we don't want records to be deleted ever, when we are putting the data, we just don't need, for instance, the delete privilege. And if some delete event appears, replication will just stop, okay? So, this is a way for us to say, okay, this channel will just have these privileges to apply the data. So, yes? Will stop for that channel? Yeah, the full word, so that statement will just stop. So, yes. If a privilege check is not successfully, it will stop, yes. And error logging will be sent to the error log. It will stop for that channel, okay? Not for all other channels. So, we can, again, use the performance schema to check the status of our option. So, some references of the manual and some blog posts that discuss all of this in detail. And that's it. Any questions? Just one thing, I played with Rep Server with Sybase like 12 years ago. Sorry? And one of the features it had, which is your, this is very similar to features that were available there, was that something I used when I was at a previous job, was to ignore the statements. So, for example, things that are up on the consolidated system we didn't want to do with crop tables or to delete data. So, we basically said, if you see a delete, just ignore it. Okay. And they didn't generate an error. They said, oh, I've got to delete these rows. Well, I won't. You obviously then have to set up your tables to have the structure to support that. But if you do that, then you just say, okay, it's a truncate table. I won't be allowed to truncate. I'll just ignore it. Okay. And that allowed things to flow through completely cleanly with, on the upstream system, the ROTP systems, deleting stuff, truncating tables, doing things which made sense for the ROTP types. But the analytical part just ignored certain things because it didn't make sense and didn't want to remove that stuff. Okay. And that was very useful. A feature like that, I could see being useful also here in my SQL. Yes. Yes. In raw base, it might be complicated. No, because we're representing exactly the same thing. You may need extra columns or you need to do some things to make it, to make the aggregation work that way. But clearly, often you don't want, in some types of systems, you just don't want to delete the data. As long as you don't overwrite the existing data to generate new rows which don't overlap, you obviously have to design your data model to handle that. Then you can do something like this very well. Because if replication breaks, that's... Yeah, that's what I was asking about earlier, right? But they didn't ask people. No, they look like nice things and I can see a lot of people or some people having a new space for that. Thank you very much. Thank you.