Following up on this entry, here are some more best practices to secure MySQL in a production environment.

But before moving forward, let me pay credit to Lenz Grimmer who helped me to put this information together.

After setting a password for the MySQL root account and removing the test database and anonymous account you can also limit the remote access to MySQL to a specific host. You do this by setting the bind-address attribute in the /etc/mysql/my.cnf file to the host ip-address:

bind-address=ip-address

If you set bind-address to 127.0.0.1, which is the loopback address, then  MySQL only accepts connections from the host where it runs.

If you uncomment skip-networking in my.cnf MySQL only …

Following up on this entry, here are some more best practices to secure MySQL in a production environment.

But before moving forward, let me pay credit to Lenz Grimmer who helped me to put this information together.

After setting a password for the MySQL root account and removing the test database and anonymous account you can also limit the remote access to MySQL to a specific host. You do this by setting the bind-address attribute in the /etc/mysql/my.cnf file to the host ip-address:

bind-address=ip-address

If you set bind-address to 127.0.0.1, which is the loopback address, then  MySQL only accepts connections from the host where it runs.

If you uncomment skip-networking in my.cnf MySQL …

Following up on this entry, here are some more best practices to secure MySQL in a production environment.

But before moving forward, let me pay credit to Lenz Grimmer who helped me to put this information together.

After setting a password for the MySQL root account and removing the test database and anonymous account you can also limit the remote access to MySQL to a specific host. You do this by setting the bind-address attribute in the /etc/mysql/my.cnf file to the host ip-address:

bind-address=ip-address

If you set bind-address to 127.0.0.1, which is the loopback address, then  MySQL only accepts connections from the host where it runs.

If you uncomment skip-networking in my.cnf MySQL …

You finished the development phase of your Web project, and you are now heading to production. This means that your web-site will be soon on-line, visible on the Internet, and may become a potential target for attacks.

During development, you have been using MySQL on your laptop, and since you are the only one accessing your laptop you used the default configuration as-is. You are perfectly right in doing that, in fact MySQL is pretty secure by default, but here are a set of post-installation best practices to bring MySQL security to the next level.

1) Set a password for the root account. Note that by "root account" I don't mean the super-user of the operating system, but the super-user of MySQL itself:
$ mysql ­-u root mysql
mysql> SET PASSWORD FOR root@localhost=PASSWORD('new_password');

2) If they exist, remove the MySQL anonymous account - or assign a password to it - and …

MySQL backup soon becomes an important matter when the database is used in production. The pain-point comes from the fact that while backuping the database is not available to respond to client requests anymore. With mysqldump - the standard tool for performing MySQL backups - and a large database the operation can go over many tenth of minutes if not hours. If I am running my business on line this is simply not acceptable.

The classical approach to workaround this problem is to take advantage of MySQL replication. I set up a master/slave configuration where the slave acts as copy of the master. Then, when needed, I run mysqldump on the slave without any service interruption on the master.

But ZFS snapshosts bring a new straightforward approach that avoids the pain and the complexity of a master/slave replication.

Snapshots are a key feature of ZFS that allows me to save a copy of …