Зеркальное отображение / репликация базы данных, SQL Server 2005

Question

У меня есть два сервера баз данных под управлением SQL Server 2005 Enterprise, которые я хочу сделать одним из них в качестве сервера зеркальной базы данных.

Что мне нужно, так это; чтобы создать точную копию базы данных с основного сервера на зеркальном сервере, чтобы при отключении основного сервера мы могли переключить IP-адрес базы данных приложения на использование зеркального сервера.

Я рассмотрел функцию «зеркала» в SQL Server 2005 и на основе этой статьи:
http://aspalliance.com/1388_Database_Mirroring_in_Microsoft_SQL_Server_2005.all

К зеркальной базе данных нельзя получить прямой доступ; однако снимки зеркальной базы данных могут быть сделаны только для чтения. (Предпосылки № 4)

Так как это может быть полезно, когда я не могу получить к нему доступ, когда основной сервер не работает?

Я думал о создании обычной резервной копии на основном сервере и почасовом восстановлении на зеркальном сервере, но это довольно неэффективно (медленно), особенно если я хочу точную копию (поскольку сотни данных добавляются раз в минуту) .

Любое другое предложение?

EDIT:
Возможно, я имею в виду репликацию, а не зеркало (спасибо JP за комментарии)

Answer 1

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

Доставка журналов - это еще одна опция, которая позволяет запрашивать (только для чтения) резервную базу данных, не создавая моментальный снимок.

Answer 2

При использовании только двух SQL-серверов вам необходимо выполнить аварийное переключение вручную. Резервная база данных будет пригодна для использования после того, как вы сделаете две вещи:

1. Отключить зеркалирование на нем
2. Восстановите базу данных с помощью RECOVERY (но без файла резервной копии, это сделает базу данных пригодной для использования).

Поэтому отражение таким образом делает сцену , однако это трудно поддерживать;

Переход от резервной базы данных к основной является «болезненным», поскольку вам необходимо заново настроить полное зеркалирование с помощью резервной копии резервного сервера. Это необходимо для ускорения работы основного устройства.

Я бы порекомендовал включить в картину три SQL-сервера, которые могут выступать в качестве свидетелей. Свидетель будет следить за состоянием зеркальных баз данных. Ваш бонус; вы получите автоматическое аварийное переключение и не будете иметь проблем с переключением (и после переключения).

Если я правильно помню, следящий сервер может работать под управлением SQL Express, поэтому не требуется версия Enterprise для всех трех - только для двух, где будет происходить фактическое зеркалирование.

Дайте мне знать, если вам нужен Transact SQL для команд при сбое и «отказоустойчивости» в сценарии с двумя серверами, и я смогу их найти.

Answer 3

Ваша путаница встречается часто - существует множество способов планирования аварийного восстановления с помощью SQL Server. Я записал 10-минутное видео-руководство по вариантам аварийного восстановления SQL Server , включая доставку журналов, зеркалирование, репликацию и многое другое. Если вам нравится этот, у нас есть более длинный в Квесте под названием Техника аварийного восстановления , но этот требует регистрации.

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

Answer 4

Если я правильно понимаю ваш вопрос, вам не нужно этого делать. Существует несколько форм переключения ролей , которые вы можете использовать, чтобы ваше зеркало стало основным. Вы не меняете IP-адрес на уровне приложения, у самого кластера есть виртуальный IP-адрес, который позволяет получить доступ к данным в любой момент времени (учитывая разумное количество времени для переключения на зеркало после первичного сбоя) , Зеркало синхронизируется само по себе. :) Есть хорошие статьи здесь и здесь по кластеризации.

Редактировать: Хорошо, основываясь на комментариях, проверьте различные варианты репликация .