Codership team announced availability of MySQL/Galera 0.8.1, which is minor release, but actually it has bunch of improvements that makes Galera replication more user friendly (there are many bugs fixed, reported by me personally, what annoyed me a lot).

As part of my evaluation activity I ported MySQL/Galera 0.8.1 to Percona Server/Galera 0.8.1 and you can get source code on Launchpad.

I appreciate the fact that not everybody has fun from compiling source code (hint, hint for Drizzle developers), that is why I also made binaries for RHEL 6.1 / Oracle Linux 6.1
…

As you may know I closely follow Galera replication development, and right now I am evaluating how it performs in our benchmarks. Of course my closest interest is Percona Server, so I made port of Galera from MySQL/InnoDB-plugin to Percona Server 5.1.57. Right now it is only in source code https://code.launchpad.net/~vadim-tk/percona-server/percona-galera-5.1.57, but it brings couple good things:

• It is based on Percona Server with XtraDB, with all its performance and diagnostic improvements
• It contains scripts for xtrabackup node propagation, which provides minimal impact on the cluster when new node joins

You are welcome to try it, however it is not recommended to use in production, as …

As you may know, Kristian Nielsen made a fix for the Group Commit Problem which we many times wrote about. The fix came into MariaDB 5.3 and Mark Callaghan tested it recently . We ported this patch to Percona Server (it is not in the main branch yet), and here are the results of my testing of the new Group Commit in Percona Server 5.1.

As background information, the problem appears when you have strict durability and recover-ability requirements, that is innodb_flush_log_at_trx_commit=1, sync_binlog=1 and you do not have storage that provides fast syncs (i.e. you do not have a battery-backed cache on your RAID card). This scenario may also appear when being on battery and your RAID card dies, automatically switching from write-back to write-through cache mode.

We …

Percona is glad to announce the release of Percona Server 5.5.12-20.3 on June 9, 2011 (Downloads are available here and from the Percona Software Repositories).

Based on MySQL 5.5.12, Percona Server 5.5.12-20.3 is now the current stable release in the 5.5 series.

Other Changes

• The list of authors of the plugins used have been corrected. Bug Fixes:#723050 (Y. Kinoshita)

For more information, please see the following links:

• Downloads: Binary distribution,  …

Released on June 8, 2011 (Downloads are available here and from the Percona Software Repositories.

Percona Server 5.1.57-12.8 is now the current stable release in the 5.1 series. It is is based on MySQL 5.1.57.

Bug Fixes

• Fixed InnoDB I/O code so that the interrupted system calls are restarted if they are interrupted by a signal. InnoDB I/O code was not fully conforming to the standard on POSIX systems, causing a crash with an assertion failure when receiving a signal on pwrite(). Bug Fixed: LaunchPad: #764395 / MySQL bug #60788 (A. …

MySQL 5.5 and Percona Server 5.5 do not solve all scalability problems even for read only workloads. Workloads which got a lot of attention such as Sysbench and DBT2/TPC-C scale pretty well a they got a lot of attention, there can be other quite typical workloads however which do not scale that well. This is why it is important to test performance and scalability for your application on your hardware if you really want results most relevant for your situation.

In this example I spotted the query pattern responsible for large portion of the load in the application by aggregating query log with mk-query-digest. When I filtered out only queries of this pattern and got a simplified part of production workload which focuses only on one query but yet mimics real world values distribution.

The query looks something like this:

SELECT *  FROM table WHERE deleted = 0 AND group_id IN (62715996, 62716592, 62717660, …

Percona is pleased to welcome Stewart Smith to the team. Stewart does not need an extended introduction for MySQL Community, but just in case: Stewart has a long history with both the MySQL and Drizzle code bases. He’s been one of the core Drizzle developers since the start of the project (working on Drizzle for Sun and then Rackspace), he maintains HailDB and previously worked for MySQL (and then Sun) on MySQL Cluster (NDB).

Stewart joins Percona to lead our development team and will take lead role in both Percona Server and Percona XtraBackup products. You can certainly expect more mutual exchange of features and ideas between Drizzle, …

Part of the InnoDB duties, being an MVCC-implementing storage engine, is to get rid of–purge–the old versions of the records as they become obsolete.  In MySQL 5.1 this is done by the master InnoDB thread.  Since then, InnoDB has been moving towards the parallelized purge: in MySQL 5.5 there is an option to have a single separate dedicated purge thread and in MySQL 5.6.2 one can have multiple dedicated purge threads.

Percona Server 5.1 supports multiple purge threads too, although using more than one is considered experimental at the moment. Unfortunately this patch hasn’t been ported to Percona Server 5.5 yet.

Let’s test these two implementations and find out what benefits, if any, do the additional purge threads bring.

The test workload makes a long history list and then lets purge thread(s) work through it while having a regular OLTP load on the server.  The OLTP part of this is provided by …

We see demand on MacOS binaries and decided to prepare binaries you can download and use. The are marked as “experimental”, as we do not have big history of using MacOS in production, so we are looking for your feedback and bug reports.

Binaries:

• Percona Server 5.5 : http://www.percona.com/downloads/TESTING/Percona-Server-55/Percona-Server-5.5.11-20.2/release-5.5.11-20.2/114/MacOSX/
• Percona Server 5.1: http://www.percona.com/downloads/TESTING/Percona-Server-51/Percona-Server-5.1.56-12.7/release-5.1.56-12.7/226/MacOSX/
• Percona XtraBackup: …

We just pushed to sysbench support for workload against multiple tables ( traditionally it used only single table).

It is available from launchpad source tree lp:sysbench .

This is set of LUA scripts for sysbench 0.5 ( it supports scripting), and it works following way:

- you should use --test=tests/db/oltp.lua to run OLTP test
i.e. prepare

./sysbench --test=tests/db/oltp.lua --oltp-tables-count=25 prepare

run:

./sysbench --test=tests/db/oltp.lua --oltp-tables-count=25 --num-threads=5 run

oltp.lua should understand most options that available for regular sysbench –test=oltp

there are couple other scripts, like
oltp_simple
select
insert
delete
update_index
update_non_index

to support different OLTP …