SQL Server Простой Избыточность

Question

Я совсем новичок здесь и хотел бы попросить всех вас экспертов здесь на предпочтительный способ настройки двух серверов SQL Server (2008 R2 и выше) для простого резервирования со следующими характеристиками:

1. Есть 2 компьютера. Каждый из них будет иметь свой собственный SQL Server, а также свою собственную службу Windows, которая записывает временные данные в базу данных. Этот сервис уже имеет свой собственный простой алгоритм переключения/отказа.

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

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

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

Из моих описаний выше, я прошел через несколько текстов и прибыл в 3 возможных методов кандидата:

1. Merge Replication
2. Зеркальное
3. Дополнительные настройки программы - действительно, в крайнем случае , но в случае необходимости мне придется загрязнять руки на этом

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

Как я понимаю, метод (2) не будет работать в нашем случае, поскольку после отказа резервная БД становится «Принципалом», а первичная БД становится «зеркальной БД». Из того, что я прочитал, Mirror DB находится в автономном режиме и недоступен для доступа. Пожалуйста, обратите внимание на поведение службы Windows в (3) выше.

Что касается метода (1), я смущен относительно того, как он будет (или не будет) работать. Например, я понимаю концепцию публикации и подписки, поэтому первичная БД будет настроена как издатель, а резервной БД будет подписчиком. Чтобы объединиться, резервная БД также потребуется настроить как издатель, и наоборот. В этом случае представьте, что служба в Primary записывает данные в БД, затем публикуется в БД резервного копирования. Затем снова БД резервного копирования опубликует это обратно в первичный БД (все на основе триггеров). Кажется, здесь бесконечный цикл.

Надеюсь, мои предположения являются довольно правильными. Что мне не хватает?

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

Спасибо и с уважением.

Answer 1

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

Answer 2

Если вам действительно нужно доверие, не инвестируя много времени, я бы предложил пойти со стандартным решением, которое является database mirroring. Automatic failover работает с свидетелем машиной, которая обрабатывает связь с базой данных, поэтому клиентское приложение даже не знает, произошел ли такой сбой на сервере базы данных. Поэтому ваши заботы о точке (3) не будут

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

Надеюсь, я помог!