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

Активные вторичные файлы: доступные для чтения вторичные реплики (группы доступности AlwaysOn)

Активные вторичные возможности групп доступности AlwaysOn включают поддержку доступа только для чтения к одной или нескольким вторичным репликам (доступные для чтения вторичные реплики). Доступная для чтения вторичная реплика разрешает доступ ко всем её вторичным базам данных только для чтения. Однако вторичные базы данных доступны для чтения, но не настроены на режим только для чтения. Они динамичны. Изменения вносятся во вторичную базу данных по мере внедрения изменений в соответствующую первичную базу данных. Для типичной вторичной реплики данные во вторичных базах данных, включая таблицы, оптимизированные для долговременной памяти, находятся фактически в режиме реального времени. Кроме того, полнотекстовые индексы синхронизируются с вторичными базами данных. Во многих случаях задержка данных между базой данных-источником и соответствующей базой данных-получателем составляет всего несколько секунд.

Параметры безопасности, происходящие в базах данных-источниках, сохраняются в базах данных-получателях. К ним относятся пользователи, роли базы данных и приложения вместе с соответствующими разрешениями и прозрачным шифрованием данных (TDE), если они включены в базе данных-источнике.

Замечание

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

Группы доступности AlwaysOn также поддерживают повторную маршрутизацию запросов на подключение с намерением чтения к доступной для чтения вторичной реплике (маршрутизация только для чтения). Сведения о маршрутизации режима только для чтения см. в статье «Использование прослушивателя для подключения к Read-Only вторичной реплике (маршрутизацияRead-Only)».

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

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

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

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

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

  • Автоматическая временная статистика на читаемой вторичной базе данных оптимизирует запросы на чтение в таблицах на основе дисков. Для таблиц, оптимизированных для памяти, отсутствующие статистические данные создаются автоматически. Однако автоматическое обновление устаревших статистических данных отсутствует. Необходимо вручную обновить статистику первичной реплики. Дополнительные сведения см. в разделе "Статистика для баз данных Read-Only access" далее в этом разделе.

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

  • Рабочие нагрузки только для чтения для оптимизированных для памяти устойчивых таблиц обращаются к данным точно так же, как и к первичной базе данных, используя встроенные хранимые процедуры или взаимодействие SQL с теми же ограничениями уровня изоляции транзакций. Отчеты о рабочих нагрузках или запросах только для чтения, выполняемых на первичной реплике, могут выполняться на вторичной реплике без каких-либо изменений. Аналогичным образом, рабочая нагрузка отчетов или запросы только для чтения, выполняемые на вторичной реплике, могут выполняться на первичной реплике без каких-либо изменений. Как и в таблицах на основе дисков, все запросы, выполняемые в вторичных базах данных, автоматически сопоставляются с уровнем транзакции изоляции моментальных снимков, даже если другие уровни изоляции транзакций явно заданы.

  • Операции DML разрешены для табличных переменных как для типов таблиц на основе диска, так и для типов таблиц, оптимизированных для памяти, на вторичной реплике.

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

  • Доступные для чтения вторичные реплики (обязательные)

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

    Замечание

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

    Дополнительные сведения см. в разделе о доступе клиента к репликам доступности (SQL Server).

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

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

  • Маршрутизация только для чтения

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

    • Для поддержки маршрутизации, доступной только для чтения, для вторичной реплики требуется URL-адрес маршрутизации только для чтения. Этот URL-адрес действует только в том случае, если локальная реплика работает в вторичной роли. URL-адрес маршрутизации только для чтения должен быть указан для каждой реплики по мере необходимости. Каждый URL-адрес маршрутизации только для чтения используется для маршрутизации запросов на подключение с намерением чтения к определенной вторичной реплике, доступной для чтения. Как правило, каждой вторичной реплике, доступной для чтения, назначается URL-адрес маршрутизации, предназначенный только для чтения.

    • Каждая реплика доступности, которая поддерживает маршрутизацию только для чтения, если она является основной репликой, требуется список маршрутизации только для чтения. Данный список маршрутизации только для чтения действует только в том случае, если локальная реплика выполняется под основной ролью. Этот список необходимо указать для каждой реплики отдельно, по мере необходимости. Как правило, каждый список маршрутизации только для чтения будет содержать каждый URL-адрес маршрутизации только для чтения с URL-адресом локальной реплики в конце списка.

      Замечание

      Запросы на подключение с намерением чтения направляются на первую доступную для чтения вторичную реплику из списка маршрутизации только для чтения текущей первичной реплики. Балансировка нагрузки отсутствует.

    Дополнительные сведения см. в статье Настройка маршрутизации Read-Only для группы доступности (SQL Server).

Замечание

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

Ограничения и условия

Некоторые операции не полностью поддерживаются, как показано ниже.

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

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

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

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

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

    • Отслеживание изменений явно отключено в вторичных базах данных.

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

  • Так как операции чтения сопоставляются с уровнем транзакции изоляции моментальных снимков, очистка записей призраков на первичной реплике может быть заблокирована транзакциями на одной или нескольких вторичных репликах. Задача очистки фантомных записей автоматически удаляет фантомные записи для таблиц с хранением на диске на первичной реплике, когда они больше не требуются ни одной вторичной реплике. Это похоже на то, что выполняется при выполнении транзакций на первичной реплике. В крайнем случае во вторичной базе данных необходимо прекратить выполнение длительного запроса на чтение, который блокирует удаление «призраков». Обратите внимание, что удаление временных данных может быть заблокировано, если вторичная реплика отключена или когда перемещение данных приостановлено на вторичной базе данных. Это состояние также предотвращает усечение журнала, поэтому если это состояние сохраняется, рекомендуется удалить эту базу данных-получатель из группы доступности. Проблемы с очисткой фантомных записей отсутствуют в таблицах, оптимизированных для памяти, так как версии строк хранятся в памяти и независимы от версий строк на основной реплике.

  • Операция DBCC SHRINKFILE с файлами, содержащими таблицы на основе дисков, может завершиться ошибкой на первичной реплике, если файл содержит записи-призраки, которые по-прежнему необходимы для вторичной реплики.

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

Замечание

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

Рекомендации по производительности

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

Задержка данных

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

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

Это означает, что между первичной и вторичной репликами обычно существует некоторая задержка. В нетипичных случаях, например в ситуации, когда проблемы с сетью ухудшают пропускную способность, задержка может стать значительной. Задержка увеличивается из-за наличия узких мест в системе ввода-вывода и в результате приостановки движения данных. Для мониторинга приостановленного перемещения данных можно использовать панель мониторинга AlwaysOn или динамическое представление управления sys.dm_hadr_database_replica_states .

Задержка данных в базах данных с оптимизированными для памяти таблицами

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

Влияние безопасной временной метки на задержку

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

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

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

Мониторинг и устранение задержки данных в таблицах, оптимизированных для памяти

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

  
SELECT MAX(base_generation)   
   AS max_base_generation  
   FROM sys.dm_db_xtp_gc_cycle_stats  
GO

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

  
SELECT begin_tsn   
   FROM sys.dm_db_xtp_transactions  
GO

Read-Only влияние рабочей нагрузки

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

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

  • Несмотря на то, что операции чтения не принимают общие блокировки из-за управления версиями строк, эти операции принимают блокировки стабильности схемы (Sch-S) , которые могут блокировать операции повторного выполнения, которые применяют изменения DDL. Операции DDL включают ALTER и DROP для таблиц и представлений, но не DROP или ALTER для хранимых процедур. Например, если вы удаляете таблицу, хранящуюся на диске, или оптимизированную для памяти, на первичном. Когда поток REDO обрабатывает запись журнала для удаления таблицы, он должен получить блокировку SCH_M на таблицу и может быть заблокирован выполняющимся запросом, обращающимся к этой таблице. Это то же поведение в первичной реплике, за исключением того, что удаление таблицы выполняется в рамках сеанса пользователя, а не потока REDO.

  • Существует дополнительная блокировка для таблиц Memory-Optimized. Удаление собственной хранимой процедуры может привести к блокировке потока REDO, если на вторичной реплике существует параллельное выполнение собственной хранимой процедуры. Это то же поведение в первичной реплике, за исключением того, что удаление хранимой процедуры выполняется в рамках сеанса пользователя, а не потока REDO.

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

Замечание

Если поток повторного воспроизведения блокируется запросами в вторичной копии, вызывается XEvent sqlserver.lock_redo_blocked.

Индексирование

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

Чтобы отслеживать активность использования индекса во вторичной реплике, выполните запрос к столбцам user_seeks, user_scans и user_lookups столбцов динамического административного представления sys.dm_db_index_usage_stats .

Статистика для баз данных Read-Only Access

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

Чтобы устранить эту проблему, вторичная реплика создает и сохраняет временную статистику для вторичных баз данных в tempdb. Суффикс _readonly_database_statistic добавляется к имени временной статистики, чтобы отличить их от постоянной статистики, сохраняемой из базы данных-источника.

Только SQL Server может создавать и обновлять временную статистику. Однако можно удалить временную статистику и отслеживать их свойства, используя те же средства, которые используются для постоянной статистики:

  • Удалите временную статистику с помощью инструкции DROP STATISTICSTransact-SQL.

  • Отслеживайте статистику с помощью представлений каталога sys.stats и sys.stats_columns . sys_stats включает столбец , is_temporary, чтобы указать, какие статистические данные являются постоянными и которые являются временными.

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

Дополнительные сведения о статистике SQL Server см. в разделе "Статистика".

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

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

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

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

Ограничения и условия

  • Так как временная статистика хранится в tempdb, перезапуск службы SQL Server приводит к исчезновению всех временных статистических данных.

  • Суффикс _readonly_database_statistic зарезервирован для статистики, созданной SQL Server. Этот суффикс нельзя использовать при создании статистики в базе данных-источнике. Дополнительные сведения см. в статье Managing statistics on tables in SQL Data Warehouse (Управление статистикой таблиц в хранилище данных SQL).

Доступ к оптимизированным для памяти таблицам во вторичной реплике

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

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

  • Для запросов, выполняемых только в таблицах, оптимизированных для памяти, доступны только уровни изоляции, являются моментальными, повторяемыми и сериализуемыми. Все запросы с уровнем изоляции без фиксации чтения или чтения возвращают ошибку, если вы не включили параметр MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT на уровне базы данных.

    SET TRANSACTION ISOLATION LEVEL READ_COMMITTED  
-- This is not allowed  
BEGIN TRAN  
SELECT * FROM t_hk  
COMMIT

    Сообщение об ошибке:

    Msg 41368, Level 16, State 0, Line 2  
Accessing memory optimized tables using the CREAD_COMMITTED isolation level is supported only for autocommit transactions. It is not supported for explicit or implicit transactions. Provide a supported isolation level for the memory optimized table using a table hing, such as WITH (SNAPSHOT).

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

    SELECT * FROM t_hk WITH (PAGLOCK)  
SELECT * FROM t_hk WITH (READPAST)  
SELECT * FROM t_hk WITH (ROWLOCK)  
SELECT * FROM t_hk WITH (READPAST)  
SELECT * FROM t_hk WITH (TABLOCK)  
SELECT * FROM t_hk WITH (XLOCK)  
SELECT * FROM t_hk WITH (UPDLOCK)

  • Для транзакций между контейнерами транзакции с уровнем изоляции сеанса "моментальный снимок", доступ к оптимизированным для памяти таблицам не поддерживается. Например

    SET TRANSACTION ISOLATION LEVEL SNAPSHOT  
-- This is not allowed  
BEGIN TRAN  
   SELECT * FROM t_hk  
COMMIT

    Сообщение об ошибке:

    Msg 41332, Level 16, State 0, Line 5  
Memory optimized tables and natively compiled stored procedures cannot be accessed or created when the session TRANSACTION ISOLATION LEVEL is set to SNAPSHOT.

Рекомендации по планированию емкости

  • В случае с таблицами на основе дисков доступные для чтения вторичные реплики могут требовать место в tempdb по двум причинам:

    • Уровень изоляции моментальных снимков копирует версии строк в tempdb.

    • Временная статистика для вторичных баз данных создается и поддерживается в tempdb. Временная статистика может привести к незначительному увеличению размера tempdb. Дополнительные сведения см. в разделе "Статистика для баз данных Read-Only Access" далее в этом разделе.

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

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

    Добавление данных версии строки зависит от уровня изоляции моментальных снимков или уровня изоляции моментальных снимков с фиксацией для чтения (RCSI) в базе данных-источнике. В приведенной ниже таблице описывается поведение версионирования на читаемой вторичной базе данных при различных настройках для таблиц на основе диска.

    Доступная для чтения вторичная реплика? Включена изоляция моментальных снимков или уровень RCSI? База данных-источник Вторичная база данных
    нет нет Нет версий строк или 14-байтовых издержек Нет версий строк или 14-байтовых затрат
    нет Да Версии строк и 14-байтовые затраты Нет версий строк, но имеется 14-байтовая накладная нагрузка.
    Да нет Нет версий строк, но 14-байтовых затрат Версии строк и 14-байтовые накладные расходы
    Да Да Версии строк и 14-байтовые накладные расходы Версии строк и 14-байтовые затраты

Связанные задачи

Связанные материалы

См. также

Общие сведения о группах доступности AlwaysOn (SQL Server)
О подключении клиента к репликам доступности (SQL Server)
Слушатели групп доступности, подключение клиентов и отказоустойчивость приложений (SQL Server)
Статистика

  • Last updated on