Миграция репозиториев Subversion между серверами

мы находимся в процессе перемещения серверов, и один из последних элементов перемещается по репозиториям svn.

существует около 10 гигабайт различных репозиториев svn. Они были созданы с помощью этой команды: svnadmin create --fs-type fsfs

сервер A (оригинал) имеет svn 1.4, а сервер B(цель) имеет svn 1.6.

моя мысль была использовать rsync для переноса всего набора репозиториев (все они находятся в 1 папке на сервере), но я беспокоюсь, что некоторые вещи могут либо не перенесите или мне нужны специальные переключатели для rsync чтобы это сработало.

большинство онлайн-учебников говорят только о перемещении 1 репозитория за раз, например, с помощью svnadmin hotcopy, но мне нужно переместить около 100 или около того все вместе. Правильно ли это?

13
fsfs migrate repository svn

3 ответов

FSFS Subversion довольно стабильна при выполнении копий и движений, даже в разных ОС. Хотя mliebelt правильно делает это через перезагрузку дампа, это занимает века перейти 10 ГБ!

вот почему я бы рекомендовал следующую процедуру:

  1. скопируйте репозитории через файловую систему на новый сервер.
    например,$ scp -r /var/repos/ user@newServer:repos/

  2. сделать $ svnadmin upgrade для обновления репозитория для 1.6 (это необязательно, но настоятельно рекомендуется, если вы хотите использовать функции 1.5 / 1.6, такие как отслеживание слияния, разреженные проверки и т. д.)

  3. сделать $ svnadmin verify в каждом репозитории для проверки всех ревизий в порядке (вы можете сделать это на уже работающем сервере).

по этой процедуре вам нужно, вероятно, от 10 до 100 раз меньше времени:

например, для сброса репозитория обычно требуется приблизительно 1 ГБ в час (в основном в зависимости от HD-скорости), файлы дампа намного больше, чем репозитории (в SVN 1.4!) Таким образом, вы должны переместить больший файл на новый сервер и сделать там дамп-нагрузку, которая также занимает около 1 часа / ГБ. Сравните это с копией файловой системы, которая обычно ограничена только сетевым подключением (100 Мбит ок. 10 МБ / сек) или HD (приблизительно 100 МБ / сек), если у вас есть GBit-LAN.

15

во-первых, я не администратор Subversion, но я много работаю с ними. Так что не доверяйте только моим словам, проверьте и другие источники.

мой опыт за последние 5 лет составил:

  • чтобы переместить репозитории Subversion, вы должны использовать инструменты администратора Subversion dump и load. Они написаны специально для этой работы.
  • dump и load дополнительно проверьте, что все в порядке. Используя их, вы получаете дополнительную "страховку", которая все двигалось нормально.
  • мы никогда не переносили более 2 основных версий, но перемещались из одной основной версии в другую. Вы должны хотя бы проверить, что миграция с 1.4.от x до 1.6.x поддерживается. Часто новая версия сервера поддерживает прямую предыдущую версию и поддерживает миграцию. Поэтому, возможно, вам придется выполнить миграцию для каждого репозитория дважды.
  • вы можете работать со старыми репозиториями, пока они перемещаются, потому что subversion позволяет добавлять более новые переделки.
  • поскольку все можно сделать с помощью командной строки, вы можете автоматизировать большую часть этого, и администраторам subversion нужно только проверить, что все работает хорошо.

Итак, да, я бы рекомендовал перемещать один репозиторий друг за другом.

3

подробнее о svnadmin dump и svnadmin load для svn 1.6 см. здесь. Он предлагает некоторые обсуждения на dump и load, а также такие параметры, как --deltas, --incremental и другие.

также имейте в виду, что если вы делаете прямую копию и обновление svnadmin, вы экономите время, но состояние репозитория может быть не оптимальным. С помощью svnadmin :

svnadmin help upgrade

использование: svnadmin upgrade REPOS_PATH

обновить репозиторий, расположенный в REPOS_PATH до последней поддерживаемой версии версия схемы.

эта функциональность предоставляется как удобство для репозитория администраторы, желающие использовать новые функции Subversion без необходимости выполнять потенциально дорогостоящий полный дамп репозитория и деятельность нагрузки. Таким образом, обновление выполняет только минимум объем работы, необходимой для этого при сохранении целостность хранилища. это не гарантия наиболее оптимизированная состояние репозитория как дамп и последующая загрузка.

3