Устранение неполадок резервного кластера

Область применения:SQL Server

В этой статье содержатся сведения о следующих проблемах:

Основные шаги по устранению неполадок

Первым шагом диагностики является проверка нового кластера. Дополнительные сведения о проверке см. в разделе Создание отказоустойчивого кластера: проверка конфигурации. Это можно завершить без прерывания работы службы, так как это не влияет на ресурсы кластера в Сети.

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

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

Как повторно проверить ваш кластер

  1. В оснастке управления отказоустойчивым кластером в дереве консоли убедитесь, что выбрано управление отказоустойчивым кластером, а затем в разделе Управление выберите Проверить конфигурацию.

  2. Следуйте инструкциям мастера по указанию серверов и тестов, а затем выполните тесты. После выполнения тестов откроется страница Сводка .

  3. На странице "Сводка " выберите "Просмотреть отчет ", чтобы просмотреть результаты теста.

    Чтобы просмотреть результаты тестов после закрытия мастера, обратитесь к %SystemRoot%\Cluster\Reports\Validation Report date and time.html, где %SystemRoot% - папка, в которой установлена операционная система (например, C:\Windows).

  4. Чтобы просмотреть статьи справки, которые помогут интерпретировать результаты, выберите дополнительные сведения о тестах проверки кластера.

Чтобы просмотреть статьи справки о проверке кластера после закрытия мастера, в оснастке отказоустойчивого кластера выберите "Справка", выберите "Разделы справки", откройте вкладку "Содержимое", разверните содержимое справки по отказоустойчивым кластерам и выберите "Проверка конфигурации отказоустойчивого кластера". После завершения работы мастера проверки результаты появятся в сводном отчете . Все выполненные тесты должны быть отмечены зеленой галочкой или в некоторых случаях желтым треугольником (предупреждение). При поиске проблемных областей (красные крестики или жёлтые вопросительные знаки), в части отчёта с итогами тестирования, выберите отдельный тест для детального просмотра. Перед устранением неполадок в SQL Server необходимо решить все проблемы, помеченные красными крестиками (X).

Установка обновлений

Установка обновлений является важной частью предотвращения проблем в системе. Полезные ссылки

Восстановление после сбоя отказоустойчивого кластера

Обычно сбой отказоустойчивого кластера является результатом одной из двух причин:

  • Сбой оборудования в одном из узлов двухузлового кластера. Такой сбой оборудования может быть вызван сбоем SCSI-контроллера или ОС.

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

    Дополнительные сведения см. в статьях «Создание нового экземпляра отказоустойчивого кластера Always On (установка)» и «Восстановление после сбоя экземпляра отказоустойчивого кластера».

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

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

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

    Дополнительные сведения см. в статьях «Создание нового экземпляра отказоустойчивого кластера Always On (установка)» и «Восстановление после сбоя экземпляра отказоустойчивого кластера».

Устранение распространенных проблем

В следующем списке приведено описание общих проблем и даны объяснения по их устранению.

Проблема. Неверное использование синтаксиса командной строки при установке SQL Server

Проблема 1. При использовании /qn переключателя из командной строки сложно диагностировать проблемы установки, так как /qn переключатель подавляет все диалоговые окна установки и сообщения об ошибках. /qn Если параметр указан, все сообщения установки, включая сообщения об ошибках, записываются в файлы журнала установки. Дополнительные сведения о файлах журнала см. в разделе "Просмотр и чтение файлов журнала установки SQL Server".

Решение 1. Используйте /qb переключатель вместо коммутатора /qn . При использовании переключателя /qb будет отображаться базовый пользовательский интерфейс на каждом шаге, включая сообщения об ошибках.

Проблема. SQL Server не может подключиться к сети после миграции на другой узел

Проблема 1. Учетные записи служб SQL Server не могут связаться с контроллером домена.

Решение 1. Проверьте журналы событий на наличие записей о проблемах сети, например о сбоях адаптеров или проблемах с DNS. Убедитесь, что вы можете отправить эхо-запрос своему контроллеру домена.

Проблема 2. Пароли учетных записей службы SQL Server не совпадают на всех узлах кластера или узел не перезапускает службу SQL Server, которая перенесена с неудачного узла.

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

Проблема. SQL Server не может получить доступ к дискам кластера

Проблема 1. Встроенное ПО или драйверы не обновляются на всех узлах.

Решение 1. Проверьте, что на всех узлах установлены правильное встроенное ПО и одинаковые версии драйверов.

Проблема 2. Узел не может восстановить диски кластера, перенесенные из узла сбоем на общем диске кластера с другой буквой диска.

Решение 2: Буквы дисков кластера должны быть одинаковыми на обоих серверах. Если они не работают, просмотрите исходную установку операционной системы и службы кластеров Microsoft (MSCS).

Проблема: сбой в работе службы SQL Server приводит к аварийному переключению

