MySQL Preacher » Intermediate

Recovering a MySQL `root` password – Three solutions

Darren Cassar — Mon, 21 Mar 2011 19:00:58 +0000

Three ways to recover a root user password:

The order of solutions here under gets more creative on the way down :)

1. obviously, before starting messing around check my.cnf or scripts for passwords entries, then try home directories for password files
2. secondly – can you restart mysql? if yes, restart with –skip-grant-tables, log into mysql, change your password and restart without –skip-grant-tables
3. third option – (on linux / unix ONLY)
If you haven’t found the password anywhere and can’t afford to restart your mysql.

cd data/mysql
cp -rp user.MYD bck_user.MYD_`date +%Y%m%d`
cp -rp user.MYD /tmp/user.MYD
vi /tmp/user.MYD #(edit the hashed passwords next to root*)
cp -rp /tmp/user.MYD user.MYD
sudo kill -HUP `pidof mysqld`

Note that the latter method of recovering a root password CAN be easily used maliciously leaving no trace! The only way to avoid such an attack is to make the data directory ONLY readable and writable by the user used to start/stop mysql (don’t user *nix root user to own mysql since that opens another can of worms … it’s a whole other blog post).

Could not find first log file name in binary log index file

Darren Cassar — Thu, 23 Dec 2010 14:19:10 +0000

Scenario Master – Master replication

MasterA is a client facing server
MasterB is a warm standby server (read only)

MasterB restarted abruptly and when instances were braught back up MasterA (it’s slave) was showing the following error:

MasterA has the following error in show slave status:
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘Could not find first log file name in binary log index file’

Solution:

Slave: stop slave;

Master: flush logs
Master: show master status; — take note of the master log file and master log position

Slave: CHANGE MASTER TO MASTER_LOG_FILE=’log-bin.00000X′, MASTER_LOG_POS=106;
Slave: start slave;

CRIB – CentRal Information Base for MySQL

Darren Cassar — Fri, 10 Dec 2010 11:19:50 +0000

CRIB is a CentRal Information Base for MySQL, a long time coming project since I worked on it on and off for a few weeks and now I decided it’s time to hand it over to the global MySQL community.

So, what is CRIB?

CRIB is a central database which collects information about all your MySQL instances which you set as clients. It is monitoring in a way, but not the typical number of connections, memory, index usage, table scans, cpu usage and such, but rather consists of a repository where, if you have tens, hundreds or even thousands of clients, you can see where a particular user was created, where a certain database name features or which tables does a database consists of. It also features a script which logs table sizes periodically (customizable) so you can graph disk usage over time and be able to forecast future disk space requirements easily.

Download the latest code with: bzr branch lp:crib

First of all lets create the user used to write to the server (mother instance)

Lets go ahead and install CRIB on both server and client

[dcassar@ubt]$ cd INSTALL [dcassar@ubt]$ ./crib_install.sh
brought to you by Darren CassarAnytime you need to cancel installation just press ( Ctrl + C )Would you like to setup source and destination or just source? 1. Client and Server 2. New Client Enter choice (default 2): 1 Installation starting
This section you'll supply the destination (CentRal Information Base) details
Enter CRIB user name (default root): mother Enter CRIB password (default 'toor'): Enter CRIB hostname (default localhost): 127.0.0.1 Enter CRIB port (default 3306): 5151
This section you'll supply the client details
Enter client user name (default root): dcassar Enter client password (default 'toor'): Enter client hostname (default localhost): dolphin Enter client port (default 3306): 3331 Installation complete [dcassar@ubt]$
Now is the time to gather the data from the clients and log it onto the server.

[dcassar@ubt]$ ./populate.sh CONFIG/crib_3331.cnf [dcassar@ubt]$ ./tablesize.sh CONFIG/crib_3331.cnf

Lets log into the CRIB database on the mother server and see what details we have at our disposal.

[dcassar@ubt]$ use5151 Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 56 Server version: 5.1.51 MySQL Community Server (GPL)
Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved. This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to modify and redistribute it under the GPL v2 license
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.mysql > use crib Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -ADatabase changed mysql > show tables; +------------------+ | Tables_in_crib | +------------------+ | info_instances | | info_object_size | | info_objects | | info_privileges | | info_users | | version | +------------------+ 6 rows in set (0.00 sec)mysql > select * from version; +----+---------+---------------------+ | ID | VERSION | UPDATED_TIMESTAMP | +----+---------+---------------------+ | 1 | 0.1 | 2010-12-09 16:24:05 | +----+---------+---------------------+ 1 row in set (0.00 sec)mysql > select * from info_instances; +----+-------------------------------------+------+-----------+---------------+-----------------+------------+--------------+------+-------+ | id | hostname | port | server_id | mysql_version | os | os_version | architecture | bits | notes | +----+-------------------------------------+------+-----------+---------------+-----------------+------------+--------------+------+-------+ | 1 | dolphin | 3331 | 14123561 | 5.1.50 | sun-solaris2.10 | 10 | sparc | 64 | NULL | +----+-------------------------------------+------+-----------+---------------+-----------------+------------+--------------+------+-------+ 1 row in set (0.00 sec)

