So, the sitch as of today:

Added ndb_mgm_set_configuration() call to the mgmapi - which is not-so-casually evil API call that sends a packed ndb_mgm_configuration object (like what you get from ndb_mgm_get_configuration) to the management server, who then resets its lists of nodes for event reporting and for ClusterMgr and starts serving things out of this configuration. Notably, if a data node restarts, it gets this new configuration.

By itself, this will let us write test programs for online configuration changes (e.g. changing DataMemory).

I’ve also added a Disabled property to data nodes. If set, just about everywhere ignores the node.

This allows a test program to test add/drop node functionality - without the need for external clusterware stopping and starting processes.

If you start with a large cluster, we can get a test program to disable some nodes and do an initial cluster restart …

So my timeout patches for the MySQL Cluster Management API have been finished. This should solve a lot of people’s problems writing management API  applications that want to do something sane when the management server either dies or gets somehow disconnected from you.

More importantly I should say, the autotest run looks good. It passed 199 tests in the daily-basic suite… which is a new record (I added some tests, so that could be classified as cheating)… probably would have been 200 if a sporadically failing test hadn’t failed :(

During my trip back to Melbourne, Jonas will probably apply these to a bunch of trees (at least some of the telco release) - with 5.1 coming at some point.

We welcome back for a second time Lisa Dobson, who has published the 36th edition of Log Buffer, the weekly review of database blogs, on the Oracle Newbies Blog. The editorship of Log Buffer is distributed amongst volunteers. There are a few editors lined-up for the coming weeks, but there’s always room for more. [...]

In addition to launching RHEL 5 earlier this week, Red Hat previewed their forthcoming online marketplace Red Hat Exchange, or RHX.  While no date has been announced, Red Hat has identified an initial set of partners which includes a who's who of leading commercial open source companies such as Alfresco, JasperSoft, MySQL, Pentaho, SugarCRM, Zimbra and Zmanda, among others. Under the Red Hat Exchange, customers will be able to buy support subscriptions for these products directly from Red Hat's web site giving newer companies direct access to Red Hat's installed base. And for Red Hat customers, they get the proverbial "one throat to choke" ensuring compatibility and integrated support. 

RHX is the brainchild of long-time Red Hat employees Matt Mattox and Mike Evans and I expect more details will be coming in the months that follow.  But in case …

I was reading a couple of items on gapingvoid

• the hughtrain
• the porous membrane: why corporate blogging works

which inspired me to use our blog for a conversation with our customers (and with potential Pythian DBAs) about what it’s like to work with Pythian.

What exactly does an on-site DBA get from working with Pythian Remote DBAs?

1. Sleep.
2. Support: phone, IM or email some who either knows how to help or knows someone who knows how to help.
3. Teammates: You can delegate tasks which are either too hard or too easy onto Pythian.
4. Accountability. Every minute, every hour is documented for all to see, internally and by individual clients.
5. Understanding: Someone who knows what being a DBA is like.

You are on-site. Picture the Pythian on-call team standing behind …

Schon wieder diese langweilige CMS-Seite, die du zum tausendsten Mal bauen musst? Das Gefühl zu haben, nicht richtig mit dem KnowHow vorwärts zu kommen, vielleicht weil du auch alleine als Freelancer unterwegs bist, es aber schöner wäre, mit Kollegen zusammen zu arbeiten und sich gegenseitig mit KnowHow zu befruchten? Das muss nicht sein, denn Mayflower sucht DICH.

An unseren Standorten in München und Würzburg entwickeln wir Highend Anwendungen für Intranet und Internet. Beispiele:

• Deutschlands größtes Video on Demand Projekt auf Basis von OXID e-Sales, mit DRM-, SOA- und Payment-Anbindung
• Die Fernparametrisierung von Heizanlagen mit intelligenter Datenanalyse und Anbindung an …

unixODBC has had support for UNICODE for quite some time but UNICODE was never implemented in the installer and setup layers. Nick has been working to implement this recently and I have been testing it out during MySQL C/ODBC v5 development.

I have been creating a new look & feel for the unixODBC web site which I hope will get used once its complete. This also involves cleaning up, updating, and enhancing some of the documentation.

Oh; almost forgot. Nick and I both had some work to get the Qt3 code to support being built in Qt4… Nick got to the finish line first

The Connectors team at MySQL has been reorganized and includes additional resources. It seemed fitting to have a meeting for those working on C/ODBC v5.

We had a week long meeting in Germany at a place called Bad Herrenalb (since 4 of the new resources are living in Germany).

By the end of the meeting we had a revised development plan in place with tasks assigned and target dates set.

More resources have been allocated to the Connectors team at MySQL and most of them are focused on either C/ODBC v3 bug fixs or C/ODBC v5 development.

The folks working on C/ODBC v3 have been knocking off bugs at speedy pace. The Engineering team have been lending their time as well by taking over the build-to-release process. Still others are working on improving QA by adding new tests and creating a new automated process to run them.

This work has resulted in a new release of C/ODBC v3.

So far, the MySQL Server RPM packages as provided by MySQL AB used to automatically start the mysqld process after the package has been installed. It has been like that since the very beginning and we think of it as a convenience for our users when they want to get up and running quickly.

However, Kristian raised an interesting point in BUG#27072 where he points out that automatically starting mysqld during the RPM installation might not always be the desired behaviour, especially in automatic installation environments or during a fresh installation (where the system might not be fully configured yet). Therefore he proposes to change this behaviour to not start mysqld as part of the installation.

While I personally agree with his proposal, this is of course a tricky decision: our users are familiar with …