Jun 302012

Drizzle is an open source fork of MySQL, actually InnoDB only, that is designed to be faster and more scalable than the vanilla MySQL.

I finally decided to test it out instead of just mucking around as I had done earlier. * My system *

uname -a
Linux Tron 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:25:36 UTC 2011 i686 i686 i386 GNU/Linux</pre>


Headed over to Drizzle and proceeded to see how I can install their box version. I chose Ubuntu as I have a bare metal 11.10 which will do quite well to test both MySQL and Drizzle out. Followed instructions athttp://docs.drizzle.org/installing/ubuntu.html The CentOS install looks a lot lengthier (workarounds?). The best way would be to compile from source but I am not really interested in that right now.

At the update I get the following errors. This is understandable.

Ign http://extras.ubuntu.com oneiric/main TranslationIndex
Ign http://extras.ubuntu.com oneiric/main Translation-en_SG
Ign http://extras.ubuntu.com oneiric/main Translation-en
Fetched 762 kB in 2min 15s (5,607 B/s)
W: Failed to fetch http://ppa.launchpad.net/drizzle-developers/ppa/ubuntu/dists/oneiric/main/source/Sources  404  Not Found
W: Failed to fetch http://ppa.launchpad.net/drizzle-developers/ppa/ubuntu/dists/oneiric/main/binary-i386/Packages  404  Not Found
E: Some index files failed to download. They have been ignored, or old ones used instead.</pre>

However, I was able to complete installation without issues. Time to RTFM. Yes! I like to dive first read later, makes it more interesting.


If you visit the docs http://docs.drizzle.org/configuration/options.html#config-files you will see it does not really say where the config file is. This tells me that Drizzle assumes prior knowledge of MySQL Administration so you can fill in the gaps yourself, but Drizzle is very different. Or you could help with Documentation yeah? Drizzle claims to work without configuration out-of-the-box. However since I do have a mysql protocol port used I want to make sure I override it in Drizzle.

I create my config directories under a regular user, in mysql it just went to /etc/ mount point by default. Drizzle made no assumption, there was no directory or anything. Maybe it’s just on Ubuntu, honestly I don’t know. Doc says default direcroty is /etc/drizzle. it even goes on to say that it has a specific name for the default file if you want to skip specifying one.

cd ~
mkdir drizzled
touch drizzled/drizzled.cnf #
touch drizzled/conf.d/server1.cnf # drizzle will read all configs in this directory automatically
touch drizzled/conf.d/auth
touch drizzled/users</pre>

This is good enough for me. So I can now specify a default conf and a directory with all my config in case I need more than one.

Edit drizzled.cnf.

vi drizzled/drizzled.cnf

adding the config values I need.

mysql-protocol.port=3307 # since I use 3306 for mysql

Edit the auth file , which you should set to strict permission I suppose. In drizzled/conf.d/auth where I will write what the doc says.

# Options for the plugin itself
users=/home/drizzle/drizzled/users #assuming your home is drizzle a full path is needed.

I could apparently write everything in one file (drizzled.cnf) except the users.

The documentation breaks off at this point and goes into details of Options and Values so I go looking for RTFM on Auth.

Setup of authentication

This I like, you can easily setup Auth just like PostGreSQL anyway you want. You can read more here http://docs.drizzle.org/administration/authentication.html To keep things simple I used flat file. The suggested way is Schema which is same as MySQL, meaning usernames and passwords are stored in a table inside the database of the Drizzle DB, like the mysql.user table. To set that up will take more time but the gyst is, we first allow all, then create an admin users…snore. Feel free to read about it and knowck yourself out. Moving on to Flat file …

Since I already added my flat file settings above I am going to now fill it in with my users. This is easy (or so I thought), e.g.


… cute.

I suppose we’re done here, it was painful but now I have a neat gun. Now the good stuff.

Start your engine

Issuing command…

drizzled &#8211;config-dir=/home/drizzle/drizzled/
 output: Local catalog /var/lib/drizzle/local does not exist

 wtf! ouch!

