Форум » LetoDB, HbNetio. » Архивация в letodb » Ответить
Архивация в letodb
Pasha: Хочу посоветоваться. Задача - сделать бэкап (архив) базы в произвольный момент времени. Пусть архиватор будет 7z, хотя это не принципиально. Утилита запускается на сервере, где установлен letodb, по определенному графику (хотя бы планировщиком). Входные параметры: каталог БД и список расширений файлов, которые надо поместить в архив. Предлагается такой алгоритм: сканируется все содержимое каталога БД, и формируется список @listfiles для архиватора. Если это не файл данных, он просто добавляется в список. Если это файл данных, то выполняется попытка его открыть монопольно. Если попытка успешная - файл закрывается и добавляется в список. Если нет - добавляется в список № 2 для 2-го прохода. Для 1-го прохода через run вызывается архиватор, и ему дается список файлов. Для 2-го прохода создается новый каталог, куда средствами letodb через команду copy to копируются открытые файлы, затем вызывается архиватор с командой добавления в архив файлов, которые не были заархивированы во время 1-го прохода. Какие будут идеи ?
Pasha: AlexMyr пишет: Наверное просит сделать попытку позже. Раскручу свой вариант еще: бэкап ждет некоторое время пока завершатся транзакции, если не дождался, делается следующая попытка дождаться, пропустив транзакции, к-е нервничают и так какое-то количество раз, если за отведенное количество не дождался, то завершаем попытки и выдаем сообщение "попробовать позже", если же дождался, то делаем бэкап, и продолжаем работу. Я так вижу процесс бэкапа в данный момент Да, наверное так и надо делать. В функции блокирования блокировок (эдакая тавтология) можно задать таймаут, в течении которого будет ожидание окончания всех операций с недопущением новых. Если операции завершились - возвращать успех, иначе - отменять блокировку блокировок. А полностью выгонять всех юзеров из базы - задача непростая. Да и делать это надо для других случаев. Блокирование новых коннектов - это отдельное действие.
Sergey Spirin: Pasha пишет: Нет, при этом все соединения останутся живые, только они на время бэкапа не смогут выполнять операции на обновление БД. А на чтение данных - смогут. Ну, это вопрос просто терминологии, что считать остановкой. Полная - не совсем полная, типа А так, ADS-ный вариант, похоже, и единственный...
Pasha: Sergey Spirin пишет: Ну, это вопрос просто терминологии, что считать остановкой. Полная - не совсем полная, типа А так, ADS-ный вариант, похоже, и единственный... На запросы сервер отвечать же будет. Правда, не на все.
PSP: Паша, как это будет выглядеть для клиентской стороны?
Pasha: Думаю, так. Если речь идет о windows, то на сервере в трее будет сидеть утилитка (написанная с помощью hwgui), которая при старте считает настройки: папку БД, папку зеркала, расширения файлов, команды архивации, график. Сначала она создаст зеркало. Затем по графику она будет просыпаться, попытается блокировать сервер, обновит зеркало и запустит архивацию. В меню трея можно будет увидеть ее состояние, ну и принудительно запустить архивацию. Можно еще дать ей функции блокировки новых соединений, ну и разблокировки соответственно. Сначала надо сделать поддержку команд блокировки сервером, а потом написать утилитку.
AlexMyr: Паша, зачем графический режим (hwgui), может быть проще, как для msde утилита osql в консоли, типа так: leto_backup -Uuser -Ppw -Tpath -Iip:port Не знаю, любой юзер может делать архив или только админ, или еще разрешения давать на работу с архивом (может лишнее это, права на создание архива) ? Допустим если путь не указать куда сохранять, то создаем архив, там где запущена утилита. АйПи и порт - может у кого два сервера крутится на одной машине. Можно еще какие параметры придумать.
Pasha: Все параметры затолкаем в ini. А интерфейс можно сделать и консольный, и gui. Запускать - хоть планировщиком.
PSP: Паша, так все-таки, как частичный стоп сервера будет восприниматься клиентским приложением? К примеру, клиент был подключен, начался бэкап, а клиент делает попытку записи в базу. Что будет? И что будет, если клиентское приложение не использует Leto_BeginTransaction() и Leto_CommitTransaction()?
Pasha: PSP пишет: Паша, так все-таки, как частичный стоп сервера будет восприниматься клиентским приложением? К примеру, клиент был подключен, начался бэкап, а клиент делает попытку записи в базу. Что будет? И что будет, если клиентское приложение не использует Leto_BeginTransaction() и Leto_CommitTransaction()? Любая попытка записи в БД, с использованием транзакции или нет, связана с попыткой блокировки. И на эту попытку клиент получит наш ответ Чемберлену: Не боимся буржуазного звона, ответим на ультиматум Керзона ! НЕТ ! rlock и fillock вернет .f., после dbappend() будет neterr()
PSP: Может быть не лишним будет сделать возможность проверки, разрешено писАть или нет, чтобы не доводить до ответа на "ультиматум Керзона", а? Ну, что-нибудь типа Leto_IsTransactionAllowed() -> .T. или .F.
Pasha: Так ведь любая попытка записи должна быть связана с проверкой. Зачем еще что-то дополнительно делать ? Как учила нас nantucket 20 лет назад, надо пару секунд попытаться выполнить блокировку, а если не получится - огорчиться.
PSP: Так-то оно так... Но Leto_IsTransactionAllowed() можно использовать для проверки с целью запретить юзерам даже пытаться редактировать данные. К примеру, в условии WHEN поля GET или еще где-то, где использование RLock(), FilLock() или DBAppend() не совсем корректно.
Pasha: PSP пишет: Так-то оно так... Но Leto_IsTransactionAllowed() можно использовать для проверки с целью запретить юзерам даже пытаться редактировать данные. К примеру, в условии WHEN поля GET или еще где-то, где использование RLock(), FilLock() или DBAppend() не совсем корректно. Не возражаю. Можно остановиться на таком синтаксисе: leto_LockUpdate([<.lOnOff.>]) При наличии параметра - включить/выключить блокировку изменений При его отсутствии - вернуть текущее состояние. Только для получения этого состояния клиенту прийдется посылать отдельный запрос на сервер, и все время так его опрашивать неэффективно.
PSP: Согласен.
Pasha: Я не забыл про эту тему, просто в силу обстоятельств могу уделять letodb немного времени. Уже почти все сделал. Возник такой ньюанс: перед копировании файлов сравниваю в том числе их размер. А он может различаться у оригинала и копии на 1-2 байта, если перед этим файл копировался средствами rdd. Приходится сравнивать размер "с погрешностью" до 2-х байт
Pasha: Сбросил на CVS
PSP: Pasha пишет: у оригинала и копии на 1-2 байта А время последнего изменения одинаково в этом случае?
Pasha: PSP пишет: А время последнего изменения одинаково в этом случае? Да, одинаково. Ситуация такая. При первом запуске таблица открыта, и, letobackup, обнаруживая это, открывает ее тоже через letodb, и создает копию средствами rdd. Затем закрывает копию, и устанавливает дату-время файла как на оригинале. А размер копии отличается от оригинала на 1-2 байта. Думаю, это несмертельно. Был еще ньюанс под windows с регистром: если имя файла набрано на верхнем регистре, то dbCreate (dbfcdx) его не создавал с параметром полное имя+расширение. Пришлось имя переводить в lower case. Еще ньюанс: если установлен режим Optimize=1 aka set hardcommit off, то надо отдельно перед созданием бэкапа делать сброс буферов, иначе копия будет неактуальной.
AlexMyr: Паша, при компиляции letobackup получил: gcc.exe: error: ../../lib/mingw/librddleto.a: No such file or directory в letobackup.hbp надо -l../../lib/librddleto.a т.к. при сборке letodb библиотека rddleto создается в папке /lib Спасибо за тулзу, будем тестировать
Pasha: Спасибо, учту. Еще наверное надо сделать свой вариант функции FileCopy, и отказаться от использования hbct. FileCopy из ct использует буфер размером всего 512 байт, что маловато, и скорость копирования при этом не самая высокая.
полная версия страницы