10.3. Unwedging Your RepositoryIf you are using the Berkeley DB backend, you may occasionally find that the repository gets "wedged" after a system crash, failed transaction, or other nasty event. This can happen when the database (for one reason or another) fails to remove an internal lock, which causes every subsequent request to hang indefinitely. Fortunately, fixing the problem is usually easy. In most cases, if you run the svnadmin recover command, you'll be back up and running (although with a large repository, the command might take a while to run). Because this command may modify files in the repository, make sure you run it as the user who owns the repository. You should also make sure that nothing else is accessing the repository while you perform the recovery (i.e., shut down Apache or svnserve). Although the recover command obtains a lock on the database, you can still have problems if another process was already accessing the repository when you started the recovery. If possible, it's also a good idea to make a copy of your repository before you run a recovery, just in case. $ svnadmin recover /srv/svnrepos Please wait; recovering the repository may take some time... Recovery completed. The latest repos revision is 13729. The svnadmin recover command is a wrapper for the most common use case of the Berkeley DB recovery command, db_recover. Unfortunately, the most common use case is sometimes not enough to recover a broken repository. So, if svnadmin recover fails, you may need to try a catastrophic recovery with db_recover itself. To perform a catastrophic recovery, you need to have an intact backup of your repository, plus all of the log files that have been generated since that backup was made (or just all of the log files that have ever been generated for your repository). Then, you need to follow these steps.
If you are recovering from a complete set of log files instead of a backup repository, you can skip steps 2 and 3. Instead, copy any necessary log file backups into the corrupted repository directory and run the recovery directly on it. You may need to remove the corrupted repository table files: nodes, revisions, representations, changes, strings, TRansactions, and uuids. Of course, you should still make a backup of the corrupted repository before you attempt the recovery. |