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



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



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



Я изучил функцию "зеркало" на SQL Server 2005, и на основе этого article:
http://aspalliance.com/1388_Database_Mirroring_in_Microsoft_SQL_Server_2005.all




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




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



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



Есть еще предложения?



редактировать:

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

716   4  

4 ответов:

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

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

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

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

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

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

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

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

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

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

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

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

Дайте мне знать, если вам нужен Transact SQL для команд fail-over и "anti-fail-over" в сценарии с двумя серверами, и я смогу их откопать.

Comments

    Ничего не найдено.