Предварительные требования, ограничения и рекомендации для групп доступности always on

Основы последовательного обновления для групп доступности

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

  • Перед началом последовательного обновления:

    • Выполните тестовый переход на другой ресурс вручную по крайней мере для одного из экземпляров реплик синхронной фиксации.

    • Защитите данные, выполнив полное резервное копирование базы данных на каждой базе данных доступности.

    • Запуск в каждой базе данных доступности

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

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

  • Во время обновления версии доступные для чтения вторичные файлы невозможно прочитать после обновления читаемой вторичной реплики и перед отработкой отказа первичной реплики на обновленную вторичную или обновление первичной реплики.

  • Чтобы предотвратить для групп доступности непреднамеренный переход на другой ресурс при обновлении, перед началом операции удалите на всех репликах с синхронной фиксацией конфигурацию перехода на другой ресурс для групп доступности.

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

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

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

  • Перед отработка отказа группы доступности убедитесь, что для целевого объекта отработки отказа задано состояние синхронизации .

    Предупреждение

    Установка нового экземпляра или новой версии SQL Server на сервер, на котором установлена более ранняя версия SQL Server, может случайно вызвать сбой для любой группы доступности, размещенной в более старой версии SQL Server. Это связано с тем, что во время установки экземпляра или новой версии SQL Server выполняется обновление модуля высокой доступности (RHS.EXE) для SQL Server. В результате временно прерывается работа существующих групп доступности в первичной роли на сервере. Таким образом, при установке новой версии SQL Server в системе, где уже размещена более старая версия SQL Server с группой доступности, настоятельно рекомендуется выполнить одно из следующих действий:

    • установить новую версию SQL Server во время периода обслуживания;

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

Установка координатора распределенных транзакций Майкрософт (MSDTC)

Перед установкой SQL Server в отказоустойчивом кластере определите, есть ли необходимость создания кластерного ресурса координатора распределенных транзакций ( Microsoft ) (MSDTC). Если вы устанавливаете только ядро СУБД, ресурс кластера MSDTC не требуется. Если вы устанавливаете ядро СУБД и службы SSIS, компоненты рабочей станции или используете распределенные транзакции, необходимо установить MSDTC. MSDTC не требуется для экземпляров служб Analysis Services.

В Windows Server 2008 и более поздних версиях можно установить несколько экземпляров MSDTC в одном отказоустойчивом кластере. Первым установленным экземпляром MSDTC будет экземпляр MSDTC по умолчанию для кластера. SQL Server будет автоматически использовать экземпляр MSDTC, установленный в локальной группе ресурсов кластера SQL Server . Однако отдельные приложения можно сопоставить с любым экземпляром MSDTC в кластере.

Для экземпляра MSDTC, выбираемого SQL Server, применяются следующие правила.

  • Использовать MSDTC, установленный в локальной группе, или

  • Использовать сопоставленный экземпляр MSDTC или

  • Использовать экземпляр MSDTC по умолчанию для данного кластера или

  • Использовать экземпляр MSDTC, установленный на локальном компьютере

Важно!

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

Настройте координатор распределенных транзакций ( Microsoft )

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

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

Для добавления в группу доступности база данных должна соответствовать следующим предварительным условиям и ограничениям.

В этом разделе.

Контрольный список: требования (базы данных доступности)

Для добавления в группу доступности база данных должна соответствовать следующим требованиям.

Требования Ссылка
Быть пользовательской базой данных. Системные базы данных не могут принадлежать к группе доступности.
Находиться на экземпляре SQL Server , на котором создана группа доступности, и быть доступной для экземпляра сервера.
Быть базой, доступной для чтения и записи. Базы данных только для чтения не могут быть добавлены в группу доступности. sys.databases (is_read_only = 0)
Быть многопользовательской базой данных. sys.databases (user_access = 0)
Не использовать параметр AUTO_CLOSE. sys.databases (is_auto_close_on = 0)
Используйте модель полного восстановления (также известную как режим полного восстановления). sys.databases (recovery_model = 1)
Необходима по крайней мере одна полная резервная копия базы данных. Примечание. После установки базы данных в режим полного восстановления потребуется полная резервная копия для включения цепочки журналов полного восстановления. Создание полной резервной копии базы данных (SQL Server)
Не принадлежать ни к одной другой группе доступности. sys.databases (group_database_id = NULL)
Не быть настроенной для зеркального отображения базы данных. sys.database_mirroring (если база данных не участвует в зеркальном отображении, все столбцы с префиксом «mirroring_» имеют значение NULL)
Перед добавлением в группу доступности базы данных, в которой используется FILESTREAM, следует убедиться, что FILESTREAM поддерживается на всех экземплярах серверов, на которых размещены или будут размещены реплики доступности для группы доступности. Включение и настройка FILESTREAM
Перед добавлением автономной базы данных в группу доступности убедитесь, что параметру сервера contained database authentication присвоено значение 1 на каждом экземпляре сервера, где размещена или будет размещена реплика доступности для группы доступности. Параметр конфигурации сервера «проверка подлинности автономной базы данных»Параметры конфигурации сервера (SQL Server)

