Есть приложение, 3-звенка, работающее в корпоративной сети.
Теперь есть необходимость в работе этого приложения не в локальной сети компании,
а в разных филиалах с минимальными изменениями сервера приложений.
В клиентских приложениях будут проводиться изменения.
Все изменения в одном городе должны быть видны клиентским приложениям в другом городе.
Есть такое вариант установки: установка в каждом филиале своей локальной БД,
а синхронизацию серверов организовать описанным ниже способом.
Теоретически, есть два варианта:
1. Linked servers (в этом случае есть всего одна база)
2. Replication (в этом случае каждый клиент имеет локальную копию БД)
В первом варианте есть много трудностей:
1. Как создать подключение к linked server в connection string ?
2. Проблемы с безопасностью, поскольку подключать головной сервер придется по IP,
а на стороне сервера делать дырку для подключения из сети.
3. Сильное падение производительности.
Второй вариант кажется более адекватным:
1. Создать главный публикующий сервер
2. Все остальные сервера приложений будут являться подписчиками и одновременно публикующими серверами.
3. Изменения приходят на главный сервер и дальше публикуются на остальные копии БД в филиалах.
Буду признателен, если кто поделится опытом, с этим я ни разу не сталкивался.
Какие есть паттерны и общепринятые практики в решении этого вопроса?
Если реализовать 2 вариант, то какие сценарии лучше всего применить
по синхронизации серверов клиентских приложений: время, разрешение конфликтов и прочее?
Доводилось делать работу с информационной системой в филиалах предприятия с использованием репликации. В центральном офисе фирмы работал MS SQL Server 2000 (редакция Standard, если я правильно помню), в филиалах — MSDE. Тип репликации — merge. Разумеется весь обмен шел поверх VPN. Если есть конкретные вопросы — задавайте, постараюсь ответить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1217>>
Re[2]: Переход к распределенной БД в разных филиалах
L>Доводилось делать работу с информационной системой в филиалах предприятия с использованием репликации. В центральном офисе фирмы работал MS SQL Server 2000 (редакция Standard, если я правильно помню), в филиалах — MSDE. Тип репликации — merge. Разумеется весь обмен шел поверх VPN. Если есть конкретные вопросы — задавайте, постараюсь ответить.
Спасибо.
Меняется ли что-либо для программиста?
По идее:
— connection string остается тем же самым — подключение к серверу приложений в домене филиала.
— вся настройка переходит в ответственность админа ( VPN и репликация )
Насколько часто оптимально делать репликацию?
Влияет ли частота репликаций на накопленные конкурентные изменения?
Конфликты в конкурирующих изменениях:
Например, в одном филиале открывается ресурс №1, во втором — ресурс №1,
клиент сохраняет, происходит репликация — как происходит разрешение конфликтов?
Думаю насчёт транзакционной репликации.
Re[3]: Переход к распределенной БД в разных филиалах
Здравствуйте, Dmdv, Вы писали:
D>Меняется ли что-либо для программиста? D>По идее: D>- connection string остается тем же самым — подключение к серверу приложений в домене филиала. D>- вся настройка переходит в ответственность админа ( VPN и репликация )
Merge-репликация добавляет ко всем реплицируемым таблицам поле типа GUID, по этому полю производится идентификация записи. Кроме того, если вы используете поля IDENTITY — надо решить как у вас будут распределяться диапазоны значений IDENTITY между филиалами — можно сделать это автоматически — в этом случае лучше заранее хорошо подумать над размерами диапазонов, плохо если они будут слишком маленькими, а можно управлять диапазонами вручную. Вроде бы все, больше ничего не припоминаю. Да и это детали, которые в общем-то программистов касаются так, краешком
D>Насколько часто оптимально делать репликацию?
Зависит от того, насколько интенсивно обновляются данные. Мы в конце концов пришли к тому, что периоды синхронизации определялись потребностями бизнеса — некоторым филиалам необходимо было, чтобы данные передавались в центральный офис каждые полчаса, некоторым было достаточно пары раз в день.
D>Влияет ли частота репликаций на накопленные конкурентные изменения?
Не уверен, что понял вопрос.
D>Конфликты в конкурирующих изменениях: D>Например, в одном филиале открывается ресурс №1, во втором — ресурс №1, D>клиент сохраняет, происходит репликация — как происходит разрешение конфликтов?
Насколько я помню, разрешение конфликтов в репликации MS SQL — большая тема. Там есть всякие настройки, есть вроде бы даже возможность написать свой резолвер конфликтов. По умолчанию, опять же насколько я помню, при возникновении конфликта этот факт фиксируется в журнале репликации и вы можете или положиться на автоматическое разрешение — оно просто считает победившим то обновление, которое произошло позже по времени, или разрешить конфликт вручную — там можно просто выбрать ту версию записи, которую следует сохранить в базе. Но в нашем случае конфликты возникали редко, т.к. бизнес-процессы на предприятии были выстроены так, что при нормальной работе каждая запись на каждом этапе работы связанной с этой записью могла обновляться только в одном месте — к примеру документ порождался в филиале, потом в этом же филиале происходило несколько правок, потом работа по нему перемещалась в центральный офис — в этот момент филиал уже править документ не мог (так была система написана, еще до того, как задумались о репликации, просто бизнес-процесс такой), и т.д. Конфликты возникали крайне редко. Я думаю во многих случаях есть возможность хотя бы частично защититься от возникновения конфликтов в репликации подобным образом, на организационном уровне. В любом случае — посмотрите документацию на сервер по этой теме.
D>Думаю насчёт транзакционной репликации.
Мы ее не особо пробовали, т.ч. ничего не могу сказать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1217>>
Re[4]: Переход к распределенной БД в разных филиалах
