Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Master and slave are still live since commits that don't access the corrupt data still work. We want to copy the slave to the master with minimal downtime.

The Repair

Ensure the master repository is off line and the other preconditions are met. Keep a backup of the master repository before starting to fix it.

Copy, by any convenient method (such as rsync or by physically shipping a disk), the following parts of the mirror repository into the master repository:

...

  1. Create a new repository that will become the new master. 2. Use 'svnsync init' to setup the slave as the temporary source for the new master. 3. At this point 'svnsync synchronize' can be used to bring the new master up-to-date, but rsync is probably faster.
    • rsync 'db/current'
    • rsync 'db' excluding 'db/current',

...

    • db/locks', 'db/transactions', 'db/txn-protorevs

...

    • ', 'db/revprops' and 'db/rep-cache.db'
    • make slave read-only
    • rsync 'db/rep-cache.db'
    • make slave read-write
      4. Adjust svn:sync-last-merged-rev to the youngest revision in the new master and run 'svnsync sync'.
      5. Disable revprop changes on the master, or make the master read-only.
      6. Copy 'db/revprops' from the master into the new master.
      7. Make the master read-only if not already.
      8. Ensure slave is up-to-date and run 'svnsync sync' to get any final commits.
      9. Delete svn:sync-* revprops from new master r0.
      10. Take master offline.
      11. Replace master 'db' with 'db' from new master.
      12. Check whether

Then delete 'db/locks/*', 'db/transactions/*' and 'db/txn-protorevs/*'.

...

    • 'db/fsfs.conf'

...

    • needs to be adjusted

...

    • .
      13. Bring master back online.