Примечание

Группы доступности AlwaysOn работает с любым поддерживаемым уровнем совместимости базы данных.

Ограничения (базы данных доступности)

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

    • Мастер создания группы доступности / Мастер добавления базы данных в группу доступности: Параметр Full не поддерживается (на странице Выбор начальной синхронизации данных).

    • RESTORE WITH MOVE: Для создания баз данных-получателей файлы базы данных должны иметь атрибут RESTORED WITH MOVE в каждом экземпляре SQL Server, в котором размещена вторичная реплика.

    • Воздействие на операции добавления файлов: Операция добавления файлов, выполняемая позднее в основной реплике, может завершиться со сбоем в базах данных-получателях. Эта ошибка может вызвать приостановку работы баз данных-получателей. Это, в свою очередь, вызовет переход дополнительных реплик в состояние NOT SYNCHRONIZING.

      Примечание

      Дополнительные сведения о реакции на операции добавления файла, завершившиеся сбоем, см. в разделе Устранение неполадок с операциями добавления файла, завершившимися сбоем (группы доступности Always On).

  • Нельзя удалить базу данных, которая принадлежит какой-либо группе доступности.

Дальнейшие действия для баз данных, защищаемых прозрачным шифрованием

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

Связанные задачи (базы данных доступности)

Задача Статья
Подготовка базы данных-получателя (вручную) Ручная подготовка базы данных-получателя для присоединения к группе доступности (SQL Server)
Присоединение базы данных-получателя к группе доступности (вручную) Присоединение базы данных-получателя к группе доступности (SQL Server)
Изменение числа баз данных доступности Добавление базы данных в группу доступности (SQL Server)Удаление базы данных-получателя из группы доступности (SQL Server)Удаление базы данных-источника из группы доступности (SQL Server)

Создание свидетеля (Quorum Witness Share)

2.1 Теперь можно перейти к настройке Quorum. Выполните действия, которые приведены на скриншоте.

2.2 Укажите file share у конфигурации свидетеля Quorum.

2.3 Создайте директорию на сервере, которая не будет участвовать в кластере, но у которой будет общая сеть с кластером. Добавьте шару для доступа к директории нод из кластера, а в настройке свидетеля укажите UNC-путь.

2.4 На этом этапе у вас может возникнуть ошибка такого типа:

Она означает, что в настройках свидетеля нужно перенастроить права доступа к сетевой директории.

2.5 Следующий этап — установка MS SQL 2015 Enterprise на ноды в кластере. Убедитесь, что брандмауэр не будет блокировать работу в сети домена у всех компьютеров из кластера.

2.6 Установка MS SQL должна выполняться в standalone режиме. Не должно быть никаких дополнительных модулей. В качестве пользователя мы для примера указали Администратора доменной сети. Для рабочих серверов в целях безопасности создавайте отдельного пользователя.

2.7 Установите SQL Management Studio на обе ноды в кластере.

Бесплатный тестовый доступ к облаку на 30 днейПолучить

Разрешение, когда первичная реплика является единственным репликой в группе доступности

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

Чтобы ототащить группу доступности, используйте следующий скрипт SQL:

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

Ограничения

При обновлении программы установки или использовании процедуры slipstream применяются следующие ограничения:

Важно!
Если файл журнала Summary.txt указывает, что необходимо удалить, необходимо удалить неустановимую установку.

Если вы используете процедуру slipstream для обновления установки до установки Wow64, необходимо выполнить одно из следующих дополнительных действий:

