Benjamin Wood talks at the Dallas MySQL Tech tour on the history of MySQL

Benjamin Wood started with a presentation on the history of MySQL and the changes in the product over the last few releases. Craig Sylvester showed how to use embedded MySQL. Then Benjamin capped off the event with a presentation on database monitoring and performance tuning. The event did go slightly over scheduled time due to an extended question and answer period following the presentations.

Thanks to all who attended.

Craig Sylvester talking at the Dallas MySQL Tech Tour about embedding MySQL

For MySQL Tech Tour events in your ares, click here.

For those of you who don’t know what this is, it’s another of the O’Reilly traditions we’re trying to continue. (We are trying very hard to make this event as close to a clone of O’Reilly’s as we can.) It’s a free table in the expo hall where people who participate in a non-commercial open source project can exhibit. I organized a Maatkit booth a few times in the past, and was always really grateful to O’Reilly for making the space available. Space in the expo hall is at a premium, but we think that these dot-org booths are even more valuable to the open-source projects and the conference attendees.

So, please tell your friends who care about open source, and ask them to tell their friends too. Let’s get some great open-source projects into the expo hall, alongside the commercial vendors!

Please RSVP below by leaving a comment so we can plan on a) enough pizza, b) any special pizza topping request, and c) have enough meeting space for the pizza.

Oracle Office
6031 Connection Drive
Irving, TX 75039

Please RSVP below by leaving a comment so we can plan on a) enough pizza, b) any special pizza topping request, and c) have enough meeting space for the pizza.

Oracle Office
6031 Connection Drive
Irving, TX 75039

So I love and need only binary tar balls. Installation and removal is done within seconds and no remainings are left over after a removal. To operate the whole I use myenv.
Some software providers unfortunately do not provide binary tar balls at all or not in the form I want and need them. Thus I was thinking about how to get those by extracting them from packages. Up to now I have not had the time to write this down. But today was the right time...

RPM

rpm2cpio galera-22.1.1-1.rhel5.x86_64.rpm | cpio -vidm
tar czf galera-22.1.1-1.rhel5.x86_64.tar.gz usr
rm -rf usr

Extract with:

tar xf galera-22.1.1-1.rhel5.x86_64.tar.gz

DEB

ar vx galera-22.1.1-amd64.deb
mv data.tar.gz galera-22.1.1-amd64.deb.tar.gz
rm debian-binary control.tar.gz

Extract with:

tar -mxf galera-22.1.1-amd64.deb.tar.gz

The packages look quite the same in size:

-rw-r--r-- 1 oli oli 6725416 2012-02-08 13:49 galera-22.1.1-1.rhel5.x86_64.rpm
-rw-r--r-- 1 oli oli 6769606 2012-02-08 14:18 galera-22.1.1-1.rhel5.x86_64.tar.gz

-rw-r--r-- 1 oli oli 1386762 2011-12-12 17:12 galera-22.1.1-amd64.deb
-rw-r--r-- 1 oli oli 1385994 2012-02-08 14:18 galera-22.1.1-amd64.deb.tar.gz

so I assume that there is nothing lost.

The differences in size between DEB and RPM seems to come from the packaging itself:

usr_deb/lib/galera/libgalera_smm.so:   ELF 64-bit (SYSV), dynamically linked, stripped
usr_rpm/lib64/galera/libgalera_smm.so: ELF 64-bit (SYSV), dynamically linked, not stripped

So nothing to worry. The programs itself worked without any problems after the first tests. So I am optimistic that this is a good workaround until I can convince the software vendor to make good binary tar balls...

• QueryScript: server side scripting is now supported by common_schema, which acts as an interpreter for QueryScript code.
• Throttling for queries is now made available via the throttle() function.
• Enhancements to processlist-related views, including the new slave_hosts view.
• Inline documentation/help is available via the help() routine.
• more...

QueryScript

common_schema makes for a QueryScript implementation for MySQL. You can run server side scripts, interpreted by common_schema, which allow for easy syntax and greater power than was otherwise previously available on the MySQL server. For example:

foreach($table, $schema, $engine: table like '%')
  if ($engine = 'ndbcluster')
    ALTER ONLINE TABLE :$schema.:$table REORGANIZE PARTITION;

QueryScript includes flow control, conditional branching, variables & variable expansion, script throttling and more.

Read more on common_schema's QueryScript implementation.

Query throttling

Throttling for MySQL queries was suggested by means of elaborate query manipulation. It is now reduced into a single throttle function: one can now just invoke throttle(3) on one's query, so as to make the query execute for a longer time, while taking short sleep breaks during operation, easing up the query's demand for resources.

Read more on query throttling.

Process views

The processlist_grantees view provides with more details on the running processes. slave_hosts is a new view, listing hostnames of connected slaves.

Read more on process views.

help()

The common_schema documentation is now composed of well over 100 pages, including synopsis, detailed internals discussion, notes and examples. I can't exaggerate in saying that the documentation took the vast majority of time for this code to release.

