Отправлено: 16.01.12 10:36. Заголовок: Архивация в letodb

Хочу посоветоваться. Задача - сделать бэкап (архив) базы в произвольный момент времени.
Пусть архиватор будет 7z, хотя это не принципиально.
Утилита запускается на сервере, где установлен letodb, по определенному графику (хотя бы планировщиком).
Входные параметры: каталог БД и список расширений файлов, которые надо поместить в архив.
Предлагается такой алгоритм: сканируется все содержимое каталога БД, и формируется список @listfiles для архиватора.
Если это не файл данных, он просто добавляется в список. Если это файл данных, то выполняется попытка его открыть монопольно. Если попытка успешная - файл закрывается и добавляется в список.
Если нет - добавляется в список № 2 для 2-го прохода.
Для 1-го прохода через run вызывается архиватор, и ему дается список файлов.
Для 2-го прохода создается новый каталог, куда средствами letodb через команду copy to копируются открытые файлы, затем вызывается архиватор с командой добавления в архив файлов, которые не были заархивированы во время 1-го прохода.
Какие будут идеи ?

 Отправлено: 16.01.12 10:51. Заголовок: А зачем два прохода?..

А зачем два прохода? По расписанию COPY TO во временную папку и потом архивировать.

 Отправлено: 16.01.12 11:19. Заголовок: Чтобы не копировать ..

Чтобы не копировать те файлы, которые не открыты letodb
Копирование больших файлов может быть длительной операцией, и в этом случае в ней нет необходимости

 Отправлено: 16.01.12 11:41. Заголовок: Pasha пишет: Если э..

Pasha пишет:

цитата:

Если это не файл данных, он просто добавляется в список. Если это файл данных, то выполняется попытка его открыть монопольно. Если попытка успешная - файл закрывается и добавляется в список. Если нет - добавляется в список № 2 для 2-го прохода. Для 1-го прохода через run вызывается архиватор, и ему дается список файлов.

А между первым и вторым проходом ничего не произойдет? Что-то откроется, что-то закроется?

 Отправлено: 16.01.12 11:56. Заголовок: Открытые файлы

Цитата: Пусть архиватор будет 7z, хотя это не принципиально.
Утилита командной строки 7za допускает ключ архивации открытых в Shared файлов.
Так что, может и "принципиально" ? Тогда не нужен проход 2 ?

 Отправлено: 16.01.12 12:17. Заголовок: petr707 пишет: Утил..

petr707 пишет:

цитата:

Утилита командной строки 7za допускает ключ архивации открытых в Shared файлов.

Это не поможет, так как letodb открывает файлы монопольно.

 Отправлено: 16.01.12 12:20. Заголовок: Петр пишет: А между..

Петр пишет:

цитата:

А между первым и вторым проходом ничего не произойдет? Что-то откроется, что-то закроется?

Конечно, это узкое место. Поэтому и прошу совета. Может быть, кто-то предложит делать по-другому.

 Отправлено: 16.01.12 12:40. Заголовок: Может прикрутить отд..

Может прикрутить отдельный поток к серверу, который будет запускать при наличии определенного ключа в ini-файле и параллельно копировать все изменения во всех файлах, которые делает сервер? Будет самая актуальная копия.

 Отправлено: 16.01.12 17:49. Заголовок: PSP пишет: параллел..

PSP пишет:

цитата:

параллельно копировать все изменения во всех файлах, которые делает сервер? Будет самая актуальная копия.

это уже какой-то raid-массив получится
Pasha пишет:

цитата:

Для 2-го прохода создается новый каталог, куда средствами letodb через команду copy to копируются открытые файлы, затем вызывается архиватор с командой добавления в архив файлов, которые не были заархивированы во время 1-го прохода.

А если во время 2-го прохода база осталась (или открыли) в монопольном режиме, что тогда делать?

 Отправлено: 16.01.12 19:08. Заголовок: AlexMyr пишет: это ..

AlexMyr пишет:

цитата:

это уже какой-то raid-массив получится

Ну, необязательно "на лету" это делать.
Скажем, сервер ведет лог операций с записями, который обрабатывается по определенному расписанию отдельным потоком.

 Отправлено: 16.01.12 20:13. Заголовок: PSP пишет: Скажем, ..

PSP пишет:

цитата:

Скажем, сервер ведет лог операций с записями, который обрабатывается по определенному расписанию отдельным потоком.

Но задача Pasha пишет:

цитата:

сделать бэкап (архив) базы в произвольный момент времени.

 Отправлено: 16.01.12 20:18. Заголовок: Расписание в ini-фай..

Расписание в ini-файле мало чем отличается от произвольного момента.
К примеру, ввести в ini-файл параметр BackupEvery = <кол-во минут>.
Но... это - мечты... Решение за Пашей.