Укажите параметр /Action в командной строке в дополнение к параметру /x86.

На странице «Параметры » центра установки выберите x86.

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

При копировании пакетов slipstream используйте пути, которые не содержат пробелов

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

Сценарий 5. Кластер Windows с автономными экземплярами SQL Server и группами доступности

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

Выполнение обновления

  1. Остановите передачу трафика в SQL Server.

  2. Для пользовательских баз данных создайте резервную копию заключительного фрагмента журнала и восстановите ее в новой среде с помощью команды RESTORE WITH RECOVERY в основной группе доступности и с помощью команды NORECOVERY в каждой вторичной группе доступности.

  3. В исходном кластере удалите группу доступности.

  4. В конечном кластере в диспетчере отказоустойчивости кластеров отключите каждую кластерную роль экземпляра отказоустойчивого кластера SQL.

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

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

  7. Измените имя каждого автономного компьютера в исходном кластере на новое уникальное имя. Перезапустите каждый из этих компьютеров согласно указаниям.

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

  9. Скопируйте системные базы данных на конечные компьютеры.

  10. В исходной среде в диспетчере отказоустойчивости кластеров измените имя ресурса «Имя сервера» для каждой роли экземпляра отказоустойчивого кластера SQL Server на новое уникальное имя.

  11. Включите только переименованные ресурсы «Имя сервера» для каждой роли экземпляра отказоустойчивого кластера SQL.

  12. Теперь в параллельных автономных экземплярах переименуйте компьютеры, присвоив им имена исходных автономных компьютеров. (Удалите имя сервера в SQL, а затем добавьте его.) Перезапустите компьютеры согласно инструкциям.

  13. После перезапуска присоедините каждый автономный компьютер к конечному отказоустойчивому кластеру Windows Server.

  14. В конечном кластере в диспетчере отказоустойчивости кластеров измените имя ресурса «Имя сервера» для каждой роли экземпляра отказоустойчивого кластера SQL Server на имя, которое использовалось в исходном кластере.

  15. После переименования всех экземпляров отказоустойчивого кластера перезапустите каждый компьютер в новом кластере.

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

  17. После того как все экземпляры перейдут в режим «в сети», повторно создайте группу доступности в основном экземпляре.

  18. Присоедините все вторичные реплики и базы данных-получатели.

  19. Повторно создайте прослушиватель группы доступности с тем же именем, что и в исходной группе доступности.

Вопросы, касающиеся отдельных компонентов

Группы доступности AlwaysOn

  • Конечная точка зеркального отображения базы данных

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

  • Группы доступности

    Группы доступности и их прослушиватели невозможно переносить между экземплярами. Ресурсы отказоустойчивого кластера Windows Server, созданные группой доступности, нельзя легко воссоздать в конечной среде. Вместо того чтобы пытаться перенести группы доступности, мы рекомендуем удалить и повторно создать группы доступности в конечном кластере.

  • Прослушиватели групп доступности

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

Репликация

  • Удаленные распространители, издатели, подписчики

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

  • Папка моментальных снимков

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

Service Broker

  • Конечная точка Service Broker

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

  • Сертификаты

    Если сертификаты требуются на новых компьютерах, следует выполнить их резервное копирование, а затем восстановить на конечных компьютерах.

  • Маршруты

    Маршруты зависят от имени виртуальной сети в конечной среде. Как имена компьютеров, так и сетевые имена экземпляров отказоустойчивого кластера SQL должны правильно разрешаться в имена компьютеров в новой среде. Прочие используемые имена VNN также должны быть перенаправлены на новые компьютеры.

  • Привязки удаленных служб

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

АгентSQL Server

  • Задания

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

  • Предупреждения и операторы

    Предупреждения и операторы переносятся надлежащим образом вместе с системными базами данных.

FILESTREAM

  • Порты обмена файлами Windows

    Для портов обмена файлами Windows 139 и 445 должны быть настроены правила, разрешающие использование файлового потока для входящего трафика FILESTREAM.

  • Общий ресурс Windows

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

  • Данные FILESTREAM

    Данные файлового потока включаются в резервную копию.

Службы Integration Services

  • проекты служб SSIS

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

  • Файловые источники данных

    Неструктурированные файлы, файлы Excel, источники XML и другие источники должны быть доступны в расположениях, указанных в пакете служб SSIS.

Сценарии миграции

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

