tickets #130661
openDatabase error upon creating/editing pages
Added by crameleon 11 months ago. Updated 11 months ago.
0%
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
| mediawiki-1.36.7-galeralock.patch (1.68 KB) mediawiki-1.36.7-galeralock.patch | pjessen, 2023-06-12 16:13 |
Updated by crameleon 11 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.
Updated by cboltz 11 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?
Updated by pjessen 11 months ago
- Has duplicate tickets #130715: wiki: Database error while trying to edit a page added
Updated by crameleon 11 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?
Updated by pjessen 11 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.
Updated by cboltz 11 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
Updated by pjessen 11 months ago
- File mediawiki-1.36.7-galeralock.patch mediawiki-1.36.7-galeralock.patch added
- Category changed from Wiki to OBS
- Assignee deleted (
cboltz)
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.phpdirectly on the server.doLock()now doesreturn microtime( true );,doUnlockdoesreturn true;. Both are copied frommediawiki_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 ....