none
Прошу помощь в настройке репликации БД. RRS feed

  • Вопрос

  • Версия SQL Server - 10.50.2789 (SQL Server 2008 R2 SP1 with CU3)

    Была поставлена задача - сделать репликацию рабочей БД, которая будет отставать на 15 минут от рабочей, с которой будут сниматься различные отчеты.

    Я сделал репликацию с помощью снимков, но при этом зеркальная БД находится в состоянии NORMAL. Она полностью доступна.  А я бы хотел перевести ее в READ-ONLY, но тогда репликация (ни один из 3-х видов в SSMS) не будет работать.

    Я слышал, что существует еще репликация с зеркалированием. Как она настраивается? БД, при таком режиме репликации, READ-ONLY?

    23 ноября 2011 г. 8:35

Ответы

  • В режиме READONLY в БД нельзя писать никакие данные. Поэтому очевидно, что репликация не может работать в таком режиме.

    Если Вы пользуетесь принципом "минимальных привилегий", то никаких проблем с тем, что БД находится в режиме MULTIUSER (Вы его называете Normal) нет. Предоставляйте разрешение только на чтение к тем объектам, которые нужны для построения отчётов.

     

    Про зеркалирование Вы можете почитать здесь: http://technet.microsoft.com/en-us/library/bb934127.aspx

    Это отдельная технология, которая в основном предназначена для построения решений высокой доступности. Теоретически можно на зеркальной БД создавать snapshot и читать из него данные, но для системы отчётности такое решение будет неудобным.

     

    • Помечено в качестве ответа Pavel Bobrovnikov 23 ноября 2011 г. 11:40
    23 ноября 2011 г. 8:55
  • log shipping

    snapshots(возможно в комбинации с миррорингом)

     

    • Помечено в качестве ответа Pavel Bobrovnikov 23 ноября 2011 г. 11:40
    23 ноября 2011 г. 8:57
  • Думаю данная статья поможет вам с выбором подхода:

    http://technet.microsoft.com/ru-ru/library/ms152565.aspx


    При этом следует учесть нагрузку, которую будет создавать передача снимков и получаемая задержка в данных (при репликации снимков). При этом репликация транзакций позволит иметь актуальные данные, но прибольшей нагрузке на исходный сервер. По поводу защиты реплики от изменения, по умолчанию, данные реплицируются только на подписчика, соответственно, даже если данные будут изменены или удалены, это не повлияет на основную базу.
    • Изменено Agapov Alexander 23 ноября 2011 г. 11:08
    • Помечено в качестве ответа Pavel Bobrovnikov 23 ноября 2011 г. 11:39
    23 ноября 2011 г. 11:02

