![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
НЕ-сетевой обмен данными между двумя БД [D5, IB5.x, IB6.x]
mio © (2002-12-03 14:11:00)Граждане! Дано: два IB-сервера с одинаковыми по структуре базами. Найти: методику переноса данных с одного на другой ПРИ ПОМОЩИ ФАЙЛОВОГО ОБМЕНА. Сетевой MIDAS с соединениями через DCOM, сокеты и вообще через сеть заказчика не удовлетворяет. Перенос всей БД в виде GBD-файла не удовлетворяет меня.
asmith (2002-12-06 14:01:00) [1]В сети есть куча примеров генерации xml (или в текстового файла) по схеме набора данных, так что никакой привязки к структуре. Еще проще экспорт в CSV-файл.
Наталия (2002-12-06 11:53:00) [2]Ну тогда смотри
kaif © (03.12.02 14:41)
mio (2002-12-06 11:47:00) [3]М-да...
Собственно, логические проблемы репликации меня НЕ интересуют.
Я всего лишь хотел спросить про метод, которым можно быстренько залить данные из БД в xml или в текстовый файл, или в любой двоичный, а потом восстановить из него. Причем хорошо бы, чтобы метод не был привязан к стркутуре сннкретных таблиц, ибо структура БД будет еще у меня меняться...
asmith (2002-12-03 16:13:00) [4]Можно организовать такую схему:
1.Source-сервер автоматически протоколирует все изменения данных в базе в виде специального лога - в нашей реализации лог формировали треггера и писали его в отдельную таблицу
2.Приложение-publisher по расписанию соединяется с Source-сервером, считывает лог и формирует XML-посылку, содержащую в себе все измененные записи из разных таблиц (XML хорош тем, что может хранить иерархические данные, т.е. с подчиненными таблицами; кроме того он самодокументируем) - в нашей реализации publisher построен как системный сервис
3.Далее посылка транспортируется тем или иным путем к приложению-subscriber-у (подписчику) или даже нескольким (publisher ведет список адресатов и методов отсылки) - мы реализовали для себя 2 вида транспорта - удаленная репликация по HTTP протоколу и локальная в пределах локальной сети.
4.В любом случае XML-посылка падает в заданный фолдер файловой системы подписчика, подписчик является системным сервисом, мониторящим изменение содержимого этого фолдера
5.Зафиксировав изменения, подписчик выбирает последовательно полученные посылки, парсит их и формирует SQL-пакет для выполнения его на Target-сервере.
Для обеспечения надежности работы все операции следует также протоколировать, обеспечивая возможность повторной публикации при неудаче предыдущей попытки. Можно использовать другой транспорт - приносить файлы на место и просто кидать их подписчику, посылать мылом с автоматическим извлечением присоединенных XML-посылок и опять таки их киданием подписчику.
kaif (2002-12-03 14:41:00) [5]Можно делать Backup, перенос файла и Restore (база сильно сжимается при этом). Однако это только если база переносится целиком.
Наталия (2002-12-03 14:20:00) [6]www.ibase.ru
ищи по слову "репликация"
Prooksius (2002-12-03 14:20:00) [7]Полезно почитать это:
http://www.ibase.ru/develop.htm
Раздел Репликация
Можно, к примеру, генерировать скрипт для обновления базы и запускать на сервере со старой базой.