[wp-trac] [WordPress Trac] #20057: Media upload for multi-webserver setups introduces a nasty race condition that could corrupt uploaded files
WordPress Trac
wp-trac at lists.automattic.com
Fri Feb 17 05:46:40 UTC 2012
#20057: Media upload for multi-webserver setups introduces a nasty race condition
that could corrupt uploaded files
--------------------------+-----------------------------
Reporter: archon810 | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Media | Version: 3.3.1
Severity: major | Keywords:
--------------------------+-----------------------------
I am in the process of scaling a Wordpress blog with several million
monthly pageviews, and I have designed a plan to scale it in the highest
availability manner possible.
'''The setup'''
Each web server that hosts HTML/PHP, static files, and uploads will be
replicated via rsync from time to time and sitting behind a load balancer.
Rsync will run every 5min to 1 hour, and to mitigate the 404s in the
uploads, I put together an nginx setup that automatically tries a
different upstream server in its configuration when it encounters 404s.
This allows any web server to go down at any time, and the system to run
as if nothing happened. This also gives me freedom for rsyncing
periodically rather than immediately and avoids 404s completely.
'''The problem'''
Now, the bug (note, I'm using Windows Live Writer which automatically
names uploads image.png, but I could see this potentially happen without
WLW too since WP seems to automatically name files on disk in case of
collisions).
Let's say we have server A and B. The site name is foo.com. Let's also say
B is out of date by an hour and a bunch of files got uploaded to A that
aren't on B. Say, A has image.png and image2.png and B has only image.png.
Now, the issue is that if the load balancer directs the new post uploader
(the new post contains a single image) to server B, the file that it will
create on disk will be named image2.png rather than image3.png. So now B
will have a file that's different from A's but is named the same way.
The main problem is that the file name is given based on what's available
on the disk rather than according to the database. It's easy for this race
condition (between rsyncs) to destroy the integrity of the files.
Furthermore, and I've experienced this first hand), if you delete the
attachment from the Wordpress UI, it could actually delete the wrong file
from the wrong server as a result.
Seeing this, I can't continue with my scaling plan until file names are
assigned by the database rather than the file system or I figure out how
to mitigate that. I don't want to force all writers to use only server A
for uploads using its direct IP, as I want HA (high availability).
Thank you.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/20057>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list