If you can do either of these on your MySQL production server, you need to correct immediately.

1. Login directly to your MySQL server as the ‘root’ Linux Operating System user. For example:

$ ssh root@server-name
Password:  ************

2. Connect to MySQL database as the ‘root’ MySQL user without a password.

$ mysql -uroot

Here are the 60 second fixes to address these major security flaws.
To disable direct root access to your server, first ensure you can login as a normal user, then su - or sudo su - appropriately. Then, disable ssh root access with the following configuration change.

$   vi /etc/ssh/sshd_config
    # ensure this is commented out and set to no
    PermitRootLogin no

$   /etc/init.d/sshd restart

This will stop any brute force attack on your server by automated bots and password generators.

Second, the default installation …

In one week, the MySQL/Sun sponsored Meetup.com subscriptions expire officially. While it's good to see that plenty of offers are available for sponsorship, I am kind of surprised that Meetup.com hasn't received much bad press out of this.

To recap what happened:
- (some years ago) Meetup.com introduced a great service for organizing meetups, and it was free!
- Then they decided that they couldn't make money this way, so they switched to a paid-service-only model.
- Most meetups on other topics started using things like Upcoming and Facebook, but MySQL negotiated a deal to have all MySQL meetups sponsored.
- Meetup.com decided they could make more money out of MySQL by charging for the groups individually, so they canceled the sponsorship deal.

I'm not against …

So I spent several hours over the last few days on the Secondary index bug. Out of frustration I decided to try and bypass the LRU concept all together and try going to a true secondary page cache. In standard Waffle a page is written to memcached only when it is expunged ( or LRU’d ) from the main buffer pool. This means anything in the BP should not be in memcached. Obviously with this approach we missed something, as Heikii pointed out in a comment to a previous post, it seems likely we are getting an old version of a page. Logically this could happen if we do not correctly expire a page on get or we bypass a push/lru leaving an old page in memcached to be retrieved later on.

So I was thinking why not bypass the LRU process? While I feel this is the most efficient way to do this, its not the only way. I modified innodb to use the default LRU code and then modified the page get to push to memcached on any disk read. Additionally I added …

I wrote a small DTrace script to understand InnoDB IO statistics. This script shows statistics about different kinds of Innodb IO requests and how many of them result in actual IO. Sample output is shown below

#./inniostat -h
Usage: inniostat [-h] [-d] [-p pid] [interval]
                 -h : Print this message
                 -p : MySQL PID
                 -d : Dump dtrace script being used

# ./inniostat
 __physical__  ___Innodb___ ____read____     ______write______
   r/s    w/s    r/s    w/s   data    pre    log dblbuf dflush     Time
    24    121     24     50     24      0     50      0      0 16:00:57
    26    130     26     51     26      0     51      0      0 16:00:58
    18    134     18     54     18      0     54      0      0 16:00:59
    25    129     25     51     25      0     51      0      0 16:01:00
    29    116     46     47     17     29     47      0      0 16:01:01
    10    140     10    132     10      0     52      0     80 …

I wrote a small DTrace script to understand InnoDB IO statistics. This script shows statistics about different kinds of Innodb IO requests and how many of them result in actual IO. Sample output is shown below

#./inniostat -h
Usage: inniostat [-h] [-d] [-p pid] [interval]
                 -h : Print this message
                 -p : MySQL PID
                 -d : Dump dtrace script being used

# ./inniostat
 __physical__  ___Innodb___ ____read____     ______write______
   r/s    w/s    r/s    w/s   data    pre    log dblbuf dflush     Time
    24    121     24     50     24      0     50      0      0 16:00:57
    26    130     26     51     26      0     51      0      0 16:00:58
    18    134     18     54     18      0     54      0      0 16:00:59
    25    129     25     51     25      0     51      0      0 16:01:00
    29    116     46     47     17     29     47      0      0 16:01:01
    10    140     10    132     10      0     52      0     80 …

Would you trust a 'for profit' company to represent your best interests? Perhaps. But when your interests diverge, will they represent you or themselves?

Following the overwhelming success of our first article on the domain name industry (1 comment ;-), we naturally thought you were begging for more! I know, I know registrars and registries can be a bit dull, but it is important. Believe me when something goes wrong with your domain name, understanding this can be quite important. So if we look at how and where issues can be dealt with, and who has influence in the industry it sheds a bit more light on the subject.

So now we know who's who in the tree (ICANN, Registries, Registrars, Resellers and You) we can see how the influence the landscape and who has control of what. In a nutshell:

…

Dear Lazyweb,

Yesterday I tried to Rsync a MySQL data directory from serverA to serverB on the same network. I thought that if out of a few hunded gigabytes maybe 2% changed, this should work, right? Wrong. Rsync is designed to minimize bandwidth, so in my case it was *much* quicker to wipe the data and start again (I feel this is something I should have known earlier, but it doesn't hurt to try and share your mistakes).

Which gets me thinking - it doesn't have to be this way. Bit-torrent works in a similar way to Rsync, but it's certainly not network efficient. Are there any projects similar to Rsync that are using network-hungry algorithms to try and make sure that two directories are in sync with the goal just being as fast as possible?

Dear Lazyweb,

Yesterday I tried to Rsync a MySQL data directory from serverA to serverB on the same network. I thought that if out of a few hunded gigabytes maybe 2% changed, this should work, right? Wrong. Rsync is designed to minimize bandwidth, so in my case it was *much* quicker to wipe the data and start again (I feel this is something I should have known earlier, but it doesn't hurt to try and share your mistakes).

Which gets me thinking - it doesn't have to be this way. Bit-torrent works in a similar way to Rsync, but it's certainly not network efficient. Are there any projects similar to Rsync that are using network-hungry algorithms to try and make sure that two directories are in sync with the goal just being as fast as possible?

I just realized that I haven't blogged for more than a month! Shame on me. But I will blame it on being away on conferences and vacation for quite some time And if you are following me on twitter, you may have noticed what I was going on in my life and that I did't get hit by a bus...

So what was going on since I returned back home from the MySQL Conference? First off, I uploaded und sorted my pictures from the conference and the Drizzle developer day on Flickr. I also uploaded the slides (PDF) from Colin and myself speaking about "MySQL Server Backup, …

When meeting with MySQL customers I find they usually have some very strong misperceptions of using the free version (Community Version) of MySQL and that they have no need to purchase the Enterprise Version of MySQL.First of all, most new MySQL users do not install, configure, tune or manage the MySQL database server properly. MySQL is the easiest database server in the world to install, but if