SQL Server сам по себе не поддерживает балансировку нагрузки. У вас могут быть активные / пассивные отработки отказа с помощью описанных вами механизмов (зеркальное отображение базы данных и доставка журналов), а также множество других опций, таких как кластеризация или репликация.
Начнем с двух вопросов:
- Как долго вы можете позволить себе быть внизу? (он же ваш показатель времени восстановления или RTO)
- Сколько данных вы можете позволить себе потерять? (или ваша точка восстановления, или RPO)
Чем больше времени вы можете позволить себе выйти из строя и чем больше данных вы можете позволить себе потерять, тем проще и дешевле становятся решения для внедрения. Чем меньше времени простоя и меньше данных, тем сложнее его реализовать.
Например, синхронное зеркальное отображение базы данных гарантирует, что вы никогда не потеряете транзакцию. Транзакции фиксируются на обоих серверах базы данных до того, как результат будет возвращен клиенту. К сожалению, вы испытываете довольно большое влияние на производительность при больших нагрузках, и встроенные утилиты управления минимальны - вам нужен полностью занятый администратор БД для управления подобными вещами.
С другой стороны, доставка журналов каждые 15 минут будет означать, что вы можете потерять 15 минут (или больше) данных, и может потребоваться 15-60 минут, чтобы вернуться в оперативный режим после сбоя. Тем не менее, это дешево, имеет очень низкое влияние на производительность, и его довольно легко настроить.
У меня есть RPO и RTO введение на BrentOzar.com и введение в функции SQL Server HA и DR . Если вы пройдете через это, вы будете лучше вооружены, чтобы вернуться и задать более конкретные вопросы. Надеюсь, это поможет!