Синхронизация данных
Модератор: kdv
Синхронизация данных
Есть главный "офис" и 7 отделений, 6 из которых модифицируют одни и те же таблички, а оставшееся отделение - другие.
Необходимо обеспечить полную синхронность данных, по итогам рабочего дня.
Пока используется простейший метод синхронизации, состоящий из 2 пунктов:
1 - Запрещено ЛЮБОЕ удаление данных (т.е. инструкция DELETE)
2 - ВСЕ INSERT и UPDATE на местах логируются в текстовый файлик в виде:
запрос = 'INSERT INTO test_table VALUES (:id, :value)'
id=123
value=типа тест
... следующий запрос ...
... следующие значения переметров ...
После окончания рабочего дня все файлики пакуются и отправляются диалапом в офис, где исполняются на главной базе. После этого отправляется ответ для каждого из отделений, содержащий все файлы, кроме принятого из этого отделения.
В отделении происходит исполнение файлов из других отделений.
Итог - база синхронизированна.
В "общих" табличках для каждой записи есть код приоритета для разрешения конфликтов между отделениями. То есть указывается, которое из отделений более приоритетно для данной записи.
Вопрос: а как белые люди это делают?
Необходимо обеспечить полную синхронность данных, по итогам рабочего дня.
Пока используется простейший метод синхронизации, состоящий из 2 пунктов:
1 - Запрещено ЛЮБОЕ удаление данных (т.е. инструкция DELETE)
2 - ВСЕ INSERT и UPDATE на местах логируются в текстовый файлик в виде:
запрос = 'INSERT INTO test_table VALUES (:id, :value)'
id=123
value=типа тест
... следующий запрос ...
... следующие значения переметров ...
После окончания рабочего дня все файлики пакуются и отправляются диалапом в офис, где исполняются на главной базе. После этого отправляется ответ для каждого из отделений, содержащий все файлы, кроме принятого из этого отделения.
В отделении происходит исполнение файлов из других отделений.
Итог - база синхронизированна.
В "общих" табличках для каждой записи есть код приоритета для разрешения конфликтов между отделениями. То есть указывается, которое из отделений более приоритетно для данной записи.
Вопрос: а как белые люди это делают?
Re: Синхронизация данных
Статьи на iBase не читал? Зря.PagaN писал(а):Вопрос: а как белые люди это делают?
Если тебе никакого дополнительного функционала не требуется, подойдёт и твой способ. Только я бы не "INSERT INTO test_table VALUES (123, 'типа текст');" писал в файл, а выбросил лишний текст, и оставил бы только "I,123,'типа текст'", а скрипт строил на приёмнике. Да и вообще, журнал сразу в виде внешней таблицы вести в этом случае.
Re: Синхронизация данных
А с роллбаками що бум делать?WildSery писал(а): Да и вообще, журнал сразу в виде внешней таблицы вести в этом случае.
Re: Синхронизация данных
Перечитал собой написанное - да, выразился косноязычно. Можно, конечно, то же, что он делает сейчас - забивает на них. Но я имел в виду только пересылку данных, после выгрузки во внешнюю таблицу из журнала внутри БД.Merlin писал(а):А с роллбаками що бум делать?
А в моей репликации не используются ни журнал (кроме удалённых), ни внешние таблицы.
PagaN
как раз изобретаю свой велосипед, т.е. систему репликации, вот смотри, после окончания рабочего дня все логи пакуются и отправляются в главный офис, где исполняются на главной базе. После этого отправляется ответ для каждого из филиалов, содержащий все логи, кроме принятого из этого филиала. но тут возникает вопрос - а как проконтролировать, что выгрузка уже не происходила раньше и была ли она полной (т.е. включала в себя все логи со всех филиалов)
В логовой таблице тогда нужно вводить по полю для каждого филиала и отмечать там отправлено/неотправлено по номеру филиала? но это некрасиво или нет?
как раз изобретаю свой велосипед, т.е. систему репликации, вот смотри, после окончания рабочего дня все логи пакуются и отправляются в главный офис, где исполняются на главной базе. После этого отправляется ответ для каждого из филиалов, содержащий все логи, кроме принятого из этого филиала. но тут возникает вопрос - а как проконтролировать, что выгрузка уже не происходила раньше и была ли она полной (т.е. включала в себя все логи со всех филиалов)
В логовой таблице тогда нужно вводить по полю для каждого филиала и отмечать там отправлено/неотправлено по номеру филиала? но это некрасиво или нет?
у меня синронизация файликами раз в 10 минут каждый выгруженый и загруженый файл логируется для того чтобы
1, если что не загружать файл дважды
2, не загружать файл если он выгружен тут же
(малоли админ был пьян и скрипты переписывал)
3, по сводному отчету можно узнать не потерялись ли у нас где файлик за прошлую неделю.
1, если что не загружать файл дважды
2, не загружать файл если он выгружен тут же
(малоли админ был пьян и скрипты переписывал)
3, по сводному отчету можно узнать не потерялись ли у нас где файлик за прошлую неделю.
ну время это конечно под себя подбирать надо =) это от надобностей .av78 писал(а):Attid
ага, значит ты логируешь сами файлы репликации, а я предлагаю логировать построчно изменения, и кстати тебе не кажется что 10мин интервал - это частный случай ? ИМХО разумеется
а логируй конечно что хочешь, только размер лога разный будет, название файла это один запись, а содержание это 100. и у меня отчет можно собрать какие файлы где прошли, а с записями это было-бы зае в табличке на тысячи записей . . . да и если не дошла запись и не узнаешь ты о ней, а реплика логирования ходит с запазданием и картину всегда востановить можно.
надо будет на праздниках если скучно будет описать систему =) может kdv на доску вывесит =) .