On Oct 28, 2014 2:56 AM, "Justin Lloyd" <jclbugz(a)gmail.com> wrote:
Again, perhaps there's a better way to architect a
resilient set of wikis
that would simplify this design, and I'm open to all suggestions, so far
what I have is the best I've come up with in the time I've managed these
wikis.
You should take a look at how WMF handles this. The wiki farm stuff (aka
hetdeploy/mwmultiversion) is documented at
https://wikitech.wikimedia.org/wiki/Heterogeneous_deployment (maybe up to
date because edited recently)
also:
*
https://github.com/wikimedia/operations-mediawiki-config/blob/master/multiv…
*
https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-co…
*
https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-co…
(and see other files in that dir too)
WMF essentially runs its own s3. (called swift. An openstack project) I
don't see why you couldn't use s3 in a similar way. might be overkill for
you to run your own swift cluster. Rackspace has a public swift cluster you
could use too.
It doesn't look like there's currently an s3 filebackend but you're welcome
to add one.
*
https://github.com/wikimedia/mediawiki/tree/master/includes/filebackend
*
https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-co…
*
https://wikitech.wikimedia.org/wiki/Media_storage
* our InitialiseSettings.php: wgUploadPath
In the short term you could load balance reads with a more frequent rsync
and then it's only spof for writes and rendering file description pages. I
think. (wgUploadPath points to load balancer for a cluster of machines that
all have a local copy of all images.)
-Jeremy