Все ответы

  • В режиме READONLY в БД нельзя писать никакие данные. Поэтому очевидно, что репликация не может работать в таком режиме.

    Если Вы пользуетесь принципом "минимальных привилегий", то никаких проблем с тем, что БД находится в режиме MULTIUSER (Вы его называете Normal) нет. Предоставляйте разрешение только на чтение к тем объектам, которые нужны для построения отчётов.

     

    Про зеркалирование Вы можете почитать здесь: http://technet.microsoft.com/en-us/library/bb934127.aspx

    Это отдельная технология, которая в основном предназначена для построения решений высокой доступности. Теоретически можно на зеркальной БД создавать snapshot и читать из него данные, но для системы отчётности такое решение будет неудобным.

     

    • Помечено в качестве ответа Pavel Bobrovnikov 23 ноября 2011 г. 11:40
    23 ноября 2011 г. 8:55
  • log shipping

    snapshots(возможно в комбинации с миррорингом)

     

    • Помечено в качестве ответа Pavel Bobrovnikov 23 ноября 2011 г. 11:40
    23 ноября 2011 г. 8:57
  • При использовании зеркального отображения данных вторая (зеркальная) база находится в состоянии Restoring, соответственно вы не сможете с ней работать.
    23 ноября 2011 г. 9:41
  • Если все таки уйти в сторону репликации и применить метод ограничения прав пользователям со второй (зеркальной) до datareader и denydatawriter, то я думаю, стоит остановится на репликации снимками, так как при репликации транзакциями надо учитывать, что в объектах есть поле для идентификации?!
    23 ноября 2011 г. 10:12
  • Думаю данная статья поможет вам с выбором подхода:

    http://technet.microsoft.com/ru-ru/library/ms152565.aspx


    При этом следует учесть нагрузку, которую будет создавать передача снимков и получаемая задержка в данных (при репликации снимков). При этом репликация транзакций позволит иметь актуальные данные, но прибольшей нагрузке на исходный сервер. По поводу защиты реплики от изменения, по умолчанию, данные реплицируются только на подписчика, соответственно, даже если данные будут изменены или удалены, это не повлияет на основную базу.
    • Изменено Agapov Alexander 23 ноября 2011 г. 11:08
    • Помечено в качестве ответа Pavel Bobrovnikov 23 ноября 2011 г. 11:39
    23 ноября 2011 г. 11:02
  • Спасибо всем за помощь!
    23 ноября 2011 г. 11:34
  • Павел, зачем такие сложности?

    1) В кучу смешалось все, и главное, никто на это не укажет! Репликация и snapshot связаны друг с другом только тем, что sanpshot используется для изначальной синхронизации паблишера и подписчика. Всё! В данном случае ( если все работает и настроено правильно) снимок делается 1 раз!!!! и дальше на него накатываются измерения.

    2) Репликация с зеркалированием могут работать вместе, т.е две технологии используются вместе для достижения орпделенных задач. Репликации с зеркалированием ( как начальным этапом синхронизации баз ) НЕТ!

    3) для того, чтобы организовать неизменяемы снимки, _можно_ использовать зеркалирование. Процесс описан тут:

    http://technet.microsoft.com/en-us/library/ms175511.aspx

    Недостаток этого подхода - нужно приложить некоторые усилия, чтобы либо приложение знало, какой снимок "актуальный", лиюо использовать alias. Под рукой статьи нет, но это было описано на SQLCAT.com , а автор был Kevin Cox

    23 ноября 2011 г. 13:04
  • Павел, зачем такие сложности?

    1) В кучу смешалось все, и главное, никто на это не укажет! Репликация и snapshot связаны друг с другом только тем, что sanpshot используется для изначальной синхронизации паблишера и подписчика. Всё! В данном случае ( если все работает и настроено правильно) снимок делается 1 раз!!!! и дальше на него накатываются измерения.

    2) Репликация с зеркалированием могут работать вместе, т.е две технологии используются вместе для достижения орпделенных задач. Репликации с зеркалированием ( как начальным этапом синхронизации баз ) НЕТ!

    3) для того, чтобы организовать неизменяемы снимки, _можно_ использовать зеркалирование. Процесс описан тут:

    http://technet.microsoft.com/en-us/library/ms175511.aspx

    Недостаток этого подхода - нужно приложить некоторые усилия, чтобы либо приложение знало, какой снимок "актуальный", лиюо использовать alias. Под рукой статьи нет, но это было описано на SQLCAT.com , а автор был Kevin Cox

    Тут поторопился:

    "для того, чтобы организовать неизменяемы снимки, _можно_ использовать зеркалирование. Процесс описан тут:"

    должно бьло выглядеть так:

    для того, чтобы организовать неизменяемы снимки для четния с определенным интервалом времени , _можно_ использовать зеркалирование. Процесс описан тут: "

     

     

    23 ноября 2011 г. 13:08
  • Если будете пользоваться mirroring+snapshot, внимательно следите за происходящим. Там можно огрести неприятных проблем с производительностью основной базы при мирроринге в синхронном режиме и тяжёлой i/o нагрузкой на чтение из снэпшота. Это решение подкупает своей простотой, конечно, но будьте осторожны. Я от него в итоге отказываюсь в пользу log shipping. Сложнее, но прозрачнее. 

    И, конечно, всё зависит от ваших конкретных задач.

    23 ноября 2011 г. 13:20