Project

General

Profile

Actions

tickets #130661

open

Database error upon creating/editing pages

Added by crameleon 10 months ago. Updated 10 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
Wiki
Target version:
-
Start date:
2023-06-10
Due date:
% Done:

0%

Estimated time:

Description

Database error
Jump to: navigation, search

A database query error has occurred. This may indicate a bug in the software.
[69162b5b3e3989398b413c6d] 2023-06-10 18:48:36: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

Possibly a fallout from updating the Wiki?


Files


Related issues 1 (0 open1 closed)

Has duplicate openSUSE admin - tickets #130715: wiki: Database error while trying to edit a pageResolved2023-06-12

Actions
Actions #1

Updated by crameleon 10 months ago

  • Assignee set to crameleon
  • Private changed from Yes to No
Actions #2

Updated by crameleon 10 months ago

  • Status changed from In Progress to New
  • Assignee changed from crameleon to cboltz

Tried to run Update.php, but it fails with the following:

[dcb895483e182a0611854523] [no req]   Wikimedia\Rdbms\DBTransactionError: Explicit transaction still active. A caller may have caught an error. Open transactions:

Unsure if it requires all services using it to be stopped first.

Actions #4

Updated by cboltz 10 months ago

The debug log says:

[DBQuery] JobQueueDB::recycleAndDeleteStaleJobs [0.001s] 192.168.47.4:3307: SELECT IF(GET_LOCK('jobqueue-recycle-refreshLinksPrioritized',1),UNIX_TIMESTAMP(SYSDATE(6)),NULL) AS acquired
[DBQuery] Error 1235 from JobQueueDB::recycleAndDeleteStaleJobs, This version of MariaDB doesn't yet support 'GET_LOCK in cluster (WSREP_ON=ON)' (192.168.47.4:3307) SELECT IF(GET_LOCK('jobqueue-recycle-refreshLinksPrioritized',1),UNIX_TIMESTAMP(SYSDATE(6)),NULL) AS acquired 192.168.47.4:3307

I get the same error if I manually run this query:

MariaDB [wiki_en]> SELECT IF(GET_LOCK('jobqueue-recycle-refreshLinksPrioritized',1),UNIX_TIMESTAMP(SYSDATE(6)),NULL) AS acquired;
ERROR 1235 (42000): This version of MariaDB doesn't yet support 'GET_LOCK in cluster (WSREP_ON=ON)'

So far, riesling.i.o.o wasn't updated, but galera*.i.o.o was (2023-06-10 01:11, which is quite close to the last entry in Special:RecentChanges). Could this be a regression in Galera?

Actions #5

Updated by pjessen 10 months ago

  • Has duplicate tickets #130715: wiki: Database error while trying to edit a page added
Actions #6

Updated by crameleon 10 months ago

I didn't compare the version number, but it seems multiple software projects using MySQL are affected:
https://jira.mariadb.org/browse/MDEV-31325

Original change:
https://jira.mariadb.org/browse/MDEV-30473
https://github.com/MariaDB/server/commit/844ddb1109410e0ab1d4444549932f1dddb7b845

I think it requires a patch in MediaWiki?

Actions #7

Updated by pjessen 10 months ago

cboltz wrote:

The debug log says:
This version of MariaDB doesn't yet support 'GET_LOCK in cluster (WSREP_ON=ON)'

If I'm reading this right, MariaDB was recently upgraded to print an error (instead of just ignoring)
https://github.com/MariaDB/server/commit/696562ce5528faa60653aa31058bf42f26d71dc4

https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/
"Unsupported explicit locking include LOCK TABLES, FLUSH TABLES {explicit table list} WITH READ LOCK, (GET_LOCK(), RELEASE_LOCK(),…)."

crameleon wrote:

I think it requires a patch in MediaWiki?

I think so too.

Actions #8

Updated by pjessen 10 months ago

pjessen wrote:

crameleon wrote:

I think it requires a patch in MediaWiki?

I think so too.

That can't be too difficult, if those unsupported lock functions were simply ignored, we can change the SQL accordingly.
Is anyone already working on that?

Actions #9

Updated by cboltz 10 months ago

  • Status changed from New to In Progress

crameleon wrote:

I didn't compare the version number, but it seems multiple software projects using MySQL are affected:
https://jira.mariadb.org/browse/MDEV-31325

Thanks for the pointers, they were useful :-)

I think it requires a patch in MediaWiki?

I'm a big fan of "if you break it, you own both parts" (and also of "if you break it, you should also fix it") ;-)

Unfortuately that would mean that we have to wait for a galera fix, therefore I took the pragmatic route:

I hand-edited mediawiki_src/includes/libs/rdbms/database/DatabaseMysqlBase.php directly on the server. doLock() now does return microtime( true );, doUnlock does return true;. Both are copied from mediawiki_src/includes/libs/rdbms/database/Database.php (where a comment says "not implemented").

Note that this is only a hotfix - a quick test shows that it seems to work, but we don't have any locking now. That's not nice, but with the quite low number of edits, it's something I'm willing to risk.

The obvious TODOs are

  • report the issue to upstream MediaWiki
  • getting the upstream fix (as soon as it's available), and/or at least the hotfix into our packages
Actions #10

Updated by pjessen 10 months ago

cboltz wrote:

I'm a big fan of "if you break it, you own both parts" (and also of "if you break it, you should also fix it") ;-)

Unfortuately that would mean that we have to wait for a galera fix, therefore I took the pragmatic route:

I hand-edited mediawiki_src/includes/libs/rdbms/database/DatabaseMysqlBase.php directly on the server. doLock() now does return microtime( true );, doUnlock does return true;. Both are copied from mediawiki_src/includes/libs/rdbms/database/Database.php (where a comment says "not implemented").

Note that this is only a hotfix - a quick test shows that it seems to work, but we don't have any locking now. That's not nice, but with the quite low number of edits, it's something I'm willing to risk.

It seems to me that explicit locking didn't work beforehand, so very little added risk.
I created a patch, but if your solution does the trick ....

Actions #11

Updated by crameleon 10 months ago

  • Category changed from OBS to Wiki
Actions #12

Updated by crameleon 10 months ago

I'm a big fan of "if you break it, you own both parts" (and also of "if you break it, you should also fix it") ;-)

I hope that's not a reference to me installing updates. ;-)

Actions #13

Updated by cboltz 10 months ago

I refuse to comment on this.

*g,d&r*

Actions #14

Updated by pjessen 10 months ago

cboltz wrote:

*g,d&r*

There is no need to be rude, especially not in Klingon 🙂

Actions

Also available in: Atom PDF