September 2009 Archives

CouchDB is great. It’s simple interface means all you need to use it is an HTTP client. cURL, for example, works great. I was running into the problem, though, of having to revisit the CouchDB reference and the cURL reference to recall the basic commands.

I was going to write up a quick reference with a bunch of common cURL commands, but Tim Huegdon has already posted a great blog entry so rather than reinvent the wheel, here’s a link!

http://nefariousdesigns.co.uk/archive/2009/08/couchdbs-restful-api/

0 Votes

I ran into this error message for the first time when I was attempting to start CouchDB, which uses Erlang, from a Solaris SMF service.

erlexec: HOME must be set

This is a rare case where a seemingly cryptic error message says exactly what it means. For some reason SMF was not setting the HOME environment variable and for some even more confusing reason Erlang requires it to be set to start up.

I solved the problem quite simply by setting a value for HOME. Since I didn’t plan to use whatever feature of Erlang requires this, I just set it it to /tmp. CouchDb now starts up as expected.

0 Votes

This is another descriptive error message from SVN. “Retrieval of mergeinfo unsupported”

If you’re seeing this error message you’re probably trying to use the reintegrate merger feature in SVN. You probably just used a command like this one:

svn merge --reintegrate svn://foobranch .

This error is caused by a configuration issue on your server, or a significant version mismatch between your client and server. It’s OK, though, this can be worked around pretty easily. Just fall back to the more reliable SVN 1.4 style explicit merger technique.

To use this approach you’ll need to know what revision you either created your branch from, or, if you’ve merged the trunk into your branch since creation, the revision you last merged into your branch. In this example, that revision is revision 42 (being the answer to the ultimate question)

svn merge svn://trunk@42 svn://foobranch .

Another option is to do an explicit revision to revision merger. This more low level syntax can be used for all sorts of crazy mergers including roll-backs and nonsensical mergers that will mess up your code. For this command you’ll need the revision from which you’d like to start your merger and the end revision. In this case I’ll be merging revisions 42 to 87. I’ll be merging these changes from the trunk to my current local path.

svn merge -r42:87 svn://trunk ./
0 Votes

Smart database usage is about more than optimizing slow queries. You also need to make sure you’re only running queries when necessary. A single N+1 query can really cause some serious problems, but luckily there’s a pretty easy way to find these hot spots: MySql query logging.

To enable query logging follow these steps (Tested with MySql 5.0):

  1. Add this to your my.cnf:
log=/var/log/mysql/query.log
  1. Make sure the directory exists and the user that is running mysql has write access to if.
sudo mkdir -p /var/log/mysql/
sudo chmod 750 /var/log/mysql/
sudo chown mysql:mysql /var/log/mysql/
  1. Restart your MySql server using whatever command is appropriate for your OS: /etc/init.d/mysql restart
  2. Generate some traffic
  3. Note the file size of the log increasing. It’s going to grow pretty fast so don’t leave it running overnight or your disk may fill up!

Now that you have some data you’ll need to analyze it. There are lots of tools available, but I’ve had good luck with the simple but awesome open source php script called myprofi

php ./parser.php query.log  > analysis.txt
0 Votes
You're probably here because you were trying to load a MySql database dump and you saw something like this:
bar@foohost:~$  mysql -uroot -p some_database < some_big_dump.db
Enter password: 
ERROR 1153 (08S01) at line 42: Got a packet bigger than 'max_allowed_packet' bytes
Don't panic! This one is easy to fix. It's happening because somewhere on either the MySql client or the MySql server, the max_allowed_packet is being exceeded. It's an easy fix, but you will need to bounce your server.
  1. Edit your /etc/my.cnf and look for the parameter max_allowed_packet. In my case it was set to 1M, which is obviously not big enough. Set it to something larger (but not insanely large). I changed mine to 16M.
  2. Save the file and bounce MySql (/etc/init.d/mysql restart on redhat).
  3. Run your import again, but this time specify an explicit maximum packet size on your client as well. Try this command:
    bar@foohost:~$  mysql -uroot -p some_database --max_allowed_packet=16M < some_big_dump.db
    Enter password: 
    bar@foohost:~$  
    
I hope it worked that time. If not, try making your max_allowed_packet a bit bigger. Once you're done don't forget to set this parameter back to the original size!
0 Votes