Форум » LetoDB, HbNetio. » Архивация в letodb » Ответить
Архивация в letodb
Pasha: Хочу посоветоваться. Задача - сделать бэкап (архив) базы в произвольный момент времени. Пусть архиватор будет 7z, хотя это не принципиально. Утилита запускается на сервере, где установлен letodb, по определенному графику (хотя бы планировщиком). Входные параметры: каталог БД и список расширений файлов, которые надо поместить в архив. Предлагается такой алгоритм: сканируется все содержимое каталога БД, и формируется список @listfiles для архиватора. Если это не файл данных, он просто добавляется в список. Если это файл данных, то выполняется попытка его открыть монопольно. Если попытка успешная - файл закрывается и добавляется в список. Если нет - добавляется в список № 2 для 2-го прохода. Для 1-го прохода через run вызывается архиватор, и ему дается список файлов. Для 2-го прохода создается новый каталог, куда средствами letodb через команду copy to копируются открытые файлы, затем вызывается архиватор с командой добавления в архив файлов, которые не были заархивированы во время 1-го прохода. Какие будут идеи ?
PSP: Петр пишет: А что от поддержки xHarbour уже отказались полностью? Я не знаю. Паша рулит.
Pasha: Петр пишет: А что от поддержки xHarbour уже отказались полностью? Сервер собрать можно только под Harbour, а клиент - и под xHarbour, и под Harbour
Pasha: PSP пишет: 1. Сервер при любой операции (добавление, удаление, изменение) с записями отражает факт операции в отдельном логе, где указывается тип операции, идентификатор файла, номер записи и значение изменяемых полей, если нужно. 2. Существуют файлы-копии в отдельной папке, в которые посредством отдельного потока того же сервера записываются последовательно те же изменения, которые внесены в лог. В каждой операции указан номер записи основного файла, изменения которой нужно сохранить. Переход в файлах-копиях осуществляется по номерам записей, т.е. достаточно быстро и отпадает необходимость в индексах. Алгоритм обработки лога нужно продумывать, чтобы он не раздувался безмерно. Обработка лога происходит либо с определенным интервалом, либо "на лету" (тоже нужно продумывать пробовать, чтобы не увеличивать сильно нагрузку). 3. Тот же поток, который делает копирование, может, при необходимости, запускать внешний архиватор для создания архива. В этой схеме создание лога это явно лишнее звено. Сначала создавать лог при каждой операции, а затем его отдельно отрабатывать на зеркале. Тогда уж лучше при каждой операции update/append сразу отрабатывать ее на зеркале, в том же потоке, в котором обрабатывается основная операция, как триггер. Но такая схема будет слишком тяжеловесной. Сейчас я не вижу, как сделать бэкап без остановки сервера. А останавливать его не получится. Поэтому наверное прийдется делать отдельную утилиту, которая бы сначала создавала бы зеркало БД, а затем поддерживала бы это зеркало: обновляла бы изменившиеся таблицы. Ну а с зеркалом уже можно делать все что угодно.
AlexMyr: Pasha пишет: Поэтому наверное прийдется делать отдельную утилиту, которая бы сначала создавала бы зеркало БД, а затем поддерживала бы это зеркало: обновляла бы изменившиеся таблицы. Снова возвращаемся к постановке задачи - как сделать снимок всех данных с сервера, с которыми можно делать, что захотим. Бег по кругу (что раньше, курица или яйца)
PSP: Паш, сервер держит файлы открытыми. Как внешняя утилита получит к ним доступ?
Pasha: PSP пишет: Паш, сервер держит файлы открытыми. Как внешняя утилита получит к ним доступ? Внешняя утилита естественно будет открывать эти файлы тоже через letodb. Я думаю, она будет хранить таблицу, когда и какие файлы копировались (дата, размер). Если обнаружится, что файлы обновились, она их откроет, и дальше copy to. Перед копированием можно сделать попытку выдать FilLock. При таком способе, конечно, гарантии целостной копии не будет. Но без останова сервера сейчас это сделать нельзя. А с остановом - это задача совершенно тривиальная, но бесполезная.
nick_mi: В момент инициации бэкап Лето приостанавливает работу до окончания начавшихся транзакций, снимает размеры всех баз - это и будет "снимок БД". Лето начинает писать данные в "журнал изменеий". причем в журнал пишется только корректировка. Добавляемые записи не пишутся Для текущей работы берутся и основные базы, и журналы. , основываясь на размерах файлов БД. ЛЕТО выполняет бэкап только тех записей, которые попали в снимок. После окончания бэкапа журналы переносятся в основную БД. Сложно конечно, может и подтормаживать будет, но зато не надо останавливать сервер.
nick_mi: А может в журнал писать не изменения, а предыдущее состояние - только один раз, дальнейшие корректировки этой же записи писать не надо, а при бэкапе учитывать журнал и накрывать измененные записи старыми.
AlexMyr: Можно поконкретней про: nick_mi пишет: нимает размеры всех баз - это и будет "снимок БД" и про nick_mi пишет: ЕТО выполняет бэкап только тех записей, которые попали в снимок. и что такое: nick_mi пишет: После окончания бэкапа журналы переносятся в основную БД.
nick_mi: 1 Средствами ОС снять размеры файлов. Я думаю, задержка реакции Лето на запросі не будет очень длинной. 2. Пересчитать максимальную запись, имея размер файла не составит труда. в бэкап писать только записи <= максимальной рассчитаной. 3. В свете последнего уточнения журнал, естественно, возвращать в основную БД не требуется.
PSP: Еще вариант, с внешней утилитой и логом: 1. Сервер ведет лог изменений. Лог открыт монопольно, в него пишутся только алиас и номер изменившейся записи. 2. Запускается (по расписанию) внешняя утилита (назовем ее "Бэкап"), обращается к серверу (можно выставить какой-нибудь мьютекс), что она хочет обработать лог, продолжая пытаться отрыть файл лога. 3. Сервер заканчивает обрабатывать все транзакции, закрывает текущий лог, открывает новый и продолжает работать. 4. Бэкапу удается открыть старый лог, он его обрабатывает, копирует нужные записи, не мешая серверу работать. После окончания удаляет старый лог. и т.д.
Pasha: nick_mi пишет: В момент инициации бэкап Лето приостанавливает работу до окончания начавшихся транзакций Кстати, это мысль. Я собирался добавить на сервере такую фичу: временный запрет соединений, когда открытые соединения остаются, а новые блокируются. Это необходимо при профилактических работах на сервере, если его надо аккуратно остановить. Оповестить открытые коннекты о необходимости закрытия, и не допускать новые. Так же можно сделать временный запрет блокировок. Утилита архивации даст такую команду, и будет опрашивать, есть ли открытые блокировки. Когда их не будет, она отработает обновление зеркала, и вновь откроет блокировки.
AlexMyr: Pasha пишет: nick_mi пишет: цитата: В момент инициации бэкап Лето приостанавливает работу до окончания начавшихся транзакций Кстати, это мысль. Паша, такой вариант я предлагал AlexMyr пишет: Может использовать какой-то флаг (типа safety car), до флага все транзакции отрабатывают, а которые появились после флага становятся в очередь и ждут когда флаг уйдет с трассы, а в момент когда перед флагом место пусто (нет транзакций) запускается архивирование, флаг обнуляется, пошла нормальная работа. Как такой вариант?
Sergey Spirin: Pasha пишет: Оповестить открытые коннекты о необходимости закрытия, и не допускать новые. Паш, но это же и есть остановка сервера. Но ты же сам говоришь: Pasha пишет: Сейчас я не вижу, как сделать бэкап без остановки сервера. А останавливать его не получится. ADS-ный бэкап так и работает, ссылка, выше. Недопускает новые коннекты, ждет завершения старых. Интересно только, что если "не дожидается", то вываливается с ошибкой тайм-аута :)
AlexMyr: Sergey Spirin пишет: Интересно только, что если "не дожидается", то вываливается с ошибкой тайм-аута :) Наверное просит сделать попытку позже. Раскручу свой вариант еще: бэкап ждет некоторое время пока завершатся транзакции, если не дождался, делается следующая попытка дождаться, пропустив транзакции, к-е нервничают и так какое-то количество раз, если за отведенное количество не дождался, то завершаем попытки и выдаем сообщение "попробовать позже", если же дождался, то делаем бэкап, и продолжаем работу. Я так вижу процесс бэкапа в данный момент
Sergey Spirin: AlexMyr пишет: Я так вижу процесс бэкапа в данный момент Ты ссылку http://devzone.advantagedatabase.com/dz/content.aspx?Key=17&RefNo=090521-2178 посмотрел? Просто точно повторил ADS-ный вариант Сколько ждать в скольких попытках еще и параметризуется.
Pasha: Sergey Spirin пишет: Pasha пишет: цитата: Оповестить открытые коннекты о необходимости закрытия, и не допускать новые. Паш, но это же и есть остановка сервера. Но ты же сам говоришь: Нет, при этом все соединения останутся живые, только они на время бэкапа не смогут выполнять операции на обновление БД. А на чтение данных - смогут.
AlexMyr: Еще про роль бэкапа, у меня для 1с каждый день в 22:00 делается архивирование с помощью arc в файл вида storageYYYYMMDD, получается новый архив содержит на один день больше работы данных чем предыдущий, и когда что-то идет не так я могу развернуть архив за любой день и посмотреть что было до внештатной ситуации. Так что по мне лучше один раз притормозить сервер, чем постоянно следить за изменениями. Решать конечно Паше
AlexMyr: 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
nick_mi: Я все-таки возвращаюсь к варианту, который я предложил. Приостановка сервера на время, пока делается "снимок БД", я думаю, это не долго, все зависит конечно от БД, далее пользователи работают, как и работали, параллельно идет бэкап, измененные записи затем накрываются из журнала БЫЛО. Возможно, он немного сложнее по реализации, но даст возможность пользователям работать паралельно с бэкапом.
полная версия страницы