Troubleshooting…as its obviously a permission issue.

Seems I am logged in as user abhishek but drizze is user drizzle facepalm A handy command line option appears: [-u] Unfortunately I need to sudo and then provide the user. Directly won;t work 

#sudo drizzled &#8211;user drizzle &#8211;config-dir=/home/drizzle/drizzled/
 To daemonize it, we need spawns @[email protected]

sudo drizzled &#8211;user drizzle &#8211;daemon &#8211;config-dir=/home/drizzle/drizzled/

_ I believe my setup is wrong on this part, it could have been done better. It works fine for now so I can test _ We’re online, lets login.


wtf!, I can login. So it seems my default file is not being read, contrary to RTFM. fair enough. I forced the –defaults-file= option but I got a new error. It turns out I need the plugin for auth-file which I am trying to use. I don’t know where I can download this, docs are being generally unhelpful here. Time to go fish… a.k.a google.

I never did get the auth working. I stopped using drizzle, though i believe you can use it as embedded DB or something.

 Posted by at 7:08 am
Jun 302012

This is not the best or perfect way, however this works for me and I was asked to share. This is going to be my first post. The AMI I am using is Instance Store backed. You could use the same for EBS backed AMI though I have not tried.

Let’s assume you are creating the original AMI in US-East and you want to put a copy in US-WEST.

  • When you create AMI simply upload bundle to US-WEST bucket as well.
  • Proceed to register AMI in US-East to ensure it works there. If it already works then try to register in US-WEST.
  • You can at this point simply register the AMI from the bucket Manifest URL or it will fail complaining about Kernel.
  • When this happens you need to fix the kernel-id. The rest of the steps are only done on the Target region US-West.
  • In US-West you will find the OS of your choice in the publicly avalable AMIs and then proceed launch it. However you don’t need to start an instance.
  • Assuming you used the AWS web console, in the following screens you can see a dropdown list of Kernel ID. Simply select the dropdown list and choose one.
  • For e.g. my original AMI is based on CentOS 5.5 so in US-West I looked for CentOS5.5 and found a kernel ID.
  • Note down a bunch of kernel ID from the list. the kernel ids start with aki-xxxx
  • Go to the US-West S3 bucket where you uploaded the AMI bundle files you wanted to migrate and find the xxxx-Manifest.xml. Download and open it in an editor of your choice.
  • Let us fix our AMI’s xxxx-Manifest.xml. Look for the section of XML about machine configuration. Something like this…


You will note there is a kernel_id element there. So edit it and replace the kernel id with the one we got in US-WEST.

  • Remember to make a copy of the original Manifest.xml in case you make a mistake. Save it somewhere for future reference or rename the manifest.xml name if you are saving in the same bucket as the orignal manifest to avoid confusion.
  • Upload your edited xxxx-Manifest.xml back to your AMI bucket replacing the one that is already there.
  • Try to register the AMI again. If that fails try another kernel-id following the same process as above

That’s about it. Pretty simple and straightforward. I am sure Tech team at AWS are working on a better solution for this.

Jun 282012

I decided it’s not worth wasting time on Blogofile, awesome concept and a working S3 deployment plugin. Unfortunately I could never get the styles to work for Code highlighting seems there is much to fix and hardly any help on the matter.

I often considered simply using Flask microframework to do a python blog system by myself. Not to reinvent the wheel but to learn Python along the way. I do not have time for that either and delaying my itch to write things on my scratch pad is getting mildly annoying now. Have…to…scratch.


So good ol’ WordPress it is, it never fails except when it gets randomly hacked by script kiddies. Plus I am using Redhat Openshift so I still get to learn something here. Now I got to figure what to do with my AWS instance which I had setup for advanced fiddling. I guess I will use the Route 53 only for now then,  AWS has been kind enough to give me  enough credits to last quite a bit.

It’s time to copy paste my only two posts in blogofile which I made before I cracked, damn monokai styles wouldn’t load. The whole thing was screwed up at the template level.

I also hope no one finds this site.

 Posted by at 5:36 pm