Hi, for our production system I’m using a MariaDB Galera cluster as RDMS backend. Though there is a feature to enable (experimental) replication of MyISAM tables, this doesn't play well with Cargo. Certain operations involving _pageData tables caused the cluster to reach an inconsistent data state, thus stopping replication and ultimately falling apart.
I could isolate the cause to the following transaction (which is embedded between two inserts for the same thing): BEGIN /* Wikimedia\Rdbms\Database::begin */ SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE 'cargo\_\_staff\_\_NEXT' SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE 'cargo\_\_staff\_\_\_files' DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo__staff` WHERE `_pageID` = '273' DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo___pageData` WHERE `_pageID` = '273' COMMIT /* Wikimedia\Rdbms\Database::commit */ cargo__staff table being InnoDB, cargo___pageData being MyISAM. Unfortunately this leads to the delete statement on the InnoDB table not being replicated, while the delete on the MyISAM table is. Thus on the following insert the row already exists, causing a unique key violation and inconsistent cluster state. Is it really still necessary to use MyISAM for these tables? Full text indices are available on InnoDB for quite some time now, so I’m wondering whether this still needs to be supported or if it would be possible to make both choices available. Best: Jan. -- idea-sketch Jan Böhme & Uwe Schützenmeister Lößnitzstr. 14 01097 Dresden www.idea-sketch.com <http://www.idea-sketch.com/> Tel.: +49 . (0)351 . 810 74 250 Mobil: +49 . (0)179 .53 41 641
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
