[ новости /+++ | форум | теги | ]

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

Ключевые слова: 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 формат, что не
слишком быстро.

Ещё один хороший вопрос - насколько этот трюк работает при откате на
мажорную версию. Но что-то желания искать на него ответ у меня не
возникло. 

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

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 -- файлы на диске, по файлу на ревизию. Используется по умолчанию помоему с svn 1.3. bash-3.00# svnadmin help create 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' ...     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 (ok), 02:47, 16/09/2008 [ответить]   +/– Простите за резкость но по моему это называется "откровенный онанизм в следствие некрофилии". В смысле, сперва искуственно придумали себе каких-то левых и глупых проблем а потом с помпой их разрулили.От себя хочу заметить что по опыту компилежки беркелеевской БД для не поддерживаемой ими официально платформы (!!) оно достаточно несложная штука.А заявлять что более старая версия дескать не работает с данными от более новой - это и вовсе пи...ц какой-то.Даунгрейд вообще крайне редко работает.Минусом это не является, ибо некрофилия - извращение.     2.8, geekkoo (??), 07:14, 16/09/2008 [^] [^^] [^^^] [ответить]   +/– >Простите за резкость но по моему это называется "откровенный онанизм в следствие >некрофилии". В смысле, сперва искуственно придумали себе каких-то левых и глупых >проблем а потом с помпой их разрулили.От себя хочу заметить что >по опыту компилежки беркелеевской БД для не поддерживаемой ими официально платформы >(!!) оно достаточно несложная штука. Речь не о компилежке BDB идет, а об апаче, сабвершене и апр-утилитах >А заявлять что более старая версия дескать >не работает с данными от более новой - это и вовсе >пи...ц какой-то.Даунгрейд вообще крайне редко работает. Заблуждение. Напрямую не работает, через бэкапы - работает не всегда, но заметно чаще.

Партнёры:

Хостинг: