Лучшая стратегия репликации сервера горячего / теплого резервного копирования (SQL Server 2005) - PullRequest
3 голосов
/ 05 марта 2009

У меня есть два идентичных сервера с SQL Server 2005 и моим приложением.

Жесткие требования:

  1. Я должен иметь возможность обновлять данные на любом сервере.
  2. Я должен иметь возможность отключить любой сервер без необходимости что-либо переконфигурировать в базе данных.
  3. Когда сервер снова подключен, он должен автоматически синхронизироваться с другим сервером.

Примечания:

  1. Я предпочитаю варианты, которые не добавят значительную нагрузку на основной сервер, если это возможно.
  2. Два сервера имеют частную сеть для репликации, поэтому пропускная способность не является проблемой.
  3. Это нормально, если данные на любом сервере устарели на несколько минут.

Из того, что я прочитал, мои варианты:

  • Транзакционная репликация с обновляемыми подписками (обновление в очереди)
  • Репликация слиянием

Какая конфигурация лучше всего соответствует моим требованиям?

Ответы [ 2 ]

1 голос
/ 09 марта 2009

Ни одна из текущих опций не допускает возможность записи на оба сервера. Практически единственным вариантом будет репликация слиянием, поскольку это позволяет обновлять оба сервера.

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

Доставка журналов и зеркалирование не позволяют обновить вторичный сервер.

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

Рассматривали ли вы доставку журналов?

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

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

Если вы хотите, чтобы резервный ресурс был обновлен до 100%, вам нужно решение, которое синхронизирует каждую транзакцию - это будет распределенный коммит.

Но если вы собираетесь отправить Standby через FedEx и можете форсировать процесс (т. Е. Отправить «окончательный» журнал) до его отключения, это должно сработать; или, если он только что отключился, FedEx'd, а затем возвращается "онлайн", доставка журналов должна просто возобновиться с того места, где она остановилась; затем, когда вы сделаете его Первичным, оно будет таким же «свежим», как и последний полученный журнал.

...