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

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

 Отправлено: 18.01.12 20:32. Заголовок: Петр пишет: А что о..

Петр пишет:

цитата:

А что от поддержки xHarbour уже отказались полностью?

Я не знаю. Паша рулит.

 Отправлено: 18.01.12 23:29. Заголовок: Петр пишет: А что о..

Петр пишет:

цитата:

А что от поддержки xHarbour уже отказались полностью?

Сервер собрать можно только под Harbour, а клиент - и под xHarbour, и под Harbour

 Отправлено: 18.01.12 23:37. Заголовок: PSP пишет: 1. Серве..

PSP пишет:

цитата:

1. Сервер при любой операции (добавление, удаление, изменение) с записями отражает факт операции в отдельном логе, где указывается тип операции, идентификатор файла, номер записи и значение изменяемых полей, если нужно. 2. Существуют файлы-копии в отдельной папке, в которые посредством отдельного потока того же сервера записываются последовательно те же изменения, которые внесены в лог. В каждой операции указан номер записи основного файла, изменения которой нужно сохранить. Переход в файлах-копиях осуществляется по номерам записей, т.е. достаточно быстро и отпадает необходимость в индексах. Алгоритм обработки лога нужно продумывать, чтобы он не раздувался безмерно. Обработка лога происходит либо с определенным интервалом, либо "на лету" (тоже нужно продумывать пробовать, чтобы не увеличивать сильно нагрузку). 3. Тот же поток, который делает копирование, может, при необходимости, запускать внешний архиватор для создания архива.

В этой схеме создание лога это явно лишнее звено. Сначала создавать лог при каждой операции, а затем его отдельно отрабатывать на зеркале. Тогда уж лучше при каждой операции update/append сразу отрабатывать ее на зеркале, в том же потоке, в котором обрабатывается основная операция, как триггер. Но такая схема будет слишком тяжеловесной.
Сейчас я не вижу, как сделать бэкап без остановки сервера. А останавливать его не получится.
Поэтому наверное прийдется делать отдельную утилиту, которая бы сначала создавала бы зеркало БД, а затем поддерживала бы это зеркало: обновляла бы изменившиеся таблицы. Ну а с зеркалом уже можно делать все что угодно.

 Отправлено: 18.01.12 23:49. Заголовок: Pasha пишет: Поэтом..

Pasha пишет:

цитата:

Поэтому наверное прийдется делать отдельную утилиту, которая бы сначала создавала бы зеркало БД, а затем поддерживала бы это зеркало: обновляла бы изменившиеся таблицы.

Снова возвращаемся к постановке задачи - как сделать снимок всех данных с сервера, с которыми можно делать, что захотим. Бег по кругу (что раньше, курица или яйца)

 Отправлено: 19.01.12 09:16. Заголовок: Паш, сервер держит ф..

Паш, сервер держит файлы открытыми. Как внешняя утилита получит к ним доступ?

 Отправлено: 19.01.12 09:46. Заголовок: PSP пишет: Паш, сер..

PSP пишет:

цитата:

Паш, сервер держит файлы открытыми. Как внешняя утилита получит к ним доступ?

Внешняя утилита естественно будет открывать эти файлы тоже через letodb.
Я думаю, она будет хранить таблицу, когда и какие файлы копировались (дата, размер).
Если обнаружится, что файлы обновились, она их откроет, и дальше copy to.
Перед копированием можно сделать попытку выдать FilLock.
При таком способе, конечно, гарантии целостной копии не будет. Но без останова сервера сейчас это сделать нельзя.
А с остановом - это задача совершенно тривиальная, но бесполезная.

 Отправлено: 19.01.12 09:46. Заголовок: В момент инициации б..

В момент инициации бэкап Лето приостанавливает работу до окончания начавшихся транзакций, снимает размеры всех баз - это и будет "снимок БД". Лето начинает писать данные в "журнал изменеий". причем в журнал пишется только корректировка. Добавляемые записи не пишутся Для текущей работы берутся и основные базы, и журналы. , основываясь на размерах файлов БД. ЛЕТО выполняет бэкап только тех записей, которые попали в снимок. После окончания бэкапа журналы переносятся в основную БД. Сложно конечно, может и подтормаживать будет, но зато не надо останавливать сервер.

 Отправлено: 19.01.12 09:50. Заголовок: А может в журнал пис..

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

 Отправлено: 19.01.12 09:55. Заголовок: Можно поконкретней п..

Можно поконкретней про:
nick_mi пишет:

цитата:

нимает размеры всех баз - это и будет "снимок БД"

и про
nick_mi пишет:

цитата:

ЕТО выполняет бэкап только тех записей, которые попали в снимок.

и что такое:
nick_mi пишет:

цитата:

После окончания бэкапа журналы переносятся в основную БД.

 Отправлено: 19.01.12 10:03. Заголовок: 1 Средствами ОС снят..

1 Средствами ОС снять размеры файлов. Я думаю, задержка реакции Лето на запросі не будет очень длинной.
2. Пересчитать максимальную запись, имея размер файла не составит труда. в бэкап писать только записи <= максимальной рассчитаной.
3. В свете последнего уточнения журнал, естественно, возвращать в основную БД не требуется.

 Отправлено: 19.01.12 10:22. Заголовок: Еще вариант, с внешн..

