don't know if this issue came up already - in case it did and has been
dismissed, I beg your pardon. In case it didn't...
I hereby propose, that pbzip2 (https://launchpad.net/pbzip2) is used
to compress the xml dumps instead of bzip2. Why? Because its sibling
(pbunzip2) has a bug bunzip2 hasn't. :-)
Strange? Read on.
A few hours ago, I filed a bug report for pbzip2 (see
https://bugs.launchpad.net/pbzip2/+bug/922804) together with some test
results done even some few hours before that.
The results indicate that:
bzip2 and pbzip2 are vice-versa compatible each one can create
archives, the other one can read. But if it is for uncomressing, only
pbzip2 compressed archives are good for pbunzip2.
I propose compressing the archives with pbzip2 for the following
1) If your archiving machines are SMP systems this could lead to a
better usage of system ressources (i.e. faster compression).
2) Compression with pbzip2 is harmless for regular users of bunzip2,
so everything should run for these people as usual.
3) pbzip2-compressed archives can be uncompressed with pbunzip2 with a
speedup that scales nearly linearly with the number of CPUs in the
So to sum up: It's a no loose and two win situation if you migrate to
pbzip2. And that just because pbunzip2 is slightly buggy. Isn't that
Dipl.-Inf. Univ. Richard C. Jelinek
PetaMem GmbH - www.petamem.com Geschäftsführer: Richard Jelinek
Human Language Technology Experts Sitz der Gesellschaft: Fürth
69216618 Mind Units Registergericht: AG Fürth, HRB-9201
I created mw:Extension:InterwikiExistence<https://www.mediawiki.org/wiki/Extension:InterwikiExistence>,
which imports a file of Wikipedia page titles and then polls the Wikipedia
API to keep the local list of Wikipedia's pages up to date. But it helps if
it knows what timestamp to start its polling at. Specifically, system
administrators installing the extension need to know the date/time at which
the AllPages snapshot gzipped as
generated; that way, the API poll function can begin with the right
value in the rcstart (recentchanges) and lestart (logevents) parameters.
Can system administrators rely on the "Last Modified" date/time of the file
as that snapshot date/time? Or is a better date/time to use listed
somewhere else? Thanks.
Good evening, I hope this is an appropriate place for this question.
I've been trying to import the current enwiki dump from Oct. Using Mwdumper
it runs fine until hitting 247,000 records and then mysql throws one of the
following 2 errors.
Error (2006 I think it was) Mysql went away
Error (2013) Lost connection to mysql server
I've tried several things on the mysql end including increasing the
and increasing max_allowed_packets.
All suggestions by a few web resources. Still to no avail..
I'm not sure where to true issue is or how to go about correcting it. Any
help would be greatly appreciated.
I'm running latest version of mediawiki, importing the october 2013 dump
and mysql version 5.6.12 via WAMP, and mwdumper 1.16
thanks in advance
I've a set of list page titles that i've extracted from the Category dump (where "cl_from" is of type "page")
Now I want to extract the CONTENT of the page from the pages dump
Although there are guidelines on how editors should mark these pages
("The titles of list articles typically begin with the type of list it is (List of, Index of, etc.), followed by the article's subject; like: List of vegetable oils.")
The majority of the times the above rule is not implemented. So my concrete question is:
- if i am consuming the pages-articles.xml dump (D) page by page, and i have a list of pages (L) i've extracted from the category (C) links dump, then how can i check that page in pages dump file D is a member of L? The titles do not resolve the names.
For instance, if I have the page title "List of the longest Asian rivers" (http://en.wikipedia.org/wiki/List_of_the_longest_Asian_rivers) then what in that page's content (http://en.wikipedia.org/w/index.php?title=List_of_the_longest_Asian_rivers&…) can tell me it is the same page "List of the longest Asian rivers"? None-list pages appear to place the title as first token with ''' markings.
Any suggestions of a robust solution would be much appreciated.
I'm setting up the database from wikipedia XML dumps. As you know that if
we import all revision dumps then it may size to 22 - 25 terabytes Aprox.
This size is too huge, what is workaround for it ??
If it is necessary to dumps all xmls to DB then i think linux only support
up to 16 TB maximum. SO how we can import into single MYSQL server deployed
on linux OS.
Please some one also tell me that how currently wikipedia it self managing
such huge data in terms of software and hardware solutions.