Как сделать репликацию MS SQL со 100+ хостами?

Question

[Azurius]

Имеем 100+ хостов раскиданных по миру с доступом в сеть Интернет со скоростями от 512Кб/с до 20 Мб/с. 1 сервер с хорошим доступом в сеть. Всё объединено в одну сеть по средствам VPN.

На каждом хосте стоит MS sql express (в основном 2005) 1 база 1,5-2Гб. Данные изменяются относительно редко.

Цель: иметь копии всех баз на сервере с актуальностью 2-3 часа.

Первая идея - 100+ Linked Servers на сервере и 100+ баз соответственно. При нескольких базах верю, что это будет работать, при всех 100+ не уверен.

Как правильно реплицировать такое количество баз данных?

Answer 1

[Борис Сёмов]

Возможно, вы просто не правильно ставите задачу, и вам надо просто пойти по пути централизации, и сделать-таки один сервер БД? (ну или два-три).

Comments

[Azurius]

К сожалению такой вариант невозможен. По большей части из-за нестабильности доступа в сеть Интернет части хостов. Даже на территории столицы РФ есть сложности (3g модемы или монополисты на территории). В меньшей части особенности софта, который потребует серьёзного вмешательства в код. Зато в Сочи всё хорошо :)

Answer 2

[Mykola Dzedzinskyi]

На всех хостах настроить cron-job по расписанию (2-3 часа), который будет кидать на нужный сервер backup'и последних изменений, там их по мере поступления распаковывать и деплоить на локальный сервер. На нем же запустить службу, которая буде информировать все другие хосты, про готовность данных. Т.е. когда все 100 бекапов задеплоятся на сервер, служба даст ответ хостам, что можно данные начинать синхронизировать, все хосты ждут этой команды, и при ее поступлении - начинать синхронизацию. Данный подход прост в реализации но нагрузка на глав.сервер будет очень большой. Можно распределить хостов на несколько серверов..

Comments

[Azurius]

Точнее делать бекапы записывая локально на хост, потом при наличии связи слать бекапы на ближайшее к серверу хранилище, потом разворачивать уже на сервере. Сопровождая всё это статистикой для отслеживания проблем. Занимаемый объём хранилища для реализации увеличится. Ну и в момент восстановления данные на сервере не доступны. Правильно идею понял?
Вроде вариант уступает репликациям, по сложности и ресурсоёмкости.
Ещё варианты?

Answer 3

[Николай Турнавиотов]

другой вариант - посчитать что будет удобнее вынести субд в облака, тот же Azure, сделать там несколько инстансов в разных регионах и синхронизировать их между собой.
и забыть про 100+ серверов

Comments

[Alexander Kind]

/me насвистывает мелодию из X-Files

@foxmuldercp, я полагаю что локальные сервера должны быть всегда доступны, вне зависимости от того есть ли доступ в интернет т.е. они юзаются каким-то локальным приложением :)

[Azurius]

Именно. Каждая потеря доступа к базе на хостах может повлечь убытки (пусть и не во всех случаях)

Answer 4

[Alexander Kind]

Добрый день,

В зависимости от сложности и кол-ва таблиц в базах я бы заморочился написанием интерфейсов выгрузки/загрузки. Я полагаю что центральный офис раздает на удаленные точки какие-то мастер данные, а обратно получает движения/транзакции. Если так - то нужно написать интерфейс для центральной базы который будет создавать для 100 точек файлы с изменениями мастер данных, раздаст их по сети, а точки уже их загрузят. И в обратном порядке - точки формируют пачки с транзакциями (изменения) и отправляют серверу, а на нем батч уже пишет все в основную БД (DWH). Т.к. незнаю бэкграунда - не претендую на правильный ответ :)

Успехов!

Comments

[Azurius]

Что-то подобное реализовано сейчас. С загрузкой/выгрузкой всеми доступными средствами. Файлы передаются через веб форму, e-mail, ftp, etc. Есть даже ещё подключенный, но не используемый модем для t-mail. Соответственно 1,5 сервера только и занимаются разбиранием всего этого, привода в единый вид и записывания в основную БД.

Пока идём по пути репликаций. На первых 10 базах как и предполагалось всё работает замечательно.

[Azurius]

Актуальность текущего подхода держится в приделах одного дня (~8 часов). В случае проблем - выявляются на следующий рабочий день. соответственно расхождение базы хоста и основной может достигнуть 2ое суток - неприятно.
Репликами сократили актуальность до 2х часов (можно быстрее, но пока не требуется) + удобный мониторинг.

[Alexander Kind]

@Azurius, было бы легче советовать если бы Вы полностью описали задачу. Цель - просто бэкап удаленных баз на основной сервер? Или Вы потом что-то еще после этого из баз выбираете? (ну не знаю, например продажи). Если первое, то репликация лучший вариант, на мой взгляд. Если второе, то репликация не подойдет - должна быть 1 база куда будут сливаться движения, а насчет обмена - можно проверять файлы на клиентах хоть каждые 5 минут - появились изменения, скачал файл (архив), накатил на DWH. Можно каждый час создавать пустые файлы на клиентах - соответственно, если сервер не получил файлов за последний час - слать алерты.. и т.п.

[Azurius]

@shineblu, Да и да. Нужны бекапы удалённых баз и данные из этих баз после определённой обработки попадают в основную и опять возвращаются на удалённые хосты. Процесс обработки и сливания в самую главную базу давно отрепетирован и мало приспособлен к кардинальным изменениям. Поэтому задача сводится к получению точной копии баз со всех 100+ хостов на отдельном сервере с актуальностью 2 часа. Вычёрпывание данных из копий выходит за приделы данного вопроса.