PlanetMysql.ru - информация о СУБД MySQL » Intermediate

Recovering a MySQL `root` password – Three solutions

Darren Cassar — Mon, 21 Mar 2011 19:01:22 +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).

PlanetMySQL Voting: Vote UP / Vote DOWN

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.

PlanetMySQL Voting: Vote UP / Vote DOWN

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?

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]$ ./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.

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!

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.

PlanetMySQL Voting: Vote UP / Vote DOWN

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!

PlanetMySQL Voting: Vote UP / Vote DOWN

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.

PlanetMySQL Voting: Vote UP / Vote DOWN

Datetime & Timestamp manipulation / migration explained

Darren Cassar — Tue, 15 Jun 2010 16:47:16 +0000

Are you doing some datetime manipulation or maybe you are migrating from some database technology to MySQL or possibly using milliseconds?
Here is an example on how to go about it:

Say you have the following date: MAR 16 2008 09:12:51:893AM
SELECT DATE_FORMAT(STR_TO_DATE('MAR 16 2008 09:12:51:893AM','%M %d %Y %h:%i:%s:%f%p'),'%Y%m%d%k%i%s.%f'); --> 2008031691251.893000

What if its PM rather than AM
SELECT DATE_FORMAT(STR_TO_DATE('MAR 16 2008 09:12:51:893PM','%M %d %Y %h:%i:%s:%f%p'),'%Y%m%d%k%i%s.%f'); --> 20080316211251.893000

Ok so this is just simple string manipulation where:
%M is the month name %d is day number %Y is the year %h is the hour %i is the minute %s is the second %f is the microsecond %p is the period: ante or post meridiem
In the DATE_FORMAT part we se a %k which is in 24hr format in order to loose the period.

A more detailed list is found here

Here is a demo:

mysql Tue Jun 15 12:32:37 2010 > CREATE TABLE test.abc(a DECIMAL(17,3)) ENGINE=MYISAM; Query OK, 0 rows affected (0.03 sec)

mysql Tue Jun 15 12:32:45 2010 > INSERT INTO abc VALUES ( DATE_FORMAT(STR_TO_DATE('MAR 16 2008 09:12:51:893PM','%M %d %Y %h:%i:%s:%f%p'),'%Y%m%d%k%i%s.%f') ); Query OK, 1 row affected (0.01 sec)

mysql Tue Jun 15 12:32:51 2010 > SELECT * FROM abc; +--------------------+ | a | +--------------------+ | 20080316211251.893 | +--------------------+ 1 row in set (0.00 sec)

mysql Tue Jun 15 12:32:56 2010 > SELECT TIMESTAMP(a) FROM abc; +----------------------------+ | TIMESTAMP(a) | +----------------------------+ | 2008-03-16 21:12:51.893000 | +----------------------------+ 1 row in set (0.00 sec)

PlanetMySQL Voting: Vote UP / Vote DOWN

Automating MySQL access with expect and bash scripting

Darren Cassar — Mon, 08 Feb 2010 17:08:26 +0000

If you have multiple database servers with strange names, or if you have to hop over multiple machines to connect to any mysql database server, then you know what a pain it can be to administer such a setup. Thanks to some scripting, you can automate such tasks as follows:

Create an expect script:
/path/to/sshmysql.exp

#!/usr/bin/expect -f
#script by darren cassar
#mysqlpreacher.com

set machine [lindex $argv 0]

set timeout -1

spawn ssh username@$machine
match_max 100000
expect -exact “assword: ”
send — “password\r”
send — “sudo -k; sudo su – mysql\r”
expect -exact “sudo -k; sudo su – mysql”
expect -exact “assword:”
send — “password\r”
interact

# you should change the word password in ’send — “password\r”‘ to your login password
# if you have the same password for each environment you could also script logging into mysql directly from the same expect script BUT that is not recommended.

Create a bash script:
/path/to/login.sh

#!/bin/bash
#script by darren cassar
#mysqlpreacher.com

sm=’/path/to/sshmysql.exp’

menu() {
echo ” 101 – dev.databaseserver1 ”
echo ” 102 – dev.databaseserver2 ”
echo ” 103 – dev.databaseserver3 ”
echo ” 201 – qa.databaseserver1 ”
echo ” 301 – uat.databaseserver1 ”
echo ” 302 – uat.databaseserver2 ”
echo ” 401 – prod.databaseserver1 ”
echo ” ”
}

ARGUMENT=notmenu

if [ -z "$1" ]
then
ARGUMENT=menu
else
choice=$1
fi

if [ $ARGUMENT = "menu" ]
then
menu
else
case “$choice” in
101|dev.databaseserver1 ) $sm dev.databaseserver1;;
102|dev.databaseserver2 ) $sm dev.databaseserver2;;
103|dev.databaseserver3 ) $sm dev.databaseserver3;;
201|qa.databaseserver1 ) $sm qa.databaseserver1;;
301|uat.databaseserver1 ) $sm uat.databaseserver1;;
302|uat.databaseserver2 ) $sm uat.databaseserver2;;
401|prod.databaseserver1 ) $sm prod.databaseserver1;;
* ) echo “Wrong value passed to script”
menu ;;
esac
fi

alias l=’/path/to/login.sh’

Output:

[darrencassar@mymachine ~ ]$ l
101 – dev.databaseserver1
102 – dev.databaseserver2
103 – dev.databaseserver3
201 – qa.databaseserver1
301 – uat.databaseserver1
302 – uat.databaseserver2
401 – prod.databaseserver1

Output:
The below command would log you into the first development database server as mysql user.

[darrencassar@mymachine ~ ]$ l 101

On each machine place aliases for each instance in the .profile

alias use3306=’mysql -u root -p -h 127.0.0.1 -P 3306 –prompt=”mysql \D> “‘

The above setup can be used using any client/server OS: Linux, Solaris, MAC OS or Windows(running Cygwin)

NOTE: If you store the password in clear text inside the expect script, you should at least save the scripts inside an encrypted partition on your machine and make sure that folder is not shared or accessible by anyone. Another way of doing it would be to use either SSHKeys OR save the password inside a file and encrypt it using OpenSSL

Enjoy!

PlanetMySQL Voting: Vote UP / Vote DOWN

Once upon a timestamp(milliseconds)….

Darren Cassar — Thu, 06 Aug 2009 12:53:49 +0000

Once upon a time`stamp`, in a `data`base far far away, someone filed a bug named: `Microseconds precision is not retained by TIME, DATETIME, and TIMESTAMP field types.` – Bug Number 8523. This was the beginning of 2005, yet now that we are approaching the end of 2009, after 4.5 years, many (including myself) are still [...]