The documentation is now made available inline, from within you mysql client, via the help() routine. Want to know more about redundant (duplicate) keys and how to find them? Just type:

call help('redundant');

and see what comes out!

The entire documentation, which is available online as well as a downloadable bundle, is embedded into common_schema itself. It's rather cool.

Tests

common_schema is tested. The number of tests in common_schema is rapidly growing, and new tests are introduced for new features as well as for older ones. There is not yet full coverage for all views, but I'm working hard at it. common_schema is a robust piece of code!

Get it!

Download common_schema on the common_schema project page.

Read the documentation online, or download it as well (or call for help())

common_schema is released under the BSD license.

QueryScript is available fro MySQL via common_schema, which adds MySQL-specific usage.

What does QueryScript look like? Here are a few code samples:

Turn a bulk DELETE operation into smaller tasks. Throttle in between.

while (DELETE FROM archive.events WHERE ts < CURDATE() LIMIT 1000)
{
  throttle 2;
}

Convert all InnoDB tables in the 'sakila' database to compressed format:

foreach ($table, $schema, $engine: table in sakila)
{
  if ($engine = 'InnoDB')
    ALTER TABLE :$schema.:$table ENGINE=InnoDB ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;
}

Shard your data across multiple schemata:

foreach($shard: {USA, GBR, JAP, FRA})
{
  CREATE DATABASE db_:$shard;
  CREATE TABLE db_:$shard.city LIKE world.City;
  INSERT INTO db_:$shard.city SELECT * FROM world.City WHERE CountryCode = $shard;
}

This tight integration between script and SQL, with the power of iteration, conditional statements, variables, variable expansion, throttling etc., makes QueryScript a power tool, with capabilities superseding those of stored routines, and allowing for simplified, dynamic code.

QueryScript code is interpreted. It's just a text, so it can be read from a @user_defined_variable, a table column, text file, what have you. For example:

mysql> set @script := "while (TIME(SYSDATE()) < '17:00:00') SELECT * FROM world.City WHERE id = 1 + FLOOR((RAND()*4079));";
mysql> call run(@script);

For more details, consult the QueryScript site.

If you're a MySQL user/DBA, better read the common_schema QueryScript documentation, to better understand the specific common_schema implementation and enhanced features.

common_schema, including the QueryScript interpreter, can be downloaded from the common_schema project page.

For events registration we use the Signup module and use a theme template function to provide a set of standard fields.  The code looks something like this:

function ourtheme_signup_user_form($node) {
  $form = array();
  // If this function is providing any extra fields at all, the following
  // line is required for form form to work -- DO NOT EDIT OR REMOVE.
  $form['signup_form_data']['#tree'] = TRUE;

  $form['signup_form_data']['FirstName'] = array(
    '#type' => 'textfield',
    '#title' => t('First Name'),
    '#size' => 40, '#maxlength' => 64,
    '#required' => TRUE,
  );
  $form['signup_form_data']['LastName'] = array(
    '#type' => 'textfield',
    '#title' => t('Last Name'),
    '#size' => 40, '#maxlength' => 64,
    '#required' => TRUE,
  );

And so on, building up the elements and then returning the form.  This is great because it allows us to have a standard set of fields for all signup pages, making life a lot simpler when creating content that requires registration.  But the Solutions Day event required an extra field.  I could have done this a number of ways, including putting logic in the template file to check for that particular node and only display the field then, or perhaps some other hack specific to this node.  I, however, don't like specifics and tend to look for a generic solution, as the exception invariably becomes the rule.

For this exercise I wanted to be able to have a way of specifying for a particular node any extra fields that are available for this form.  So I now have in the template.php file the following code:

// If there is a special field required for this, check and display
  if (!empty($node->field_signup_extra) && !empty($node->field_signup_extra[0]['value'])) {
    $extras = explode("\n", $node->field_signup_extra[0]['value']);
    foreach ($extras as $field_def) {
        $field_def = trim($field_def);
        if (empty($field_def)) {
            continue;
        }
        $elems = explode('|', $field_def);
        $field_name = array_unshift($elems);

        $form['signup_form_data'][$field_name] = array();
        foreach ($elems as $field_element) {
          list($key, $val) = explode('=',$field_element);
          if ($key == 'options') {
              $val = explode(',', $val);
          }
          $form['signup_form_data'][$field_name]['#' . $key] = $val;
        }
    }
  }

Now all I need to do is create a field that is non-displayable but contains information to build extra fields.  For example the content that describes the Dietary Requirements field is:

dietary_requirements|title=Dietary Requirements|size=40|type=textfield

The production version does a little more analysis of the input to ensure there are no possible attack vectors, but I've left that out for clarity sake.

Now, if I have an event (or other content type) that needs extra signup fields, I ensure that the content type has the new Signup Extras field and fill it on the new content with a simple field definition that Signup can use.