Russian Qt Forum
Ноябрь 15, 2024, 05:20 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 [2]   Вниз
  Печать  
Автор Тема: Синхронизация баз данных  (Прочитано 15127 раз)
crossly
Гость
« Ответ #15 : Май 21, 2010, 16:22 »

http://wm-help.net/articles/article/28.06.20063898-0.html
Записан
break
Гипер активный житель
*****
Offline Offline

Сообщений: 846


Просмотр профиля
« Ответ #16 : Май 22, 2010, 11:57 »

В одной крупной конторе где приходилось работать - была сеть магазинов по РФ и синхронизация данных из магазинных БД в общую главную БД происходила через почту. Клиентская часть в одно и то же время (вечером перед закрытием магазина) высылала письмо на главный офис с определенной темой и вложениями. Со стороны главного офиса робот получал письма правильно парсил их извлекал вложения и т.д.

Но там использовалась БД Firebird так что если процесс обновления не завершился удачно - то транзакция просто не подтверждалась, это позволяло избежать вставки двойных записей и т.д.

Кроме того робот мог еще и сам выслать письмецо с запросом каких-нибудь данных, на которое уже мог отреагировать клиент.

Почта использовалась чтобы не реализовывать самим транспорт и если письмо не дошло получать соответствующее сообщение от почтового сервера...
Записан
Prm
Гость
« Ответ #17 : Май 24, 2010, 13:20 »


Поддерживаю на все 100!!! Все уже придумано и отлажено! Кроме того, ведение бинарных журналов очень сильно пригодится при восстановлении данных после краха базы!

Записан
MrLink
Гость
« Ответ #18 : Июнь 03, 2010, 14:56 »

В одной крупной конторе где приходилось работать - была сеть магазинов по РФ и синхронизация данных из магазинных БД в общую главную БД происходила через почту. Клиентская часть в одно и то же время (вечером перед закрытием магазина) высылала письмо на главный офис с определенной темой и вложениями. Со стороны главного офиса робот получал письма правильно парсил их извлекал вложения и т.д.

Но там использовалась БД Firebird так что если процесс обновления не завершился удачно - то транзакция просто не подтверждалась, это позволяло избежать вставки двойных записей и т.д.

Кроме того робот мог еще и сам выслать письмецо с запросом каких-нибудь данных, на которое уже мог отреагировать клиент.

Почта использовалась чтобы не реализовывать самим транспорт и если письмо не дошло получать соответствующее сообщение от почтового сервера...
Я тоже делал таким же образом, но база другая. Синхронизация БД между двумя офисами. По началу делал через почту, а потом поднял VPN и написал скрипты. Синхронизировалась раз в час.
По поводу репликации MySql - тоже пробовал. Тут встаёт другой вопрос, как часто теряется связь? Настроил и оставил посмотреть, как будет происходить (один компьтер с БД периодически выключался). Через какой-то период (не засекал), базы перестали синхронизироваться и нужно было ручками лезть восстанавливать. Мне это не очень понравилось. Если это будет часто происходить - накладно.
Записан
crossly
Гость
« Ответ #19 : Июнь 03, 2010, 14:59 »

В одной крупной конторе где приходилось работать - была сеть магазинов по РФ и синхронизация данных из магазинных БД в общую главную БД происходила через почту. Клиентская часть в одно и то же время (вечером перед закрытием магазина) высылала письмо на главный офис с определенной темой и вложениями. Со стороны главного офиса робот получал письма правильно парсил их извлекал вложения и т.д.

Но там использовалась БД Firebird так что если процесс обновления не завершился удачно - то транзакция просто не подтверждалась, это позволяло избежать вставки двойных записей и т.д.

Кроме того робот мог еще и сам выслать письмецо с запросом каких-нибудь данных, на которое уже мог отреагировать клиент.

Почта использовалась чтобы не реализовывать самим транспорт и если письмо не дошло получать соответствующее сообщение от почтового сервера...
Я тоже делал таким же образом, но база другая. Синхронизация БД между двумя офисами. По началу делал через почту, а потом поднял VPN и написал скрипты. Синхронизировалась раз в час.
По поводу репликации MySql - тоже пробовал. Тут встаёт другой вопрос, как часто теряется связь? Настроил и оставил посмотреть, как будет происходить (один компьтер с БД периодически выключался). Через какой-то период (не засекал), базы перестали синхронизироваться и нужно было ручками лезть восстанавливать. Мне это не очень понравилось. Если это будет часто происходить - накладно.
доставка в и накатка журнала процедура менее ресурсоемка... т.е. нагрузка на удаленные сервер меньше...
Записан
MrLink
Гость
« Ответ #20 : Июнь 03, 2010, 15:13 »

доставка в и накатка журнала процедура менее ресурсоемка... т.е. нагрузка на удаленные сервер меньше...
Вы, наверное, более опытны в этом вопросе. Да и я по ушёл в сторону (в требованиях раз в 2-10 минут).
А как быть с установкой блокировки на таблицы (если я не ошибаюсь), если синхронизация будет падать достаточно часто? Хотя бы для пользователей основной базы - будут неудобства.
Но говорить вообще, мне понравилась такая опция - огромная масса проблем решается.
Записан
crossly
Гость
« Ответ #21 : Июнь 03, 2010, 15:31 »

при использовании репликации эти проблемы будет решать сервер.... при накатывании скриптов в принципе тоже...
к тому же блокировка только на запись... и чем чаще реплицируем тем меньше времени будет блокировка...
« Последнее редактирование: Июнь 03, 2010, 15:36 от crossly » Записан
Страниц: 1 [2]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.134 секунд. Запросов: 22.