Вторичные реплики гипермасштабирования

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных SQL Azure

Как указано в статье Архитектура распределенных функций, База данных SQL Azure уровня "Гипермасштабирование" использует два типа вычислительных узлов, которые также называются репликами:

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

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

Реплика высокой доступности

Реплика высокой доступности (HA) использует те же серверы страниц, что и первичная реплика, поэтому для добавления реплики высокой доступности не требуется копировать данные. Реплики высокой доступности обычно используются именно для повышения уровня доступности базы данных, выполняя роль ресурса горячей замены на случай отработки отказа. Если первичная реплика станет недоступной, быстро и автоматически выполняется отработка отказа в одну из существующих реплик высокой доступности. Для этого не потребуется даже менять строку подключения, а время простоя будет минимальным из-за сброса активных подключений. Обычно в этом сценарии рекомендуется использовать надежную логику повторных попыток. Несколько драйверов уже предоставляют некоторый уровень автоматической логики повторных попыток. Если вы используете .NET, последняя версия библиотеки Microsoft.Data.SqlClient обеспечит вам полную поддержку для настраиваемой логики автоматических повторных попыток.

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

Количество реплик высокой доступности может составлять от нуля до четырех. Это количество можно изменить в процессе создания базы данных или после ее создания с помощью распространенных конечных точек и средств управления (например, PowerShell, AZ CLI, портал или REST API). Создание или удаление реплик высокой доступности не влияет на активные подключения, работающие с первичной репликой.

Подключение к реплике высокой доступности

В базах данных уровня "Гипермасштабирование" передаваемый клиентом аргумент строки подключения ApplicationIntent определяет, куда направляется подключение: к первичной реплике (для чтения и записи) или ко вторичной реплике высокой доступности (только для чтения). Если параметр ApplicationIntent имеет значение ReadOnly, но у этой базы данных нет вторичных реплик, подключение будет направляться к первичной реплике в режиме ReadWrite по умолчанию.

-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

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

Именованная реплика (в предварительной версии)

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

Свойства именованных реплик, которые отличают их от реплик высокой доступности:

  • они отображаются как обычные базы данных SQL Azure (доступные только для чтения) на портале и в вызовах API (AZ CLI, PowerShell, T-SQL);
  • имя базы данных для них может отличаться от базы данных в первичной реплике, а также они могут размещаться на другом логическом сервере (но обязательно в том же регионе, что и первичная реплика);
  • они имеют собственный целевой уровень обслуживания, который можно настроить и изменить независимо от первичной реплики;
  • поддерживается до 30 именованных реплик (для каждой первичной реплики);
  • создание разных имен входа на логических серверах, где размещаются именованные реплики, позволяет использовать разные способы аутентификации для каждой именованной реплики.

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

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

Основное назначение именованных реплик — поддерживать сценарий масштабирования для чтения в OLTP и улучшить выполнение рабочих нагрузок HTAP (гибридная транзакционная и аналитическая обработка). Примеры, демонстрирующие создание таких решений, доступны здесь:

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

  • Изоляция доступа. Вы можете предоставить доступ к определенной именованной реплике, но не к первичной реплике или другим именованным репликам.
  • Целевой уровень обслуживания в зависимости от рабочей нагрузки. Так как для именованной реплики можно указать собственный целевой уровень обслуживания, можно настроить разные именованные реплики для разных рабочих нагрузок и вариантов использования. Например, одна именованная реплика будет обслуживать запросы Power BI, а другая — предоставлять данные в Apache Spark для задач обработки и анализа данных. Они могут иметь разные целевые уровни обслуживания и масштабироваться независимо друг от друга.
  • Маршрутизация в зависимости от рабочей нагрузки. Так как число именованных реплик может достигать 30, можно объединять их в группы для изоляции разных приложений. Например, одна группа из четырех именованных реплик может обслуживать запросы от мобильных приложений, а другая с двумя именованными репликами — запросы от веб-приложения. Такой подход позволяет детально настраивать производительность и затраты для каждой группы.

В следующем примере создается именованная реплика WideWorldImporters_NR для базы данных WideWorldImporters. Первичная реплика использует цель уровня обслуживания HS_Gen5_4, а именованная реплика — HS_Gen5_2. Обе они используют один логический сервер MyServer. Если вы предпочитаете использовать REST API напрямую, изучите такой вариант в разделе, посвященном созданию вторичной именованной реплики.

ALTER DATABASE [WideWorldImporters]
ADD SECONDARY ON SERVER [MyServer] 
WITH (SERVICE_OBJECTIVE = 'HS_Gen5_2', SECONDARY_TYPE = Named, DATABASE_NAME = [WideWorldImporters_NR]);

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

Примечание

Часто задаваемые вопросы об именованных репликах с гипермасштабированием собраны в статье Часто задаваемые вопросы об именованных репликах уровня "Гипермасштабирование" в Базе данных SQL Azure.

Подключение к именованной реплике

Чтобы подключиться к именованной реплике, необходимо использовать строку подключения для конкретной именованной реплики, указав имена ее сервера и базы данных. Параметр ApplicationIntent=ReadOnly указывать необязательно, так как все именованные реплики доступны только для чтения.

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

Изменение именованной реплики

Целевой уровень обслуживания для именованной реплики можно задать при ее создании с помощью команды ALTER DATABASE или с помощью любого другого поддерживаемого способа (AZ CLI, PowerShell, REST API). Если вам потребуется изменить целевой уровень обслуживания после создания именованной реплики, это можно сделать с помощью команды ALTER DATABASE ... MODIFY в самой именованной реплике. Например, если используется именованная реплика WideWorldImporters_NR для базы данных WideWorldImporters, команда будет выглядеть указанным ниже образом.

ALTER DATABASE [WideWorldImporters_NR] MODIFY (SERVICE_OBJECTIVE = 'HS_Gen5_4')

Удаление именованной реплики

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

DROP DATABASE [WideWorldImporters_NR];

Важно!

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

Известные проблемы

sys.databases возвращает частично неверные данные

В период общедоступной предварительной версии значения записей, возвращаемые из sys.databases для именованных реплик, могут быть несогласованными и неправильными для любых столбцов, кроме name и database_id. Например, столбец compatibility_level для именованной реплики может возвращать значение 140, даже если в базе данных-источнике, из которой создана именованная реплика, задано значение 150. Чтобы обойти эту проблему, во всех случаях, когда это возможно, получайте данные с помощью функции DATABASEPROPERTYEX(), которая возвращает правильные данные.

Геореплика (в предварительной версии)

При использовании активной георепликации вы можете создать доступную для чтения вторичную реплику для базы данных-источника уровня "Гипермасштабирование" в том же или другом регионе Azure. Геореплики нужно создавать на другом логическом сервере. Имя базы данных для геореплики всегда совпадает с именем базы данных первичной реплики.

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

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

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

Георепликация для баз данных уровня "Гипермасштабирование" в настоящее время предоставляется в режиме предварительной версии со следующими ограничениями:

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

Дальнейшие действия