MariaDB 5.5.21 Release Notes

The most recent release in the MariaDB 5.5 series is:MariaDB 5.5.68 Download Now

Download | Release Notes | Changelog | Overview of 5.5

Release date: 16 Mar 2012

MariaDB 5.5.21 is a Beta release. In general this means that there are no known serious bugs, except for those marked as feature requests. This is the second release of the MariaDB 5.5 series and includes features left out of the 5.5.20-alpha release, and various bug fixes.

For a description of MariaDB 5.5 see theWhat is MariaDB 5.5 page.

For a list of changes made in -beta, with links to detailed information on each push, see the .

In most respects will work exactly as MySQL: all commands, interfaces, libraries and APIs that exist in MySQL also exist in MariaDB.

Note: There are no RPM packages of available at this time.

Includes MySQL 5.5.21

This version of MariaDB includes MySQL 5.5.21. See for what changed between this and previous MySQL versions.

Security fix

• A fix is included for a COM_BINLOG_DUMP crash on invalid data. See for details.

Threadpool

is the first release to feature the new . This is comparable in functionality to the closed-source feature in MySQL Enterprise.

Preliminary benchmarks of the new threadpool code are available .

For our Windows users, pool-of-threads is now the default scheduler on Windows Vista (and higher). It is not the default on Linux/Unix yet as we don't feel we have had enough time to thoroughly test various corner cases.

Updated SphinxSE

has been updated to version 2.0.4 (the latest upstream version) in .

LIMIT ROWS EXAMINED

In 5.5.21 there is a new LIMIT ROWS EXAMINED optimization which provides the means to terminate the execution of statements which examine too many rows, and thus use too many resources. This is achieved through an extension of the clause —LIMIT ROWS EXAMINED <number_of_rows>. Whenever possible the semantics of LIMIT ROWS EXAMINED is the same as that of normal LIMIT (for instance for aggregate functions).

More information is available on the page.

INSTALL SONAME

includes a new INSTALL SONAME statement. This statement is a variant of . It installs all plugins from a given plugin_library.

See the page for details.

Extended Keys support for XtraDB and InnoDB

In 5.5.21 there is a new "extended keys" optimization which, when enabled, makes use of existing components of InnoDB/XtraDB keys to generate more efficient execution plans. Using these components in many cases allows the server to generate execution plans which employ index-only look-ups.

See the page for more information.

Non-blocking Client Library

MariaDB, starting with version 5.5.21 supports . This allows an application to start a query or other operation against the database, and then continue to do other work (in the same thread) while the request is sent over the network, the query is processed in the server, and the result travels back. As parts of the result become ready, the application can — at its leisure — call back into the library to continue processing, repeating this until the operation is completed.

Non-blocking operation is implemented entirely within the client library. This means no special server support is necessary and non-blocking operation works with any version of the MariaDB or MySQL server, the same as the normal blocking API. It also means that it is not possible to have two queries running at the same time on the same connection (this is a protocol limitation). But a single thread can have any number of non-blocking queries running at the same time, each using its own MYSQL connection object.

See for details.

mysql_real_connect() Changes

In MySQL, and in MariaDB versions before 5.5.21, mysql_real_connect() removes from the MYSQL object any options set with mysql_option() when it fails. Beginning with , options are preserved by a failingmysql_real_connect(); use mysql_close(), as normal, to clear them.

This only has effect if the MYSQL object is reused after amysql_real_connect() failure (which is unusual). No real-life incompatibilities are expected from this change (it is unlikely that an application would rely on options being automatically removed between connection attempts).

Selectively skipping replication of binlog events

Normally, all changes that are logged as events in the binlog are also replicated to all slaves (though still subject to filtering by--replicate-do-xxx, --replicate-ignore-xxx, and similar options). However, sometimes it may be desirable to have certain events be logged into the binlog, but not be replicated to all or a subset of slaves, where the distinction between events that should be replicated or not is under the control of the application making the changes.

This could be useful if an application does some replication external to the server outside of the built-in replication, or if it has some data that should not be replicated for whatever reason.

This is possible with two new system variables introduced in : @@skip_replication and --replicate-events-marked-for-skip.

See for details.

_{This page is licensed: CC BY-SA / Gnu FDL}