The Ultimate Guide to High Availability with MariaDB

MariaDB 5.2 replication feature preview

You are viewing an old version of this article. View the current version here.

This page describes a feature preview release which gives users a convenient way to test out some of the new replication-related features that will be included in the upcoming MariaDB 5.3. There has been quite a lot of interest in these features, and providing this feature preview release allows the developers to get more and earlier feedback, as well as allowing more users an early opportunity to evaluate the new features.

The feature preview release is based on stable release MariaDB 5.2, adding a number of fairly isolated features that are considered complete and fairly well-tested. It is however not a stable or GA release, nor is it planned to be so. The stable release including these features will be MariaDB 5.3. That being said, we greatly welcome any feedback / bug reports, and will strive to fix any issues found and update the feature preview until MariaDB 5.3 stable is ready.

Download/Installation

These packages are generated the same way as "official" MariaDB releases. Please see the main download pages for more detailed instructions on installation etc.

Debian/Ubuntu

For Debian and Ubuntu, it is highly recommended to install from the repositories, using apt-get, aptitude, or other favorite package manager.

First import the public key with which the repositories are signed, so that apt can verify the integrity of the packages it downloads. For example like this:

    wget -O- http://knielsen-hq.org/maria/PublicKey | sudo apt-key add -

Now add the appropriate repository. An easy way is to create a file mariadb-5.2-rpl.list in /etc/apt/sources.list.d/ with contents like this for Debian:

    deb http://knielsen-hq.org/maria/mariadb-5.2-rpl/debian squeeze main
    deb-src http://knielsen-hq.org/maria/mariadb-5.2-rpl/debian squeeze main

Or this for Ubuntu:

    deb http://knielsen-hq.org/maria/mariadb-5.2-rpl/ubuntu maverick main
    deb-src http://knielsen-hq.org/maria/mariadb-5.2-rpl/ubuntu maverick main

Replace "squeeze" respectively "maverick" with the distro version being used. Supported are "lenny" and "squeeze" (for Debian), and "hardy", "jaunty", "karmic", "lucid", and "maverick" (for Ubuntu).

Now run

    sudo apt-get update

The packages can now be installed with the package manager of choice, for example

    sudo apt-get install mariadb-server-5.2

(To manually download and install packages, browse the directories below http://knielsen-hq.org/maria/mariadb-5.2-rpl/ - the .debs are in debian/pool/ and ubuntu/pool/.)

Generic Linux binary tarball

Generic linux binary tarballs can be downloaded here:

Centos 5 RPMs

Windows (32-bit)

Source tarball

Features

Here follows an overview of the new features:

Group commit for the binary log

This preview release implements group commit that works when using XtraDB with the binary log enabled. (In previous MariaDB releases, and all MySQL releases at the time of writing, group commit works in InnoDB/XtraDB when the binary log is disabled, but stops working when the binary log is enabled).

Documentation.

Enhancements for START TRANSACTION WITH CONSISTENT SNAPSHOT

START TRANSACTION WITH CONSISTENT SNAPSHOT now also works with the binary log. This means that it is possible to obtain the binlog position corresponding to a transactional snapshot of the database without any blocking of other queries at all. This is used by mysqldump --single-transaction --master-data to do a fully non-blocking backup that can be used to provision a new slave.

START TRANSACTION WITH CONSISTENT SNAPSHOT now also works consistently between transactions involving more than one storage engine (currently XTraDB and PBXT support this).

Documentation.

Annotation of row-based replication events with the original SQL statement

When using row-based replication, the binary log does not contain SQL statements, only discrete single-row insert/update/delete events. This can make it harder to read mysqlbinlog output and understand where in an application a given event may have originated, complicating analysis and debugging.

This feature adds an option to include the original SQL statement as a comment in the binary log (and shown in mysqlbinlog output) for row-based replication events.

Documentation.

Row-based replication for tables with no primary key

This feature can improve the performance of row-based replication on tables that do not have a primary key (or other unique key), but that do have another index that can help locate rows to update or delete. With this feature, index cardinality information from ANALYZE TABLE is considered when selecting the index to use (before this feature is implemented, the first index was selected unconditionally).

Documentation.

Early release during prepare phase of XtraDB row locks

This feature adds an option to make XtraDB release the row locks for a transaction earlier during the COMMIT step when running with --sync-binlog=1 and --innodb-flush-log-at-trx-commit=1. This can improve throughput if the workload has a bottleneck on hot-spot rows.

Documentation.

PBXT consistent commit ordering

This feature implements the new commit ordering storage engine API in PBXT. With this feature, it is possible to use START TRANSACTION WITH CONSISTENT SNAPSHOT and get consistency among transactions that involve both XtraDB and InnoDB. (Without this feature, there is no such consistency guarantee. For example, even after running START TRANSACTION WITH CONSISTENT SNAPSHOT it was still possible for the InnoDB/XtraDB part of some transaction T to be visible and the PBXT part of the same transaction T to not be visible.)

Miscellaneous

  • Small change to make mysqlbinlog omit redundant use statements around BEGIN/SAVEPOINT/COMMIT/ROLLBACK events when reading MySQL 5.0 binlogs.

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.