Поддержка высокого уровня доступности в базах данных OLTP в памяти
Применимо к:SQL Server
Базы данных, содержащие оптимизированные для памяти таблицы со скомпилированными в собственном коде хранимыми процедурами или без них, полностью поддерживаются с группами доступности AlwaysOn. В конфигурации и поддержке баз данных, содержащих объекты OLTP в памяти, нет разницы по сравнению с базами данных без них.
Изменения таблиц, оптимизированных для памяти, в первичной реплике применяются к таблицам во вторичной реплике на стадии повтора. Это позволяет быстро выполнять отработку отказа на вторичную реплику, так как данные уже находятся в памяти. Для запросов чтения доступны таблицы во вторичных репликах, для которых был настроен доступ на чтение.
Группы доступности AlwaysOn и базы данных OLTP в памяти
Настройка баз данных с компонентами OLTP в памяти обеспечивает следующие преимущества:
Полная интеграция
Вы можете настроить базы данных, содержащие оптимизированные для памяти таблицы, с помощью одного мастера с тем же уровнем поддержки для синхронных и асинхронных вторичных реплик. Кроме того, вы можете отслеживать работоспособность с помощью знакомых функций мониторинга AlwaysOn в SQL Server Management Studio.Сравнимое время отработки отказа
Вторичные реплики поддерживают состояние в памяти для устойчивых таблиц, оптимизированных для памяти. При автоматической или принудительной отработке отказа время переключения на новую первичную реплику сравнимо с дисковыми таблицами, при этом восстановление не требуется. В этой конфигурации поддерживаются оптимизированные для памяти таблицы, созданные как SCHEMA_ONLY. Однако изменения в этих таблицах не записываются в журнал, поэтому во вторичной реплике в этих таблицах не будет данных.Доступные для чтения вторичные
Вы можете обращаться к оптимизированным для памяти таблицам и запрашивать их во вторичной реплике, если она настроена для доступа на чтение. В SQL Server 2016 (13.x) метка времени чтения на вторичном реплика находится в тесной синхронизации с меткой времени чтения на первичном реплика, что означает, что изменения на первичном объекте становятся видимыми на вторичном быстро. Это поведение тесной синхронизации отличается от SQL Server 2014 (12.x) в памяти OLTP.
Рекомендации
- В SQL Server 2019 реализована параллельная операция повтора для баз данных группы доступности, оптимизированных для памяти. В SQL Server 2016 и 2017 таблицы на диске не используют параллельную операцию повтора, если база данных в группе доступности также оптимизирована для памяти.
Экземпляр отказоустойчивой кластеризации (АСШ) и базы данных OLTP в памяти
Чтобы добиться высокого уровня доступности в конфигурации общего хранилища, можно настроить экземпляр отказоустойчивого кластера с базами данных с оптимизированными для памяти таблицами. При настройке FCI учитывайте следующие факторы:
Цель времени восстановления
Время отработки отказа, вероятно, будет больше, так как оптимизированные для памяти таблицы необходимо загрузить в память перед тем, как база данных станет доступна.Таблицы SCHEMA_ONLY
Имейте в виду, что таблицы SCHEMA_ONLY после отработки отказа будет пустыми (без строк). Это обусловлено приложением. Это точно то же поведение при перезапуске базы данных OLTP в памяти с одной или несколькими таблицами SCHEMA_ONLY.
Поддержка репликации транзакций в базах данных OLTP в памяти
Таблицы, выступающие в качестве подписчиков репликации транзакций, за исключением одноранговой репликации транзакций, можно настроить как оптимизированные для памяти таблицы. Другие конфигурации репликации несовместимы с таблицами, оптимизированными для памяти. Дополнительные сведения см. в разделе Репликация на подписчиков оптимизированных для памяти таблиц.
См. также
Группы доступности AlwaysOn (SQL Server)
Обзор групп доступности Always On (SQL Server)
Активные вторичные реплики. Доступ только для чтения к вторичным репликам (группы доступности Always On)
Репликация в подписчики таблиц, оптимизированных для памяти
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по