Решение: Чтобы предотвратить переключение группы SQL Server на другой узел из-за сбоя определенных служб, настройте эти службы с помощью оснастки "Администратор кластера" в Windows следующим образом:

  • Сбросьте флажок Применить к группе на вкладке Дополнительно диалогового окна Свойства полного текста . Однако, если SQL Server инициирует переключение на резервный сервер, служба полнотекстового поиска перезапускается.

Проблема. SQL Server не запускается автоматически

Решение. С помощью администратора MSCS настройте автоматический запуск отказоустойчивого кластера. Служба SQL Server должна запускаться вручную; Администратор кластера должен быть настроен в MSCS, чтобы запустить службу SQL Server. Дополнительные сведения см. в разделе Управление службами.

Проблема. Сетевое имя находится в автономном режиме, и вы не можете подключиться к SQL Server с помощью TCP/IP

Причина 1. Сбой службы DNS, в то время как ресурсы кластера настроены на использование DNS.

Решение 1. Устраните проблемы с DNS.

Причина 2. Повторяющееся имя в сети.

Решение 2. Используйте nbtstat , чтобы найти повторяющееся имя, а затем исправить проблему.

Проблема 3. SQL Server не подключается с помощью именованных каналов.

Решение 3. Для подключения через именованные каналы создайте псевдоним с помощью диспетчера конфигурации SQL Server для подключения к нужному компьютеру. Например, при использовании кластера с двумя узлами (Узел A и Узел B) и экземпляра отказоустойчивого кластера (Virtsql) с экземпляром по умолчанию подключиться к серверу, ресурс сетевого имени которого находится вне сети, можно, выполнив следующие шаги.

  1. Определите с помощью Cluster Administrator, на каком узле работает группа, содержащая экземпляр SQL Server. В этом примере это Node A.

  2. Запустите службу SQL Server на этом компьютере с помощью net start. Дополнительные сведения об использовании команды net startсм. в разделе Запуск SQL Server вручную.

  3. Запустите диспетчер конфигурации SQL Server SQL Server на узле A. Просмотрите имя канала, на котором прослушивается сервер. Это должно быть похоже на \\.\$$\VIRTSQL\pipe\sql\query.

  4. На клиентском компьютере запустите диспетчер конфигурации SQL Server.

  5. Создайте псевдоним SQLTEST1 для подключения к этому имени канала через именованные каналы. Для этого введите Node A в качестве имени сервера и измените имя \\.\pipe\$$\VIRTSQL\sql\queryканала.

  6. Подключитесь к этому экземпляру с помощью псевдонима SQLTEST1 в качестве имени сервера.

Проблема. Программа установки SQL Server на кластере завершилась с кодом ошибки 11001

Проблема: Осиротевший раздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\Clusterреестра.

Резолюция: Убедитесь, что MSSQL.X улей реестра не используется в данный момент, а затем удалите ключ кластера.

Проблема. Ошибка установки кластера: "У установщика недостаточно прав доступа к каталогу: <диск>\Microsoft SQL Server. Невозможно продолжить установку. Войдите в систему как администратор или обратитесь к системному администратору»

Выпуск: Эта ошибка вызвана общим диском SCSI, который не секционирован должным образом.

Резолюция: Создайте одну секцию на общем диске, выполнив следующие действия.

  1. Удалите данный дисковый ресурс из кластера.
  2. Удалите на этом диске все разделы.
  3. Проверьте в свойствах диска, что он является основным.
  4. Создайте один раздел на общем диске, отформатируйте диск и назначьте диску букву диска.
  5. Добавьте этот диск к кластеру с помощью администратора кластеров (cluadmin).
  6. Запустите программу установки SQL Server.

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

Выпуск: Так как координатор распределенных транзакций (MS DTC) не полностью настроен в Windows, приложения могут не заручиться ресурсами SQL Server в распределенной транзакции. Эта проблема касается связанных серверов, распределенных запросов и удаленных хранимых процедур, использующих распределенные транзакции. Дополнительные сведения о настройке MS DTC см. в разделе Перед установкой отказоустойчивой кластеризации.

Решение. Чтобы предотвратить такие проблемы, необходимо полностью включить службы MS DTC на серверах, на которых установлен SQL Server, и MS DTC настроен.

Для полного включения служб MS DTC выполните следующие шаги.

  1. На панели управления откройте Администрирование, затем Управление компьютером.

  2. В левой области управления компьютерами разверните узел "Службы и приложения" и выберите "Службы".

  3. В правой панели окна "Управление компьютером" щелкните правой кнопкой мыши Координатор распределенных транзакцийи выберите Свойства.

  4. В окне координатора распределенных транзакций выберите вкладку "Общие " и нажмите кнопку "Остановить ", чтобы остановить службу.

  5. В окне "Координатор распределенных транзакций " выберите вкладку "Вход " и задайте учетную запись NT AUTHORITY\NetworkServiceвхода.

  6. Нажмите кнопку "Применить " и "ОК ", чтобы закрыть окно координатора распределенных транзакций . Закройте окно Управление компьютером . Закройте окно Администрирование .

Проблема: агент SQL Server не может подключиться к мультиподсетевому резервному кластеру на пользовательском порте

