Форум » LetoDB, HbNetio. » Архивация в letodb » Ответить
Архивация в letodb
Pasha: Хочу посоветоваться. Задача - сделать бэкап (архив) базы в произвольный момент времени. Пусть архиватор будет 7z, хотя это не принципиально. Утилита запускается на сервере, где установлен letodb, по определенному графику (хотя бы планировщиком). Входные параметры: каталог БД и список расширений файлов, которые надо поместить в архив. Предлагается такой алгоритм: сканируется все содержимое каталога БД, и формируется список @listfiles для архиватора. Если это не файл данных, он просто добавляется в список. Если это файл данных, то выполняется попытка его открыть монопольно. Если попытка успешная - файл закрывается и добавляется в список. Если нет - добавляется в список № 2 для 2-го прохода. Для 1-го прохода через run вызывается архиватор, и ему дается список файлов. Для 2-го прохода создается новый каталог, куда средствами letodb через команду copy to копируются открытые файлы, затем вызывается архиватор с командой добавления в архив файлов, которые не были заархивированы во время 1-го прохода. Какие будут идеи ?
PSP: А зачем два прохода? По расписанию COPY TO во временную папку и потом архивировать.
Pasha: Чтобы не копировать те файлы, которые не открыты letodb Копирование больших файлов может быть длительной операцией, и в этом случае в ней нет необходимости
Петр: Pasha пишет: Если это не файл данных, он просто добавляется в список. Если это файл данных, то выполняется попытка его открыть монопольно. Если попытка успешная - файл закрывается и добавляется в список. Если нет - добавляется в список № 2 для 2-го прохода. Для 1-го прохода через run вызывается архиватор, и ему дается список файлов. А между первым и вторым проходом ничего не произойдет? Что-то откроется, что-то закроется?
petr707: Цитата: Пусть архиватор будет 7z, хотя это не принципиально. Утилита командной строки 7za допускает ключ архивации открытых в Shared файлов. Так что, может и "принципиально" ? Тогда не нужен проход 2 ?
Pasha: petr707 пишет: Утилита командной строки 7za допускает ключ архивации открытых в Shared файлов. Это не поможет, так как letodb открывает файлы монопольно.
Pasha: Петр пишет: А между первым и вторым проходом ничего не произойдет? Что-то откроется, что-то закроется? Конечно, это узкое место. Поэтому и прошу совета. Может быть, кто-то предложит делать по-другому.
PSP: Может прикрутить отдельный поток к серверу, который будет запускать при наличии определенного ключа в ini-файле и параллельно копировать все изменения во всех файлах, которые делает сервер? Будет самая актуальная копия.
AlexMyr: PSP пишет: параллельно копировать все изменения во всех файлах, которые делает сервер? Будет самая актуальная копия. это уже какой-то raid-массив получится Pasha пишет: Для 2-го прохода создается новый каталог, куда средствами letodb через команду copy to копируются открытые файлы, затем вызывается архиватор с командой добавления в архив файлов, которые не были заархивированы во время 1-го прохода. А если во время 2-го прохода база осталась (или открыли) в монопольном режиме, что тогда делать?
PSP: AlexMyr пишет: это уже какой-то raid-массив получится Ну, необязательно "на лету" это делать. Скажем, сервер ведет лог операций с записями, который обрабатывается по определенному расписанию отдельным потоком.
AlexMyr: PSP пишет: Скажем, сервер ведет лог операций с записями, который обрабатывается по определенному расписанию отдельным потоком. Но задача Pasha пишет: сделать бэкап (архив) базы в произвольный момент времени.
PSP: Расписание в ini-файле мало чем отличается от произвольного момента. К примеру, ввести в ini-файл параметр BackupEvery = <кол-во минут>. Но... это - мечты... Решение за Пашей. PS. Сделать "стандартный" бэкап в "произвольный момент времени" не представляется возможным по той причине, что файлы открыты другим приложением (сервером) в монопольном режиме. Придётся ждать освобождения, а потом обеспечить копирование данных, не мешая серверу, т.к. он в любой момент после начала бэкапа может потребовать "отдать файлы" назад. А у нас тут бэкап полным ходом... Даже, если открыть файлы в разделенном режиме, будет некорректно копировать данные из файлов, которые могут в любой момент измениться. Копия может быть, мягко говоря, неработоспособной. Я же предлагаю, чтобы при наличии определенного ключа в ini-файле сервер вёл лог изменений записей всех файлов в каком-то формате, отдельный поток читал бы этот лог и повторял все "манипуляции" сервера, но уже в совершенно других файлах. Этому же потоку можно поручить запуск внешнего архиватора, если нужно. Но, повторю, решение за Пашей...
Pasha: По поводу копирования всех изменений - проще использовать зеркалирование средствами ОС. Но только для архивации включать зеркалирование не хотелось бы. А по поводу 2-го прохода. Это letodb открывает файл монопольно. Но предполагается, что клиенты окрывают файлы в режиме разделения через letodb. И утилита архивирования может открыть их через letodb в режиме разделения. Перед copy to можно выдать fillock, другие клиенты при копировании гарантированно файл не изменят. А после копирования файл конечно будет закрыт, и архиватор будет иметь дело уже с созданной копией. Узкое место: во время 1-го прохода при работе архиватора letodb не сможет открыть файл, открытый архиватором. Или успеет открыть файл до того, как его откроет архиватор. Во время 2-го прохода может не сработает fillock. Но тут останется только ждать по таймауту. Еще вариант: можно, возложить архивацию на сам letodb, используя библиотеку работы с zip. В этом случае можно архивировать и открытые файлы, по файловому хэндлу. Но при этом сервер будет загружен несвойственными ему функциями, что мне не очень нравится.
Dima: Интересно а куда исчез alkresin Саша Кресин ?
AlexMyr: Pasha пишет: Еще вариант: можно, возложить архивацию на сам letodb, используя библиотеку работы с zip. В этом случае можно архивировать и открытые файлы, по файловому хэндлу. Но при этом сервер будет загружен несвойственными ему функциями, что мне не очень нравится. Как по мне, то это будет более приемлемый и рабочий вариант, т.к. архивирование происходит по требованию или допустим раз в сутки, а если понадобится раз в десять минут на протяжении двух часов, то вынужденная мера заставит и сервер нагрузить, и на звонки не отвечать, и потерпеть. И организовано будет все своими средствами, без привлечения сторонних программ.
AlexMyr: Dima пишет: Интересно а куда исчез alkresin Саша Кресин ? Тоже интересно, в том году пробовал писать ему - молчит.
Dima: AlexMyr пишет: Тоже интересно, в том году пробовал писать ему - молчит. Он всегда очень живо реагировал на любые изменения в LetoDB и тут бац и пропал. Надеюсь с ним все хорошо !?!!
Sergey Spirin: Pasha пишет: Еще вариант: можно, возложить архивацию на сам letodb, используя библиотеку работы с zip. В этом случае можно архивировать и открытые файлы, по файловому хэндлу. Но при этом сервер будет загружен несвойственными ему функциями, что мне не очень нравится. Ну, вообще, изготовление бэкапа вполне традиционное занятие для db-серверов. А как сейчас обстоят дела в лето с транзакциями? Есть ли snapshot-транзакции? Если нет, то по любому сервер останавливать, иначе целостного бэкапа не сделать вроде...
Pasha: snapshot-транзакции не поддерживаются, есть только read commited
Sergey Spirin: Pasha пишет: snapshot-транзакции не поддерживаются, есть только read commited Тогда очевидно, что сервер надо стопить. При этом ещё либо дождаться завершения всех активных транзакций, либо все их насильно откатить, не допуская, естественно, старта новых. В противном случае получим нарушение целостности данных. Бэкап не увидит данные некой транзакции X, при проходе одной таблицы, а при проходе другой таблицы транзакция X уже закоммитится и ее данные попадут в бэкап частично.
santy: Бэкап (архив) базы - это критическая операция, её желательно делать, когда пользователи не работают в базе . Возможны варианты: копирование не файлов, а записей которые были изменены во время работы до операции копирования.
полная версия страницы