Требуются все серверные объекты и имена VNN Требуются все серверные объекты и имена VNN Серверные объекты и имена VNN не требуются* Серверные объекты и имена VNN не требуются*
Группы доступности? (Да/Нет) Да Нет Да Нет
Кластер использует только экземпляр отказоустойчивого кластера SQL
Кластер использует автономные экземпляры

*Исключая имена прослушивателей группы доступности

Рекомендации по сетевым возможностям подключения

Настоятельно рекомендуется использовать одни и те же сетевые соединения для обмена данными между узлами WSFC и репликами доступности. Использование отдельных сетевых соединений может привести к непредвиденному поведению в случае отказа даже некоторых из них.

Например, чтобы группа доступности поддерживала автоматический переход на другой ресурс, вторичная реплика, которая является участником обработки отказа, должна находиться в состоянии SYNCHRONIZED. В случае отказа (даже временного) сетевого соединения с этой вторичной репликой она переходит в состояние UNSYNCHRONIZED и не может начать повторную синхронизацию до тех пор, пока соединение не будет восстановлено. Если кластер WSFC запрашивает автоматический переход на другой ресурс, пока вторичная реплика не синхронизирована, автоматический переход на другой ресурс не выполняется.

Рекомендации для компьютеров, на которых размещены реплики доступности (ОС Windows)

Разрешения (ОС Windows)

Для администрирования кластера WSFC пользователь должен быть системным администратором на каждом узле кластера.

Дополнительные сведения об учетной записи для администрирования кластера см. в Приложении A. Требования к отказоустойчивому кластеру.

Связанные задачи (ОС Windows)

Задача Ссылка
Установите значение HostRecordTTL.

Изменение параметра HostRecordTTL (с помощью Windows PowerShell)

  1. Откройте окно Powershell с помощью варианта Запуск от имени администратора.

  2. Импортируйте модуль FailoverClusters.

  3. С помощью командлета Get-ClusterResource найдите ресурс сетевого имени, а затем с помощью командлета Set-ClusterParameter задайте значение HostRecordTTL следующим образом:

    Get-ClusterResource «<NetworkResourceName>» | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

    В следующем примере для PowerShell задается значение HostRecordTTL в 300 секунд для сетевого ресурса сетевого имени .

    Совет

    Каждый раз при открытии нового окна PowerShell потребуется импортировать модуль FailoverClusters .

См. также (PowerShell)
  • Кластеризация и высокая доступность (блог группы отказоустойчивой кластеризации и балансировки сетевой нагрузки)

Группа доступности с узлами экземпляров отказоустойчивого кластера

Если группа доступности содержит узлы экземпляра отказоустойчивого кластера (FCI), сначала нужно обновлять неактивные узлы, а затем — активные. На приведенном ниже рисунке показан обычный сценарий для групп доступности с использованием экземпляров FCI для достижения локального высокого уровня доступности и асинхронной фиксации между экземплярами FCI для удаленного аварийного восстановления, а также последовательность обновления.

  1. Обновление или обновление
  2. Отработка отказа FCI2 на
  3. Обновление или обновление
  4. Обновление или обновление
  5. Отработка отказа FCI1 на
  6. Обновление или обновление

Установка отказоустойчивого кластера

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

  1. Для установки, настройки и обслуживания отказоустойчивого кластера SQL Server применяется программа установки SQL Server .

    • Определить, какие сведения необходимы для создания экземпляра отказоустойчивого кластера (это могут быть дисковый ресурс кластера, IP-адреса и сетевое имя) и какие узлы могут быть использованы для перехода на другой отказоустойчивый кластер. Дополнительные сведения

    • Эти шаги по конфигурации должны быть выполнены до запуска программы установки SQL Server , для их реализации необходимо использовать оснастку Windows «Администратор кластера». Для каждого экземпляра настраиваемого отказоустойчивого кластера необходимо иметь одну группу WSFC.

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

  2. Добавление или удаление узлов из конфигурации отказоустойчивого кластера, не затрагивая другие узлы кластера. Дополнительные сведения см. в статье Добавление и удаление узлов в отказоустойчивом кластере SQL Server (настройка).

    Все узлы на отказоустойчивом кластере должны работать на одной платформе: либо на 32-разрядной, либо на 64-разрядной. Кроме того, на них должен работать один и тот же выпуск и версия операционной системы. Кроме того, 64-разрядные версии выпусков SQL Server должны быть установлены на 64-разрядном оборудовании, работающем под управлением 64-разрядных версий операционной системы Windows. В этой версии отсутствует поддержка WOW64 для отказоустойчивой кластеризации.

  3. Указание нескольких IP-адресов для каждого экземпляра отказоустойчивого кластера. Для каждой подсети можно указать несколько IP-адресов. Если в одной подсети имеется несколько IP-адресов, то программа установки SQL Server устанавливает зависимость в «И». Если выполняется кластеризация узлов по нескольким подсетям, то программа установки SQL Server устанавливает зависимость в «ИЛИ».

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

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

