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

Применимо к:База данных 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 именованных реплика (для каждого первичного реплика).
  • Именованные реплика поддерживают разные проверки подлинности для каждого именованного реплика путем создания различных имен входа на логических серверах с именем реплика.

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

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

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

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

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

Примечание.

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

Избыточность зоны для гипермасштабирования с именем реплика

Примечание.

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

Избыточность зон для гипермасштабирования База данных SQL Azure с именем реплика использует Azure Зоны доступности для распространения именованных реплика вычислительных узлов между различными физическими расположениями в регионе Azure. Выбрав избыточность зоны для именованных реплика, вы можете повысить устойчивость всех уровней баз данных гипермасштабирования до более широкого диапазона сбоев, включая сбои центра обработки данных без каких-либо изменений логики приложения. Дополнительные сведения см. в разделе "Избыточность зоны гипермасштабирования".

Руководство по созданию избыточного по зонам гипермасштабирования с именем реплика см. в статье "Создание гипермасштабирования с именем реплика".

Сведения об устранении неполадок и тестировании отказоустойчивости приложений см. в разделе "Тестирование отказоустойчивости приложений".

Геореплика

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

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

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

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

  • можно создать только одну геореплику (в том же или другом регионе);
  • восстановление геореплики до точки во времени не поддерживается;
  • Создание гео-реплика гео-реплика (также известного как гео-реплика цепочка) не поддерживается.

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

Устранение неполадок с избыточным по зонам гипермасштабированием с именем реплика

  • Сведения об устранении неполадок и тестировании отказоустойчивости приложений см. в разделе "Тестирование отказоустойчивости приложений".

  • Убедитесь, что при создании избыточной зоны с именем реплика в PowerShell и CLI указывается по крайней мере один реплика высокого уровня доступности. Пример см. в статье "Создание гипермасштабирования" с именем реплика.

    • В Azure CLI необходимо указать параметры "ha-реплика" и "избыточные".
    • В PowerShell необходимо указать параметр HighAvailabilityReplicaCount и ZoneRedundant.
    • Если опущено, вы получите сообщение об ошибке: (ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.
  • База данных гипермасштабирования должна иметь избыточность зоны, которая уже включена в качестве необходимых компонентов, чтобы включить эту функцию для именованных реплика.

    • Необязательно включить избыточность зоны для именованных реплика, даже если база данных-источник имеет избыточность зоны.
    • Если этот параметр не включен, вы получите сообщение об ошибке: (DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant.

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

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

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

Инструкции по настройке гипермасштабирования и управлению ими с именем реплика см. в приведенных ниже руководствах.

Дополнительные сведения см. в разделе: