Recovering/Resetting a MySQL root password

In this small post, I’ll show you how to reset the MySQL password in case you lost it.

You’ll need at least the root access of the machine where MySQL run.

Reset the MySQL root password

Resetting the root password of a MySQL database in case you lost it, is really easy.

Now start the database in the background, via the mysqld_safe command. Start MySQL with a flag to tell it to ignore any username/password restrictions which might be in place.

# /usr/bin/mysqld_safe --skip-grant-tables &
[1] 8705
Starting mysqld daemon with databases from /var/lib/mysql mysqld_safe
[8345]: started

Now that the server is running, you can connect without any password

# mysql --user=root mysql
        Enter password:
mysql> update user set Password=PASSWORD('newpassword') WHERE User='root';
       Query OK, 2 rows affected (0.04 sec)
       Rows matched: 2 Changed: 2 Warnings: 0
mysql> flush privileges;
       Query OK, 0 rows affected (0.02 sec)
mysql> exit Bye

Stop the server,

# fg

hit CTRL_C to kill the process and start normally MySQL

# /etc/init.d/mysql start
      Starting MySQL database server: mysqld.
      Checking for corrupt, not cleanly closed and upgrade needing tables..

You should now be able to connect to your server using the password

Reset the MySQL root password

If you've got access to the root account already, because you know the password, you can change it easily:

# mysql --user=root --pass mysqlpassword
       Enter password:
mysql> update user set Password=PASSWORD('newpassword') WHERE User='root';
       Query OK, 2 rows affected (0.04 sec)
       Rows matched: 2 Changed: 2 Warnings: 0
mysql> flush privileges;
       Query OK, 0 rows affected (0.02 sec)
mysql> exit Bye

Optimizing MySQL jdbc under windows using named pipe

According to this MySQL page here, you can win 30 to 50% more performances using MySQL jdbc named pipe!

Named pipes only work when connecting to a MySQL server on the same physical machine as the one the JDBC driver is being used on.
In simple performance tests, it appears that named pipe access is between 30%-50% faster than the standard TCP/IP access.

As default, when you install mySQL on windows using the installer, TCP IP is the default option. The question remains why nobody seems
to use named pipe, or has write any articles on internet about it. Lorenz and me were trying nearly 2 hours to make this damn things work.
We googled on internet, finding nothing, e try and try until we finally succeed. That is the reason why I write this article now.

We were testing successfuly MySQL 5.0 using named pipe, and what an increase in speed! 50% in the case of this big project
First it may be a good idea to use the latest JConnector driver from MySQL

MySQL Connector/J is a native Java driver that converts JDBC (Java Database Connectivity) calls into the network protocol used by
the MySQL database. It lets developers working with the Java programming language easily build programs and applets that interact
with MySQL and connect all corporate data, even in a heterogeneous environment. MySQL Connector/J is a Type IV JDBC driver and
has a complete JDBC feature set that supports the capabilities of MySQL.
Download Binaries & Source

Read more: Optimizing MySQL jdbc under windows using named pipe

MYSQL tuning with mysqlreport

I found this interesting tool (beside tuning-primer.sh) while trying to optimizing my server setting for Joomla!

mysqlreport

mysqlreport makes an easy-to-read report of important MySQL status values. Unlike SHOW STATUS which simply dumps over 100 values to screen in one long list, mysqlreport interprets, formats, and then nicely presents the values in report readable by humans. Numerous example reports are available at the mysqlreport web page.
The benefit of mysqlreport is that it allows you to very quickly see a wide array of performance indicators for your MySQL server which would otherwise need to be calculated by hand from all the various SHOW STATUS values. For example, the Index Read Ratio is an important value but it is not present in SHOW STATUS; it is an inferred value (the ratio of Key_reads to Key_read_requests).

Grab it at http://hackmysql.com/mysqlreport

How to run it (more options), it require PERL to run.

# ./mysqlreport --user xxxxx--password xxxxxx| more

Running mysqlreport against my host, gave the following results:

• very good table lock 0.02%
• very good read ratio 99.93%
• good query cache, but could be reduce to 40Mb to avoid wasting memory resource

if you need something more professional and can afford it, you can try Mysql Enterprise (free for 30 days, enough to tune any small server bottleneck)

Read more: MYSQL tuning with mysqlreport

Optimizing mysql with tuning-primer.sh

Digging into mySQL settings can be time consuming, like with any other component. Most of the time, and just by changing a few settings, you can expect a performance increase. The problem is to change what, and  to which value. This is where tuning-primer.sh help you:

Get this script, http://forge.mysql.com/projects/view.php?id=44 upload it, unzip it, and install it in your /etc folder. Then run it from the command line by entering ./path-to-file/tuning-primer.sh

MySQL Server must run a few days or weeks, or it wont be be safe to follow these recommendations.

To find out more information on how each of these runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html

Here is an example of  tuning-primer.sh output

SLOW QUERIES
Current long_query_time = 5 sec.
You have 2856 out of 4725688 that take longer than 5 sec. to complete
The slow query log is enabled.
Your long_query_time seems to be fine

WORKER THREADS
Current thread_cache_size = 128
Current threads_cached = 55
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 15
Historic max_used_connections = 55
The number of used connections is 55% of the configured maximum.
Your max_connections variable seems to be fine.

MEMORY USAGE
Max Memory Ever Allocated : 305 M
Configured Max Per-thread Buffers : 1017 M
Configured Max Global Buffers : 143 M
Configured Max Memory Limit : 1 G
Total System Memory : 2.99 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 4 M
Current key_buffer_size = 5 M
Key cache miss rate is 1 : 3740
Key buffer fill ratio = 35.00 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is enabled
Current query_cache_size = 128 M
Current query_cache_used = 27 M
Current query_cach_limit = 2 M
Current Query cache fill ratio = 21.13 %
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 4 M
Current record/read_rnd_buffer_size = 1020 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 1.00 M
You have had 7065 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.