 just a developer. Start learning database administration information. My name is Ligaya Chamelle. My official Oracle title is Principal Technical Support Engineer. My SQL. I swear this thing gets longer every time. Here's my email address. If you have any questions, feel free to either hit me up on my email address or on my Twitter handle. And I will answer your questions. I will always answer your questions if you have and if you send them over to my email address. My Twitter handle, I would love if you would tell me how I did on this presentation. Did I do well? Did I totally suck? Did I bomb? Let me know. And if I sucked and I bombed, tell me how I did it. What I did wrong, what I did right, because I give these kind of presentations. And if you don't tell me what I do well, I can't improve on them. And if you don't tell me what I do bad, I still can improve on them. Okay. This is the Oracle Safe Harbor statement. I am required to show this whenever I do a presentation. So we're just going to sit here for a couple of seconds while you read it. And this is my agenda for our talk today. We're going to be covering over four areas. I'm going to be talking about MySQL access control. I'm going to be talking about how you're going to methods of collecting diagnostic data from MySQL. I'm going to be talking about the various log files that are available within MySQL. And as a database administrator, one of the first things you should be doing is doing with backups. So we're going to be talking about those as well. Just to let you know real quick, the slide deck will be available publicly since I have 45 slides for 45 minutes, so we're going to be moving fast. Don't feel you have to take notes or anything like that because the slide deck will be available for you later. OK, so let's start now with access control. Access control in MySQL has two distinct phases. The first phase is the connection phase. That's when your client's connecting. What the first thing that MySQL is going to do is it's going to ask this client that connects, who are you? And the client's going to send it its information. MySQL is going to look first at the host information, not the username, the host information that you are connecting from. Now, the reason why I'm accentuating the part that you're connecting from your host is so if you have a connection problem where you are connecting as a different user than you thought you should be, it's more than likely because of this method that it connects. The way the connection is checked for the MySQL is that it'll take the host that you are connecting from and it's going to be as specific as it possibly can. Whether that means a host name, whether it means an IP address, whether it's the local host, whatever, it's going to take that information and it's going to go to the MySQL user table. It's going to pull that up into its memory. It's going to sort the MySQL user table by the host address from most specific to least specific. And then it's going to take the connection you're coming from and it's going to match that up on the most specific. So if you have a Bob able to connect from anywhere, he has a wild card host name. If he's connecting from a local host, they're still going to look at local host and then they're only going to look at the user names under local host. That's it. So Bob from wild card has the potential to connect as the anonymous user from the local host because it matched the specific local host value first. Understand that, gotcha? Okay. So once it figures out what user account it's going to match up from the host value to the user name that you're connecting it as, it's then going to ask you, oh, I totally screwed that up. This is the user account information. That was what I was talking about earlier with the host name and the user names. This is how you create them. Specifically, you're going to notice that over here in the create, the SHA-256 at local host, those are a user account names that you're actually connecting under. So when I said earlier, you're going to connect under the host name. That's the local host that you're going to be connecting under. And then it's going to look at that SHA-256 to try to match it. Quick things you need to know about the user accounts. If you're in 5.7, you want to use the create user and the alter user to create the user accounts. If you're on an older version of that, you could use create user. Alter user was an... Alter user did exist at that time, but it has very limited functionality. Prior to 5.7, you had to use another command that we're going to be getting into real soon. See, this is what happens when I'm not able to look at my presenter's desktop. I forget which slides are coming up next. Anyway, as I was saying, once it figures out what user account that you're connecting as, it's going to ask you to prove it. And that's where you're talking about your passwords. In MySQL, a blank password for a user account does not mean that any password will work. You literally have to give it an empty password string. Also, in MySQL, we now have the ability for you to expire your passwords. In the 5.6 and 5.7, the expression of passwords are available. In 5.6, you have to do it manually. So you have to explicitly say, expire this password for this user. In 5.7, you have the ability to set a policy for a password to expire like after six months, 180 days. That forces your users to have to change their password because the next time they connect, once their password expires, they have to change their password. MySQL is not very smart about this. This is still a relatively new feature. So if they change their password, there's nothing right now to prevent them from changing their password from their old password to the same old password. But it does make them change it. Officially. MySQL also has a hashing of the passwords. We have multiple authentication plugins that you can use for the hashing. You have the original native hashing algorithms. You have the, what was it, the SHA-256. We have PAM available now. You have the Windows native authentication is now available for you to use with your MySQL user accounts. We also have a password policy that you're allowed to use now using the Validate Password plugin, which is a community version. You can totally use it. Basically, if you use that for your native passwords and using the Clear Text Supplied Checker, it allows you to set up the strength of the password that you require the user to have. It has three levels of password checkings that you can be modified and a whole bunch of settings from how many lowercase letters you require, how many uppercase letters you require, do you require numbers to be used, do you require special characters to be used, do you require a specific length, all of that can be set by you to force your users into using a strong password. See, I told you we'd be moving fast, didn't I? OK. Next on Access Control, you're talking about Stage 2. This is where the client has come in now. It's matched up the user account. It's verified that, yes, they are that user. Now, what do you want to do? Do you want to select something? Do you want to create something? Do you want to... Whatever it is. What are you doing? Are you allowed to do that? And this is where MySQL grants come in. MySQL grants defines the privileges and account characteristics for the user accounts within MySQL. MySQL does not have the concept of ownership that other databases may have. Everything belongs in a global scope and the individual users have individual permissions for those database objects. So it's a little different conceptually than a lot of other databases if you're using those. In MySQL, you have multiple privileges that can be given to a user. So you can give them the create privilege, the ultra privilege, the select privilege, the super privilege, the insert privilege, the cult privilege, the function privilege. Whatever you want to think of, there's probably a privilege for it. So you can be very specific about what the individual users are able to do. You can do it at multiple levels. You can do it at the global level where they can do it to anything that's in the system. You can do it at the database level. You can do it at the table level. You can even do it at the individual column level, if that's all you want to give them for at least privileges. You also can give them... This was the remember when I was talking about the create user and the older versions, you use a secondary command to give them the account characteristics and stuff like that. You use it with grant. In 5.7, we're trying to move it all over to the create user, but if you're on a version earlier than that, you do that with the grant. That's where you can tell them that you require the client to connect using SSL. You can also set restrictions on those clients. You are only allowed to query this database X number of times so that way you can have flooding from the user. There's a various other characteristics you can set to them. It's all available in the manual. There are a number of pages going over the grant command specifically. If you're starting to handle user accounts and giving them access control and stuff like that, those are going to be pages that you're going to want to read really early on to get a grasp of what's going on. Here's some examples of grant commands. Show Grants will show you the grants for the user that is connected. On that one, in that case, it was Root, and it gives all the grant commands that they have. For Root, it has Grants All Privileges. That means I have access to everything on star.star, which means I have global privileges on everything. With Grant Option means that I can now give somebody else grant permission. That's another one of those permissions that they do. Here's down here. I'm asking for the grants of a specific user, in this case it's test.localHulse, which their usage is totally different than the Root, because if you look, they have the grant All Privileges on test. So in the test database, the test user can do whatever they want, but on no other database, they have it available. Now, if you're dealing with Grant, you've got to be able to revoke those privileges as well. That's what the revoke command is for, to take away the grants that you gave. The big thing about revoke that you have to remember is that it is not smart. It is absolutely stupid. It will not be able to extrapolate out any of the permissions that you're trying to revoke. I'll go over that in a little bit so you can understand what that means. Revoke also does not remove a user from the user table. You actually have to drop the user to remove them. And if you give revoke without giving a host name, it will always use the wildcard host value. And then when I say it won't extrapolate, if you have Bob at localhost and you say revoke permissions for Bob with no host values, Bob at localhost will still stay there, because Bob at localhost is not the same as Bob at wildcard. Here's a little bit of the examples for revoke. We have our test user again. I'm trying to revoke the delete permission on the test.t1, test database table one for the test at localhost. And I get a kickback, I get an error on it. Remember I said that it's not smart. Because my privilege up here says grant all, it will not be able to extract the delete out of the grant all. You literally have to revoke the all and then grant it all the permissions back except the delete. Told you it's not smart. This is kind of, it's a sucky part about the access. The user accounts, but there you go. It's something to help you understand if you end up doing these kinds of things. Quick note, usage just means that you're allowed to connect, it doesn't give you any access to anything but it allows you to connect to the account. Next, diagnostic information. As a DBA you're gonna wanna collect diagnostic information about your system. MySQL has what's called the show command and it is a specific MySQL command to get information about the MySQL system. You have commands using show to collect diagnostic information, sorry metadata information as well as server status information and there are metric crap ton of them. There are commands for just about anything. So, if you wanna know what databases are available within your MySQL instance, using the show command you would say show databases. You wanna know about what tables are in a specific database you use into that database and show tables. Let's see now, I got show databases, show triggers, show plugins, show create procedure. If you wanna see the create statement for a specific table, a show create table. Show grants, we showed that earlier. Show indexes, you wanna know the indexes that are on a table, show indexes for the table. That's why I said there's a crap ton of them. You have status, show slave status if you're using replication, show open tables. Table status tells you things like how many rows are in the table, how big the table is, things of that nature. All of these commands have their own manual pages that'll give you information about what the different commands go into. The reason why I'm telling you about the show command is so that we as a future administrator, you can go up and look and say there's probably a show command for that and you can hit the manual and go look them up. Now, along with the specific show command for MySQL, we also have the information schema. If you're familiar with other databases, you're probably used to the concept of these things. Information schema provides mostly metadata about your system. So you can get things like the process list, the variables, which are your server settings, the global status, which is MySQL keeps counters of everything that happens in the system that's part of the global status. And files, table spaces, data files, all of that stuff is available as part of the metadata. But inside the information schema, they also have a couple of other tables that are very interesting. Specifically, the NODB transaction table, the NODB locks table, and the NODB lock weights table. Those are big ones if you're probably having problems with your transactions as well as your locking. You're gonna wanna look at those. As well as NODB temp table info, if you're using 5.7 and using NODB for your temporary tables. As a beginning DBA, I highly, highly, highly can't stress this enough. Highly recommend you take a look at the Sys Schema. Sys Schema comes installed by default in 5.7. You can, however, manually install it in 5.6 if you have that. It was originally known as PS Helper and it was originally created by an old boss of mine by the name of Mark Leith, who actually works at MySQL still. Here's his website where it was information. There's the link for the downloads if you want to install it in 5.6 and you do wanna install it in 5.6. And the really cool thing about Sys Schema is that it takes the information out of the information schema and something I'm gonna talk about in a little bit called the performance schema. And it actually makes it into something human readable and easy to use for you. Now the Sys Schema has what's called paired views. So you have, for example, one of the views that are available in Sys Schema is host summary by file.io. So that lets you find out which hosts are hitting your I.O. disk most often. You also have the same name started by X and dollar sign. The one without the X and dollar sign is done in values that are easy for humans to read and comprehend. The ones that start with X and dollar sign is the raw data. That's actually like timers are in picoseconds. I want something actually in seconds or minutes, something that I understand, so I always use the original names. But if you have some kind of tooling or automation that you wanna throw onto or monitoring, you'd wanna hit the raw data, so that way you could use that. Examples of the views that are available with Sys Schema that you as a DBA would be interested in. Statement using full table scans, so that way you could look at your queries to find out who's doing full table scans for query optimization. Statements with run times in the 95th percentile that is queries that are running slow, the longest running queries. I.O. by thread by latency, which connections are hitting the disk the longest. Why are they? That would be something for you as a DBA to investigate. Memory by user by current bytes. What user accounts are using the most memory? Are they something that you need to investigate? And another one, schema redundant indexes. If you are doing dynamic, if you are changing your tables over time for tuning your queries, you're probably gonna have redundant indexes along the way. Why take up the extra space? Why have the extra maintenance involved with a secondary index that you're not using or is redundant? This will tell you which ones are set, where you could remove them, help optimize the use of your resources. All of the scheme is available through the command line, just like any other database. If you prefer a gooey kind of interface, MySQL workbench has an interface, community edition, doesn't even have to be entered about prize edition, to install and then look at this scheme of views and tables. So it'll list all the various views and reports that it has available and you can just click on them and then you have the information right there. Cool? That's why I said, SIS is fantastic for beginning intermediate and even advanced level DBAs because it's so easy to use and it's just built in right there. Now if you wanna be a hardcore DBA, you wanna look at the performance schema. Generally speaking, this is for your knowledge because as an entry level DBA, you're not gonna use a whole lot of this unless your back is totally against a wall and you're totally screwed and you have no other options. Performance schema allows for the monitoring of the MySQL server at an extremely low level which is good because it means that you have access to various times and information but it may, due to the way it is, it's by nature extremely complex. Performance schema uses the performance schema storage engine. It has information available on the current events that are occurring in the server and by current events that could be anything from a statement running to how a mutex is doing. You have event histories, summations, all of that is available through there. The configuration is dynamic. There is no change in behavior by turning on the performance schema on the server. It's all built into the server itself and you can query the performance schema using SQL. When using the performance schema, we have an entire manual section of course available for you to read and learn about. So here's your link for your general manual. If you want to help, want information on helping diagnosing problems using the performance schema, there's a manual page for that. And if you want to query, profile a query for whatever reason you have a query that's running slow and you don't know one know why and you want to know the nitty gritty of how the query is executing and the times involved. That's when you want to do your query profiling to be able to get that information. There's a number of blog posts available on the performance schema through the MySQL server blog and many, many presentations and webinars available. If I remember correctly, there is right now a webinar on the MySQL's on-demand webinars curving at least in part performance schema if you want to get an idea. Again, this is, performance schema is more for the advanced database administrator, but as an entry-level database administrator, administrator, you need to know about it because if no other reason than to have at least a general idea that this is built on top of it. So that's where you find diagnostic information. Next, log files. As a DBA, you had better know where your MySQL systems error log is. If you remember nothing else about this entire session, the single thing you need to know as a DBA is that you need to set your error log in a specific location and you need to know exactly where that is. I can't tell you the number of times that I have had customers come to me and say, I have problem X, how do I fix it? And I say, I need your error log and they say, where's that? Okay? Single greatest takeaway, set your error log, know where it is. By default, the error log is located in the data dictionary just out of curiosity. How many people even know where their data dictionary is in their MySQL instance? A lot of you people are gonna be looking up things, aren't ya? Just saying. So by default, it's in your data dictionary. The type of information that is logged in your MySQL error log includes things like start and stops of your servers. If you have a server crash, that will be logged in there. If you have critical errors on your server, that'll be logged in there. If you have my iSAM tables that are, who here's still using my iSAM? Oh, come on, fess up, fess up. Who's using my, I saw one person, okay. If you're using my iSAM tables and they crash, the only place, the only place it is notated is in the MySQL error log. It is not notated anywhere else. And if you have a server crash, you're gonna find, MySQL will always try to provide you with a stack trace for the server. Reason why I note the stack trace is because if you wanna know if it's a bug that crashed your server, you wanna take your stack trace and go take a look at the various bugs and try to match it up. Easiest way to find out if you hit a bug. Now, some people don't like having their MySQL error log in its own little thing. They wanna keep it in the syslog for maybe company purposes, whatever. As at 5.7, now you could automatically turn that on there with the log syslog to send your MySQL error log to your syslog. And in 5.7, we also have a, now you can set the verbosity of your error log. As a DBA, you will always want it to set that almost as high as you possibly can take it because nothing worse than a problem with your system and you have zero information on the problem. So you wanna have it as verbose as you possibly can take it. Error log, if you remember nothing else, you remember this. Okay, next thing that's a good thing for a DBA to know is about their slow query log. Their slow query log is your first line of defense in tuning your server. I don't care how much tweaking and tuning you do with your MySQL configuration. Tuning your queries will give you the single greatest performance boost on your server than anything else. Think of it this way. If you have a race car with a driver that is afraid to go over 35 miles an hour, no matter how fast that car can go, guess how fast it's gonna go? No more than 35 miles an hour. Your queries are the driver. Okay, so why would you turn on the query log? Again, it's usually done for performance issues. Generally speaking, as a DBA, you're going to want to be ahead of the problems. You wanna be proactive, not reactive. So it's good to occasionally, especially after you have a new functionality applied to your application. If you, I'm totally missing that word. Refactor your code or something like that. There you go. You're gonna wanna take a look at, you're gonna watch your query logs after those things to see if anything has changed and if you have to tune anything. You could turn on your slow query log dynamically or you could use it on the command line when you start your server. The default location is within the data directory again. Another cool thing you could do with the slow query log now is instead of it actually having it being a log file, you could actually make a table out of it. So that way you could run SQL queries against the table to find these things. You have multiple options for controlling it, everything from queries that do full table scans, automatically write it to your slow query log to queries that take longer than 10 seconds to run, two seconds to run, 0.2 seconds to run worth them to the query log. That's all available for you. Now when you're working with a slow query log, your best friend, well, officially according to MySQL policy, your best friend is MySQL dump slow. That's the utility we tell you to use to aggregate the information in your slow query log to actually find information instead of just raw data out of it. Now, since I don't have time, I can't show you that, but we could always talk about it later if you guys ever want to, back at the table. Next thing I wanna talk about is the general query log. This is MySQL's general record for the community version. Why would you turn on the general query log? If order is important, the general query log logs everything as it comes into the server, not as it executes, but as it comes into the server. So if you have deadlocks occurring and you don't know why, maybe they're coming in, maybe these two queries that are deadlocking are coming in in a different order than you thought they were. General query log would help you figure something like that out. If you have a query that's throwing a syntax error and you don't know why, but it's dynamically generated through your application, this will catch the exact query that's coming into the server. So you can take a look at it from there and then work backwards into your application. It also provides a minimal audit to find out what the various connection IDs did on the server. It's enabled dynamically again. You can set it at the server level and there are multiple options for controlling it. The biggest problem people have with the general query log is because it logs every single thing that comes into the server, it can grow very fast on even just a moderately busy server. So that's something, if you're worried about it, you can potentially hit space problems really quick. So generally speaking, most people, if they know they're having a problem, they'll turn it on for a few minutes, run the problem and turn it off. Okay? Next log you need to know about is the binary log. The binary log is different from the general query log because it only logs the change events that occur in the server. The general query log records everything. The binary log is change events. So the binary log is not gonna have your shows, it's not gonna have your selects or anything like that. It's gonna show your inserts, your updates, your deletes, your creates, things of that nature. Why would you turn on the binary log? If you use replication, you use your binary log. And the important one, data recovery. Binary log should be a part of your backup strategy. We'll go over that in a little bit. You enable your binary logs using the log bin and it has a lot of options for using it and controlling it. And when I say a lot, I mean the manual pages like Mondo, Mondo long. So take a look at that. You want to read your binary log. If you need to read your binary logs for whatever reason, you're gonna use the MySQL bin log utility. And you can also disable the binary logs for your current session using the SQL log bin. So for example, you're running a long running query that's a one off for a quarter something and you don't care about it or you're testing something and you don't want it on the slave, you can turn it off for that individual session. Any questions so far? Yes, sir. Oh wow, you guys do microphones. I'm used to people just yelling. Yeah, so, sorry. I was wondering if there is a way to get cumulative reports of connections that led up to the database crash. To give you an instance, we had a surge of connections. It went all the way to max connection limit. Easily? No, not unless you have your general query log. I see. MySQL does not remember things unless you have a log to remember it for you. And even if you have general query log enabled, it doesn't give you any reports or cumulative stats or anything like that. No, it tells you the individual connections. Okay, and what is the performance overhead of having, I mean, pushing your log verbosity all the way up? Let's say I'm logging to a table. Just whatever your IO would be for writing it. Okay, so that relates to the disk. So if you have your log file or any of these log files on a separate disk, separate from your data directory, your IO implementation would, I'm not done yet. Just to let you guys know, I still have more stuff. I just wanted to catch any quick questions in here. So the performance implication would be whatever it is for you to have to dealing on that disk. Okay, so my last question is that you said just general query log is my only option. So would event histories and performance schema help me in debugging crashes? Catch me on later, because that's a yes and no answer. Okay, so sorry about that. I just want to see if anybody had any quick questions. The next big thing, we have a whopping 11 minutes to cover backups. And backups are the single greatest thing that you as a DBA have to implement. And when I say you have to implement it, you have to have a rock solid backup. Because I can't tell you the number of times that people have said my system has crashed. I have corruption in my files or whatever and I can't get it back up. First question is, do you have a backup? No, stop your server, pull your disk. Depending on how bad it is, that's your only option. Backups, you have to have people get fired for not having a good backup. Now there are two types of backups. You have a logical backup and you have a physical backup. We're gonna go over logical backups first. Logical backups save the logical structure of your system and its contents. Logical structure, I mean like your tables, your triggers, your views, your procedures, all of that stuff. Logical backups are machine independent, so you can put them on any system and rebuild your system from them. But they are generally speaking slower to generate. They usually require the server to be up and or warm while you are making those backups. But they have full granularity if you ever have to restore anything for them. Examples of things you could use to make a logical backup is MySQL dump. This thing has been around forever. It is rock solid. What it does is it makes the logical backup from a command line, a client, and it generates text files of your data. Most people use MySQL dump to generate SQL files so that way they can be loaded into any system. Although if I remember it, you could also do, it also is available for, you can output it in XML and tabs limited as well. You can't remember but I think you can. Very, very flexible because it's a text file. You can edit it in any way you want it to. You can copy and paste sections out if you only want to restore individual things. If you want to switch over from your storage engine for a specific table to be from MyASM to NODB, it's delete, type, done. It has questionable scalability though because if you have a large system, MySQL dump literally queries the system, grabs everything from the table, sends it to the client and the client then has to write it in a text file on the system. That all takes time. So larger systems is gonna take longer to do these but these are rock solid though. You will always be able to restore from one of these. If you are one of those people that like GUI interfaces instead of the command line, Workbench actually has a data export that has an interface for you to actually back up using MySQL dump for it. Some people like that. I want to make sure it was known it was available. If you have a larger system you might want to consider using MySQL pump. MySQL pump is only available within 5.7 and it requires a 5.7 server to use it. At least the MySQL official version I should say. It's similar to MySQL dump. However it allows for the parallel processing of the backup rather than the single threaded nature of the MySQL dump. It dumps the user accounts. Instead of dumping the MySQL user tables it dumps the user accounts as create users and grants which is kind of nice. By default the information schema, the performance schema if you're using cluster MySQL, the NDB info and the SIS schema are not included in your dump because it's assumed they're transitional or ephemeral. They're not gonna be around very long. You're not gonna need them when you restore. And reloading it has faster loading of the secondary indexes. So if you're on 5.7 that might be a better option than MySQL dump. If you only need to do a logical backup of your content rather than your structure you might wanna check out a select into out file and load data in file. Select into out file allows you to put your information into a text file wherever the heck you want it to. But it's data only. So you're not gonna have your create tables. You're not gonna have your create procedures. You're not gonna have your triggers or any of that stuff. But if you need to do a dump of a backup of just the data itself this is actually pretty relatively quick to back up your information with. Big thing you have to remember about it though is that it will not by default give you a consistent backup because it'll only depending on how you do it you can have one table in a different state than another at the time. So if you use that pay attention to make sure you get a consistent backup you can specify with the line and column terminators as you want and there's lots and lots of details. Again, see your manual if you wanna use that option. Physical backups. Physical backups are raw copies of the actual files on the server. It's much, much faster than logical backups. Can be extremely compact because depending upon what file system you use that you work that way. The big thing to remember though is that it's file based granularity which may not be the level of granularity you need. And they are usually taken, the physical backup is usually taken while either the server is down or locked. So what types of physical backups can you take? You can take a file system snapshot if it's available on your file system for your OS. And you will basically do a flush tables with re-lock so that way you lock your tables in one consistent state. Take your snapshot so that way everything is consistent and then unlock your tables. Five minutes. So that's what that is. You have to, it's pretty good. I know a lot of people that use it, the biggest drawback is if they actual files themselves are corrupted, you have a corrupted backup. Since I work from MySQL, I have to mention the MySQL Enterprise backup. Anybody here a MySQL customer? Okay. Get with me later if you wanna know about MySQL backup because we're running out of time. But it's our official backup solution. I have to admit, it's actually very, very good. So if you're a customer, or that might be enough to make you a customer, I don't know, it's actually a very, very good product. So that lets us skip two slides. Oh, if you have MySQL backup as the customer, you also have an Enterprise Edition in Workbench. You have a hook into it to use a GUI interface to use it, which is actually quite nice. Now, part of your backup system, this is actually my last slide, part of your backup procedure, whether you use logical backups, physical backups, whatever, or a combination of both, you should also be backing up your binary logs. The reason why you wanna backup your binary logs is because after you make this backup of your whole system, you have a time between that backup until your server crashes. That time means that that's how much data you can lose. By backing up your binary logs, you're getting the change events from the time of that backup to whenever you want. So you can do a point in time recovery. You could literally reload your backup for whatever type it is, and then roll your binary logs forward till right before the crash. And your bosses will love you for that. So that's why I said earlier, when we were talking about the binary logs, you always wanna have them turned on, even if you only have one server. If for no other reason, then data recovery is part of your backup system. Ch-ch-ch-ch-ch-ch. You can do a physical copy of your binary logs. You just basically have to rotate your binary logs and take a copy of the individual files. You can do a logical copy to a remote server. Using MySQL bin log, remember that utility I mentioned earlier, you can now either do a streaming backup of your binary logs to a remote server or a static copy whenever you want them to. The big gotcha potentially about a streaming backup of your binary logs is that bin log was never originally designed to do this. So if for whatever reason, if you have a break in that streaming, it won't automatically restart again. So you're gonna have to regularly check on it to make sure it occasionally is still running, depending upon what your requirements are, is how often you might have to check that it's actually still running. So that was all of my slides. I told you it was a lot of information really fast. We're running out of time. Any quick questions? Hi, I have two questions. So there's an option called I not to be forced recovery. And that has six options from one to six. That's gonna take too long for the time we have. Hit me up on the table. Am I at totally out of time for the next person? Yes. Actually, yes I am. Okay, I am sorry about that. If you have questions, I apologize. Hit me up on my booth. I will answer any questions that you have up there. I don't wanna take time out for the next person. Thank you very much, and you guys have a good day, okay? Oh, and don't forget, I have another talk later on this afternoon. It's called a minuscule troubleshooting TLDR. Too long didn't read. It's basically gonna say, if you have a problem, what information should you collect to try to figure out what your problem was? That's what that's gonna be this afternoon. Thank you very much. Thank you, Liga.