Показаны сообщения с ярлыком AlwaysON. Показать все сообщения
Показаны сообщения с ярлыком AlwaysON. Показать все сообщения

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» с недоступностью баз, которая длилась до тех пор, пока не восстанавливалось соединение между узлами.

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

10.9.24

Как добавить несколько прослушивателей в одну группу доступности AlwaysOn

Автор: Goden Yao, Program Manager SQL Server Engine High Availability
How to create multiple listeners for same Availability Group

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

1.9.23

Новое в SQL Server 2022: Контейнерные группы доступности

В этой статье мы кратко познакомимся с контейнерными (автономными в терминологии BOL) группами доступности, которые появились в SQL Server 2022.   Подробно о них можно почитать в документации: Что такое автономная группа доступности? Также, можно почитать уже вышедшие статьи из других источников:

Это новая концепция обеспечения идентичности ограниченного набора системных объектов и сущностей, которой до этого очень недоставало. Администраторам баз данных приходилось «вручную» синхронизировать логины, задания агента, планы обслуживания и множество других системных сущностей, которые описывались в таблицах системных баз данных master и msdb. Теперь появился способ возложить это на SQL Server 2022, но ждать этой возможности нам пришлось 10 лет…

18.4.23

Высокая доступность в репликации SQL Server 2008 с зеркалированием и доставкой журналов

Статья написана по мотивам технического документа Майкрософт: "SQL Server Replication: Providing High Availability using Database Mirroring" и описания в электронной документации SQL Server 2008 Books Online (далее BOL): "Репликация и зеркальное отображение базы данных".
В этой статье мы рассмотрим новые возможности обеспечения высокой доступности тиражируемых данных, используя для этого Репликацию транзакций, Доставку журналов и зеркальные копии баз данных.
Основанная на Репликации транзакций распределённая система хранения данных может обеспечить высокую устойчивость к отказам серверов баз данных. Подобные решения позволяют достичь высокой степени доступности, за счёт поддержки избыточных копий данных. Кроме Репликации, избыточность на уровне баз данных способны обеспечить несколько механизмов SQL Server 2008. Это такие возможности, как резервное копирование с последующим восстановлением, Доставка журналов и Зеркальное отображение базы данных. Причём, Зеркальное отображение является единственным механизмом, который поддерживает точную копию защищаемой базы данных практически в реальном масштабе времени, и гарантирует отсутствие потерь данных.
В этой статье на примерах мы посмотрим, как можно использовать Зеркальное отображение реплицируемой базы данных для повышения её доступности. Мы рассмотрим как Репликация и Зеркальное отображение влияют друг на друга, а также, как Зеркальное отображение совместимо с Доставкой журналов и как Доставка журналов совместима с Репликацией. Кроме того, в этой статье мы коснёмся возможностей использования для первоначальной синхронизации баз данных механизмов Доставки журналов, и вкратце рассмотрим принципы работы инициализации подписчика, основанной на логических номерах виртуальных журналов (LSN), которая позволяет сократить время восстановления после отказа при наличии зеркальной копии базы данных Подписчика.

12.4.23

Миграция группы доступности AlwaysON в другой кластер

Миграция в новый кластер подразумевает, что для перемещаемой группы доступности необходимо создать новую первичную реплику на сервере в новом кластере. Основной целью планирования миграции группы доступности в другой кластер является минимизация времени недоступности ресурсов. Для этого ресурсы переезжают на новый, специально выделенный для этого сервер. Новый сервер вначале подключается, как вторичная реплика с синхронной фиксацией, а потом принимает на себя роль первичной реплики. Прослушиватель группы доступности удаляется из старого кластера и заново создаётся в новом кластере, вслед за созданием группы доступности.