Maintenance problems

List overview All Threads
Download

newer

older

Re: [Mediawiki-l] always being...

Programmatically getting the...

Plamen Gradinarov

28 Nov 2004 28 Nov '04

4:46 p.m.

Hello, However I try to start any file from the maintenance, say, refreshLinks or rebuildSearchIndex, the result is invariably one and the same: "Sorry! The wiki is experiencing some technical difficulties, and cannot contact the database server." Even the proposed workaround for rebuilding the links is not working. First it returns ERROR 2006: MySQL server has gone away No connection. Trying to reconnect... Connection id: xxxxxx Current DB: XXXX_XX After about two minutes we have @foo:=COUNT(*) 397167 1 row in set (2 min 11.91 sec) After issuing the second command, the server returns: Query OK, 0 row affected (0.00 sec) Rows matched: 1 Changed: 0 Warnings: 0 Open any category page, say, http://www.unipedia.info/Category:Computer_science.html and see "There are 0 articles in this category." What am I doing wrong, and why none of the maintenance files is working? I am using mediawiki 1.3.8 Thank you, Plamen

Show replies by date

Heli Retzek

28 Nov 28 Nov

11:51 p.m.

New subject: [Mediawiki-l] DB-Prefix, 9930 Chars, Hooks&Filters

I converted from CoMa Wiki to Wikimedia 2 weeks ago, try to explore now Wikimedias features an options. Q1: can I use HTML-Mails here in this forum? Now - after having spent many nights I am stunned about the fact, that wikimedia seems to have not implemented many things yet, that are rather obvious and that I accepted before as standard for a wiki-machine, having looked for some. Interestingly the one-person project CoMa seems to have many features seemless implemented in a very efficient way, they seem so obivious that I assume that I missed it somewhere in the dokumentation of the Wikimedia project e.g. a DB-Prefix so that I can handle several WIKIS in one MySQL - in CoMa every MySQL-Access is started with TABLE_PREFIX to be able to get that, thats very very simple but does a great job i think. // load page if (!$page) $page = $this->LoadSingle("SELECT * FROM ".$this->config["table_prefix"]."pages WHERE tag = '".mysql_escape_string($tag)."' ".($time ? " AND time = '".mysql_escape_string($time)."'" : " AND latest = 'Y'")." LIMIT 1"); e.g. the HOOK & FILTER - FEATURES - in Coma you just throw a function in the action subdir and you simply call it within the Wiki, thus you find many interesting Plugins ready like: Polls, Tooltips, Smileys [not for the sake of smileys but instead of each time hardcode "[[image:pct_arrow_right14.png]]" to get something like "-->" Arrow - it would make greatly sense to let that all do certain plugins and formater within the Wikimedia, that are either or not available in certain installations, just by throwing them into the directory (and maybe setting a config-value)] forms, diagrams, calendar ... well, another issue: I actually missed a certain discussion to the very ambitous plug&hooks email last week from Evan Prodromou, is this here really the developer list? and finally: anyone has any clue, just any Idea why I cannot save pages longer than 9930 chars - I asked that question yesterday allready. What could I test, where to look at - is this a host/server problem or a config. problem? Can I go back to Wikimedia 1.3.7 to circumvent that? Tx for reading HeliR

Brion Vibber

29 Nov 29 Nov

12:12 a.m.

New subject: [Mediawiki-l] DB-Prefix, 9930 Chars, Hooks&Filters

On Nov 28, 2004, at 3:51 PM, Heli Retzek wrote:

...

Q1: can I use HTML-Mails here in this forum?

I'd recommend against it.

...

e.g. a DB-Prefix so that I can handle several WIKIS in one MySQL - in CoMa every MySQL-Access is started with TABLE_PREFIX to be able to get that, thats very very simple but does a great job i think.

