Launchpad Entry: packageselection-server-n-drizzle-integration
Packages affected: drizzle7 wordpress-drizzle
Drizzle is a lighter weight, more flexible fork of MySQL. They are planning a stable release in February, and will definitely be included in the Natty release. Many MySQL based projects will be able to use drizzle with very little if any modification. Drizzle's replication model is also quite a bit more flexible and enabled currently via rabbitmq (though that is pluggable). We should ensure that this works in Natty as well as mysql replication, if not better.
Drizzle, a lightweight, modular SQL database that operates over the MySQL protocol, has been added in the drizzle-server package. To highlight the ease of porting applications to Drizzle, a new package, wordpress-drizzle, is included to showcase Drizzle's flexibility.
Drizzle has a bright future ahead of it, and has had a single overriding purpose from day one of being highly configurable and lightweight. These two attributes make it an excellent choice for both deploying onto IaaS clouds and also for building highly scalable SaaS back end data storage.
Because Drizzle speaks the MySQL protocol, and is 99% SQL compatible (most differences are in the schema DDL, which is simplified in Drizzle to reduce the number of code paths in applications and the DB), we can drop it in as a replacement for most MySQL based applications with minimal changes.
As a web developer, I want to use Drizzle as a backend for a scalable web application that I will deploy onto the cloud using Ubuntu Server.
As a hosting provider I want to provide access to a multi-tenant SQL database that integrates with my existing user authentication system which is stored in LDAP.
As an embedded systems developer I have reached the point of scale beyond which SQLite or similar systems can take me, and I am evaluating Drizzle as a light weight solution on top of Ubuntu/Linaro.
Drizzle will release their stable version before Natty FeatureFreeze.
- Drizzle will have a tested, usable replication system in said stable release.
Drizzle, by defualt, does not have any authentication built in. In order to keep users from accidentally exposing data, we will want to implement some kind of basic authentication. Discussions have been centered around PAM integration, but the drizzle version of the MySQL protocol does not support SSL, so the users' password would not be protected. Another option is to simply configure the 'auth_file' plugin which works something like an htaccess file from apache.
On the same vein, once you are in, you have access to everything with the auth_file plugin and pam plugins, unless you have defined some kind of authorization scheme. Work will be done to extend the auth_file plugin to allow basic pairs of user->schema (a.k.a. "database name").
Configuration of replication as a slave or master will be made clear. There is a lot of work upstream right now on how best to do replication, but RabbitMQ is already supported in some capacity, and since it is in main, may be a good choice. We will work directly with upstream to develop a good generic solution that will be easy to turn on, most likely by copying an example config and changing some values.
A new package called 'wordpress-drizzle' will be created that, when installed, results in a working wordpress blog, backed by drizzle. The database setup will be similar to the normal wordpress package, but the blog will use the drizzle schema. This will probably involve modifying the wordpress package so that its recommends are satisfied with drizzle-server instead of mysql-server | postgresql.
See blueprint whiteboard for work items.
The wordpress blog will be a primary source of testing for the functioning of the different pieces of the system. This also provides a very easy demo story to help users test it and demo it themselves.
We should also test the replication stories with something similar to an ISO test, and almost entirely automated.