Active - стратегия Active DR для SQL Server 2005 - PullRequest
4 голосов
/ 11 марта 2009

Мы пытаемся разработать стратегию Active - Active DR для нашего хранилища данных объемом 6 ТБ. Наше хранилище данных имеет 40 БД, и все должно быть реплицировано в режиме реального времени.

Сайт 1: необходимо обрабатывать все ETL Сайт 2: будет обрабатывать все запросы отчетности.

  • Зеркальное отображение базы данных (не может позволить себе удалять и создавать моментальные снимки, поскольку мы не можем разорвать какие-либо соединения)
  • Тиражирование
  • Журнал доставки

Возможен переход на SQL Server 2008.

Каков наилучший способ повышения производительности и доступности?

С уважением, Nagy

Ответы [ 4 ]

2 голосов
/ 12 марта 2009

Поскольку вы не можете позволить себе сбросить активные подключения, доставка журналов тоже не вариант. Вам необходимо получить эксклюзивный доступ к базе данных для восстановления журнала. Аппаратная поддержка (SAN) будет большой помощью здесь. Я почти хотел бы видеть вас ETL на одном сервере, а затем сделать его активным сервером для отчетов и использовать другой сервер для ETL. Таким образом, у вас есть сервер отчетов без ETL-процесса и сервер ETL без отчетов, но вы меняете, какой именно на ночной? основа.

0 голосов
/ 31 марта 2009

Практически лучшим вариантом будет репликация SQL Server или какое-либо клиентское решение с использованием SQL Service Broker. Если ваши таблицы статичны и все изменения данных выполняются на одном сайте, то репликация транзакций может быть вашим лучшим выбором. Вам потребуется большой канал WAN для обработки репликации, поскольку поддерживается согласованность транзакций, даже если используется несколько потоков.

SQL Server 2008 имеет некоторые улучшения в производительности репликации, поскольку он позволяет распространять несколько потоков для распространителя, что может вам помочь.

0 голосов
/ 13 марта 2009

Одноранговая репликация транзакций , вероятно, является лучшим вариантом для вас, если вы не хотите идти по дорогому пути репликации оборудования SAN.

Это предложение практически в реальном времени, так что этого должно быть достаточно для отчетности.

0 голосов
/ 11 марта 2009

Вам нужно поговорить с поставщиком оборудования, особенно с хранилищем, чтобы узнать, предоставляют ли они какую-либо аппаратную репликацию. Глядя на объем данных, я не думаю, что программное решение будет оптимальным.

Вот как я сейчас справляюсь с 3 базами данных (11, 17 и 23 ТБ).

  1. Мы размещаем базу данных в EMC SAN.
  2. Каждые 12 часов базы данных клонируются на разных компьютерах, расположенных в одной и той же сети SAN, а затем монтируются на разных серверах. Это резервная копия на случай, если основные серверы будут подключены. Эти базы данных обычно на 12 часов отстают от основных баз данных. Мы используем их для отчетов, где мы можем жить с данными за 12 часов.
  3. Каждые 24 часа клоны из 2 копируются в другую сеть хранения данных в другом здании и монтируются. Это вторичная резервная копия. В этих базах данных мы проводим диагностику, проверки DBCC и т. Д.
  4. В общей сложности мы используем в общей сложности 9 экземпляров SQL Server Enterprise Edition (3 выпуска, 3 DR первой строки и 3 DR второй строки).
  5. Мы решили пойти по этому пути, поскольку мы могли бы жить с задержкой в ​​данных до 24 часов.

Это, безусловно, выполнимо, но это потребует значительного планирования, а также инвестиций с вашей стороны. Для нас стоимость лицензии на 9 EE была незначительной по сравнению с ценой двух сетей SAN и соединением между ними.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...