Поделиться через

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

  • Статья

Применимо к: База данных SQL Azure

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

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

  • Реплика высокой доступности
  • Геореплика
  • Именованной реплики

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

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

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

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

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

Количество реплик высокой доступности может составлять от нуля до четырех. Можно указать число реплик во время создания новой базы данных или обновить количество реплик для существующей базы данных. Общие конечные точки и средства управления (например, Azure PowerShell, Azure CLI, портал Azure, 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=<password>;Trusted_Connection=False; Encrypt=True;

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

Геореплика

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

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

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

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

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

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

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

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

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

    • В Azure CLI необходимо указать параметры ha-replicas и redundant.
    • В 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, могут быть несогласованными и неправильными. Например, столбец именованной реплики может быть указан как 140, compatibility_level даже если база данных-источник, соответствующая именованной реплике, имеет уровень совместимости 150. Решение, когда это возможно, — получить те же данные с помощью DATABASEPROPERTYEX() функции, которая возвращает правильные данные.

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

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

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