Most out-of-the-box MySQL configurations allow access only from the same host on which the server is running. This is absolutely the correct default from a security standpoint. However, it can also cause real confusion if, for example, you launch MapReduce jobs that try to access the database on that host. You may see the job fail with connection errors. If that happens, you fire up the mysql command-line client on the host; this will succeed. Then, perhaps, you will write a quick JDBC client to test connectivity. This will also work. Only when you try these steps from one of the Hadoop worker nodes will the problem be apparent. Yes, this has bit ten me several times in the past!

The previous change tells MySQL to bind to all available interfaces and thus be accessible from remote clients.

After making the change, we need to restart the server. In Ubuntu 11.10, many of the service scripts have been ported to the Upstart framework, and we can use the handy restart command directly.

If you are using a distribution other than Ubuntu—or potentially even a different version of Ubuntu—the global MySQL configuration file may be in a different location; /etc/my.cnf, for example, on CentOS and Red Hat Enterprise Linux.

Or at least not without thinking about the consequences. In the earlier example, we gave a really bad password to the new user; do not do that. However, especially don't do something like that if you then make the database available across the network. Yes, it is a test database with no valuable data, but it is amazing how many test databases live for a very long time and start getting more and more critical. And will you remember to remove that user with the weak password after you are done?

Enough lecturing. Databases need data. Let's add a table to the hadooptest database that we'll use throughout this chapter.