PS. Сделать "стандартный" бэкап в "произвольный момент времени" не представляется возможным по той причине, что файлы открыты другим приложением (сервером) в монопольном режиме. Придётся ждать освобождения, а потом обеспечить копирование данных, не мешая серверу, т.к. он в любой момент после начала бэкапа может потребовать "отдать файлы" назад. А у нас тут бэкап полным ходом... Даже, если открыть файлы в разделенном режиме, будет некорректно копировать данные из файлов, которые могут в любой момент измениться. Копия может быть, мягко говоря, неработоспособной.
Я же предлагаю, чтобы при наличии определенного ключа в ini-файле сервер вёл лог изменений записей всех файлов в каком-то формате, отдельный поток читал бы этот лог и повторял все "манипуляции" сервера, но уже в совершенно других файлах. Этому же потоку можно поручить запуск внешнего архиватора, если нужно.
Но, повторю, решение за Пашей...

 Отправлено: 16.01.12 22:53. Заголовок: По поводу копировани..

По поводу копирования всех изменений - проще использовать зеркалирование средствами ОС. Но только для архивации включать зеркалирование не хотелось бы.
А по поводу 2-го прохода. Это letodb открывает файл монопольно. Но предполагается, что клиенты окрывают файлы в режиме разделения через letodb. И утилита архивирования может открыть их через letodb в режиме разделения. Перед copy to можно выдать fillock, другие клиенты при копировании гарантированно файл не изменят. А после копирования файл конечно будет закрыт, и архиватор будет иметь дело уже с созданной копией.
Узкое место: во время 1-го прохода при работе архиватора letodb не сможет открыть файл, открытый архиватором. Или успеет открыть файл до того, как его откроет архиватор.
Во время 2-го прохода может не сработает fillock. Но тут останется только ждать по таймауту.

Еще вариант: можно, возложить архивацию на сам letodb, используя библиотеку работы с zip. В этом случае можно архивировать и открытые файлы, по файловому хэндлу. Но при этом сервер будет загружен несвойственными ему функциями, что мне не очень нравится.

 Отправлено: 16.01.12 23:09. Заголовок: Интересно а куда исч..

Интересно а куда исчез alkresin Саша Кресин ?

 Отправлено: 16.01.12 23:16. Заголовок: Pasha пишет: Еще ва..

Pasha пишет:

цитата:

Еще вариант: можно, возложить архивацию на сам letodb, используя библиотеку работы с zip. В этом случае можно архивировать и открытые файлы, по файловому хэндлу. Но при этом сервер будет загружен несвойственными ему функциями, что мне не очень нравится.

Как по мне, то это будет более приемлемый и рабочий вариант, т.к. архивирование происходит по требованию или допустим раз в сутки, а если понадобится раз в десять минут на протяжении двух часов, то вынужденная мера заставит и сервер нагрузить, и на звонки не отвечать, и потерпеть. И организовано будет все своими средствами, без привлечения сторонних программ.

 Отправлено: 16.01.12 23:18. Заголовок: Dima пишет: Интерес..

Dima пишет:

цитата:

Интересно а куда исчез alkresin Саша Кресин ?

Тоже интересно, в том году пробовал писать ему - молчит.

 Отправлено: 16.01.12 23:20. Заголовок: AlexMyr пишет: Тоже..

AlexMyr пишет:

цитата:

Тоже интересно, в том году пробовал писать ему - молчит.

Он всегда очень живо реагировал на любые изменения в LetoDB и тут бац
и пропал. Надеюсь с ним все хорошо !?!!

 Отправлено: 17.01.12 00:05. Заголовок: Pasha пишет: Еще ва..

Pasha пишет:

цитата:

Еще вариант: можно, возложить архивацию на сам letodb, используя библиотеку работы с zip. В этом случае можно архивировать и открытые файлы, по файловому хэндлу. Но при этом сервер будет загружен несвойственными ему функциями, что мне не очень нравится.

Ну, вообще, изготовление бэкапа вполне традиционное занятие для db-серверов. А как сейчас обстоят дела в лето с транзакциями? Есть ли snapshot-транзакции? Если нет, то по любому сервер останавливать, иначе целостного бэкапа не сделать вроде...

 Отправлено: 17.01.12 09:55. Заголовок: snapshot-транзакции ..

snapshot-транзакции не поддерживаются, есть только read commited

 Отправлено: 17.01.12 10:37. Заголовок: Pasha пишет: snapsh..

Pasha пишет:

цитата:

snapshot-транзакции не поддерживаются, есть только read commited

Тогда очевидно, что сервер надо стопить. При этом ещё либо дождаться завершения всех активных транзакций, либо все их насильно откатить, не допуская, естественно, старта новых.

В противном случае получим нарушение целостности данных. Бэкап не увидит данные некой транзакции X, при проходе одной таблицы, а при проходе другой таблицы транзакция X уже закоммитится и ее данные попадут в бэкап частично.

 Отправлено: 17.01.12 16:18. Заголовок: Бэкап (архив) базы -..

Бэкап (архив) базы - это критическая операция, её желательно делать, когда пользователи не работают в базе . Возможны варианты: копирование не файлов, а записей которые были изменены во время работы до операции копирования.