OpenNET: статья - Перенос репозитория Subversion на старую версию BerkeleyDB. (cvs subversion BerkeleyDB )

Ключевые слова: cvs, subversion, BerkeleyDB, (найти похожие документы)
From: geekkoo <mkondrin@hppi.troitsk.ru.> Newsgroups: email Date: Mon, 14 Sep 2008 17:02:14 +0000 (UTC) Subject: Перенос репозитория Subversion на старую версию BerkeleyDB. Мне потребовалось перенести репозиторий 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_archive45 -s changes copies lock-tokens locks nodes representations revisions strings transactions uuids вот эти файлы и составляют базу данных репозитория. Идея состоит в том, что в начале я скидываю эти файлы в промежуточное хранилище с помощью 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 формат, что не слишком быстро. Ещё один хороший вопрос - насколько этот трюк работает при откате на мажорную версию. Но что-то желания искать на него ответ у меня не возникло.

Обсуждение

[ RSS ]

1.1, Аноним, 10:39, 15/09/2008 [ответить] [смотреть все]	+/–
Ух ты, сколько проблем, а почему было сразу не хранить репозиторий в fsfs Это б... весь текст скрыт [показать]

2.2, geekkoo, 11:28, 15/09/2008 [^] [ответить] [смотреть все]	+/–
>Ух ты, сколько проблем, а почему было сразу не хранить репозиторий в >fsfs? Это более простой, быстрый, надёжный, компактный и вообще официально рекомендуемый >метод. WTF fsfs?

3.3, Аноним, 15:36, 15/09/2008 [^] [ответить] [смотреть все]	+/–
Тип хранилища, можно berkeleyDB, а можно fsfs -- файлы на диске, по файлу на рев... весь текст скрыт [показать]

4.4, geekkoo, 15:58, 15/09/2008 [^] [ответить] [смотреть все]

+/–

>[оверквотинг удален]
>create: usage: svnadmin create REPOS_PATH
>
>Create a new, empty repository at REPOS_PATH.
>
>Valid options:
>...
> --fs-type arg
> : type of repository: 'fsfs' (default) or 'bdb'
>
>...

Да, действительно

Когда создавался репозиторий bdb был дефолтным

1.5, сергио, 23:35, 15/09/2008 [ответить] [смотреть все]	+/–
Можно было сделать проще: svnadmin dump REPO_Path > dumpfile.dump svnadmin load /path/to/new/reponame < /path/to/dumpfile.dump И неважно какие хранилища bdb или fsf.

2.6, geekkoo, 00:19, 16/09/2008 [^] [ответить] [смотреть все]	+/–
>Можно было сделать проще: >svnadmin dump REPO_Path > dumpfile.dump >svnadmin load /path/to/new/reponame < /path/to/dumpfile.dump > >И неважно какие хранилища bdb или fsf. Я ж с этого и начал - что не хотел пересобирать subversion с новыми BerkeleyDB. А тот что был не читал более новый формат данных.

1.7, User294, 02:47, 16/09/2008 [ответить] [смотреть все]	+/–
Простите за резкость но по моему это называется "откровенный онанизм в следствие некрофилии". В смысле, сперва искуственно придумали себе каких-то левых и глупых проблем а потом с помпой их разрулили.От себя хочу заметить что по опыту компилежки беркелеевской БД для не поддерживаемой ими официально платформы (!!) оно достаточно несложная штука.А заявлять что более старая версия дескать не работает с данными от более новой - это и вовсе пи...ц какой-то.Даунгрейд вообще крайне редко работает.Минусом это не является, ибо некрофилия - извращение.

2.8, geekkoo, 07:14, 16/09/2008 [^] [ответить] [смотреть все]

+/–

>Простите за резкость но по моему это называется "откровенный онанизм в следствие
>некрофилии". В смысле, сперва искуственно придумали себе каких-то левых и глупых
>проблем а потом с помпой их разрулили.От себя хочу заметить что
>по опыту компилежки беркелеевской БД для не поддерживаемой ими официально платформы
>(!!) оно достаточно несложная штука.

Речь не о компилежке BDB идет, а об апаче, сабвершене и апр-утилитах
>А заявлять что более старая версия дескать
>не работает с данными от более новой - это и вовсе
>пи...ц какой-то.Даунгрейд вообще крайне редко работает.

Заблуждение. Напрямую не работает, через бэкапы - работает не всегда, но заметно чаще.

Ваш комментарий