Amahi Forums

This particular MediaWiki (MW) Problem resulted from a server issue (accessing HDA dashboard) I had. Just in case that background is important, here is the link to that issue which was resolved (insofar as the server problem was resolved). For one thing, it's good to know that the server issue, even when resolved, may be having this MW database side effect. The solution to the MW database problem, however, may involve steps related to the MW software itself, rather than the server issue that created it, and so I'm posting here:

viewtopic.php?f=16&t=5083

----

Here's what works fine:

1) I can pull the MW up either via the HDA dashboard or by directly entering it's address.
2) The couple dozen articles I've put into it, the latest one last night, are still accessible, and render math perfectly.

The problem:
3) There is something wrong with the search function, which I've used without issue all the time, over the last couple months. IF I type a search item like "ring homomorphism", and the MW 'recognizes' what I'm up to, then it will fill in the rest of the words for me (like all MWs do). IF I then click on that convenient fill-in, the MW will then take me right to the article, no problem. However, if I hit enter (thereby ignoring the fill-in) because I want to see all articles in the MW database with the term "ring homomorphism" (a function that literally worked up until the time I had my server issue), then I receive the following error:

Database error
A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
(SQL query hidden)
from within function "SearchMySQL::searchInternal". Database returned error "145: Table './mediawiki/searchindex' is marked as crashed and should be repaired (localhost)".


I rather repair this issue somehow rather than reinstall the entire MW for two important reasons
1) I'd lose the articles, unless I took steps to somehow grab them all and save them somewhere first
2) I'd rather not go thru the process of adding the math-rendering (installing MathJax and XyJax) steps again.

Hopefully, someone has an idea about a rapid fix here. I have to believe that this is also just something that needs to be tweaked following the server issue I had earlier today. Again, this MW was working almost up to the time I decided to reboot my server (I had been working on adding a USB hard drive yesterday and wanted to see what would happen if I rebooted the entire server...)

All my other apps appear to be working fine.

Thanks again !

Please see my reply to your other post. Please do not double post about the same issue in more than one topic area. Once is enough to get a response.

BTW, if you want to save yourself a lot of trouble, consider using an online wiki. I use this one and it works great.
http://www.shoutwiki.com/wiki/Main_Page

They are very responsive to issues as well.

OK. Apologies. When I saw that other post was closed, I got to thinking that the current forum might be a better place for this topic, and I discussed my reasoning above. Just trying to be helpful regarding categories.

Understand. Always best to post in the appropriate area. You could edit the other post and provide just a link to the new one. That at least directs others and does not cause confusion.

Edited as suggested.

I found this proposed solution. I haven't tried it yet, but posting here for later reference. Would be interested if anyone had any thoughts on this approach (particularly as I'm not particularly expert at all this). For one thing, don't know how to "log into the database server". However, the description appears to address the issue, and is fairly step-by-step. Looks promising.

http://www.formatccolon.com/blog/?p=38

Copying it all here in case the link disappears (the article is from 2013):

Media Wiki Search Error
If you ever move an database driven application, you always can run the risk of something getting corrupted along the way. MediaWiki is no exception. Moving this wiki to a hosted solution yielded an error that resulted in the following message appearing any time that I tried to run a standard search for content in my wiki:

