Экземпляры отказоустойчивого кластера alwayson

Управляемый экземпляр SQL

Если вы хотите воспользоваться преимуществами разгрузки обслуживания и затрат, но считаете, что набор функций отдельной базы данных База данных SQL Azure слишком ограничен, можно перейти на Управляемый экземпляр SQL. Управляемый экземпляр похож на локальную SQL Server, не беспокоясь о сбоях оборудования или установке исправлений. Управляемый экземпляр — это коллекция системных и пользовательских баз данных с общим набором ресурсов, которые можно использовать для выполнения большинства операций миграции в облако. Этот вариант подходит для новых приложений или существующих локальных приложений, которые используют последние стабильные возможности Компонент SQL Server Database Engine и переносятся в облако с минимальными изменениями.

Преимущества

Затраты — Затраты можно сэкономить путем разгрузки обслуживания программного обеспечения и оборудования.
Методика Lift-and-Shift. Вы можете переместить весь локальный экземпляр SQL Server в управляемый экземпляр, включая все базы данных с минимальными изменениями базы данных.
Компоненты. Набор функций управляемого экземпляра точно соответствует аналогичным функциям локального экземпляра SQL Server, таким как запросы между базами данных, публикация и распространение репликации транзакций, планирование заданий SQL и поддержка CLR.
Масштабируемость. Все базы данных в управляемом экземпляре совместно используют ресурсы, и в любой момент времени можно увеличивать и уменьшать его работу без простоев.
Автоматизация. Исправление и резервное копирование происходит автоматически, экономя время на обслуживание.
Доступность. Стоимость службы включает в себя как хранение, так и высокий уровень доступности с гарантией доступности 99,99 %.
Intelligent Insights. Получите представление о производительности баз данных с помощью встроенной аналитики средства искусственного интеллекта.
Без версии: База данных SQL Azure не имеет версий, то есть всегда находится в последней версии и никогда не нужно беспокоиться об обновлении или простоях. Кроме того, вы всегда в курсе последних событий, и наши новейшие стабильные функции будут выпущены в первую очередь в «облако».
Низкая степень риска для приложений баз данных. Поддерживая совместимость базы данных на том же уровне, что и локальные базы данных, существующие приложения базы данных защищены от функциональных изменений и изменений производительности, которые могут иметь негативные последствия. Приложение следует повторно сертифицировать, только если необходимо использовать функции, которые являются производными от более новых параметров совместимости базы данных. Дополнительные сведения см. в статье Сертификация на совместимость.

Ресурсы

Обзор Управляемого экземпляра SQLChoose the right deployment option in Azure SQL (Выбор правильного варианта развертывания в SQL Azure)Azure SQL Database Features (Функции Базы данных SQL Azure)Миграция SQL Server в Управляемый экземпляр SQL AzureAccelerate migration by migrating multiple databases or entire SQL Servers (Ускорение миграции путем миграции нескольких баз данных или целых серверов SQL Server)

Инструменты:

Помощник по миграции данных
Database Migration Service

Перед началом

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

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

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

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

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

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

Предварительные условия для выполнения мастером полной первоначальной синхронизации данных

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

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

Чтобы при помощи мастера можно было создавать резервные копии и обращаться к ним, необходимо будет указать общую сетевую папку. Для каждой первичной реплики учетная запись, используемая для запуска Компонент Database Engine , должна иметь разрешения в файловой системе на чтение и запись в общей сетевой папке

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

Важно!
Резервные копии журналов будут входить в цепочку резервных копий журналов. Храните файлы резервных копий журналов надлежащим образом.

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

Это можно сделать до или после запуска мастера. Дополнительные сведения см. в статье Ручная подготовка базы данных-получателя для присоединения к группе доступности (SQL Server).

Permissions

Требуется членство в фиксированной роли сервера sysadmin и одно из разрешений: CREATE AVAILABILITY GROUP, ALTER ANY AVAILABILITY GROUP или CONTROL SERVER.

Кроме того, требуется разрешение CONTROL ON ENDPOINT, если мастер группы доступности должен иметь возможность управлять конечной точкой зеркального отображения базы данных.

Требования к оборудованию

Следующие требования к оборудованию применимы к SQL Server 2016 и SQL Server 2017:

