Page MenuHomePhabricator

Introduce maintenance script to switch searchindex table between InnoDB and myISAM
Open, Needs TriagePublic

Description

Wikimedia and MediaWiki are stuck on myISAM for the searchindex table because InnoDB doesn't support virtual tables for fulltext indexes

However users of MediaWiki would generally be better off with InnoDB.
We should introduce a maintenance script for 3rd party users to allow people to switch this table between MyISAM and InnoDB.
Potentially, we can also call this script from the installer/updater and switch people over from the MyISAM default if they want to.

Event Timeline

TheDJ renamed this task from Introduce maintenance script to switch search index between innodb and myISAM to Introduce maintenance script to switch searchindex table between InnoDB and myISAM.Oct 31 2024, 12:38 PM
TheDJ updated the task description. (Show Details)
TheDJ removed a project: Patch-Needs-Improvement.

Change #1086573 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/core@master] [WIP] Add script to reconfigure schema settings of searchindex table

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

The WIP script I have now:

  • I still need to check if I have to rebuild the index after an switch
  • also allows to switch collation, another task that a few people have indicated as desired in the support fora.
  • Some of this code might move into DatabaseMySQL
  • I want to make it possible to call this step from the installer, so that 3rd party users can choose innoDB, even though we are stuck with MyISAM
  • I might also want to hook the sqlite searchindex to switch between with and without FTS support, so that people do not have to run the entire updater for that and possible I can find a few more tasks

@Ladsgroup You indicated that it might be a good idea to move this further up the tree and I can see why that would be a good idea. But i'm not very familiar in this area, so a question about where to put some of this code.

This script now uses 3 queries:

  1. get schema info about a specific column. The output of this is mysql (database type) specific
  2. and 3 alter table schema options. The input for both of these is mysql specific

So I see several options to place the code

  1. Put implementation as statics in DatabaseMySQL, but keep them out of IDatabase
  2. Put implementations in DatabaseMySQL and abstract similar to indexInfo at IDatabase with php base types, and document that input and output is engine specific
  3. Put in a separate class ?

Thoughts ?

I'm in favor of option 2. With caveat that it probably should be in IMaintainableDatabase instead something like "columnInfo" and can be an associative array of "something" => "value"?