On 16/02/13 03:27, Justin Lloyd wrote:
Hello all,
I have two version 1.16 wikis that use a shared database configuration that
I'd like to split (I'm working towards upgrading them to 1.20). Say X is
the database that has the user and user_properties tables, and Y is the one
that shares those tables. Would it be sufficient to mysqldump the user and
user_properties tables from X, import them into Y, and set $wgSharedDB to
null in the wiki that uses Y?
Yes.
But if you want to share them again, don't split it.
Also, what would the process be if I just wanted to
upgrade the wikis to
1.20 but still with the shared configuration?
Upgrade one after the other. update.php does not change non-native (ie.
shared) tables by default.
Note that 1.20 will run with the 1.16 tables (but 1.16 won't work if you
try to run it with an ‘upgraded’ user table where you dropped the
user_options field). However, changing your password on 1.20, it may not
work on 1.16, though.
One stumbling block so far is
that one database is about 5 GB and the shared one is around 50 GB. As a
test, I ran the 1.20 update.php script against a copy of the 5 GB database
and it took about 18 hours, though that's on a small (2 CPU, 1 GB RAM)
VMware VM. Even on the wiki database production hardware I'd be concerned
about how long an update.php run against the 50 GB database might take, as
I want to avoid a lengthy downtime. Is there any way to speed up the
process? Any field-tested recommendations on improving this procedure?
It depends on what is filling those 50 GB. For instance page contents
won't be changed by the db upgrade.
You can check the patches to be used by the update process and manually
apply them one by one (it is also safe to run it).
The only major change from 1.16 to 1.20 seems to be the addition of sha1
hashes for files and revisions. And that will be slow.
I would do the following:
- Apply to your db: patch-rev_sha1.sql, patch-ar_sha1.sql,
patch-img_sha1.sql, patch-fa_sha1.sql (maintenance/archives folder)
- Run maintenance/populateImageSha1.php (fills the sha1 for images)
- Run maintenance/populateRevisionSha1.php (fills the sha1 for pages)
So you can be populating the sha1 hashes in a background instance (with
1.20 code) while you still run the old code of the wiki.
Once it is done, you can run update.php, which will be fast as it won't
have to perform that step (it used to be possible to update the wiki
without calculating the hashes -which could then be done in background-
but I'm not sure if 1.20 has at this point a dependency where it will
fail if the sha1 entries are empty. It is probably safe to do).