Page MenuHomePhabricator

Percona XtraDB Cluster gives error when using GET_LOCK() when pxc_strict_mode=ENFORCING is set (e.g. By ApiStashEdit.php)
Open, Needs TriagePublic

Description

We have a report of trouble using Percona XtraDB Cluster with MediaWiki. I know almost nothing about this DB, but it is freely available and advertises itself as a "server for MySQL" so it should be tested as a DB server for MediaWiki.

SELECT GET_LOCK('695f25141b5213ec078ceed7dbde8264bc651753', 30) AS lockstatus Function: ApiStashEdit::checkCache Error: 1105 Percona-XtraDB-Cluster prohibits use of GET_LOCK with pxc_strict_mode = ENFORCING (10.0.2.80)

Percona cluster runs using pxc_strict_mode=ENFORCING, and one of its limitations is explicit table locking, which seems to be what installation is trying to use here.

https://www.percona.com/doc/percona-xtradb-cluster/LATEST/features/pxc-strict-mode.html

Event Timeline

Bawolff renamed this task from Ensure MediaWiki works with Percona XtraDB Cluster to Percona XtraDB Cluster fails to install as GET_LOCK() when pxc_strict_mode=ENFORCING is set.Jul 26 2018, 10:10 PM
Bawolff updated the task description. (Show Details)
Bawolff renamed this task from Percona XtraDB Cluster fails to install as GET_LOCK() when pxc_strict_mode=ENFORCING is set to Percona XtraDB Cluster gives error when using GET_LOCK() when pxc_strict_mode=ENFORCING is set (e.g. By ApiStashEdit.php).Jul 26 2018, 10:18 PM

From a glance, it looks like xtradb cluster is build on Galera (which is something itself to consider in the future). Use of GET_LOCK is tricky there since it would have to use wsrep or have such queries directed to dedicated master (perhaps with some HA in front that doesn't split brain).

Something like https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/332950/ could probably be built off of to use for workarounds.

I was about to file another bug but rememberd this one, instead.

I've begun to put together some basic support for Percona, but I really need to get this code reviewed and I think (since I first learned of Percona on the support desk) that this support would help others.

From this description of Percona:

Percona Server for MySQL® is a free, fully compatible, enhanced and open source drop-in replacement for any MySQL database. It provides superior performance, scalability and instrumentation.

One of the primary benefits of using Percona is the clustering. However, this typically involves a "strict mode".

PXC Strict Mode is designed to avoid the use of experimental and unsupported features in Percona XtraDB Cluster. It performs a number of validations at startup and during runtime.

Strict modes available include:

ENFORCING: If a validation fails during startup, halt the server and throw an error. If a validation fails during runtime, deny the operation and throw an error.

And the documentation continues:

It is recommended to keep PXC Strict Mode set to ENFORCING, because in this case whenever Percona XtraDB Cluster encounters an experimental feature or an unsupported operation, the server will deny it.

Something like https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/332950/ could probably be built off of to use for workarounds.

I'll look at this. Thank you.

Change 477942 had a related patch set uploaded (by MarkAHershberger; owner: MarkAHershberger):
[mediawiki/core@master] Add initial Percona code

https://gerrit.wikimedia.org/r/477942

Change 477942 abandoned by markahershberger:
Add initial Percona code

Reason:
Doing as an extension

https://gerrit.wikimedia.org/r/477942

Krinkle moved this task from Untriaged to Rdbms library on the MediaWiki-libs-Rdbms board.
Krinkle subscribed.

I don't think we should support and test everything that aims to be compatible with MySQL. If they are true to their word, they would work regardless. And if not, it's first and foremost an upstream problem. But certainly something to consider on a case-by-case basis to see what kind of workarounds we could tolerate in the codebase, and balance it with the added maintenance cost from its complexity.

It looks like in this case, there isn't a patch to add a Percona-specific workaround to MediaWiki's MySQL support layer, rather the patch provides an entirely new top-level backend type what extends MysqlBase. That is indeed out of scope for core I think (or rather, bundling it would be a separate conversation), and seems already handled by Mark in an extension. So closing this issue for now.

Feel free to re-open if I misunderstood.

As the task stood, you did not misunderstand. However, since creating it, I've been working on doing the DB support as a pure extension which I hope to move to Gerrit soon. That is where this task should be targeted.