Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

SqlServer 2005 Огранизация зеркалирования

307
07 февраля 2011 года
Artem_3A
863 / / 11.04.2008
Доброго времени суток, уважаемые.

Имею следующую задачу: необходимо организовать зеркалирование(желательно на н серверов). Имеется мссиквел сервер 2005, форточка сервер 2003.

Какие пути решение вижу:
  1. Использование стандартного зеркалирования сиквел сервера.
    Проблемы:
    • насколько я понял зеркалирование возможно лишь на один сервер(допускается одно зеркало), или я не прав?
    • в сети стоят различные версии сервера(стандарт и девелопт), что как я опять же понял не допускается, или я не прав? в принципе поставить везде стандарт можно, но обойдется мне головной болью и бумажной волокитой, а по сему рассматриваю это на крайний случай.
  • Сбор велосипеда на репликациях, тригерах или написание мини сервера, который бы предоставлял клиентам доступ к серверам, следил бы за их синхронизацией и доступностью.
    Проблема - велосипед и черт его знает как он еще работать будет.
    В связи с чем прошу поправить меня, если я где то заблуждаюсь. Так же интересно услышать ваши альтернативные предложения.
  • 385
    07 февраля 2011 года
    SomewherSomehow
    477 / / 25.07.2004
    А в общем какую задачу решаете?
    Зеркалирвоание согласно задумке предназначено в первую очередь для обеспечения "горячей замены" в случае сбоя основного сервера. Так что к чему там несколько серверов?
    Да, редакции должны быть одинаковые.
    Про несколько серверов, можно вроде использовать доставку журналов+зеркалирование. Но я этого никогда не делал, вот тут можно почитать подробнее, вдруг подойдет.
    В общем есть варианты "репликация vs доставка журналов vs зеркалироание vs их комбинации" - какой вариант подойдет вам, трудно сказать не зная общей задачи.
    8.2K
    07 февраля 2011 года
    bagie2
    299 / / 26.10.2008
    я вот когда то хорошо знал все эти подробности, но сейчас уже позабыл. насколько мне не изменяет память можно использовать SQL Standard\Enterprise для зеркалирования. Developer наверняка тоже можно, он как Enterprise, с единственным отличием, что его нельзя использовать в реальной производственной среде то есть чисто с точки зрения лицензирования.
    а доставка журналов (log shipping) доступна уже с редакции SQL Server Workgroup.
    к тому же зеркалирование работает в нескольких режимах синхронный\асинхронный и синхронный с режимом следящего (Witness) сервера или без него, роль которого может выполнять даже Express редакция.

    по ссылке что привел SomewherSomehow я не читал, но вот еще одна о чем я говорил
    307
    07 февраля 2011 года
    Artem_3A
    863 / / 11.04.2008
    В общем ситуация такая, имеется система работающая 24х7, она собирает инфу с датчиков, обрабатывает и предоставляет специалистам уже на анализ, такое слабое подобие олап системы. Физически это два сервера. Требуется зеркалировать между ними базы. Желательно н серверов так как возможно расширение для распределения нагрузки и так хочет начальник.

    В общем склоняюсь к варианту с зеркалирование + репликации + доставка журналов.

    Относительно разных версий сиквел серверов, может я что то не то делаю, но при попытки зеркалировать из девелопта в стандарт нарвался на кучу ругани по причине несоответствия версий.

    Пошел читать по сцылкам.
    5
    19 февраля 2011 года
    hardcase
    4.5K / / 09.08.2005
    А если просто сделать из этих машин кластер?
    307
    19 февраля 2011 года
    Artem_3A
    863 / / 11.04.2008
    Кластер не совсем хорошие решение.

    Во первых, масштабирование не совсем удобно финансово, каждый раз надо увеличивать кол-во серверов в два раза.

    Во вторых, не самая крутая надежность в силу того, что работают все сервера кластера от одного райдмассива и если он умирает(накрылся контроллер, аль еще чего), то все юзеры дружно идут курить бамбук, к тому же физически сервера могут стоять на довольно большом расстоянии.

    В третьих, так как физически кластер использует одну и ту же базу, то на лицо потеря производительности из за синхронизации, а значит ни о каком распределении нагрузки мечтать не стоит, конечно у нас пока в задаче речь об этом не идет, но в близлежащем будущем может и появиться.

    ЗЫ: если интересно, то постфактум решили так: зеркалируем, именно мирроринг, без смотрящего сервера, переключение делается софтово для чего на каждом сервере сидит по процессу, которые друг с другом общаются. Расширение будем делать через доставку журналов, если надо будет распределять нагрузку, то репликациями, хотя это пока что спорно, бо репликации сами по себе тормозные.
    Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
    Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог