Какова оптимальная практика для уровня доступа к базе данных отказоустойчивого кластера SQL Server?
В принципе отказоустойчивый кластер SQL Server представляет собой виртуальную машину, к которой приложения могут подключаться, не обращая внимания на тот факт, что SQL Server фактически является кластером серверов, следовательно, в принципе никакой дополнительной логики на уровне доступа к базе данных приложения не требуется.,
Мой вопрос заключается в том, верно ли вышеизложенное и существуют ли передовые практики изменения уровня доступа к БД при использовании отказоустойчивого кластера. Например, предположительно, когда происходит аварийное переключение, будет задержка, которая может вызвать ошибку тайм-аута на уровне доступа к БД, мы рассматриваем возможность размещения логики на этом уровне, чтобы повторить [некоторые] вызовы БД при наступлении тайм-аута (у нас уже есть повтор логика тупиков БД). Это обеспечивает еще один уровень защиты от ошибок, влияющих на приложение.
Если происходит переключение при сбое и в результате более высокий уровень приложения получает ошибку тайм-аута при вызове службы, то это не является бесшовным переключением. Должны ли мы просто устанавливать наши тайм-ауты на время, которое учитывает аварийное переключение?
Благодарю.
1 ответ
В принципе отказоустойчивый кластер SQL Server представляет собой виртуальную машину, к которой могут подключаться приложения, не обращая внимания на тот факт, что SQL Server фактически является кластером серверов.
А? В самом деле? Это противоречит документации. Кластер - это не что иное, как движущийся IP-адрес с разной установкой на разных серверах, вряд ли это виртуальная машина.
в принципе никакой дополнительной логики на уровне доступа к базе данных приложения не требуется.
Да и нет - сбойный узел уничтожает все текущие транзакции и соединения, очевидно, поэтому КЛИЕНТ должен иметь возможность реагировать на это и повторить попытку. Если клиент аварийно завершает работу из-за разрыва соединения и не повторяет попытку, это не поможет вам снова достичь доступности сервера через секунду или две.
Должны ли мы просто устанавливать наши тайм-ауты на время, которое учитывает аварийное переключение?
Нет, соединение прерывается при сбое, так как текущее состояние транзакции теряется. Вам необходимо восстановить соединение и затем снова запустить все команды Sql, которые были выполнены в транзакции.
Обратите внимание, с точки зрения безопасности, кластеризация плохая, и вы должны использовать зеркалирование - у вас есть определенный риск того, что отказавший узел кластера повредит файлы базы данных, и в этом случае произойдет сбой при сбое. Зеркальное отображение является более надежным.