LAMP with ·dotmanila » Perl

Maatkit Parallel Dump and Restore

jervin — Mon, 07 Feb 2011 03:18:11 +0000

Maatkit’s mk-parallel-dump and mk-parallel-restore are great tools for quickly dumping and restoring your MySQL databases. I mean “quick” because it does this via user configurable number of threads. However, if you’re new to the tools, you may encounter several issues like ‘Out of memory!’ or MySQL error ‘Lost connection to MySQL during query…’. Here are 2 tips to avoid them:

Use the –chunk-size with data size option. If you have large tables (a couple of GB), dump and restore may simply consume a lot of RAM. Using –chunk-size like 20M or 50M you use a reasonable amount of memory. The tool manual also specifies more benefits when using chunks http://www.maatkit.org/doc/mk-parallel-dump.html#chunks
Make sure your server’s max_allowed_packet is large enough to accommodate large rows. When mk-parallel-restore fails with “Packet too large” error or any other error in that case, it simply emits the whole SQL statements onto the console making it hard to catch the actual error if your console buffer is too small in turn leaving you clueless if this is indeed your first time.

mk-parallel-restore Outputs BLOB Data

jervin — Sun, 01 Aug 2010 01:54:55 +0000

Recently I was playing around with the Maatkit tools specifically mk-parallel-dump and mk-parallel-restore for refreshing development database copies with production copies. A problem arises when BLOB data is being displayed on the console and transforming my shell prompt into gibberish and missing the results of the restore. Breaking the restore as soon as the BLOB starts output, it was revealed that I was getting the “Got a packet bigger then ‘max_allowed_packet’ bytes” error. After setting this variable to a reasonable value the restore went smoothly.

mod_perlite: Reviving an old part of the dynamic web.

jervin — Thu, 15 Jan 2009 11:33:14 +0000

Back in the 90′s, when the web was new and anything dynamically scripted is ever exciting, CGI scripts takes the role.As the web evolved, mod_perl made it simpler for programmers to write highly capable web applications. And indeed the web is constantly evolving. With the advent of PHP and its upload and run deployment, it took the lead with statistics.

But Perl and CGI scripts may not be lagging behind forever, with the development of mod_perlite, an Apache module the matches deployment simplicity of that of PHP, Perl may again be on the rise.

From its freshmeat.net project page, the creators Aaron Stone and Byrne Reese describes:

mod_perlite is a lightweight Apache module that embeds a Perl interpreter and suggests a default configuration where any file ending in “.pl” is interpreted by Perl. It is the Perl equivalent of PHP in its simplicity and nothing like mod_perl in its complexity.

I believe truly, these is one of the 5 things Perl absolutely needs to gain more adaptations from new breeds. As chromatic from the O’Reilly blog network writes on his article Five Features Perl 5 Needs Now:

mod_perlite, the equivalent of mod_php for Perl. mod_perl is an amazing piece of technology, but it asks a lot of administrators — it effectively takes over the web server. Perl on the web could benefit from a system which allows cheap hosting providers to say “Just upload a few files into this directory, and everything will happen for you automatically!” without worrying about other customers on the same host fighting for resources (or namespaces or memory or…).

Very Serious Developers may still use mod_perl — but novices and the rest of us who aren’t handling more than a hit per second at peak time should have something easier to set up and gentler on resources than CGI.

There are many programming languages out there, and many would argue popularity is a major factor for adaptation. I’d agree most of the time, as soon as mod_perlite hits your local repository shelves Perl could again gain the internet buzzwords.