''A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden)
from within function "SearchMySQL::searchInternal". Database returned error "144: Table './xxxwiki/searchindex' is marked as crashed and last (automatic?) repair failed (localhost)".'''
As luck would have it, the fix for this is a fairly simple one. First you need to log into the database server hosting the database for the MediaWiki application. Select or “use” the database and remove the corrupted searchindex table, and create a fresh one to take it’s place. This can be done by using the following sql statement:

DROP TABLE `searchindex`;
CREATE TABLE `searchindex` (
`si_page` INT(10) UNSIGNED NOT NULL,
`si_title` VARCHAR(255) NOT NULL DEFAULT '',
`si_text` mediumtext NOT NULL,
UNIQUE KEY `si_page` (`si_page`),
FULLTEXT KEY `si_title` (`si_title`),
FULLTEXT KEY `si_text` (`si_text`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
Once the fresh database table has been created, the search index will need to be refreshed. Again as luck would have it, those fine developers over at MediaWiki have included a script in the installation that does exactly that.

SSH over to your MediaWiki server and cd into the maintenance folder under the wiki install folder. For example on a linux host, it may be somewhere like:
“cd /var/www/html/mysite/mediawiki-1.19.1/maintenance”

Once in the directory, reindex the site using either the rebuildtextindex.php or the rebuildall.php script.

php rebuildtextindex.php
In the event that you are also are using a hosted solution, PHP may have the register_argc_argv variable set to off. In which case, the reindex will fail with an error message that says:

Content-type: text/html

Cannot get command line arguments, register_argc_argv is set to false
If that is the case, you can create a custom php.ini file, which sets the register_argc_argv=”On” directive and run the script specifying that custom php.ini file. In my case, my hosting provider allows me to have a custom php.ini file in my account that I can modify. I don’t however have the ability to restart apache, which is usually required when making changes to the php.ini file, but php does give you the ability to specify the custom php.ini file on execution, and will honor the values set in that file. So in order to run the index rebuild script, we now run the following command:


php -c ../../../php.ini rebuildtextindex.php
Content-type: text/html

Dropping index...
Rebuilding index fields for 697 pages...
500

Rebuild the index...
Done.
Once complete, you should have a functional search in your mediawiki again

++++

And a MW.org discussion about database access:

http://www.mediawiki.org/wiki/Manual:Da ... into_MySQL

Thanks for the update.

OK. I have taken the first couple steps in the repair process. Would greatly appreciate it if anyone could let me know if there are any issues for the HDA in what I'm doing. The process has been described as "fairly simple one", but I'm a newbie.

I am following the steps in the two article posted above (one from a blog article; the other from mediawiki.org), I have logged in the MediaWiki database server. Login info for this server are located in the mediawiki's localsettings file.

This file is located here: /var/hda/web-apps/mediawiki/html

To log into the MediaWiki's database server, enter the following via terminal, filling in all the <....> variables as appropriate:

mysql -u <$wgDBuser> -p --database=<$wgDBname>
Enter password: <$wgDBpassword>

To obtain the appropriate values of the above login variables (i.e., all the stuff inside the "<.....>" brackets), see the localsettings file. The relevant section in that file will look like this:

## Database settings
$wgDBtype = "mysql";
$wgDBserver = "localhost";
$wgDBname = "mediawiki";
$wgDBuser = "mediawiki";
$wgDBpassword = "mediawiki";

If the login to the database server is successful, I believe you should see this:

Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 473
Server version: 5.5.31-MariaDB MariaDB Server

Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [mediawiki]>


++++++++
Next step:

According to the blog, the next step is to run the following:
DROP TABLE `searchindex`;
CREATE TABLE `searchindex` (
`si_page` INT(10) UNSIGNED NOT NULL,
`si_title` VARCHAR(255) NOT NULL DEFAULT '',
`si_text` mediumtext NOT NULL,
UNIQUE KEY `si_page` (`si_page`),
FULLTEXT KEY `si_title` (`si_title`),
FULLTEXT KEY `si_text` (`si_text`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

HERE ARE MY QUESTIONS:

1) Is this o.k. to do ? Any issues for breaking HDA or Amahi ?

2) If yes to 1), then how do I enter the above SQL code ? Is it done one line at a time ? Or is it entered all together in one shot? If so, how does one enter it all in one shot ?

Many thanks !

I would do the following:

1. Create a file and paste the text in it:

DROP TABLE `searchindex`;
CREATE TABLE `searchindex` (
`si_page` INT(10) UNSIGNED NOT NULL,
`si_title` VARCHAR(255) NOT NULL DEFAULT '',
`si_text` mediumtext NOT NULL,
UNIQUE KEY `si_page` (`si_page`),
FULLTEXT KEY `si_title` (`si_title`),
FULLTEXT KEY `si_text` (`si_text`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

2. Save the file and then execute it as follows: That should do it.

OK. Thank you very much.

I didn't get chance to post -- had to run out -- but I discovered moments after posting (which itself was a moments after logging in the the MW database) that the search function began to work again. Definitely was not working minutes earlier, but after logging into it, posting the message here, I took a few moments to check the MW and was surprised to find the search functions working again. No problems I could see.

Could it be that yesterday's issue with the HDA Dashboard (following server shutdown and restart) interfered with a restart of my MW's database server, and today's act of simply logging into it, just switched it back on again ?

I didn't do anything else.

Presumably, under normal server shutdown circumstances (unlike yesterday's scenario), the database server would automatically turn itself back on again ?

Should I run the script you ask me to anyway, or leave well-enough alone, and run only when/if I see problems ?

Regards

Interesting that it came back to life. Could have been related to the other issue, but hard to say.

If it ain't broke, don't fix it. That's my take on things. I am gonna mark this one as resolved.