Подготовка базы данных для кластеризации SQL Server

Question

мы планируем внедрить кластер sql server 2005 в ближайшие несколько месяцев. Я хотел бы знать, какие шаги / меры предосторожности должны быть предприняты как разработчик базы данных, пытаясь достичь этого? нам нужно изменить какой-либо код ado.net (передний конец) / хранимые процы и т. д. и т. д.? есть ли лучшие практики, которым нужно следовать?

причина, по которой я задаю этот вопрос: для балансировки нагрузки asp.net вы должны убедиться, что ваш код для сессий / приложения / кэша соответствует среде со сбалансированной нагрузкой (если вы используете сеансы inproc, вы должны переписать этот код, чтобы он работал в среде с балансировкой нагрузки). Теперь это на уровне вашего веб-сервера. я просто хотел делать правильные вещи при попытке масштабирования на уровне сервера базы данных

Прошу прощения, если этот вопрос глупый. прошу прощения за мои ограниченные знания по этому предмету: -)

Answer 1

Для реализации кластера SQL Server не нужно вносить никаких изменений во внешний интерфейс, вы просто подключаетесь к экземпляру SQL Server как обычно.

Однако отказоустойчивая кластеризация SQL Server не является балансировкой нагрузки. Он используется для добавления избыточности в случае сбоя любого оборудования на вашем основном узле. Ваш другой (вторичный) узел ничего не делает, пока не произойдет сбой основного, в этом случае аварийное переключение происходит автоматически, и ваша база данных снова обслуживает соединения после 10-20 секундной задержки.

Другая проблема заключается в том, что кэш на вторичном узле пуст, поэтому после сбоя вы можете увидеть некоторое снижение производительности. Вы можете реализовать «теплый» кэш на своем зеркальном сервере, используя зеркальное отображение базы данных SQL Server , но с кластеризацией сделать что-то похожее не существует.

Answer 2

Кластеризация базы данных отличается от балансировки нагрузки. Это высокая доступность, а не «масштабирование»

В основном:

• 2 сервера (или узла) с общими дисками (которые могут принадлежать только одному узлу в любое время)
• один «активен», работает под управлением виртуального сервера Windows и экземпляра SQL Server
• один следит за другим («пассивный»)
• вы подключаетесь к серверу виртуальных окон.

Если узел 1 переходит в автономный режим, узел 2 вступает во владение. Или это может быть сбой вручную.

Это означает, что службы отключены на узле 1, узел 2 берет на себя управление дисками и службами и запускается. Любые соединения будут разорваны, а состояние или сеанс не будут переданы.