Nathan J. Yoder wrote:
Why was the newst copy of enwiki with the full history
the downloads site? I checked around and was only able to find one
place with it:
We almost filled the disk on the storage cluster and needed to purge
older snapshots. Tim ran a purge on all 2008 snapshots which is why you
don't see them anymore. Thankfully I have archive copies saved of
several wiki's including en that can be restored.
You'll want the "enwiki-20080103-pages-meta-history.xml.7z" file,
which is about 17GB. There is another file that is 130GB, but that is
the SAME thing, just compressed with bz2 insteaf of 7z, making it
larger, so don't get that one.
Tomasz, I am willing to volunteer my services as a programmer to help
with this problem in making full history enwiki dumps, if it is
possible (I can't donate hardware/money). What are the issues which
are causing it to be so slow and what methods are you employing to
Currently pulling page text is really really really slow. Even spinning
up multiple instances of pullers doesn't really help us much.
I know that LiveJournal has some sort of live backup system using
MySQL and Perl, but couldn't find any details on their presentations.
You might be able to ask one of their developers for help, on their LJ
blog. Can Wikimedia afford a snapshot server? It doesn't need to be as
fast as the others.
Very cool. Their right down the street from us so perhaps a contact
could be made.
In the long run, whatever this system is, it will probably need to be
integrated into some sort of backup, because it would be a huge pain
if something happened at the data center and you needed to restore
from the partial quasi-backups in the current systems.
Possibly, were looking at many different ways of incorporating backups
to be mysql slaves, snapshots & xml. Plus were adding offiste backup to
make our emergency recovery even better.
How does the current dump method work? Are they incremental in the
sense that they build up on previous dumps, instead of re-dumping all
of the data?
Each full history snapshot first checks to see if a previous one has run
and only does new work.
For future dumps, we might have to resort to some form of snapshot
server that is fed all updates either from memcaches or mysqls. This
allows for a live backup to be performed, so it's useful for not just
Possibly but the crux of it is simply the page text from external
storage. Fetching the meta content while long is very short in the grand
scheme of things.
Is it possible to suspend any individual slaves temporarily during off
peak hours to flush the database to disk and then copy the database
files to another computer? If not, we may still be able to use a
"stale" database files copied to another computer, as long as we only
use data from it that is at least a few days old, so we know that it's
been flushed to disk (not sure how mysql flushes the data...).
Spinning down a slave wont help us much since external storage is the
slowdown. But mirroring that content elsewhere might be the way to go.
External storage by itself is just a set of mysql db's. I'm curious to
see if there might be a better storage sub system to optimize for this.
Of course, this may all be totally off, since I don't know a lot about
the current configuration and issues, so I'll take whatever input you
have to help work on something better.
No worries, feel free to find me on freenode to chat more about this and
how you can help.