Проблема: агент SQL Server не может подключиться к локальному ядро СУБД, когда все следующие условия выполнены:

  1. SQL Server устанавливается как экземпляр многоподсетевого резервного кластера.
  2. Отказоустойчивый экземпляр кластера является экземпляром по умолчанию.
  3. ядро СУБД слушает на фиксированном TCP-порте, отличном от стандартного 1433.
  4. агент SQL Server подключается к локальному экземпляру при запуске.

Для экземпляра отказоустойчивого кластера с несколькими подсетями первоначальное подключение агент SQL Server использует MultiSubnetFailover=Yes. Эта настройка заставляет клиента использовать TCP. Соединение не переключается на общую память или именованные каналы. Если целевой узел — (local) и порт не указан, выполняется попытка подключения к порту TCP 1433. Не удается установить соединение, если компонент ядро СУБД не прослушивает этот порт.

Вы можете увидеть в трассировке ODBC примерно следующее подключение:

DRIVER=ODBC Driver 17 for SQL Server;SERVER=(local);APP=SQLAgent - Initial Boot Probe;DATABASE=master;MultiSubnetFailover=YES;

Решение: Создать TCP-псевдоним, который направляет соединение агент SQL Server на имя виртуальной сети и настроенный TCP-порт экземпляра резервного кластера. Настройте псевдоним на каждом узле, который может размещать экземпляр резервного кластера.

Шаг 1: Подтвердите настроенный TCP-порт

  1. На активном узле откройте SQL Server Configuration Manager.
  2. Расширите конфигурацию сети SQL Server, затем выберите Протоколы для MSSQLSERVER.
  3. Откройте TCP/IP, затем выберите вкладку IP-адресов .
  4. Если Listen All установлен на Да, обратите внимание на значение TCP-порта в IPAll.
  5. Если Listen All установлен в No, обратите внимание на значение TCP-порта для каждого включённого IP-адреса, используемого экземпляром резервного кластера.
  6. Убедитесь, что журнал ошибок SQL Server содержит запись о том, что компонент ядро СУБД прослушивает ожидаемый порт.

Дополнительные сведения см. в статье "Настройка SQL Server для прослушивания определенного TCP-порта".

Шаг 2: Создайте TCP-псевдоним на каждом узле кластера

Выполните эти шаги на каждом узле, который может разместить экземпляр резервного кластера:

  1. Откройте инструмент настройки клиентского псевдонима SQL Server, который применяется к установленной версии SQL Server.
  2. Создайте новый псевдоним.
  3. В Псевдониме введите уникальное имя для локального соединения агент SQL Server. Используйте один и тот же псевдоним на каждом узле.
  4. Выберите TCP/ IP в качестве протокола.
  5. В разделе Server введите имя виртуальной сети экземпляра резервного кластера. Не вводите имя физического узла.
  6. В порте No введите фиксированный TCP-порт, указанный на шаге 1.
  7. Оставь псевдоним.

Для подробных инструкций и требований к версии см. раздел «Создать или удалить псевдоним сервера для использования клиентом».

Important

Псевдоним SQL Server — это клиентская конфигурация. Создайте идентичный псевдоним на каждом узле, который может владеть экземпляром резервного кластера. В противном случае агент SQL Server может отказать после того, как экземпляр переместится на узел, где псевдоним не настроен.

Шаг 3: Настройте агент SQL Server для использования псевдонима

  1. В SQL Server Management Studio подключитесь к экземпляру резервного кластера.
  2. В обозреватель объектов разверните экземпляр.
  3. Щелкните правой кнопкой мыши агент SQL Server, а затем выберите Свойства.
  4. В разделе «Выбрать страницу» выберите «Соединение».
  5. В Alias local host server введите имя псевдонима, созданное на шаге 2.
  6. Нажмите ОК.
  7. Перезапустите агент SQL Server.

Для получения дополнительной информации см. раздел «Установить псевдоним SQL Server для сервиса агент SQL Server».

Шаг 4: Проверьте конфигурацию

  1. Убедитесь, что агент SQL Server успешно запускается.
  2. Просмотрите журнал агент SQL Server и убедитесь, что агент подключён к предполагаемому локальному экземпляру ядро СУБД.
  3. Запустите простую задачу агент SQL Server, чтобы убедиться, что задачи могут подключиться к экземпляру.
  4. В то время, когда это не нарушит обычную бизнес-деятельность, переместите экземпляр резервного кластера на другой возможный узел владельца.
  5. Убедитесь, что агент SQL Server запускается и тестовое задание успешно выполняется на этом узле.
  6. Повторите тест для каждого возможного узла-владельца.

Использование расширенных хранимых процедур и объектов COM

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

Если эти расширенные хранимые процедуры используют компоненты COM, администратор должен зарегистрировать эти компоненты на каждом узле кластера. Чтобы компоненты COM можно было создать, сведения для их загрузки и выполнения должны содержаться в реестре активного узла. Иначе эти сведения содержатся в реестре компьютера, на котором эти компоненты COM были зарегистрированы в первый раз.

Связанный контент

  • Последнее обновление: