Мне потребовалось перенести репозиторий Subversion с одной машины на
другую в виде тарболла содержащего его базу данных. При этом выяснилось,
что на старой машине subversion был собран с BerkeleyDB 4.5, а на новой-
4.4. В результате просто распаковкой архивов ограничиться не удалось,
поскольку между BDB разных версий имеется несовместимость в формате
файлов баз данных.
Пересобирать Subversion, aprutils, Apache (предполагалось открыть доступ
через https) с новой версией BDB мне не хотелось, вместо этого я решил
сделать downgrade репозитария до более старой версии BDB, которая по
умолчанию использовалась на моем компьютере. В отличии от upgrade,
который делается практически автоматически с помощью утилиты db_upgrade,
выполнение отката на одну минорную версию оказалась не вполне очевидной
затеей. Поиск в интернете ни к чему не привёл, поэтому пришлось
действовать на свой страх и риск.
Для этого мне всё же пришлось установить соответствующую версию
BerkeleyDB (4.5.20), для чего я просто скачал исходники с сайта Oracle,
взял сборочный скрипт из своего дистрибутива, поменял там версии пакета
и запустил компиляцию. Потом в готовом пакете переименовал исполняемые
файлы (/usr/bin/db_* поскольку только их имена конфликтовали с уже
имеющимися из пакета BerkeleyDB4.4), просто добавив к их имени суффикс
45. После этого можно было приступать к downgrade.
Итак, репозитарий был распакован в каталог /var/lib/svn, так что его
базы данных содержатся в подкаталоге /var/lib/svn/db. В первую очередь
backup:
# cp -a db db.original
и можно начинать эксперименты:
# cd db
Неплохо бы начать с восстановления:
# db_recover45 -v -e -h ./
и сброса последних записей в файлы данных:
# db_checkpoint45 -v -1
Если какие-то команды ругаются (у меня ругались, база данных была после
крэша) и отказываются работать, то ничего не поделаешь - с надеждой на
лучшее переходим к следующему этапу.
Я решил переносить файлы в максимально портабельном формате, т.е. в виде
dump-а. Однако, для начала стоит выяснить, dump чего нужно делать:
вот эти файлы и составляют базу данных репозитория. Идея состоит в том,
что в начале я скидываю эти файлы в промежуточное хранилище с помощью
db_dump45, а потом загружаю с помощью db_load, которая уже слинкована с
BerkleyDB 4.4.20. Чтобы было меньше возни, я написал пару скриптов на
tcl:
#!/usr/bin/tclsh
exec mkdir ~/svn.dump
set db [exec db_archive45 -s]
foreach i $db {
exec db_dump45 -f ~/svn.dump/$i.dump $i
}
exec cp DB_CONFIG ~/svn.dump
Это чтобы скинуть архив и конфигурационный файл DB_CONFIG. Запускается
скрипт в директории /var/lib/svn/db, после чего эту директорию можно
смело удалять и запускать следующий:
#!/usr/bin/tclsh
set h [ exec ls ~/svn.dump ]
exec mkdir db
cd db
foreach i $h {
set k [lindex [regexp -inline {(.*).dump} $i] 1]
exec cat ~/svn.dump/$i | db_load -h ./ $k
}
exec cp ~/svn.dump/DB_CONFIG ./
В итоге имеем каталог db со всеми нужными файлами внутри. Теперь
осталось войти в этот каталог и восстановить рабочее окружение:
cd db
db_recover -h ./ -e -v
В результате там появятся ещё несколько файлов вида __db.* и log.*.
Можно убедиться, что теперь svn работает:
svn list file:///var/lib/svn
Я думаю, что эта стратегия - db_checkpoint, db_archive, db_dump,
db_load, db_recover, может быть полезна при архивировании баз данных
других серверов, использующих BerkeleyDB, но не имеющих своих утилит
архивирования. Например, OpenLDAP, где альтернативой может быть только
скидывание и восстановление всего каталога через ldif формат, что не
слишком быстро.
Ещё один хороший вопрос - насколько этот трюк работает при откате на
мажорную версию. Но что-то желания искать на него ответ у меня не
возникло.
902 Прочтений • [Перенос репозитория Subversion на старую версию BerkeleyDB. (cvs subversion BerkeleyDB )] [08.05.2012] [Комментариев: 0]
Vova
