Comments on: Introducing percona-patches for 5.1

By: Joshua

Joshua — Fri, 21 May 2010 00:00:23 +0000

Thank you very much sir!

Greatly appreciated, as with all of percona’s efforts.

Joshua

By: Vadim

Vadim — Tue, 18 May 2010 14:17:54 +0000

Joshua,

Please try 10.1, it is fixed there.
http://www.percona.com/downloads/Percona-Server-5.1/Percona-Server-5.1.45-10.1/

By: Joshua

Joshua — Tue, 18 May 2010 08:09:54 +0000

I currently have a server on Ubuntu Hardy with the following installed:

ii libmysqlclient15off 5.0.90-percona-b21.hardy.3 MySQL database client library
ii libpercona-xtradb-client-dev 5.1.45-xtradb-1.0.6-10-80.hardy.24 Percona SQL database development files
ii libpercona-xtradb-client16 5.1.45-xtradb-1.0.6-10-80.hardy.24 Percona SQL database client library
ii percona-xtradb-client-5.1 5.1.45-xtradb-1.0.6-10-80.hardy.24 Percona SQL database client binaries
ii percona-xtradb-common 5.1.45-xtradb-1.0.6-10-80.hardy.25 Percona SQL database common files (e.g. /etc
ii percona-xtradb-server 5.1.45-xtradb-1.0.6-10-80.hardy.25 Percona SQL database server (metapackage dep
ii percona-xtradb-server-5.1 5.1.45-xtradb-1.0.6-10-80.hardy.24 Percona SQL database server binaries

Is the userstat patch included?

mysql> set global userstat_running = ‘ON’;
ERROR 1193 (HY000): Unknown system variable ‘userstat_running’

I am hoping you can tell me what I must do to enable it.

Thank you all for your work and results!

Joshua

By: Gregory Youngblood

Gregory Youngblood — Wed, 24 Feb 2010 00:19:16 +0000

It appears there’s a problem with the patch when applied to 5.1.43 and compiled under Solaris 10.

Initially I was trying to get it to compile using Sun Studio but that didn’t go too well, so I switched to gcc. I am getting closer, but still do not have a build under Solaris 10 that works.

What I’m finding is that os_atomic_increment is not defined when HAVE_IB_SOLARIS_ATOMICS is set. It appears to be more likely an oversight in os0sync.h starting around line 315. It is defined in the previous block using the GCC builtins, but not Solaris and Windows.

If I were to hazard a guess, I’d think the generic os_atomic_increment was not supposed to be used in the main code, just os_atomic_increment_lint or os_atomic_increment_ulint, which are defined in the Solaris and Windows blocks.

By: Morgan Tocker

Morgan Tocker — Tue, 16 Feb 2010 07:10:32 +0000

Kay – it is an apples-to-apples comparison. As Vadim writes, the motivation for backporting some of these patches from XtraDB to built-in InnoDB is for customers who have policies against using an RC in production.

Having said that, it would be good to get a comparison to XtraDB and the plugin on a few different workloads.

By: Michel

Michel — Mon, 15 Feb 2010 19:53:32 +0000

Vadim,

“We will prepare document which explains it to avoid more confusions”

Do you have this document already? I still a bit cofused.

By: Vadim

Vadim — Mon, 15 Feb 2010 00:15:33 +0000

Kay,

Yes, I compare to build-in InnoDB.
If we spoke about InnoDB-plugin, then to compare apple to apple we need to compare
InnoDB-plugin vs Percona-XtraDB.
And some results you can see there
http://www.mysqlperformanceblog.com/2010/01/13/innodb-innodb-plugin-vs-xtradb-on-fast-storage/

By: Kay Roepke

Kay Roepke — Sun, 14 Feb 2010 23:16:36 +0000

I take it that your comparison with 5.1.43 is using the built-in InnoDB, right?
How about comparing apples to apples and at least including the bundled plugin version from 5.1.43, as well? (Which is InnoDB Plugin 1.0.6 iirc).

By: Olivier B.

Olivier B. — Fri, 12 Feb 2010 12:28:54 +0000

Great news ! And Debian backports have just upgrade to 5.1.43 too, so I will try to compile a Debian-Lenny version. Thanks for your job !

By: peter

peter — Fri, 12 Feb 2010 03:09:42 +0000

Shlomi,

From the data storage standpoint XtraDB is same as Innodb and you can go back and forth freely with Innodb plugin. There are some features in XtraDB which can break binary compatibility you however need to explicitly enable them.