notes/webdav-proxy

   1 Purpose: A master/slave server replication model for Subversion WebDAV-based
   2 transactions.
   3
   4 All clients interact with a slave server, but the slave transparently
   5 passes all of the write-oriented activites to the master (rewriting the
   6 content as necessary).  The slaves are essentially read-only, but they
   7 do have a complete copy of the repository locally.  This serves to
   8 alleviate read traffic from the master server which may be desirable
   9 in certain circumstances.
  10
  11 This model has several advantages to using a straight HTTP DAV-aware
  12 caching proxy, in that each slave can respond to all read-only requests
  13 without ever having to relay them to the master backend.
  14
  15 Requirements: Subversion 1.5 or newer (merged to trunk as of r22606)
  16               Apache HTTP Server 2.2.0 or higher with mod_proxy enabled
  17               (Several fixes to mod_proxy were committed for this patch that
  18                were not backported to the 2.0 branch of httpd.)
  19
  20 Example configuration:
  21
  22 Participants:
  23   Slave  -> slave.example.com  (there can be many!)
  24   Master -> master.example.com (there can only be one!)
  25   A WebDAV client (ra_neon, ra_serf, other WebDAV clients)
  26
  27 Each client does:
  28
  29  % svn co http://slave.example.com/repos/slave/
  30  ...
  31  % svn ci
  32  % ...etc...
  33
  34  (The client can perform all operations as normal.)
  35
  36 Each slave has:
  37
  38 <Location /repos/slave>
  39   DAV svn
  40   SVNPath /my/local/copy/of/repos
  41   SVNMasterURI http://master.example.com/repos/master
  42 </Location>
  43
  44 The master:
  45
  46 The master MUST have a post-commit hook that updates all of the slaves.  An
  47 example that does this using 'svnadmin dump'/'svnadmin load' and ssh is
  48 provided below.  svnsync can probably do the same thing, but is left as an
  49 exercise to the reader.
  50
  51 Additionally, if locks are permitted on the master repository, lock databases
  52 need to kept in sync via post-lock and post-unlock hooks on the master pushing
  53 the lock state to the slaves.  (Username preservation is left as an exercise to
  54 the reader.)  If the lock database is not propogated, users will not be able to
  55 accurately determine whether a lock is held - but locking will still work.
  56
  57 ----
  58 #!/bin/sh
  59 REPOS="$1"
  60 REV="$2"
  61 SLAVE_HOST=slave.example.com
  62 SLAVE_PATH=/my/local/copy/of/repos
  63
  64 # Ensure svnadmin is in your PATH on both this machine and the remote server!
  65 svnadmin dump --incremental -r$2 $1 > /tmp/$2.dump
  66 scp /tmp/$2.dump $SLAVE_HOST:$SLAVE_PATH
  67 ssh $SLAVE_HOST "svnadmin load $SLAVE_PATH < $SLAVE_PATH/$2.dump"
  68 ssh $SLAVE_HOST "rm $SLAVE_PATH/$2.dump"
  69 rm /tmp/$2.dump
  70 ----
  71
  72 Issues/Thoughts:
  73 - The master maybe should update the slaves using a DAV commit of its own.
  74   (essentially replay the commit once it is approved).  This requires
  75   a way to inject commits/user to the slave.  But, this would eliminate the
  76   reliance on post-commit hooks.
  77 - This isn't multi-master replication.  The slave won't accept commits
  78   on its own.  If the master can't be contacted for a write operation, it
  79   will return a proxy error.  (Multi-master == distributed repositories.)
  80 - Remove the location_filter for the header.  I believe mod_proxy does this
  81   for us already.  We may just be duplicating things.  We will still have
  82   to rewrite the bodies of the requests/responses though.
  83 - Determine a better way to handle the MERGE call.  It's the only operation
  84   that doesn't occur on the activity URL.