Everything is a Freaking DNS problem

My good friend Fred just blogged about his favourite set of MySQL tools including Maatkit, Querysniffer , MyTop and other interresting tools.

Check them out..

It makes sense. Sun didn't have a Database in their platform stack yet.

They have an OS they should abandon, but they have the hardware and they have appservers, however for a database people needed to go shop elsewhere.
Oracle , IBM and Microsoft also have a pretty complete stack
Others still need to fill the gaps.. Interesting times..

Some people obviously think I`m still interresting enough to interview

Reminds me of my first interviews over a decade ago .. I`m still being remembered by one of my famous quotes back then rougly translated to "those toddlers steal my bandwith" , when being asked about how the growing userbase of the KULeuven PC rooms in the Dekenstraat influenced my network usage :) (Think 1994 ish :))

But the acutal news is that Profoss is coming closer and closer .. and you should now Register!
So all you Drupal and MySQL folks out there.. this is your chance to learn about virtualization !

Peter notes that you indeed can find pretty recent Enterprise level MySQL rebuilds over at the CentOSPlus repository.

Good things come to those who wait :)

The nice folks over in Luxembourg just posted the schedule for their Linuxdays 2008 conference.
I`ll be talking about MySQL High Availability

I was at LinuxDays.lu already 2 years ago and I remember it as a nice an cosy conf with an interesting combo of tutorials and conference talks. If you are in the neigborhood its worth the time.

Oh .. and you can also see Matt in action again :)

The doorbell rang, I was almost to late .. but I still catched the post guy before he left..
He had a package

I knew what was in the package ..

but I was even more surprised when I opened the book..

Thnx a lot folks !!

I spent way too much time this weekend trying to get the pager stuff in Drupal working for a module I`m playing with.

I had learned a lot from the watchdog module on how paging was supposed to be working and I was trying to do the same with another database. As I got a page limited by the number of records I wanted but I couldn't find any of the fancy next, previous and page number thingies that I wanted.

The watchdog module worked for me and I started stripping the watchdog module till I could actually replace my function with watchdog_overview function. Even replaced the watchdog query with my qeury.. but not such luck.. I couldn't get $output .= theme('pager', NULL, 50, 0); to work.

So as every open source geek does.. I started looking into the code. pager.inc
The header told me the author.. I could mail him and wait or even call him , , but I read on.
$pager_total_items[$element] = db_result(db_query($count_query, $args));
Never returned anything useful.., my mysql log learned me there never was any query with a count ..
Till I modified the pager.inc file to actually perform the query I wanted it to do.. and it started working.
Then I took a closer look at the regexp that was being used to create the $count_qeury
$count_query = preg_replace(array('/SELECT.*?FROM /As', '/ORDER BY .*/'), array('SELECT COUNT(*) FROM ', ''),$query);
However my query was all in lowercase so the count was never inserted.

The only difference between the working watchdog module and my own code was in the use of uppercase SQL statements.
So call me lazy :)

Arjen wonders why the MySQl Cluster Study book is published on Lulu and not trough MySQL 's traiditional publisher.

Altough I was involved in the creation process of the mentionned book, I have no idea why this decision was made but to me it makes perfect sense. MySQL Cluster is a piece of software that is still going to change a lot in the next couple of months and years.
A book published in a traditional way needs a minimal sales volume in order to be worth publishing. If there even is a slight chance that by the time the book gets published a significant amount of content of the book has already changed traditional publishers shouldn't publish the book. Now over at Lulu.com a book won't be print before a customer orders it. So when the book is being sent to me. I get the current version of the book.. If in 3 months the authors decide to rewrite a chapter or make some bugfixes. The book can be updated much faster.
I can imagine that people buying the same title in april next year will already get bugfixes on the version that will arrive at my doorstep in a couple of days.

At least that's why I would publish a technical book on Lulu.

Apart form the Xen book I coauthored earlier this year the nice folks of the MySQL documentation team asked me to review parts of their MySQL Cluster Certification guide.

After a long wait it's finally out !
In contrary to the other one, this book took over a year to finish because there was actually a lot of reviewing done by different people.

You can buy it now at Lulu.com !

John might want to read it to figure out about his 5th step.

John Quinn writes about Scaling Drupal he is taking a one step at a time approach and is still writing his 4th and 5 stages.

His first step obviously is separating the drupal from a separate database server, and he chooses mysql for this purpose, moving your DB to a different machine is a good thing to do.

However then he gets this crazy idea of using NFS to share his his drupal shared files :(
(he even dares to mention that the setup ease is good) Folks, we abandonned NFS in the late nineties. NFS is still a recipe for disaster, it has performance issues , it as stability issues (stale locks), and no security admin in his right mind will tolerate portmap to be running in his DMZ.
(Also think about the IO path that one has to follow to serve a static file to a surfer when the file is stored on a remote NFS volume)

On top of that he adds complexity in a phase where it isn't needed yet. Because of the fact he needs to manage and secure NFS and he is storing his critical files on the other side of the ethernet cable he did create a single point of failure he didn't need creating yet.
Yes as soon as you start to scale you need to look at a scalable and redundant way to share your files.
When those files are pretty static you'll start out with a set of rsync scripts or scripts that push them to different servers upon deploying your application. When they are changing often you start looking into filesystems or block devices that bring you replication, such as DRBD or Lustre
But if today his NFS server goes down he is screwed, much harder than when his database has a hickup.

One could discuss the order of scaling, but adding more webservers might not always be the first step to take, one might want to tackle the database first depending on the application.
He decides to share the load of his application over multiple Drupal instances using apache mod_proxy , then adds Linux-HA to make it highly available.
I`m interested in knowing why he chose for apache mod_proxy and not for LVS

Although using NFS for me belongs in a How NOT to scale tutorial, his other steps give you a good idea of the steps to take.

I`m looking forward to his next steps :) I hope that in part 4 he also removes NFS in favour of a solution with no performance and locking issues that really takes away a big fat single point of failure. In part 5 he discusses how to scale your database environment. The actual order of implementing step 2 and 5 will be different for each setup.

Anyway.. I`m following up on his next steps.. interesting reading