Добрый день.
Встал вопрос об отказоустойчивости. Настроить отказоустойчивый кластер проблем не составило. Теперь нужно, чтобы при падении того сервера, на котором стоит SQL Server, мы могли подключить пользователей ко второму и не потерять данные. А затем после восстановления основного, вернуться обратно на него. В сети гуляет информация, что полная синхронизация для 1с невозможна из-за отсутствия ключей на регистрах. А зеркалирование ненадежно, потому что [и там куча разных тонкостей].

Есть ли всетаки надежное решение по этой теме для 1С и SQL сервер 2012?

Минимум понадобится три хоста. Один из них Always On, один резервный.

(0) Использую PostgreSQL Hot Standby, на реплике первого уровня задержка максимум несколько секунд в момент большой загрузки. Основной сервер может хоть синем пламенем сгореть, можно сразу переключаться на первую реплику и работать дальше на ней, пока ищешь железо под новый основной.

Автоматический failover для баз данных, в отличие от вычислительной части - не рекомендую. При ложном срабатывании failover объем работ по восстановлению будет в сотни раз больше объема работ по ручному переключению, особенно если несколько раз туда-сюда переключит. Есть негативный опыт в прошлом.

(0) Обычный  кластер. У нас такой пашет отлично. Никуда пользователей переключать не надо, т.к у обоих SQL хостов единое кластерное имя, и оно всегда работает, если жив хоть один из хостов.

(0) Например, настроить кластер серверов. Только уже Windows.

(3) а диски-то у этих хостов в одном ДЦ? или в разных?

(5) диски в хранилище, хранилище по MPIO подключены к контроллерам на обоих серверах. Говорю ж - стандартный кластер

(6) и что произойдет, когда экскаватор найдет кабель электроснабжения под этим хранилищем?

(7) Без разницы - пользовательские ПК питаются от этого же кабеля :)

(7) хранилище может быть не одно, и ДЦ может быть не один - всё зависит от фантазии и финансовых возможностей :)
(8) +1 :)

(8) Ну ок. Мои-то мало того, что в разных офисах все сидят, так еще и если свет в офисе выключили - ноуты похватали и побежали по домам.

(0) Настроить отказоустойчивый кластер проблем не составило. Теперь нужно, чтобы при падении того сервера, на котором стоит SQL Server, мы могли подключить пользователей ко второму и не потерять данные. А затем после восстановления основного, вернуться обратно на него


Стандартный отказоустойчивый кластер подойдет. Автор усложняет

Зеркалирование ненужно. AlwaysOn не нужен

(10) тогда просто переключатся на кластер во втором ДЦ, куда дополнительно реплицируется база. А юзера запускают резервный ярлычок RemApp-1C. Вообщем, всё упирается в фантазию и финансы. :)

Так если делать обычный кластер на SQL, то что будет при отказе дискового устройства? Я больше за сами данные переживаю, чем за сервер, физически дающий доступ к ним..

(0)Все эти отказоустойчивые технологии, на практике оказываются устойчиво отказывающими. Просто имеем второй сервер на который каждые 2 часа бэкапится и разворачивается база.
Отказоустойчивый у нас только проджект сервер и SQL server для него. Постоянно какие-то глюки в при аварийных ситуациях. Среднее время "перекидывания" около 10-15 минут. Так что, даже не скажу что чувствуется какое-то преимущество. Особенно учитывая что один сервер в кластере SQL всегда простаивает.

(13) Ничего не будет. Кластер тут вообще непричем. Просто база перестанет работать. Была такая ситуация.

(13) в любом случае - бэкапы всегда должны быть :)

(14) странно, время переключения в случае аварии - 0 секунд, время переключения в случае аварии 1 хоста кластер, затем другого, затем восстановление одного из них - примерно 30 секунд. Жопа наступает, только если какая-то проблема с хранилищем :) там - да, весь кластер падает. Кстати, мельком читал что в 2012 SQL'е, помимо отказоустойчивого кластера, можно одновременно запилить и распределённую нагрузку на оба хоста, но пока не озадачивался этим вопросом :) Кто-нить пробовал такое?