I just pushed up a new Drizzle branch at
lp:~fallenpegasus/drizzle/newplugins
It contains two new plugin types, one for configuration
interface, and one for query cache. Those two are not "plumbed
in", and are in fact just templates, containing two dummy entry
points with two dummy parameters. But they follow the evolving
pattern for plugin types.
It also contains fixes and improvements for the logging and
errmsg plugins. The logging engine implementation has parameters
for filtering for slow queries and for "big queries", both ones
that return a lot of rows, and ones that just examine a lot of
rows.
It's all also been internationalized.
There is still lots of work to be done, but it's fun to get this
foundation stuff going.
I just read that Toru has a branch he's been working on a query
cache plugin interface as well, so we need to work together to
stitch all our work …
It’s like removing the brakes from your car. yes, it will go faster (slightly less weight) but, dude, you just removed the brakes.
The errmsg plugin interface is almost done.
The next plugin interface will be fairly more fraught, but
useful. Making the configuration interface as a plugin.
This means that instead of keeping the configuration in the
/etc/my.cnf and/or /etc/drizzle.cnf, the configuration variables
could be kept in the Gnome registry, or in LDAP, or via lookups
in some online configuration database server.
This would make managing and configuring huge arrays of Drizzle
servers much much easier.
A while back, Giuseppe pointed out Andrey Zhakov’s implementation of Virtual Columns for MySQL.
Since then, Andrey has ported that code to Drizzle and sent us a message about the Launchpad Tree.
First, the bad news. I waited long enough to actually look at it that the merge was no longer clean. The Drizzle codebase moves pretty quickly, you know. Andrey was wonderful about helping fix those issues, I got it all merged in and tested, and pushed.
Drizzle now has Virtual Columns. w00t.
As a quick aside, I’d like to mention a few things Andrey …
[Read more]
So many engines, and so little to choose from. This is one of our
two major decision points in Drizzle right
now.
Let me explain.
Today we have Innodb, Maria, Falcon, and PBXT.
Simple?
Not really. Innodb is not a single engine, it is three engines.
We have the default one which is shipped. It has been the
wunderkinder for years now but has been showing its age. Go buy a
piece of hardware that has four cores and it quickly becomes
apparent that it is not aging well. There is the Innodb plugin,
and while it delivers on features, performance still …
So, I installed one of those math question anti-spam plugins for WordPress comments. It stopped the spam! Unfortunately it also stopped all valid comments when the answer was right, although it did work when I first set it up. So if you tried leaving a comment (I see a few were denied) for one of the recent Drizzle or MySQL related posts (like the New libdrizzle), please try again. :)
Anyone have a suggestion for a good anti-spam plugin for WordPress comments? I’ve looked a bit but nothing really stands out.
What’s the new libdrizzle? It’s a complete rewrite of the client library for the Drizzle project, but it also has full support for the current MySQL protocol (4.1+). Right now Drizzle uses the same protocol as MySQL, but work is being done to design a new, more robust protocol. Even when the Drizzle protocol changes, I plan to keep full support for the MySQL protocol since there is a need for a good low-level non-blocking client library. Also, once libdrizzle turns into a full protocol library (server and client packets) it could make for some interesting Drizzle/MySQL hybrid proxies.
Over the weekend I made a lot of progress on the new library, and last night I just finished up the first pass at the core functionality. It can now do full query and result processing. Currently only non-cached results are being used (no store_result() function), but the cached interfaces will be …
[Read more]
MySQL, and thus currently Drizzle, logs stuff to it's error log.
"Stuff" being errors, warnings, and info messages. Inside the
code, they ultimately get sent to stderr, which is directed to
whatever file is specified by the "log-error" option. It's all in
the MySQL documentation at http://dev.mysql.com/doc/refman/6.0/en/error-log.html
I'm changing that in Drizzle, replacing the error logging stuff
with a plugin interface.
The first implementation will, just like the current builtin
system, write to a file, or to stderr. I expect soon after,
plugins that send the messages to syslog, as SNMP traps, and to a
CSV table, will be written.
Just like the query logging work, getting this going will shink
the drizzle core even more, and likely remove still more unneeded
locks.
Is anyone out there actually still using 32-bit systems for new deployments? On purpose?
I know I occasionally see people who have 64-bit systems and have installed 32-bit OS on them. They are one of two things: people who don’t know what they are doing, or why their server is then having memory problems, or people who have 32-bit Linux installed on their laptops because there is no good 64-bit Flash Player plugin for Linux. (/me shoots Adobe in the Face… it’s called re-compile it and release, please)
The 32-bit laptop people I don’t care about - they are not yet hosting websites on their laptops while browsing YouTube. Yet.
The others just need the learning.
Which brings me back to… should we start to consider 32-bit a dinosaur sort of like AIX 4.1?
(I should be clear here… I am honestly asking… not just trolling. I’m also not advocating bad code - see previous …
[Read more]
I haven’t been doing any new features or exciting things like Query Logging on Drizzle, although I have to say that I’m very much looking forward to logging to syslog. What I have been up to is continuing the seemingly never ending battle to clean up things in the code. Some of the changes are essentially style issues, but some of them additionally help to uncover potential problems. Take my most recent nemesis, ulong.
There are multiple problems with ulong. The
first is that it’s non-standard. If you want your code to be
portable at all, you have to do something like this in a header
file.
#if !defined(HAVE_ULONG) && !defined(__USE_MISC)
typedef unsigned long ulong; /* Short for unsigned long */
#endif
Now, of course, there’s nothing fundamentally wrong with …