It is bit panic to see ‘Using filesort‘ from the extra field when one runs a explain of select query on MySQL server. At times it is bit annoy why MySQL optimizer does not avoid this as you can see from the following cases…

This is the information (Extra field) that scares a lot for many users from Explain output:

1
2
3
4
5
6
7
8
9
10

          id: 1
  select_type: SIMPLE
        table: t1
         type: index
possible_keys: NULL
          key: col1key
      key_len: 5
          ref: NULL
         rows: 1000000
        Extra: USING index; USING temporary; USING filesort

Lets consider the following simple …

I came across a problem on site yesterday. In moving the development environment to a new server and creating more appropriate permissions for users (they were using ALL on *.*) I found that the Java application would crash with a NullPointerException. The permissions were standard, and calling the Stored Procedure worked via the mysql prompt.

CREATE USER devuser@99.99.99.99;
GRANT SELECT,INSERT,UPDATE,DELETE,EXECUTE ON devdb.* to devuser@99.99.99.99;
CALL sp_test()

You can spend a lot of time looking into problems, luckily this development configuration had taken my advice to enabled the General Query Log. (Something everybody should do to know your SQL).

In closer inspection the following command was being sent to the MySQL Server. SHOW CREATE PROCEDURE sp_test; Attempting to run this command via the mysql prompt works.

SHOW CREATE PROCEDURE sp_test;
+-----------+----------+------------------+
| Procedure …

Time to install MySQL on my new MacBook.

$ cd /opt
$ wget http://dev.mysql.com/get/Downloads/MySQL-5.0/mysql-5.0.45-osx10.4-i686.tar.gz/from/http://mysql.mirrors.hoobly.com/
$ tar xvfz mysql-5.0.45-osx10.4-i686.tar.gz
$ cd mysql-5.0.45-ox10.4-i686
$ scripts/mysql_install_db
Installing MySQL system tables...
071129 22:10:48 [Warning] Setting lower_case_table_names=2 because file system for /opt/mysql-5.0.45-osx10.4-i686/data/ is case insensitive
OK
Filling help tables...
071129 22:10:48 [Warning] Setting lower_case_table_names=2 because file system for /opt/mysql-5.0.45-osx10.4-i686/data/ is case insensitive
OK

bin/mysqld_safe &
[1] 239
macbook:mysql-5.0.45-osx10.4-i686 rbradfor$ chown: /opt/mysql-5.0.45-osx10.4-i686/data/macbook.err: Operation not permitted
Starting mysqld daemon with databases from /opt/mysql-5.0.45-osx10.4-i686/data

$ bin/mysqladmin …

Time to install MySQL on my new MacBook . $ cd /opt $ wget http://dev.mysql.com/get/Downloads/MySQL-5.0/mysql-5.0.45-osx10.4-i686.tar.gz/from/http://mysql.mirrors.hoobly.com/ $ tar xvfz mysql-5.0.45-osx10.4-i686.tar.gz $ cd mysql-5.0.45-ox10.4-i686 $ scripts/mysql_install_db Installing MySQL system tables... 071129 22:10:48 [Warning] Setting lower_case_table_names=2 because file system for /opt/mysql-5.

I'm onsite at a customer's site this week. One of the questions I was asked, was if they have any problems with upgrading to 5.0, could they migrate quickly back to 4.1.

I thought this was a simple (but fair) question, so I devised a test:

1. They send me their 4.1 database (from mysqldump)
2. I import it into my 4.1, then mysqldump (eliminate variables)
3. Import that dump into 5.0, export it.
4. Import that export into 4.1, export it.
5. I then run diff over the file in step 2 and in step 4.

In theory the diff should be identical (except for the the date in a comment). However, this isn't always the case!

It has been over three years since we began our road to build an open source ERP and CRM suite, and I am frankly surprised by how far we have come in such a short period of time. I owe a great deal both to our team of outstanding professional developers who work full time on developing and advancing opentaps and to the open source community at large for providing us with so many great tools.

Nevertheless, I think it is time to look further and higher--to look beyond open source ERP and CRM. I say this for several reasons:

First, "ERP" and "CRM" refer to software that was invented 15, even 20 plus years ago. The driving technologies behind classic ERP and CRM were the SQL database and client/server networks. This predates just about every other piece of software you use today. So, if we merely set our sights to build ERP or CRM software, we are really looking to …

Tomorrow is the first of five days I will spend working on mk-table-sync, the data synchronization tool I developed as part of Maatkit. The first thing I’ll do is pull the row-checksumming code out into a module and write a unit test suite for it. I’ll probably add the code to the module [...]

A bit of exciting news… Proven Scaling has officially gone global with the addition of a new MySQL Geek, Mike Griffiths of London, England to our team. We are now capable of easily and efficiently (timezone-wise and travel-wise) handling your on-site MySQL consulting needs in the London area, the UK, and Europe at large. (As well as making remote work in the middle of the night for our US customers a fair bit easier.)

Mike comes to us from Yahoo! Europe where he worked for a number of years specializing in MySQL operations, performance and optimization, replication and high availability, and scalability. He has been a personal friend for several years and I have been looking forward to him joining the Proven Scaling team since we started the company.

If you’re looking for MySQL consulting in Europe (or anywhere, for that matter), …

We are just in the process of running the final 5.0.10 builds. If Johannes does not discover any last-minute major bug we are going to upload to the mirrors soon and the release will be available tomorrow. The complete build and packaging process is now fully scripted.

The community did an amazing job in reporting bugs - there were a lot of issues that slipped through the first release. And so did the team. 75 bugs were closed since the 5.0.9 release in just 9 days. If we can keep that pace we will reach RC even sooner than I expected.

A lot of P1 and P2 bugs have been closed, we still have a load of P3 + P4 to go and I hope the stream of bugs keeps getting in, so we discover all issues soon. My biggest concern is about some threading issues we seem to have in the core which causes “random” crashes. We will run stress tests to trace those down during the next weeks.

Ok, builds have finished, now the last QA test are …

I think the briefest way to sum up the difference between a good developer mindset and a good sysadmin mindset is “a good developer thinks, ‘how will this work?’ and works accordingly. A good sysadmin thinks, ‘how will this break?’ and works accordingly.”

Developers think in terms of “edge cases” and “off by 1″ errors, which start from a default of things working. This is good as a design skill; developers need to think algorithmically, pondering a main way of something functioning and then dealing with anomalies.

However, sysadmins tend to install systems and maintain them with scripts, as opposed to building new software — usually. Sysadmins deal with systems when anomalies happen, so they must have a mindset of “how will this break?” vis-a-vis — “how will this break and how can I be notified of the breakage before my boss/the customers call?” which leads to “what if the notification system …