MS SQL Server дело тонкое...

23.8.25

SQL Server 2025 Release Candidate 0 (RC0) — анонс

Автор: Venkata_Raj_Pochiraju. Announcing SQL Server 2025 Release Candidate 0 (RC0)

Мощный ИИ, усиленная безопасность и функции в режиме предварительного просмотра - SQL Server 2025 RC0 продолжает развитие после первой публичной версии-превью, вышедшей 15 мая 2025 года. Этот релиз знаменует значительный шаг вперёд, предлагая новые возможности разработки, а также важные улучшения производительности, безопасности и аналитики.

Дальше »

22.8.25

AlwaysOn Availability Groups – пошаговая настройка гибридной конфигурации

Автор: SQLYARD. SQL Always On Availability Groups – Hybrid Setup Steps

Это руководство описывает настройку отказоустойчивого кластера AlwaysOn Availability Group (AG) с двумя обычными узлами, одним узлом в Azure и использованием Azure Cloud Witness для кворума. В итоге вы получите продакшн‑кластер с автоматическим переключением на локальном уровне и DR‑репликой в облаке.

Дальше »

18.8.25

MSSQL - Workgroup and Multi-domain clusters

Автор: John Marlin. Workgroup and Multi-domain clusters in Windows Server 2016

До появления Windows Server 2016, кластер можно было создать только для компьютеров в одном домене. Начиная с Windows Server 2016 появилась возможность создания отказоустойчивого кластера без зависимостей от Active Directory. Таким образом, отказоустойчивые кластеры теперь можно создавать в следующих конфигурациях:

Однодоменные кластеры: кластеры, в которых все узлы присоединены к одному домену.
Мульти-доменные кластеры: кластеры с узлами из разных доменов.
Workgroup кластеры: кластеры с узлами, которые являются участниками рабочей группы (не присоединены к домену).

Дальше »

14.8.25

SQL Server 2022: Распределённая группа доступности без кластера

Автор: Pablo Echeverria, 14.07.2025г. SQL Server 2022 Clusterless Distributed Availability Group

У одного клиента был очень конкретный сценарий:

·        У них была группа доступности Always On с отказоустойчивым кластером Windows Server.
·        Каждый узел имел собственные диски, поэтому кворум был с использованием сетевой «шары».
·        Один узел находился в облаке, а другой был обычным сервером.
·        Сеть была нестабильной, что подтверждал агент мониторинга, который обнаружил потери связи, даже когда провайдер заверял, что проблем нет.
·        Некоторые сбои в работе сети привели к переходу кластера в состояние «resolving» с недоступностью баз, которая длилась до тех пор, пока не восстанавливалось соединение между узлами.

Однажды эти проблемы привели к повреждению операционки, когда на одном узле перестала запускаться служба кластера, а другой узел не смог принять на себя роль ведущего, потому что кластер был неисправен.

Дальше »