Еще вариант, с внешней утилитой и логом:
1. Сервер ведет лог изменений. Лог открыт монопольно, в него пишутся только алиас и номер изменившейся записи.
2. Запускается (по расписанию) внешняя утилита (назовем ее "Бэкап"), обращается к серверу (можно выставить какой-нибудь мьютекс), что она хочет обработать лог, продолжая пытаться отрыть файл лога.
3. Сервер заканчивает обрабатывать все транзакции, закрывает текущий лог, открывает новый и продолжает работать.
4. Бэкапу удается открыть старый лог, он его обрабатывает, копирует нужные записи, не мешая серверу работать. После окончания удаляет старый лог.
и т.д.

 Отправлено: 19.01.12 10:25. Заголовок: nick_mi пишет: В мо..

nick_mi пишет:

цитата:

В момент инициации бэкап Лето приостанавливает работу до окончания начавшихся транзакций

Кстати, это мысль.
Я собирался добавить на сервере такую фичу: временный запрет соединений, когда открытые соединения остаются, а новые блокируются.
Это необходимо при профилактических работах на сервере, если его надо аккуратно остановить. Оповестить открытые коннекты о необходимости закрытия, и не допускать новые.
Так же можно сделать временный запрет блокировок. Утилита архивации даст такую команду, и будет опрашивать, есть ли открытые блокировки.
Когда их не будет, она отработает обновление зеркала, и вновь откроет блокировки.

 Отправлено: 19.01.12 10:42. Заголовок: Pasha пишет: nick_m..

Pasha пишет:

цитата:

nick_mi пишет: цитата: В момент инициации бэкап Лето приостанавливает работу до окончания начавшихся транзакций Кстати, это мысль.

Паша, такой вариант я предлагал
AlexMyr пишет:

цитата:

Может использовать какой-то флаг (типа safety car), до флага все транзакции отрабатывают, а которые появились после флага становятся в очередь и ждут когда флаг уйдет с трассы, а в момент когда перед флагом место пусто (нет транзакций) запускается архивирование, флаг обнуляется, пошла нормальная работа. Как такой вариант?

 Отправлено: 19.01.12 13:10. Заголовок: Pasha пишет: Оповес..

Pasha пишет:

цитата:

Оповестить открытые коннекты о необходимости закрытия, и не допускать новые.

Паш, но это же и есть остановка сервера. Но ты же сам говоришь:

Pasha пишет:

цитата:

Сейчас я не вижу, как сделать бэкап без остановки сервера. А останавливать его не получится.

ADS-ный бэкап так и работает, ссылка, выше. Недопускает новые коннекты, ждет завершения старых. Интересно только, что если "не дожидается", то вываливается с ошибкой тайм-аута :)

 Отправлено: 19.01.12 13:22. Заголовок: Sergey Spirin пишет:..

Sergey Spirin пишет:

цитата:

Интересно только, что если "не дожидается", то вываливается с ошибкой тайм-аута :)

Наверное просит сделать попытку позже.
Раскручу свой вариант еще: бэкап ждет некоторое время пока завершатся транзакции, если не дождался, делается следующая попытка дождаться, пропустив транзакции, к-е нервничают и так какое-то количество раз, если за отведенное количество не дождался, то завершаем попытки и выдаем сообщение "попробовать позже", если же дождался, то делаем бэкап, и продолжаем работу. Я так вижу процесс бэкапа в данный момент

 Отправлено: 19.01.12 13:27. Заголовок: AlexMyr пишет: Я та..

AlexMyr пишет:

цитата:

Я так вижу процесс бэкапа в данный момент

Ты ссылку http://devzone.advantagedatabase.com/dz/content.aspx?Key=17&RefNo=090521-2178 посмотрел?

Просто точно повторил ADS-ный вариант Сколько ждать в скольких попытках еще и параметризуется.

 Отправлено: 19.01.12 13:33. Заголовок: Sergey Spirin пишет:..

Sergey Spirin пишет:

цитата:

Pasha пишет: цитата: Оповестить открытые коннекты о необходимости закрытия, и не допускать новые. Паш, но это же и есть остановка сервера. Но ты же сам говоришь:

Нет, при этом все соединения останутся живые, только они на время бэкапа не смогут выполнять операции на обновление БД.
А на чтение данных - смогут.

 Отправлено: 19.01.12 13:35. Заголовок: Еще про роль бэкапа,..

Еще про роль бэкапа, у меня для 1с каждый день в 22:00 делается архивирование с помощью arc в файл вида storageYYYYMMDD, получается новый архив содержит на один день больше работы данных чем предыдущий, и когда что-то идет не так я могу развернуть архив за любой день и посмотреть что было до внештатной ситуации.
Так что по мне лучше один раз притормозить сервер, чем постоянно следить за изменениями.
Решать конечно Паше

 Отправлено: 19.01.12 13:38. Заголовок: Sergey Spirin пишет:..

Sergey Spirin пишет:

цитата:

Ты ссылку http://devzone.advantagedatabase.com/dz/content.aspx?Key=17&RefNo=090521-2178 посмотрел? Просто точно повторил ADS-ный вариант Сколько ждать в скольких попытках еще и параметризуется.

Нет, не заходил, только смотрел это
Dima пишет:

цитата:

Да вроде есть такой механизм начиная с версии 8 http://www.hotsoft.ru/ADS/ads_80.htm

 Отправлено: 19.01.12 13:40. Заголовок: Я все-таки возвращаю..

Я все-таки возвращаюсь к варианту, который я предложил. Приостановка сервера на время, пока делается "снимок БД", я думаю, это не долго, все зависит конечно от БД, далее пользователи работают, как и работали, параллельно идет бэкап, измененные записи затем накрываются из журнала БЫЛО. Возможно, он немного сложнее по реализации, но даст возможность пользователям работать паралельно с бэкапом.