This is already in 1.4 (but the installer doesn't support it yet, it must be manually configured). 1.4beta1 will be out within a couple days.

...

e.g. the HOOK & FILTER - FEATURES

http://meta.wikimedia.org/wiki/Write_your_own_MediaWiki_extension

...

well, another issue: I actually missed a certain discussion to the very ambitous plug&hooks email last week from Evan Prodromou, is this here really the developer list?

This is the announcements and help list. wikitech-l is the developer list.

...

and finally: anyone has any clue, just any Idea why I cannot save pages longer than 9930 chars - I asked that question yesterday allready. What could I test, where to look at - is this a host/server problem or a config. problem? Can I go back to Wikimedia 1.3.7 to circumvent that?

Can you be more specific about *exactly* what happens, what you see on screen, if anything unusual happens or is displayed? 1.3.8 includes a workaround for an apparent PHP bug which has been reported by several users. It's possible that you have, somehow, the inverse bug. Look at includes/EditPage.php and try switching the enctype attribute on the edit form, see if it makes a difference. -- brion vibber (brion @ pobox.com)

Rowan Collins

4:38 p.m.

New subject: [Mediawiki-l] DB-Prefix, 9930 Chars, Hooks&Filters

On Mon, 29 Nov 2004 00:51:40 +0100, Heli Retzek <helmut.retzek(a)asak.at> wrote:

...

I converted from CoMa Wiki to Wikimedia 2 weeks ago, try to explore now Wikimedias features an options.

Just a very quick note, to nip confusion in the bud: "Wikimedia" is not the same as "MediaWiki": one is a group of websites, and the non-profit organisation that runs them; the other is the software used on those websites. See http://meta.wikimedia.org/wiki/Names for more detail. -- Rowan Collins BSc [IMSoP]

Brion Vibber

12:15 a.m.

New subject: [Mediawiki-l] Maintenance problems

On Nov 28, 2004, at 8:46 AM, Plamen Gradinarov wrote:

...

However I try to start any file from the maintenance, say, refreshLinks or rebuildSearchIndex, the result is invariably one and the same: "Sorry! The wiki is experiencing some technical difficulties, and cannot contact the database server."

Can you confirm that the database username and password in AdminSettings.php are correct, and that you can use them to connect to the server with the command-line 'mysql' client? Can you confirm that you spelled $wgDBadminuser and $wgDBadminpassword correctly, with that exact case usage?

...

Even the proposed workaround for rebuilding the links is not working.

What workaround is that, and where is it proposed?

...

First it returns ERROR 2006: MySQL server has gone away No connection. Trying to reconnect...

Check mysql's error log; MySQL may be crashing or having other problems. -- brion vibber (brion @ pobox.com)

Plamen Gradinarov

9:06 a.m.

New subject: [Mediawiki-l] Maintenance problems

...

Can you confirm that the database username and password in

AdminSettings.php are correct? Thank you very much, Brion, you are very helpful! Of course, it was my fault, there were my wikiadmin logins in the AdminSettings.php, not the wikiDB ones. Now the real count started by 50 and seems to take several hours (probably more than 36 at the present rate). The workaround (I'm afraid I took it for a standalone replacement of the entire rebuild problem, while it should be applied only if the commandline solution works but still returns 0 articles) is found here: http://meta.wikimedia.org/wiki/Documentation:Administration starting with: "To rebuild the article count manually" Thanks again, Plamen BTW, how much time and space will take the creation of a SearchIndex for the last dump of the English Wiki? Now the CPU load is about 3.60 (Dual Xeon 2.8 HT). Probably it will be less with an additional 1 GB RAM... Are there any hardware requirements for running, say, an English cur replica of Wikimedia?

Brion Vibber

10:50 a.m.

New subject: [Mediawiki-l] Maintenance problems

On Nov 29, 2004, at 1:06 AM, Plamen Gradinarov wrote:

...

Can you confirm that the database username and password in

Building the link tables takes a long time as it requires parsing and rendering every page in the database to determine which links are used. If you're just pulling the Wikipedia database dumps, you might consider importing the links table backups that we provide with the dumps. At http://download.wikimedia.org/archives/en/ you'll see en_links_table.sql.gz, en_brokenlinks_table.sql.gz, etc.

...

The workaround (I'm afraid I took it for a standalone replacement of the entire rebuild problem, while it should be applied only if the commandline solution works but still returns 0 articles) is found here: http://meta.wikimedia.org/wiki/Documentation:Administration starting with: "To rebuild the article count manually"

This explains how to set the article count; it's not related to rebuilding the link tables at all, but is a separate operation. This doesn't take _too_ long, but again if you want to skip it you can pull eg en_site_stats_table.sql.gz.

...

BTW, how much time and space will take the creation of a SearchIndex for the last dump of the English Wiki?

The searchindex table for en.wikipedia.org and its fulltext index together are about 5.2GB on our server. Generating the search index should go much faster than building the link tables, as the entries are only lightly processed, but may still take a few hours for that large a database depending on your system's speed and other system load while it's running. We don't currently make public backups of the search index table due to the size and the relative ease of regenerating it.

...

Now the CPU load is about 3.60 (Dual Xeon 2.8 HT). Probably it will be less with an additional 1 GB RAM... Are there any hardware requirements for running, say, an English cur replica of Wikimedia?

Requirements will depend mainly on usage. You should probably install a PHP optimizer such as Turck MMCache (a very easy way to make any PHP apps run faster), and if load is high consider the other caching options (file cache mode, squid reverse proxy with squid mode turned on, memcached+parser cache). -- brion vibber (brion @ pobox.com)

7088

days inactive

7089

days old

mediawiki-l@lists.wikimedia.org

Manage subscription

6 comments

4 participants

tags (0)

participants (4)

Brion Vibber
Heli Retzek
Plamen Gradinarov
Rowan Collins