Активные вторичные реплики: Доступ к вторичным репликам только для чтения (группы доступности AlwaysOn)
Возможности Группы доступности AlwaysOn по активному доступу к вторичным репликам включают поддержку доступа только для чтения к одной или нескольким вторичным репликам (доступным для чтения вторичным репликам). Доступная для чтения вторичная реплика разрешает доступ только для чтения ко всем своим базам данных-получателям. Однако доступные для чтения базы данных-получатели не переводятся в режим доступа только для чтения. Они являются динамическими. Определенная база данных-получатель изменяется по мере того, как к ней применяются изменения, вносимые в данные базы данных-источника. Для большинства вторичных реплик данные в базу данных-получатель поступают почти в реальном времени. Более того, полнотекстовые индексы синхронизируются с базами данных-получателями. Во многих случаях задержка данных между базой данных-источником и соответствующей базой данных-получателем находится в пределах нескольких секунд.
Параметры безопасности, которые встречаются в базах данных-источниках, сохраняются в базах данных-получателях. К ним относятся пользователи, роли баз данных и роли приложений, а также соответствующие разрешения и прозрачное шифрование данных, если оно включено в базе данных-источнике.
Примечание |
---|
Хотя в базы данных-получатели нельзя записывать данные, их вы можете записывать в базы данных, предназначенные для чтения и записи, на экземпляре сервера, содержащем вторичную реплику, в том числе в пользовательские и системные базы данных, например в базу данных tempdb. |
Группы доступности AlwaysOn также поддерживает маршрутизацию запросов соединения с намерением чтения к доступной для чтения вторичной реплике (маршрутизация только для чтения). Дополнительные сведения о маршрутизации только для чтения см. в разделе Использование прослушивателя для подключения к доступной только для чтения вторичной реплике (маршрутизация только для чтения).
В этом разделе.
Преимущества
Предварительные условия для использования группы доступности
Ограничения
Вопросы производительности
Рекомендации по планированию загрузки
Связанные задачи
См. также
Преимущества
Направление подключений «только для чтения» к доступным для чтения вторичным репликам обладает следующими преимуществами:
Перераспределяет нагрузку, вызываемую некритическими рабочими процессами, с основой реплики, ресурсы которой высвобождаются для критически важных нагрузок. Если на систему возлагается рабочая нагрузка критической важности, не терпящая задержек, для нее следует использовать основную реплику.
Это позволяет повысить окупаемость систем со вторичными репликами, предназначенными только для чтения.
Кроме того, доступные для чтения вторичные реплики обеспечивают надежность операций чтения.
Временная статистика в доступной для чтения базе данных-получателе позволяет оптимизировать запросы только для чтения. Дополнительные сведения см. в разделе Статистика баз данных, предназначенных только для чтения далее в этой теме.
Рабочие нагрузки только чтения используют систему управления версиями для удаления состязаний блокировок в базах данных-получателях. Все запросы, выполняемые к базе данных-получателю, автоматически сопоставляются с уровнем транзакций изоляции моментального снимка баз данных, даже если другие уровни изоляции транзакций заданы явно. Кроме того, все указания блокировки пропускаются. Это позволяет исключить конфликт между чтением и записью.
[В начало]
Предварительные условия для использования группы доступности
Доступные для чтения вторичные реплики (необходимое условие)
Администратор базы данных должен настроить одну или несколько реплик, чтобы при выполнении во вторичной роли они разрешали либо все соединения (для доступа только для чтения), либо только соединения с намерением чтения данных.
Примечание Кроме того, администратор базы данных может настроить любую из имеющихся реплик доступности на исключение соединений только для чтения во время работы в первичной роли.
Дополнительные сведения см. в разделе Сведения о доступе клиентского соединения с репликами доступности (SQL Server).
Прослушиватель группы доступности
Для поддержки маршрутизации только для чтения группа доступности должна иметь прослушиватель группы доступности. Клиент, запрашивающий данные в режиме только для чтения, должен направлять свои запросы к данному прослушивателю, и в строке подключения клиента должно быть задано намерение приложения «только для чтения». Это означает, что они должны быть запросами на соединение с намерением чтения.
Маршрутизация только для чтения
Маршрутизация только для чтения обозначает возможность SQL Server направлять входящие запросы соединения с намерением только чтения, предназначенные для прослушивателя группы доступности, на имеющуюся и доступную для чтения вторичную реплику. Необходимые условия для использования маршрутизации только для чтения:
Для поддержки маршрутизации только для чтения доступная для чтения вторичная реплика должна иметь URL-адрес для маршрутизации только для чтения. Этот URL-адрес задействуется, только если локальная реплика выполняется под вторичной ролью. URL-адрес маршрутизации только для чтения должен быть указан для каждой реплики отдельно (если подобная маршрутизация требуется для реплики). Все URL-адреса маршрутизации только для чтения используются для направления запросов на соединение с намерением чтения к определенной, доступной для чтения вторичной реплике. Как правило, каждой доступной для чтения вторичной реплике назначается URL-адрес маршрутизации только для чтения.
Каждая реплика доступности, поддерживающая маршрутизацию только для чтения и при этом являющаяся первичной репликой, требует наличия списка маршрутизации только для чтения. Определенный список маршрутизации только для чтения вступает в силу, только если локальная реплика выполняется под первичной ролью. Данный список должен быть указан для тех отдельных реплик, для которых это необходимо. Как правило, каждый список маршрутизации только для чтения будет содержать какие-либо URL-адреса маршрутизации только для чтения, причем URL-адрес локальной реплики будет идти в конце списка.
Примечание Запросы на соединение с намерением чтения направляются в первую имеющуюся вторичную реплику, доступную для чтения, из списка маршрутизации только для чтения текущей первичной реплики. Балансировка нагрузки отсутствует.
Дополнительные сведения см. в разделе Настройка маршрутизации только для чтения в группе доступности (SQL Server).
Примечание |
---|
Сведения о прослушивателях групп доступности и дополнительные сведения о маршрутизации только для чтения см. в разделе Прослушиватели групп доступности, возможность подключения клиентов и отработка отказа приложений (SQL Server). |
[В начало]
Ограничения
Некоторые операции поддерживаются не полностью.
Сразу при присоединении вторичной реплики, предназначенной только для чтения, к группе доступности вторичная реплика сможет принимать подключения к размещенным в ней базам данных-получателям. Однако при наличии любых активных транзакций в базе данных-источнике версии строк не будут сразу же и полностью доступны в базе данных-получателе. Любые активные транзакции, существовавшие в основной реплике при настройке вторичной реплики должны или применяться или откатываться. До момента завершения этого процесса сопоставление уровней изоляции транзакций в базе данных-получателе — неполное, а забросы временно блокируются.
Примечание Запуск продолжительных транзакций отразится на числе строк с версиями, сохраняющихся в системе.
Изменение режима отслеживания измененных данных не поддерживается во вторичных базах данных, принадлежащих к доступной для чтения вторичной реплике.
Отслеживание изменений явно отключено в базах данных-получателях.
Режим отслеживания измененных данных можно включить в базе данных-получателе, но это не поддерживается.
Операции чтения отображаются на уровень транзакций с изоляцией моментальных снимков, поэтому очистка фантомных записей в первичной реплике может быть заблокирована транзакциями в одной или нескольких вторичных репликах. Задача очистки фантомных записей автоматически очищает фантомные записи в основной реплике, когда они более не нужны в любой из вторичных реплик. Этот процесс сходен с другим процессом, когда транзакции запускаются в первичной реплике. В крайних случаях может понадобиться завершить долго выполняющийся запрос на чтение в базе данных-получателе, который блокирует процесс очистки фантомных записей. Обратите внимание, что очистка фантомных записей может блокироваться, если вторичная реплика отключена или если перемещение данных в базе данных-получателе приостановлено. Это состояние также предотвращает усечение журнала, поэтому, если оно не проходит, рекомендуется удалить эту базу данных-получатель из группы доступности.
Операция DBCC SHRINKFILE может завершиться с ошибкой в первичной реплике, если файл содержит фантомные записи, которые все еще необходимы во вторичной реплике.
Примечание |
---|
При выполнении запроса к динамическому административному представлению sys.dm_db_index_physical_stats на экземпляре сервера, на котором размещена вторичная реплика, может возникнуть критическое препятствие REDO. Это связано с тем, что данное динамическое административное представление получает блокировку (IS) в указанной пользовательской таблице либо в представлении, которые могут блокировать запросы посредством потока REDO для монопольной блокировки (X) этой пользовательской таблицы или представления. |
[В начало]
Вопросы производительности
В этом разделе рассматриваются некоторые соображения в отношении производительности баз данных-получателей с доступом для чтения
В этом разделе.
Задержка данных
Влияние на рабочую нагрузку только для чтения
Индексирование
Статистика доступа к базам данных только для чтения
Задержка данных
Применение доступа только для чтения ко вторичным репликам полезно, если для нагрузок, связанных с операциями с ними, приемлема некоторая задержка данных. В ситуациях, когда задержка данных неприемлема, рассмотрите возможность выполнения рабочих нагрузок только чтения за счет первичной реплики.
Из основной реплики выполняется отправка журнала изменений в базе данных-источнике на вторичные реплики. На каждой базе данных-получателе выделенный поток повтора применяет записи журнала. В базе данных, доступной для чтения, каждое изменение данных не появляется среди результатов запроса до тех пор, пока запись журнала о данном изменении не будет применена к базе данных-получателю, а транзакция не будет зафиксирована в базе данных-источнике.
Это означает, что между первичной и вторичной репликами возникает некоторая задержка, обычно порядка нескольких секунд. В нетипичных случаях, например в ситуации, когда проблемы с сетью ухудшают пропускную способность, задержка может стать значительной. Задержка увеличивается из-за наличия узких мест в системе ввода-вывода и в результате приостановки движения данных. Для отслеживания приостановок перемещения данных можно использовать Панель управления AlwaysOn или динамическое административное представление sys.dm_hadr_database_replica_states.
Влияние на рабочую нагрузку только для чтения
При настройке вторичной реплики для доступа только для чтения, нагрузки только для чтения в базах данных-получателях потребляют системные ресурсы, т. е. ресурсы процессора и системы ввода-вывода, за счет потоков повтора, в особенности если нагрузка операций чтения приходится на операции ввода-вывода.
Рабочие нагрузки только чтения на вторичных репликах могут также блокировать изменения с помощью языка описания данных (DDL), проводимые через записи журнала. Даже несмотря на то, что операции чтения не вызывают совмещаемых блокировок в связи с управлением версиями строк, эти операции вызывают блокировки стабильности схемы (Sch-S), что может приводить к блокировке операций повтора, в которых применяются изменения с помощью DDL.
Необходимо учитывать рекомендации по построению запросов и следовать им в работе с базами данных-получателями. Например, планируйте долговременные задачи, такие как статистическая обработка данных, на периоды наименьшей активности.
Примечание |
---|
Когда поток повтора блокируется запросами ко вторичной реплике, возникает событие XEvent sqlserver.lock_redo_blocked. |
Индексирование
Чтобы оптимизировать рабочие нагрузки только чтения в доступных для чтения вторичных репликах, можно создать индексы на таблицах в базах данных-получателях. Возможность вносить изменения в схемы или данные баз данных-получателей отсутствует, поэтому следует создать индексы в базах данных-источниках и разрешить перенос изменений в базы данных-получатели с помощью процесса повтора.
Чтобы отслеживать действия, использующие индекс во вторичной реплике, следует выполнить запрос к столбцам user_seeks, user_scans и user_lookups динамического административного представления sys.dm_db_index_usage_stats.
Статистика доступа к базам данных только для чтения
Статистика по столбцам таблиц и индексированных представлений используется для оптимизации планов запросов. Что касается групп доступности, то статистика, создаваемая и поддерживаемая по базам данных-источникам, автоматически сохраняется в базах данных-получателях в ходе применения записей журнала транзакций. Однако рабочая нагрузка только чтения в базах данных-получателях может требовать иной статистики, чем статистика, формируемая в базах данных-источниках. Однако поскольку базы данных-получатели доступны только для чтения, данные статистики в них сохранять нельзя.
Для решения этой проблемы во вторичной реплике, в базе данных tempdb создается и ведется временная статистика для баз данных-получателей. Суффикс _readonly_database_statistic добавляется к имени временной статистики. Он позволяет отличить временную статистику от постоянной, которая сохраняется в основной базе данных.
Только SQL Server может создавать и обновлять временную статистику. Тем не менее можно удалять временную статистику и наблюдать за ее свойствами с помощью тех же средств, которые используются для работы с постоянной статистикой.
Удаление временной статистики с использованием инструкции Transact-SQL DROP STATISTICS.
Наблюдение за статистикой ведется с помощью представлений каталога 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. Этот суффикс нельзя использовать при создании статистики в базе данных-источнике. Дополнительные сведения см. в разделе Статистика.
[В начало]
Рекомендации по планированию загрузки
Вторичным репликам, предназначенным только для чтения, может потребоваться свободное место в базе данных tempdb по двум следующим причинам.
Применение уровня изоляции моментальных снимков приводит к копированию версий строк в базу данных tempdb.
В базе данных tempdb создается и ведется временная статистика для баз данных-получателей. Временная статистика может привести к небольшому увеличению размера базы данных tempdb. Дополнительные сведения см. в пункте Статистика баз данных, предназначенных только для чтения далее в этом разделе.
При настройке доступа для чтения для одной или нескольких вторичных реплик база данных-источник добавляет 14 дополнительных байт для удаляемых, изменяемых или вставляемых строк данных для сохранения указателей на версии строк в базах данных-получателях. Эти дополнительные 14 байт переносятся в базы данных-получатели. Так как к строкам данных добавляются 14 байт, может происходить разбиение страниц.
Данные версий строк не формируются в базах данных-источниках. Вместо этого версии строк создаются базами данных-получателями. Тем не менее управление версиями строк увеличивает объем хранения данных как в базах данных-источниках, так и в базах данных-получателях.
Добавление данных управления версиями строк зависит от настройки уровня изоляции моментальных снимков или уровня изоляции моментальных снимков с чтением зафиксированных данных (RCSI) в базе данных-источнике. В следующей таблице описано поведение управления версиями в базе данных-получателе, доступной для чтения, в различных ситуациях.
Доступна ли для чтения вторичная реплика?
Включен ли уровень изоляции моментальных снимков или RCSI?
База данных-источник
База данных-получатель
Нет
Нет
Отсутствуют версии строки, либо 14-байтовые издержки
Отсутствуют версии строки, либо 14-байтовые издержки
Нет
Да
Версии строк и 14 дополнительных байт
Нет версий строк, но есть 14 дополнительных байт
Да
Нет
Нет версий строк, но есть 14 дополнительных байт
Версии строк и 14 дополнительных байт
Да
Да
Версии строк и 14 дополнительных байт
Версии строк и 14 дополнительных байт
[В начало]
Связанные задачи
Настройка доступа только для чтения в реплике доступности (SQL Server)
Настройка маршрутизации только для чтения в группе доступности (SQL Server)
Создание или настройка прослушивателя группы доступности (SQL Server)
Используйте диалоговое окно «Создание группы доступности» (SQL Server Management Studio)
[В начало]
См. также
[В начало]
См. также
Основные понятия
Обзор групп доступности AlwaysOn (SQL Server)
Сведения о доступе клиентского соединения с репликами доступности (SQL Server)