I’m working on building an ideal server setup that allows for both PHP 4 and PHP 5 on Apache with suPHP (I’ll blog about this later). While testing my PHP 4 build, I got the following error:

Warning: mysql_connect() [function.mysql-connect]: Client does not support authentication protocol requested by server; consider upgrading MySQL client in /var/www/test-php.php on line 3
Couldn’t authenticate with MySQL

The code I used to test this is quite simple:

<?php

if ( false === ( $db = mysql_connect( 'localhost', 'username', 'password' ) ) )
    die( "Couldn't authenticate with MySQL" );

if ( false === mysql_select_db( 'database' ) )
    die( "Couldn't connect to database" );

echo "Yay!";

?>

After digging around for a bit, I found that mixing PHP 4 with a MySQL version greater than or equal to 4.1 causes this problem. MySQL 4.1 introduced a new password caching scheme that PHP 4 can’t work with.

The solution is to update the database user’s password using the OLD_PASSWORD function of MySQL. For example:

[chris@office ~]$ mysql -u root -p mysql
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 267
Server version: 5.1.41-3ubuntu12.1 (Ubuntu)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> update user set Password=OLD_PASSWORD('password') WHERE User='username';
Query OK, 0 rows affected (0.02 sec)
Rows matched: 0  Changed: 0  Warnings: 0

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

mysql>

Note the underlined areas. That is where you’ll want to provide your own username and password.

Once you’ve followed these steps, both PHP 4 and PHP 5 will be able to communite with the database.

Thanks to digitalpeer for providing the answer to my issue.

I recently had a issue getting MySQL to read a specific database. Each time I tried to manually query a table in the database, I received the following error message:

ERROR 1018 (HY000): Can't read dir of './default/' (errno: 13)

I’ve seen this message before as it means that there is a permissions issue. I checked the ownerships and permissions, and everything seemed to be in order.

The only thing special about this database is that I have it symlinked to another partition. This has always worked in the past, so I was stumped.

The problem turned out to be that Ubuntu has AppArmor. This software sets up rules that prevent software from gaining access to different areas of the file system. In my case, AppArmor was preventing read and write access to the actual location of my database files.

The solution was quite easy: First, I added the path that I wanted MySQL to have access to in the AppArmor configuration file for MySQL. Second, I restarted the apparmor service. Here’s the technical details:

1. On my system, the configuration file that controls MySQL permissions through AppArmor are located at /etc/apparmor.d/usr.sbin.mysqld. The following shows the contents of the file as it now exists:

   # vim:syntax=apparmor
   # Last Modified: Tue Jun 19 17:37:30 2007
   #include 
   
   /usr/sbin/mysqld {
     #include
     #include
     #include
     #include
     #include 
   
     capability dac_override,
     capability sys_resource,
     capability setgid,
     capability setuid,
   
     network tcp,
   
     /etc/hosts.allow r,
     /etc/hosts.deny r,
   
     /etc/mysql/*.pem r,
     /etc/mysql/conf.d/ r,
     /etc/mysql/conf.d/* r,
     /etc/mysql/my.cnf r,
     /usr/sbin/mysqld mr,
     /usr/share/mysql/** r,
     /var/log/mysql.log rw,
     /var/log/mysql.err rw,
     /var/lib/mysql/ r,
     /var/lib/mysql/** rwk,
     /var/log/mysql/ r,
     /var/log/mysql/* rw,
     /var/run/mysqld/mysqld.pid w,
     /var/run/mysqld/mysqld.sock w,
     /home/sites/default/mysql/ rw,
     /home/sites/default/mysql/* rw,
   
     /sys/devices/system/cpu/ r,
   }

   The two lines in bold show what I added to the configuation. The first line gives read and write access to the directory itself while the second gives read and write access to the files contained in the directory.

2. After saving the configuration changes, I simply needed to restart the AppArmor daemon. I did this with the following command:

   [chris@rommie ~]$ sudo service apparmor restart
    * Reloading AppArmor profiles
   Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox

I recently worked on a project where I had to sort a set of rows returned from a MySQL query. The problem is that most of the data in the field being sorted is numeric yet the field type is varchar since some of the entries contained characters.

The reason that this is a problem is that MySQL sorts character fields using a method that will produce undesirable results with numeric data. For example, sorting 4, 10, and 50 as character data produces 10, 4, and 50. In most applications, this is highly undesirable.

The solution to this is to force a sorting order that is commonly referred to as a natural sort. Natural sort is just a term that refers to how humans would commonly sort a set of information (numbers as numbers and non-numeric characters alphabetically). Fortunately, this isn’t difficult to achieve in MySQL.

To further illustrate the problem, here is a simple table description:

> DESC SampleData;



Field
Type


data_char 
varchar(5)

I filled up the table with sample data. The following example query and resulting data shows the problem clearly:

> SELECT * FROM SampleData ORDER BY data_char;



data_char


10


11


120


21


3


a1

As you can see, the results aren’t exactly usable. If we simply modify the order by declaration slightly (add “+0″ to the order by field), you can force MySQL to sort the field naturally.

> SELECT * FROM SampleData ORDER BY data_char+0;



data_char


3


10


11


21


120


a1

There you have it. To force a natural sort, just add a 0 onto the field you wish to be naturally sorted.

Web applications developers such as myself often have a hard time keeping up with everything that’s going on. There’s always some new programming or scripting language, new standards, new browsers, new technologies, new paradigms, new social networks, and on and on. Every day, something new happens. The end result of all of this always ends up being very similar: people demand faster applications that deal with ever-increasing amounts of data which end up putting massive stress on the server architecture.

As we toil to improve the performance of the applications and their snappy response times, it becomes easy to forget about how we can tweak settings on a low level to provide massive speed improvements on the front-end. For example, most people don’t know that you can configure MySQL to take better advantage of the resources that the server has available.

By default, MySQL is configured to consume a relatively limited amount of memory resources. Start giving MySQL more memory to work with, and your application’s performance can improve greatly.

Unfortunately, I’m not a MySQL configuration guru. I’ve never read through the source code or any low-level technical documents about how it functions. So most of the configurations options are a complete mystery to me, and I don’t know if changing a specific option could benefit me at all.

Fortunately, I don’t have to be a MySQL configuration guru to get better performance. There is an amazing tool created by Matthew Montgomery called the MySQL performance tuning primer script.

Matthew Montgomery’s script does an amazing job of giving me information about how my MySQL configuration may be inappropriate for the queries being executed and provides information about what variables to modify in order to better optimize my configuration. For example, the “TEMP TABLES” section of the output tells me the following:

TEMP TABLES
Current max_heap_table_size = 512 M
Current tmp_table_size = 512 M
Of 1684 temp tables, 10% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

Previously, I had my max_heap_table_size and tmp_table_size variables set to default settings and had up to 60% of my temp tables created on disk. As much as possible, temp tables should be created in memory to reduce the performance penalty of using the disk for random access to such data rather than memory which is much faster.

Now this doesn’t mean that you should set your variables to the same settings as I have. The server that this is running on is dedicated to running a dispatching system that has many tables containing hundreds of thousands of rows each. The value of the script is that it will help you tailor your settings to best use your hardware without having MySQL consume too many resources that other processes (such as you web server) could use.

The script is provided as a standard Linux shell script. Download the script into a folder of your choosing and run “sh tuning-primer.sh“.

Good luck with your MySQL optimization. I hope that you get as great of results as I have. Keep in mind that if your table structures and queries are inefficient to begin with, that configuration optimization can only do so much to improve the performance.

Further Reading

• Tuning LAMP systems, Part 3: Tuning your MySQL server
  This is a great read that should help most novice database administrators understand some of the basics about tuning their database’s performance.
• MySQL Performance Blog
  A blog by the authors of High Performance MySQL (also highly recommended). This blog is updated frequently with great tips that will help you develop higher-performance apps.