On the 9th of September at 10am CET I will present in Italian a Webinar titled: "Scaling Web Services with MySQL Cluster". You can register here.

This is a summary of the english webinar series in two parts that are now available on-demand:

• Scaling Web Services with MySQL Cluster, Part 1: An Alternative to MySQL Server & memcached
• Scaling Web Services with MySQL Cluster, Part 2: An Alternative to the Memory Storage Engine

Content

There are two common choices to power web …

As a continuation to a previous blog post last week and inspired by Kedar I have created a small script to export tables, stored procedures, functions and views into their respective file. It works for multiple databases where you can specify a list of databases too and although things like events, triggers and such are still missing they are easily added.

It is especially useful to dump stored procedures separately since it is a lacking functionality in mysqldump.

I placed the script in mysql forge for anybody to use, provide feedback and possibly enhancements to it.

Tell us, do you want that you can specify more than one MySQL server address at connect, and if one of the servers doesn't work to connect to the next one in the list. Or use round-robin, so next connect will be to the next server, or some other strategy?

What about if you can specify a callback, so when you throw a SELECT or UPDATE for specific table + column the callback will be called to determine which MySQL server from a list to use - effectively allowing sharding.

Would you like to be able to throw the same query at many servers, like Domas' tool that can query hundreds of servers at once. This functionality could also verify that the results returned from the different servers are the same, or in case of DML - that all server get updated.

Any other ideas? Tell us!

To have more visibility of our systems I needed a method to quickly query large sets of MySQL servers. Though there are few methods like ‘xargs -P’ and dsh, they are overkill for the SQL-only job, and simply not fast enough.

So, I hacked pmysql (274 lines of C) – a tool that is able to run queries on multiple servers in parallel. It can run SQL query on 1000 servers in under 0.1s, and scales well with larger sets of servers.

Use cases can be various – from configuration/schema checks (I really enjoyed using information_schema), to ‘global processlist’ analysis.
Ability to crunch hundreds of megabytes of processlist info in few seconds – priceless, so is schema verification of millions of tables.

It is fast enough to use it as backend for some of real-time health check CGI …

The Sakila project was designed to demonstrate all cutting-edge capabilities of dbForge Studio for MySQL such as Database Projects, Database Diagram, Data Reports, Pivot Grid, Visual Query Builder, Code Refactoring, Database Comparison and Synchronization, and also to let a user get acquainted with the mentioned functionality quickly and easily with the help of the prepared examples.

First of all, you should have MySQL server version 5.1 installed locally (localhost).
Then launch dbForge Studio for MySQL, open Start Page and click Sakila in the Recent Projects section (or open the Sakila project from the File -> Recent Projects -> Sakila.mydev menu).

Open Sakila …

In MySQL Workbench 5.2.26 a new query execution command is available, where query output is sent as text to the text Output tab of the SQL Editor. Some MySQL Workbench users liked the “Results to Text” option available in Microsoft SQL Server Management Studio. Cool thing is with a few lines of Python we implemented this command using the SQL Editor scripting API.

For full documentation on scripting and plugin development, refer to the documentation pointers page.

In this post, you will learn:

• Python script for implementing “Results to Text”
• How you can customize the script to deliver your own customized results format command.

Execute Query to Text (accessible from Query …

For a few years now Proven Scaling has been hosting the MySQL mirror/archive at mirror.provenscaling.com, which provides mainly older MySQL releases (which have been removed from MySQL’s mirror long ago) and MySQL Enterprise releases for the last few years.

Since Proven Scaling has been winding down (and we’ve started paying the bills personally), it doesn’t really make sense for us to maintain as large of a colocation footprint as we have. We’re looking to shift things around, and the mirror is something that’s fairly painful for us to host with a small footprint. We’re hoping another MySQL community member with an already-large datacenter/bandwidth footprint will want to pick it up, where it won’t affect their bottom line so much.

I think there’s still some value in having these files be …

From here :

Hi,

we (MySQL Connectors Team at Oracle, well mostly Andrey in fact) have
created a few experimental extensions, hooking into mysqlnd to extend
the functionality in a more or less transparent way.

A list of these includes

* mysqlnd_sip - A plugin trying to detect SQL injections by learning
  about valid queries and then validate against the known format
* mysqlnd_mc  - A plugin splitting single queries over multiple
  connections (distribution of workload over multiple servers;
  query-splitting / multi-read)
* mysqlnd_ms  - A plugin for doing master/slave read/write splitting
* possibly others might be coming, too.

These plugins were created to validate our APIs wich we are also using
for …

Important note: Please note that if you have installed a MONyog 4.0 (beta) release you cannot install this one unless first completely removing the 4.0 installation including the complete MONyog data folder.

Changes (as compared to 3.77) include:

Bug Fixes:
* Monitors/Advisors on InnoDB Deadlocks were truncating the output message and hence in some cases, users were unable to view both queries involved in the deadlock. This has been changed such that the first 2048 characters of both queries are displayed.
* On Windows 7 systems changes to MONyog’s .INI file from external programs had no effect upon restart (as Windows reverted the changes). Now throughout MONyog’s lifetime the .INI file will be locked so that a user may only edit the file manually when MONyog is not running (but users can use the MONyog interface to change any setting while MONyog is running). Any …