Компонент	Требование
Жесткий диск	ДляSQL Server требуется как минимум 6 ГБ свободного места на диске. Требования к месту на диске определяются набором устанавливаемых компонентов SQL Server . Дополнительные сведения см. в разделе далее в этой статье. Сведения о поддерживаемых типах хранилищ для файлов данных см. в разделе . Рекомендуется устанавливать SQL Server на компьютерах с файловой системой NTFS или ReFS. Установка в файловой системе FAT32 поддерживается, но не рекомендуется, поскольку эта система менее защищенная, чем системы NTFS или ReFS. Диски, доступные только для чтения, подключенные и сжатые диски блокируются во время установки.
Накопитель	Для установки с DVD-диска необходим соответствующий дисковод.
Монитор	ДляSQL Server требуется монитор Super VGA с разрешением 800×600 пикселей или более высоким.
Интернет	Для поддержки функциональных средств Интернета требуется доступ к Интернету (могут применяться дополнительные тарифы).
Память *	Минимальные: Экспресс-выпуски: 512 МБ Все другие выпуски: 1 ГБРекомендуется: Экспресс-выпуски: 1 ГБ Все другие выпуски: Для обеспечения оптимальной производительности требуется не менее 4 ГБ с последующим увеличением по мере роста размера базы данных.
Быстродействие процессора	Минимум: процессор x64 с тактовой частотой 1,4 ГГцРекомендуется: 2,0 ГГц и выше
Тип процессора	Процессор x64: AMD Opteron, AMD Athlon 64, Intel Xeon с поддержкой Intel EM64T, Intel Pentium IV с поддержкой EM64T.

Примечание

Установка SQL Server поддерживается только для процессоров x64. Процессоры x86 больше не поддерживаются.

* Минимальный объем оперативной памяти, необходимый для установки компонента Сервер DQS в Data Quality Services (DQS), составляет 2 ГБ. Это значение отличается от требований, предъявляемых к минимальному объему памяти SQL Server. Подробные сведения об установке DQS см. в разделе Install Data Quality Services.

Автоматическое восстановление страниц

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

Дополнительные сведения см. в статье Автоматическое восстановление страниц (группы доступности: зеркальное отображение баз данных).

Перед началом

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

Предварительные условия для выполнения мастером полной первоначальной синхронизации данных

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

Permissions

Параметры

Как только ваш SQL Server достигнет конца этапа поддержки, вы можете выбирать один из приведенных ниже вариантов.

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

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

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

Отработка отказа вручную

Используйте средства управления кластером для отработки отказа в группе доступности, находящейся под управлением внешнего диспетчера кластера. Например, если для управления кластером Linux в решении применяется Pacemaker, используйте для отработки отказа вручную в RHEL или Ubuntu. В SLES используйте .

Важно!

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

Этапы отработки отказа вручную

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

Отработка отказа вручную выполняется в два этапа.

Сначала из узла кластера, которому принадлежит этот ресурс, в новый узел.

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

Во-вторых, .

Шаг 1. Выполнение отработки отказа вручную с перемещением ресурса группы доступности

Чтобы вручную выполнить отработку отказа для ресурса группы доступности с именем ag_cluster на узел кластера nodeName2, выполните соответствующую вашему дистрибутиву команду:

Пример для RHEL/Ubuntu
Пример для SLES

Важно!

При использовании параметра —lifetime ограничение расположения, созданное для перемещения ресурса, является временным и действует в течение 30 секунд в предыдущем примере.
Обратите внимание, что временное ограничение не удаляется автоматически и может отображаться в списке ограничений, но в качестве ограничения с истекшим сроком действия. Ограничения с истекшим сроком действия не влияют на режим отработки отказа кластера pacemaker

Если при перемещении ресурса параметр —lifetime не используется, следует удалить ограничение расположения, которое автоматически добавляется, как указано ниже.

Шаг 2. Удаление ограничения расположения

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

Пример для RHEL/Ubuntu
Пример для SLES

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

Примечание

Имя ресурса группы доступности в кластерах Pacemaker на Red Hat Enterprise Linux 8.x и Ubuntu 18.04 может выглядеть следующим образом: ag_cluster-clone. Это связано с тем, что наименования ресурсов теперь создаются с учетом клона с возможностью продвижения.

Пример для RHEL/Ubuntu

где — это код ограничения, которое необходимо удалить. возвращает этот код.

либо

Кроме того, вы можете выполнять перемещение и очистку автоматически созданных ограничений в одной строке, как показано ниже. В следующем примере термин клон используется в значении, употребляемом в Red Hat Enterprise Linux 8.x.
Пример для SLES

В следующей команде — это идентификатор ограничения. возвращает этот код.

Примечание

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

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

Chapter 7. Managing Cluster Resources (Глава 7. Управление ресурсами кластера)
Pacemaker — перемещение ресурсов вручную

1С:Предприятие Бухгалтерия переход с редакции 2.0 на 3.0. Практика перевода информационной базы для работы в управляемом приложении. Промо

Из информационного выпуска 1С № 16872 от 08.07.2013г. стало известно об относительно скором необходимом переходе на редакцию 1С:Бухгалтерия 3.0. В данной публикации будут разобраны некоторые особенности перевода нетиповой конфигурации 1С:Бухгалтерия 2.0 на редакцию 3.0, которая работает в режиме «Управляемое приложение».
Публикация будет дополняться по мере подготовки нового материала. Публикация не является «универсальной инструкцией».

Update 3. Права доступа. 14.08.2013
Update 4. Добавлен раздел 0. Дополнен раздел 4. Добавлен раздел 7. Внесены поправки, актуализирована информация. 23.11.2013.