-
North Texas MySQL Users Group Meeting set for March 12th
The March meeting of the North Texas MySQL Users Group will be March 12th from five to seven PM at the Irving office. Pizza will be provided and a special guest speaker is double checking their schedule. Come come network, gather swag, and learn more about MySQL.
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
-
Shinguz: I prefer MySQL binary tar balls with Galera...
In my set-ups I have different MySQL versions (MySQL 5.0, 5.1, 5.5 and 5.6, Percona Server 13.1 and 24.0, MariaDB 5.2.10, 5.3.3, Galera 1.0, 1.1 and 2.0) running in parallel at the same time.
Up to now I have not found a practical way yet to do this with RPM or DEB packages. If anybody knows how to do it I am happy to hear about it.
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.gzDEB
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...
-
common_schema rev. 218: QueryScript, throttling, processes, documentation
common_schema, revision 218 is released, with major new features, top one being server side scripting. Here are the highlights:
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 amp; 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: SQL scripting language
Introducing QueryScript: a programming language aimed for SQL scripting, seamlessly combining scripting power such as flow control amp; variables with standard SQL statements or RDBMS-specific commands.
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 lt; 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:
mysqlgt; set @script := while (TIME(SYSDATE()) lt; '17:00:00') SELECT * FROM world.City WHERE id = 1 + FLOOR((RAND()*4079));;
mysqlgt; 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.
-
Adding dynamic fields to Signups on Drupal
In my day job at SkySQL I work with Drupal as our content management system.#160; One thing we often need to do is provide a way for people to sign up for events and the like.#160; One such event is the upcoming SkySQL and MariaDB: Solutions Day for the MySQL#174; Database and unlike other events we needed to take into account the dietary requirements of those wishing to attend.
For events registration we use the Signup module and use a theme template function to provide a set of standard fields.#160; 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' =gt; 'textfield', '#title' =gt; t('First Name'), '#size' =gt; 40, '#maxlength' =gt; 64, '#required' =gt; TRUE, ); $form['signup_form_data']['LastName'] = array( '#type' =gt; 'textfield', '#title' =gt; t('Last Name'), '#size' =gt; 40, '#maxlength' =gt; 64, '#required' =gt; TRUE, );
And so on, building up the elements and then returning the form.#160; 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.#160; But the Solutions Day event required an extra field.#160; 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.#160; 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.#160; 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-gt;field_signup_extra) amp;amp; !empty($node-gt;field_signup_extra[0]['value'])) { $extras = explode(\n, $node-gt;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.#160; 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.Original post blogged on Saki Envirotech Blogs.
|
.
News Feeds