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).