This blog entry is about a specific storage engine in MySQL. The Federated storage engine enables data to be accessed from a remote MySQL database on a local server without using replication or cluster technology. When using a Federated table, queries on the local server are automatically executed on the remote (federated) tables. No data is stored on the local tables.

When we released MySQL 5.1.24, the Federated engine was not compiled in, pending decisions on our future steps. The reason for the removal was that we realised (albeit quite late in the game) that Federated has some bugs that expose the server to unnecessary risks. Fixing these bugs is a time consuming process, because the root cause lies in the design of the Federated engine.

The removal was a safety precaution, which made the server more secure. However, it also deprived some users of an engine that they had been using for some time (Federated was introduced in MySQL 5.0.3).

Thus, we were left with the dilemma of more security versus more features. After much internal discussion, we reached a compromise. In 5.1.25, we reintroduced Federated as it was, but in the meantime we prepared a change for 5.1.26 which was just released. Federated is now compiled in, but disabled by default. This means that normal users won’t be exposed to the possible side effects of using Federated tables. Users who require the Federated engine will be able to use it, by adding an option (–federated) to the mysqld command line or to the configuration file. Existing users of the Federated engine must be warned that using Federated can be risky, and it is not recommended for production.

We have a list of outstanding bugs affecting the Federated engine in our Bugs database.

Notice that the 5.0.x server is not affected by this decision. However, to allow security conscious users to disable Federated, we plan to introduce a similar configuration option in 5.0.66 and later releases.

We realise that the situation with Federated is undesirable. Therefore, we plan to replace Federated with a better designed, more robust engine, and we will welcome feedback about this task from the community and from our customers.

And as followers of MySQL Forge know (thanks Brian Aker for reminding me), there is already an initiative from the community, called FederatedX:

FederatedX Pluggable Storage Engine for MySQL is based off of the Federated Storage Engine, and is an attempt to moved the Federated Storage Engine forward to fix bugs, add new features and develop new concepts that are easier to achieve as a pluggable storage engine.

Thanks, Patrick Galbraith and Antony Curtis!

As for our general Federated plans: Please address your suggestions to community-contributions(at)mysql.com

Links:

• MySQL 5.0 manual entry on the “Federated” storage engine: http://dev.mysql.com/doc/refman/5.0/en/federated-storage-engine.html
• MySQL 5.1 manual entry on the “Federated” storage engine: http://dev.mysql.com/doc/refman/5.1/en/federated-storage-engine.html
• MySQL Forum dedicated to the Federated to the “Federated” storage engine: http://forums.mysql.com/list.php?105
• Community-based FederatedX storage engine on Forge: http://forge.mysql.com/projects/project.php?id=265
• FederatedX shortlog: http://hg.patg.net/federatedx-storage-engine/
• Bugs related to the “Federated” storage engine: http://bugs.mysql.com/saved/bugs_federated

This entry was posted on Monday, July 21st, 2008 at 12:24 and is filed under Architecture of Participation, MySQL, Release Policy. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.