Существует ли возвомность зеркалирования MS SQL?

Если я правильно понял вопрос.
то это Log shipping.

еще есть Failover Clustering, но что выбрать для сценария в котором есть сервер A и пусть еще один сервер B - необходимо постоянно синхронизировать B с A и в случае выхода из строя A - B должен автоматически его заменить

Лучше Failover Clustering если можете себе позволить, если нет, то Log Shipping.

Нельзя однозначно сказать, что Failover Clustering лучше Log Shipping или наоборот. Иногда лучьше обойтись без обоих, вложив эти средства в надёжность по-другому.
Надёжность системы иужно повышать наиболее оптимальными способами, обеспечивающими максимальную отдачу за каждый ам. рубль.

Я для себя выработал шкалу используемых методов по времени простоя; это время включает ВСЁ время, в течении которого система частично или полностью функционирует не в полном объёме, ВСЁ время, в течении которого пользователь чувствует дискомфорт от того, что "что-то не так".

Вот методы, сортировка по увеличению стоимости и уменьшению времени простоя; в другом порядке применять не следует, т.к. за бОльшие деньги будет получен мизерный результат.
1. Качественная аппаратура - хорошие брэнды или хорошая сборка с тестированием по несколько месяцев на реальном софте; например, на серверах для разработчиков и тестеров (могут себе позволить только достаточно крупные компании)
2. Правильное написание и тестирование приложения
пункты 1 и 2 самые главные; позволяют достичь время простоя 10-20 суток в год; обычно это достаточно для большинства компаний, т.к. режим 24х7 нужен далеко не всем, и обычно приемлимо в нерабочее время делать перезагрузки, обновления софта, ремонты и т.д.
3. Использование отказоустойчивого оборудования - БП с гор. заменой, диски с гор. заменой и т.д. - позволяют достичь время простоя 2-10 суток в год
4. Log Shipping необходимо использовать, когда без него достигнуто время простоя примерно 2-5 суток в год; реально этот метод позволяет добится 10 часов.
5. Failover Clustering - наиболее дорогое средство для "убирания" последних часов, его необходимо использовать, когда уже достигнуто время простоя 10-20 часов в год; реально этот метод позволяет добится 2-5 часов (надёжность 99.9 - 99.98%).

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

2alexeyvg: полностью согласен - только непонимаю почему это самый дорогой способ - в принципе есть возможность поставить вместо одно 2 машины - с деньгами проблем не будет - так почему бы этого не сделать?

только непонимаю почему это самый дорогой способ - в принципе есть возможность поставить вместо одно 2 машины

Ну так стоимость оборудования умножается на 2, а реально работает только одна половина - вторая только ждет момента сбоя

А как Вам такой вариант, вообще без простоя, правда требующий трёхзвенки.
1. Два сервера с непрерывной Marge репликацией.
2. Сервер приложений, который может работать одновременно с двумя СУБД, прозрачно для клиента.
3. Клиент.

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

2Александр Гладченко: и какие у такого варианта приимущества кроме лишнего гемороя?

>funikovyuri
Ничего синхронизировать не надо