Video: Building a MySQL Slave and Keeping it in Sync At the Boston MySQL User Group Sheeri Cabral presented on how to get a consistent snapshot to build a slave, how to use mk-table-checksum to check for differences between masters and slaves on an ongoing basis, and how to use tools such as mk-table-sync and mysqldump to sync the data if there are any discrepancies. This link contains the slides and the videos

Over the weekend, I worked on a client's two computers, trying to get a slave in sync with the master. It was during this time that I began thinking about:a) how this never should have happened in the first place.b) how "slave drift" could be kept from happening.c) how this is probably keeping some businesses from using MySQL.d) how MySQL DBAs must spend thousands of hours a year wasting time fixing replication issues.I'll be the first person to tell you that the replication under MySQL is pretty much dead-simple to set up. My only complaint is that it is annoying to type in the two-line "CHANGE MASTER" command to set up a new slave. Even so, it makes sense.It is also very easy, however, for a slave to end up with different data than the master server has. This can be caused by replication bugs, hardware problems, or by using non-deterministic functions. Without proper permissions, a user/developer/DBA can log  []

Last week I had to confront one of those situations where you can't really tell what is going on with a piece of software, and the final conclusion would sound completely crazy if postulated as the initial hypothesis. The regular MySQL commands and utilities fall short in these cases, so I had to resort to the three tools reviewed in this article.The problem we were diagnosing was this: at some point in time, a number of queries that use to take less than one minute to execute, started to take between five to 15 minutes. We needed to get an insight into what was going on inside the MySQL server.MySQL TunerAt some point in a long diagnosis process, MySQL's "SHOW [GLOBAL] VARIABLES" and "SHOW [GLOBAL] STATUS" are nothing more than a long list of numbers. Going through a team mate's notes on another issue, I came across MySQL Tuner. This is an extremely simple tool that takes the information from the  []

Today I've been checking out a new client environment. My mission is to figure out (cold) some of the characteristics of the queries being run, and particularly if they're "good" or "bad". In my arsenal of "tools I really want to check out" has been Ma'atkit's Query Profiler.They're very different tools. Ma'atkit's query profiler profiles a batch of queries, without granularity (at least not the way I ran it) to see what query is doing what. So I ran this against a production machine:(I ran the query profiler for a while and then hit "enter" (apparently after about 17 minutes))> ./mk-query-profiler --external --host localhost --user <user> --password <password> Press <enter> when the external program is finished +----------------------------------------------------------+ | 1 (1028.2091 sec) |  []

The Maatkit toolkit is a real blessing for the MySQL DBA. And while its documentation is pretty good, in some cases it's necessary to read carefully a second and third time to make sure you are not missing an important piece of information. In this article I will comment on mk-table-chksum and mk-table-sync. My comments are mostly aimed at those DBAs who are considering using these utilities with medium or larger-sized databases.--replicateThis option allows you to store the checksum results on the master, in a table that will get replicated to the slaves. Although it might seem like overhead for a simple check, it really simplifies your life, especially when used in combination with "mk-table-sync". I always use it, for the following reasons:\tYou only need to run "mk-table-chksum" on the master.\tA simple query will tell you the slave status.\tWhen used with "--chunksize", it divides the checking  []

Scenario: Someone wants to know which of the over 50 MySQL users have certain privileges.There are many ways to solve this problem. Some of these scenarios are tedious and repetitious, others take no time at all.The issue, of course, lies in what the "certain" privileges are. If it is "who has the SUPER privilege?" then a simpleSELECT user,host FROM mysql.user WHERE Super_priv='Y';is sufficient. If it is "who has write access to the foo database", you might write:SELECT user,host FROM db WHERE Db='foo' AND Select_priv='Y';but that only shows who explicitly has read permissions on that database; it does not include those who have global read permissions. The full query would be:

The "sla" in mysqlsla stands for "statement log analyzer". This does a much better job than mysqldumpslow of analyzing your slow query log. In fact, you can sort by many different parameters -- by sheer number of times the query shows up in the slow query log, by the total or average query time, by the lock time, etc. This is really good for weeding out pesky entries in the slow query log that you do not care about. In this case, our client was using log-queries-not-using-indexes, so there was a lot of junk in the slow query log as well (for instance, every time a mysqldump backup was run, the slow query log got plenty of entries). In this case, I'm using --slow to read the slow query log at the filename specified, --flat to flatten all the text to lowercase (basically case-insensitive matching) and --sort at to sort by "average time".> ./mysqlsla --flat --slow ~mysql/var/mysql-slow.log  []