From the above you realize you can identify all versions used in your setup, what hardware you are using, port numbers used and much more!

Lets see what users we have so far.
mysql > select * from info_users; +----+-------------+------------+---------------------------+-------------------------------------------+ | id | instance_id | username | hostname | password | +----+-------------+------------+---------------------------+-------------------------------------------+ | 1 | 1 | root | localhost | *BA44AFCA02B64C198FAEB3043F47CA3797638975 | | 2 | 1 | root | %.dev.domain.com | *BA44AFCA02B64C198FAEB3043F47CA3797638975 | | 3 | 1 | root | 127.0.0.1 | *BA44AFCA02B64C198FAEB3043F47CA3797638975 | | 4 | 1 | abc | % | *A4456E2A03EC0EE4E164BFA533443E82691DA163 | | 5 | 1 | def | localhost | *5162BA4456B42A01FD8DDBB4CDBE46AFAD06C5AB | | 6 | 1 | ghi | % | *95E6C48AFC85167C37A24130DD4F5FE0F48AB658 | | 7 | 1 | jkl | % | *7A2D095E620E354F216EE00635E163406AD47392 | | 8 | 1 | mno | % | | | 9 | 1 | qpr | localhost | *5162BA4456B42A01FD8DDBB4CDBE46AFAD06C5AB | +----+-------------+------------+---------------------------+-------------------------------------------+ 9 rows in set (0.00 sec)

If we had multiple machines set up as clients then we would have another group with instance_id 2, so on and so forth.

Remember this is an alpha tool and whatever you do with it is your responsibility. You are advised NOT TO set this up on production for now.

Do you use MySQL replication? Do you use “FLUSH LOGS”? If yes you might want to read this.

Darren Cassar — Tue, 31 Aug 2010 18:12:22 +0000

Scenario: Master-Master replication
Description: Master A is the active db server whilst Master B is a read only swappable db server hence both are creating binary logs. During backup I run “FLUSH LOGS” in order to have a simpler point in time recovery procedure if that case arises.
Problem: Flush logs is mean mean command :) …. it rotates not only my binary logs but my error log too (since I user error-log=blahblahblah in my my.cnf). Well given I flush logs every night my error log is cycled through every night, but unlike binary logs which have an incrimental number attached to the fine, error logs only have a `-log` attached to the filename and a second “FLUSH LOG” would just clear all error logs permanently. That is really not fun believe me!

So what is the solution? you could either:
1. Not use “FLUSH LOGS” (nah that aint happenin)
2. Not use –error-log (that aint happenin either cos I need to use it for my specific setup)
3. Create an ugly hack script which saves the error log or renames it or whatever (Ugly Ugly)
4. Create a variable in MySQL which says: flush-log-ignore-error-log which if set “FLUSH LOGS” will know not to mess around with my error log. Hence … create a feature request (nicer and friendlier solution) and submit a tested patch too whilst at it.

If you think it is not idea that “FLUSH LOGS” recycles through error logs or and you have been bitten by the way it works like me, then feel free to put your vote into http://bugs.mysql.com/bug.php?id=56385&thanks=sub so that MySQL sees the importance of it.

Because Sharing is Caring!

Getting a return code from a stored procedure

Darren Cassar — Thu, 26 Aug 2010 06:00:20 +0000

Sometimes we have some special need for a stored procedure to call another to do something. That is fine, but what if the second stored proc failed for some reason? Maybe you want to halt the first stored procedure (the caller) and not proceed with the work until the problem is verified and resolved. So How do you do it?

Simple, get a return code from the called procedure to determine if it worked or not!

Here’s a sample piece of code to explain better:

DROP PROCEDURE IF EXISTS `test`.`testing123`; DELIMITER $$


CREATE

    PROCEDURE `test`.`testing123`(OUT a INT)

    BEGIN

        DECLARE EXIT HANDLER FOR SQLEXCEPTION

        BEGIN

          SET a=2;

        END;

        SET a=0;
# toggle the below as comment or not to see the call at the bottom working

# if you uncomment select abc you'll see the error, otherwise all is cool
#        select abc;
    END$$
DELIMITER ;
DROP PROCEDURE IF EXISTS `test`.`testing456`;

DELIMITER $$
CREATE

    PROCEDURE `test`.`testing456`()

    BEGIN

        SET @a=0;

        CALL `test`.`testing123` (@a);
        IF @a != 0 THEN

           SELECT "There is a problem with proc `testing123`";

        ELSE

           SELECT "Everything is cool";

        END IF;
    END$$
DELIMITER ;

CALL `test`.`testing456` ();

testing123 is the second stored proc in this case, called from testing456. The trick is to have an exit handler which returns a status number to the first stored proc (testing456). The latter will hold an if condition to do `something` depending on the return code received by testing123.

If you have any other suggestions I’d appreciate your input.