Форум » LetoDB, HbNetio. » Архивация в letodb » Ответить
Архивация в letodb
Pasha: Хочу посоветоваться. Задача - сделать бэкап (архив) базы в произвольный момент времени. Пусть архиватор будет 7z, хотя это не принципиально. Утилита запускается на сервере, где установлен letodb, по определенному графику (хотя бы планировщиком). Входные параметры: каталог БД и список расширений файлов, которые надо поместить в архив. Предлагается такой алгоритм: сканируется все содержимое каталога БД, и формируется список @listfiles для архиватора. Если это не файл данных, он просто добавляется в список. Если это файл данных, то выполняется попытка его открыть монопольно. Если попытка успешная - файл закрывается и добавляется в список. Если нет - добавляется в список № 2 для 2-го прохода. Для 1-го прохода через run вызывается архиватор, и ему дается список файлов. Для 2-го прохода создается новый каталог, куда средствами letodb через команду copy to копируются открытые файлы, затем вызывается архиватор с командой добавления в архив файлов, которые не были заархивированы во время 1-го прохода. Какие будут идеи ?
Dima: santy пишет: Бэкап (архив) базы - это критическая операция, её желательно делать, когда пользователи не работают в базе У меня такое бывает крайне редко. Обычно это праздники. Обычно с базой идет работа 24 часа в сутки.
santy: Если база крутится постоянно, тогда нужно использовать средства сервера или специальные программы, например Effector saver 3 -Автоматическое архивирование баз данных 1С:Предприятия, произвольных данных .... Возможно ли в Letodb реализовать команды резервного копирования?
AlexMyr: Может использовать какой-то флаг (типа safety car), до флага все транзакции отрабатывают, а которые появились после флага становятся в очередь и ждут когда флаг уйдет с трассы, а в момент когда перед флагом место пусто (нет транзакций) запускается архивирование, флаг обнуляется, пошла нормальная работа. Как такой вариант?
Sergey Spirin: Dima пишет: santy пишет: цитата: Бэкап (архив) базы - это критическая операция, её желательно делать, когда пользователи не работают в базе У меня такое бывает крайне редко. Обычно это праздники. Обычно с базой идет работа 24 часа в сутки. Ну, если выбор "между двух зол", то пауза в работе сервера зло все-таки меньшее, чем неполноценный бэкап Паш, а на каких механизмах реализована поддержка транзакций в лето? Как обеспечивается одномоментность видимости всей совокупности изменений одной транзакции относительно других?
PSP: Pasha пишет: проще использовать зеркалирование средствами ОС Какими?
Pasha: PSP пишет: цитата: проще использовать зеркалирование средствами ОС Какими? Да вот хотя бы так: http://support.microsoft.com/kb/307880
PSP: Паш, там вот такой текст: [pre2]"Вы не можете создавать зеркальные тома на компьютерах под управлением Windows XP Home Edition, Windows XP Professional или Windows XP 64-Bit Edition. Однако вы можете использовать компьютер с Windows XP Professional для создания зеркальных томов на удаленных компьютерах, работающих под управлением серверных операционных систем Windows 2000 Server, Windows 2000 Advanced Server или Windows 2000 Datacenter Server."[/pre2] Только на Windows Server такое возможно. У меня же (да и у тебя, наверное) LetoDB работает на XP. А у некоторых - под Linux. Может все-таки присмотришься к моему предложению, а? Всё может делаться самим сервером, отдельным его потоком, ничего останавливать не надо, нагрузки большой, имхо, не будет, файлы (как основные, так и копия) всегда открыты монопольно, индексы для копии создавать не нужно.
AlexMyr: У меня на 98 крутится . PSP пишет: файлы (как основные, так и копия) всегда открыты монопольно, индексы для копии создавать не нужно. Я уже писал о своей проблеме, когда портится индекс и база с поврежденным заголовком, решаю ее удалением индекса и правкой базы с помощью dbedit (спасибо Паше ) - это происходит по причине пропадания питания (упс не предлагать ). Так вот, что будет с бекапом в такой ситуации и можно ли будет использовать его для восстановления для дальнейшей работы? И еще вопрос - как при PSP пишет: файлы (как основные, так и копия) всегда открыты монопольно, индексы для копии создавать не нужно. записать этот бекап на болванку, на флешку когда они открыты монопольно, север останавливать?
PSP: AlexMyr пишет: когда портится индекс и база с поврежденным заголовком, решаю ее удалением индекса и правкой базы с помощью dbedit (спасибо Паше ) - это происходит по причине пропадания питания (упс не предлагать ). Так вот, что будет с бекапом в такой ситуации и можно ли будет использовать его для восстановления для дальнейшей работы? Ну, сервер должен быть защищен бесперебойником в любом случае. А без него любой бэкап будет непригоден для использования. Даже полный бэкап от MS SQL Server, если во время его создания выключить питание. Я думаю, всё будет зависит от того, писались ли данные в бэкап в момент отключения или нет. Если не писались, то может быть он и будет исправен. Предсказать это невозможно, имхо. AlexMyr пишет: записать этот бекап на болванку, на флешку когда они открыты монопольно, север останавливать? Я уже писал, что потоку, который создает бэкап, можно также поручить периодическое архивирование в zip. А zip уже будет доступен для копирования и т.д.
AlexMyr: PSP пишет: Я уже писал, что потоку, который создает бэкап, можно также поручить периодическое архивирование в zip. А zip уже будет доступен для копирования и т.д. Так, допустим zip у нас с датой 18.01.2012 10:00, следующий будет создан через 12 часов (или через сколько?), сейчас допустим 18.01.2012 12:13 и мне надо проверить данные в архиве, как быть?
PSP: AlexMyr пишет: как быть? Можно придумать команду для сервера "Создать Архив Немедленно".
AlexMyr: PSP пишет: Можно придумать команду для сервера "Создать Архив Немедленно". Пришли к тому, о чем Паша спрашивал, вот
PSP: AlexMyr пишет: Пришли к тому, что Паша спрашивал, вот Нееее, отличия есть. Когда есть в наличии точная копия файлов базы данных, нет никакой проблемы сделать из нее zip. Даже zip делать не надо. Есть точная копия. PS. Но, всё зависит от Паши. Помочь ему в написании этого не могу, поэтому умолкаю.
Chikanuk: Pasha пишет: Пусть архиватор будет 7z 7z умеет такое: -ssw (Compress files open for writing) switch Compresses files open for writing by another applications. If this switch is not set, 7-zip doesn't include such files to archive. И делать update ( -u ). Хоть после каждой записи в таблицу...
AlexMyr: Chikanuk пишет: 7z умеет такое: Проверил: C:\TEMP\>7z a -ssw rrr.7z res.dbf 7-Zip 9.22 beta Copyright (c) 1999-2011 Igor Pavlov 2011-04-18 Scanning Updating archive rrr.7z Compressing res.dbf WARNING: Процесс не может получить доступ к файлу, так как этот файл занят други м процессом. WARNINGS for files: res.dbf : Процесс не может получить доступ к файлу, так как этот файл занят друг им процессом. ---------------- WARNING: Cannot open 1 file
PSP: Chikanuk, это для файлов, открытых в для совместного доступа. Для монопольно открытых не подойдет.
Sergey Spirin: PSP пишет: Может все-таки присмотришься к моему предложению, а? Всё может делаться самим сервером, отдельным его потоком, ничего останавливать не надо, нагрузки большой, имхо, не будет, файлы (как основные, так и копия) всегда открыты монопольно, индексы для копии создавать не нужно. А сформулируй точно своё предложение, я что-то его не понимаю.
PSP: Sergey Spirin пишет: А сформулируй точно своё предложение Попробую (всё это очень сыро, разумеется)... 1. Сервер при любой операции (добавление, удаление, изменение) с записями отражает факт операции в отдельном логе, где указывается тип операции, идентификатор файла, номер записи и значение изменяемых полей, если нужно. 2. Существуют файлы-копии в отдельной папке, в которые посредством отдельного потока того же сервера записываются последовательно те же изменения, которые внесены в лог. В каждой операции указан номер записи основного файла, изменения которой нужно сохранить. Переход в файлах-копиях осуществляется по номерам записей, т.е. достаточно быстро и отпадает необходимость в индексах. Алгоритм обработки лога нужно продумывать, чтобы он не раздувался безмерно. Обработка лога происходит либо с определенным интервалом, либо "на лету" (тоже нужно продумывать пробовать, чтобы не увеличивать сильно нагрузку). 3. Тот же поток, который делает копирование, может, при необходимости, запускать внешний архиватор для создания архива. Вот, вкратце. Можете пинать...
AlexMyr: 1-й поток - идет транзакция, все успешно, 2-й поток заметил изменения и начинает архивирование и одновременно в 1-ом потоке начинается новая транзакция при которой происходит сбой вплоть до падения letodb, в результате архив получился не полным или битым. Что делать? PSP пишет: Существуют файлы-копии в отдельной папке, в которые посредством отдельного потока того же сервера записываются последовательно те же изменения, которые внесены в лог. Я правильно понимаю, что поток который делает архивирование ждет когда закончится основная транзакция?
PSP: В лог должна попадать информация только о завершенных транзакциях. Только эти изменения должны копироваться. На самом деле вариантов сбоя очень много. Нужно продумывать. PS. Тут еще нужно понимать, какой необходимый уровень безопасности данных нужен. Не стОит доводить до паранойи.
полная версия страницы