Получение исправлений для SQL Server 2008

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

Обновление установки SQL Server 2008

При попытке установить SQL Server 2008 с DVD-диска или из сетевой папки установка завершается сбоем из-за проблемы с версией выпуска программы установки.

Ниже описано, как обновить SQL Server 2008 при возникновении проблемы с установкой.

  1. Если на компьютере установлены файлы поддержки программы установки SQL Server 2008, вы применяете накопительный пакет обновления или исправление для обновления файлов поддержки программы установки SQL Server 2008, а затем повторно запустите программу установки с DVD-диска или сетевого ресурса.

  2. Если файлы SQL Server установки 2008 не установлены, см. раздел «Упреждающее выполнение установки».

Чтобы определить, установлены ли на компьютере файлы поддержки SQL Server 2008 Setup, просмотрите запись с помощью функции добавления или удаления программ в панель управления операционных системах, предшествующих Windows Vista. В Windows Vista или более поздних версиях Windows просмотрите запись с помощью программ и компонентов в панель управления. Чтобы применить cu или исправление и запустить программу установки, выполните следующие действия:

  1. Если исправление доступно через исправление, скачайте накопительный пакет обновления или исправление, а затем установите его на компьютере, запустив файл .exe или с помощью командной строки. Пакет обнаруживает файлы поддержки SQL Server 2008 на компьютере, а затем применяет новую версию SQLSupport.msi файла.

  2. Запустите программу установки еще раз с DVD-диска или из сетевой папки. Программа установки обнаруживает, что на компьютере доступна более поздняя версия файла SQLSupport.msi, а программа установки запускается из локальной версии на компьютере, а не из DVD-диска или сетевого ресурса.

Дополнительные сведения

При запуске исходной версии выпуска SQL Server 2008 программа установки копирует себя на локальном компьютере, а затем повторно выполняет запуск из локальной копии. Таким образом, если на компьютере установлена более поздняя версия файлов поддержки, программа установки запустит эти обновленные файлы. Таким образом, можно обновить файлы поддержки SQL Server 2008, прежде чем запускать Setup.exe файла.

Начиная с SQL Server 2008 с пакетом обновления 1 (SP1), вы можете обновить SQL Server 2008 с помощью инфраструктуры slipstream. При установке пакета обновления 1 с помощью процедуры slipstream или установки в существующую установку SQL Server 2008 создается запись для пакета обновления в разделе «Добавление или удаление программ». Пакет обновления можно удалить с помощью этой записи.

Чтобы проверить, правильно ли установлен пакет обновления, запустите отчет об обнаружении SQL, доступный в центре установки SQL Server 2008. Вы должны увидеть функции версии 10. n. xxxx, где n представляет версию пакета обновления. Например, 10.1. Xxxx представляет пакет обновления 1.

Веб-синхронизация для репликации слиянием

Для использования веб-синхронизации репликации слиянием необходимо скопировать в виртуальный каталог служб IIS, используемый для синхронизации, прослушиватель репликации SQL Server (replisapi.dll). При настройке веб-синхронизации этот файл копируется в виртуальный каталог мастером настройки веб-синхронизации. Для обновления компонентов SQL Server , установленных на сервере IIS, необходимо вручную скопировать библиотеку replisapi.dll из каталога COM в виртуальный каталог сервера IIS. Дополнительные сведения о конфигурации см. в статье Настройка веб-синхронизации.

Рейтинг
( Пока оценок нет )
Editor
Editor/ автор статьи

Давно интересуюсь темой. Мне нравится писать о том, в чём разбираюсь.

Понравилась статья? Поделиться с друзьями:
Работатека
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: