Форум » LetoDB, HbNetio. » Архивация в letodb » Ответить
Архивация в letodb
Pasha: Хочу посоветоваться. Задача - сделать бэкап (архив) базы в произвольный момент времени. Пусть архиватор будет 7z, хотя это не принципиально. Утилита запускается на сервере, где установлен letodb, по определенному графику (хотя бы планировщиком). Входные параметры: каталог БД и список расширений файлов, которые надо поместить в архив. Предлагается такой алгоритм: сканируется все содержимое каталога БД, и формируется список @listfiles для архиватора. Если это не файл данных, он просто добавляется в список. Если это файл данных, то выполняется попытка его открыть монопольно. Если попытка успешная - файл закрывается и добавляется в список. Если нет - добавляется в список № 2 для 2-го прохода. Для 1-го прохода через run вызывается архиватор, и ему дается список файлов. Для 2-го прохода создается новый каталог, куда средствами letodb через команду copy to копируются открытые файлы, затем вызывается архиватор с командой добавления в архив файлов, которые не были заархивированы во время 1-го прохода. Какие будут идеи ?
Sergey Spirin: PSP пишет: Вот, вкратце. Можете пинать... Ну, почему пинать Но это все "техника", "способы реализации". С помощью каких механизмов что-то реализовать, тут Паше виднее. Вопрос тогда с другой стороны, а к чему этой техникой идем? "Какой бэкап" идеален с нашей общей точки зрения? Когда есть чётко сформулированная цель тогда и средства подбирать удобнее :)
Sergey Spirin: Аппаратный сбой приведет к порче бэкапа любого сервера, не думаю, что нужно принимать такую вероятность во внимание.
PSP: Sergey Spirin пишет: "Какой бэкап" идеален с нашей общей точки зрения? В общем-то да. Кому-то проще развернуть RAID-5 и 1 раз в сутки копировать файлы. Но, честно говоря, я бы не отказался от наличия в LetoDB функции бэкапа.
Sergey Spirin: PSP пишет: Но, честно говоря, я бы не отказался от наличия в LetoDB функции бэкапа. Нет-нет, я о бэкапе, зеркалирование имеет все-таки несколько другой смысл. Можно ли принять за аксиому вот такое утверждение: "Полноценный бэкап - это моментальный снимок БД на момент старта процесса бэкапа. "Снимок" включает в себя все данные закомиченные к моменту старта и не включает данные более поздних транзакций". Частичное попадание данных одной транзакции в бэкап недопустимо. ?
AlexMyr: Sergey Spirin пишет: Можно ли принять за аксиому вот такое утверждение: Скорее да, чем нет.
PSP: Sergey Spirin пишет: Можно ли принять за аксиому вот такое утверждение Думаю, можно. По-крайней мере, это утверждение довольно чётко описывает цель. Но я не знаю, как такой снимок сделать в контексте LetoDB.
Sergey Spirin: AlexMyr пишет: Скорее да, чем нет. PSP пишет: Думаю, можно. Тогда, можно ли считать аксиомой второе утверждение: "Прерывание работы сервера во время работы процесса бэкапа недопустимо". Если это аксиома, то я думаю, очевидно, что никакое внешнее средство, типа 7z, нам здесь не помошник. Но реализация такой задачи фактически сводится к реализации snapshot-транзакций в сервере Лето. Snapshot-транзакции это и есть такие транзакции, которые видят только данные существовавшие на момент их старта, ну и свои, конечно. ReadCommited-транзакции видят все закоммиченные данные и свои любые... На каких механизмах это можно реализовать Паше, конечно, лучше знать. Но мне кажется логичным, что начать надо с анализа реализации ReadCommited-транзакций, для попытки понять можно ли "вписаться" в тот же механизм. Но про механизм Паша что-то не ответил... Если же это не аксиома, а реализация snapshot-а затруднительно, то задача сводится к реализации такой остановки сервера "по команде", а чем копировать данные становится уже не так важно. Давайте определяться, аксиома ли это?
AlexMyr: Sergey Spirin пишет: Тогда, можно ли считать аксиомой второе утверждение: "Прерывание работы сервера во время работы процесса бэкапа недопустимо". Что такое прерывание работы сервера? Если сам сервер создает бэкап без использования внешних средств, это есть прерывание работы, или все таки это нужная фича сервера? И в целом, что такое актуальный бэкап, насколько он актуален через два, три часа, 15 минут, когда данные вносятся сотнями за 10, 40 минут, за сутки? Про второе утверждение, не знаю, и да, и нет.
PSP: Sergey Spirin пишет: "Прерывание работы сервера во время работы процесса бэкапа недопустимо". Это - не аксиома. Ответ зависит от конкретной задачи. Где-то "допустимо", где-то "недопустимо". Я предлагаю все-таки дождаться Пашу.
Sergey Spirin: AlexMyr пишет: Что такое прерывание работы сервера? Если сам сервер создает бэкап без использования внешних средств, это есть прерывание работы, или все таки это нужная фича сервера? Ok. Действительно, надо уточнить. Давайте "прерывание работы сервера" определим как "существенную временную паузу в обслуживании клиентских подключений и откат незавершенных транзакций, существовавших на момент прерывания". AlexMyr пишет: И в целом, что такое актуальный бэкап, насколько он актуален через два, три часа, 15 минут, когда данные вносятся сотнями за 10, 40 минут, за сутки? Ну, исходя из первого утверждения, во временном отношении, бэкап абсолютно актуален только на момент своего старта Но, мне кажется, здесь и разница с зеркалкой кроется. Не всегда, данные нужны строго актуальные. Потребность откатится часто вызвана не физическим разрушением, а логическим. И прогер, и админ, да и юзер могут такого "наколбасить", что лучше откатиться
AlexMyr: Паша, какие мысли?
PSP: Что такое snapshot-транзакция (или уровень изоляции)? Как я понимаю, сессия, для которой установлен этот уровень, будет всегда получать данные, существовавшие на момент включения этого уровня до момента отключения, независимо от того, что происходит с данными между двумя этими моментами. Но для такого варианта нужно реализовывать полноценный механизм транзакций. Думаю, для LetoDB пока это не подходит. :)
Sergey Spirin: PSP пишет: Но для такого варианта нужно реализовывать полноценный механизм транзакций. Конечно, нужен какой-то механизм. PSP пишет: Думаю, для LetoDB пока это не подходит. :) Тогда вариант с "прерыванием работы сервера" фактически единственный для реализации полноценного бэкапа... Кстати, а "родственник" ADS на dbf-ах бэкапит?
Dima: Sergey Spirin пишет: Кстати, а "родственник" ADS на dbf-ах бэкапит? Да вроде есть такой механизм начиная с версии 8 http://www.hotsoft.ru/ADS/ads_80.htm
Sergey Spirin: Dima пишет: Да вроде есть такой механизм начиная с версии 8 http://www.hotsoft.ru/ADS/ads_80.htm Да, даже вот цитата оттуда "с нами перекликается": :) All backups can be performed while the database is in use and will provide a logically correct “snapshot” of the database at the time the backup is started. То есть, принципиально это реализуемо и для dbf-ов....
PSP: Sergey Spirin пишет: То есть, принципиально это реализуемо и для dbf-ов.... Да, но бывают казусы... http://devzone.advantagedatabase.com/dz/content.aspx?Key=17&RefNo=091104-2224
Петр: Ну вы здесь и наваяли Откуда можно скачать последнюю версию Leto, посмотреть так сказать.. типа :pserver:anonymous@hwgui.cvs.sourceforge.net:/cvsroot/hwgui
PSP: Петр пишет: Ну вы здесь и наваяли cvs -d:pserver:anonymous@letodb.cvs.sourceforge.net:/cvsroot/letodb checkout -r rel-1-mt letodb
Sergey Spirin: PSP пишет: Да, но бывают казусы... http://devzone.advantagedatabase.com/dz/content.aspx?Key=17&RefNo=091104-2224 Ух ты, перешел из этого топика на другой по ссылке и обнаружил эту статью: http://devzone.advantagedatabase.com/dz/content.aspx?Key=17&RefNo=090521-2178 Где четко разъясняется, что ADS-ный бэкап работает на принципе нашего "прерывания работы сервера" Гм.. Текущие транзакции он не откатывает, а пытается ждать когда они закончатся. И если не дождется, то вываливается с ошибкой
Петр: PSP пишет: cvs -d:pserver:anonymous@letodb.cvs.sourceforge.net:/cvsroot/letodb checkout -r rel-1-mt letodb А что от поддержки xHarbour уже отказались полностью?
полная версия страницы