So, one of master server’s disk filled up with replication logs last night. We had a permission issue due to our data center move. An oversight on my part. Anyhow, I got to the server and purged the old logs and the master server started responding with no problems. However, the slaves did not. Both slaves connected to the master would not respond to a slave stop. Nor would they respond to a mysqladmin shutdown. I had to kill -9 the daemons to get them to stop. When I restarted the daemon and started the slave, all was fine.

I am hoping someone knows what is going on or can tell me what to send in a bug report. I don’t want to just put that in a bug report. It is kind of lame and useless.

Update: This may be my problem. Bug #31024.  I certainly did not give the slave a long time to stop.

…

MySQL master servers won’t remove their logs automatically when slaves are done with them. You can set expire_logs_days to remove them after a certain number of days. But, you are not assured that a slave is done with the logs. So, we wrote a script to connect to slaves and then purge logs on the master servers. It works for us. Your mileage may vary. BSD style license. Enjoy.

flush_mysql_master.php.gz

…

I spent some time going through the source the other day in order to try to understand the difference between these SHOW STATUS variables in 5.x:

Innodb_buffer_pool_read_requests Innodb_buffer_pool_reads Innodb_pages_read
Here's what I discovered that I'm not sure is 100% right, but I suspect is at least on the right track:
Innodb_buffer_pool_read_requests:  requests to get something from the buffer pool.  This isn't really that great of a mystery.  I suspect these are 'direct' read requests, meaning those caused directly from a query of some kind.  

read more

I spent some time going through the source the other day in order to try to understand the difference between these SHOW STATUS variables in 5.x:

Innodb_buffer_pool_read_requests Innodb_buffer_pool_reads Innodb_pages_read
Here's what I discovered that I'm not sure is 100% right, but I suspect is at least on the right track:
Innodb_buffer_pool_read_requests:  requests to get something from the buffer pool.  This isn't really that great of a mystery.  I suspect these are 'direct' read requests, meaning those caused directly from a query of some kind.  

read more

A new version of myq_gadgets has been released and you can download it here.

Changelog since the last released version here:

Version 0.0.9 -
    - Documented new reports in README
    - Updated 'thds' column in the 'cttf' report to read 'crtd' instead.
Version 0.0.8 -
    - Added a bunch more innodb reports, looking for the good stuff.
Version 0.0.7 -
    - Added an 'innodb' mode to myq_status to support 5.0+ STATUS variables.
      'myq_innodb_status' continues to handle SHOW INNODB STATUS output,
      mostly for 4.1 and earlier.
    - Beefed up the format_memory function to use recursion to determine the
      appropriate output multiplier (tera, giga, mega, kilo, etc.)

A new version of myq_gadgets has been released and you can download it here.

Changelog since the last released version here:

Version 0.0.9 -
    - Documented new reports in README
    - Updated 'thds' column in the 'cttf' report to read 'crtd' instead.
Version 0.0.8 -
    - Added a bunch more innodb reports, looking for the good stuff.
Version 0.0.7 -
    - Added an 'innodb' mode to myq_status to support 5.0+ STATUS variables.
      'myq_innodb_status' continues to handle SHOW INNODB STATUS output,
      mostly for 4.1 and earlier.
    - Beefed up the format_memory function to use recursion to determine the
      appropriate output multiplier (tera, giga, mega, kilo, etc.)

It took a while, but I finally found time to upgrade my MySQL certifications from 4.1 to 5.0 and also the Cluster 5.1 one. Good feeling I passed them all on the first try! But, it ain't easy! Even me having worked on some questions, and reviewing the Cluster ones more than a year ago, I made mistakes. Not easy!

There is an old joke about the concert violinist on his first visit to New York City who finds himself lost and late for rehearsal. So he asks a police officer, "How do I get to Carnegie Hall?"

The cop answers, "Practice, practice!"

If you new to the world of databases (or MySQL's world of databases) and want to do well on your MySQL certification tests, one of the best things you can do to internalize the knowledge needed is to practice. And the best practice tool is out there for free at http://dev.mysql.com/doc/ under Example Databases.

The MySQL Student Guides from our excellent training classes and our Certification Guides use the World database in their examples. I encourage you to type in the examples and work through any exercises our questions with this wonderful collection of tables.

Then work up your own exercises. Write a query to display the head of state and …

One thing that sometimes bugs me in MySQL is the huge amount of errata. The database is packed with features and abilities that are side-effects from "historical decisions". Decisions that were made when it wasn't planned to be an enterprise product, or changes made to ease porting applications to MySQL from other databases. Legacy, so to speak.

The timestamp data type is a good example - the timestamp manual section is a long list of exceptions and special cases. I usually re-read the manual page before using it. Another good example is the amount of date and time functions that exist in MySQL. There are way too many of them, some overlapping in function, and some just exist as aliases to other functions for compatibility. Just go over the list.

On …

We uploaded a updated beta release 5.0.14a to our mirrors yesterday. There was a small issue (with not so small effects) where some users were unable to open files created with earlier versions of MySQL Workbench. Please fetch this update to avoid this problem.