AlwaysOn работает поверх failover cluster'а. В чём отличие:
«Классический» кластер обеспечивает высокую доступность группы ресурсов, в которую входят сервисы SQL Server и общее для узлов хранилище с файлами БД. При отказе основного узла на резервном запускаются сервисы SQL Server, которые обрабатывают файлы БД так же, как при каждом старте (rollforward/rollback) по журналу с диска. Это занимает время.
«AlwaysOn» кластер обеспечивает высокую доступность listener'а, к которому подключаются клиенты. SQL Server запущен на всех узлах, поддерживающих Availability Group. При отказе основного узла переключение на резервный происходит практически со скоростью переноса IP-адреса. Приведение БД в консистентное состояние проходит быстро по данным журнала в памяти.
Активные (на момент сбоя) транзакции теряются в обоих случаях.
Но есть подозрение, что сессии, открытые для чтения (ApplicationIntent=ReadOnly), и работавшие с резервным узлом, могут спокойно продолжать себе работать
Добавлю к каше масла :-). Достаточно попробовать написать schema bound view или функцию в MSSQL, где обязательно указывать имя схемы. И будет не User.Name, а MySchema.User.Name для каждого поля. А ещё табличка с пробелом в названии. Вроде dbo.[Order Details].ProductID. Короткие алиасы весь этот визуальный шум убирают.
И при изменении структуры БД удобнее рефакторить — меньше изменений делать нужно.
https://www.deadmansswitch.net/?
«Классический» кластер обеспечивает высокую доступность группы ресурсов, в которую входят сервисы SQL Server и общее для узлов хранилище с файлами БД. При отказе основного узла на резервном запускаются сервисы SQL Server, которые обрабатывают файлы БД так же, как при каждом старте (rollforward/rollback) по журналу с диска. Это занимает время.
«AlwaysOn» кластер обеспечивает высокую доступность listener'а, к которому подключаются клиенты. SQL Server запущен на всех узлах, поддерживающих Availability Group. При отказе основного узла переключение на резервный происходит практически со скоростью переноса IP-адреса. Приведение БД в консистентное состояние проходит быстро по данным журнала в памяти.
Активные (на момент сбоя) транзакции теряются в обоих случаях.
Но есть подозрение, что сессии, открытые для чтения (ApplicationIntent=ReadOnly), и работавшие с резервным узлом, могут спокойно продолжать себе работать
И при изменении структуры БД удобнее рефакторить — меньше изменений делать нужно.