SQL AlwaysOn - Что делать, если вы не используете его в качестве кластера / отработки отказа?

Question

Мне предложили концепцию использования двух SQL-серверов, использующих AlwaysOn в качестве формы репликации.

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

Поскольку кажется, что предложение неопределенное, поскольку нет информации о настройке чего-либо подобного, кто-нибудь узнает, хорошая это или ужасная идея?

ДОБАВЛЕНО ПРИМЕЧАНИЕ: нет кластеризации или прослушивателя AG,Серверы сгруппированы, но доступны и адресованы напрямую.

Answer 1

Начиная с SQL Server 2017, кластеризация или прослушиватель не нуждаются в предоставлении решения для вашего сценария.

Однако следует учесть несколько вещей:

• AlwaysOn включает уровень изоляции READ_COMMITED_SNAPSHOT на первичном сервере.Это означает, что накладные расходы на TEMPDB и дополнительные 14 байтов на строку при каждом изменении строки
• В случае асинхронного режима время ожидания данных на вторичном сервере может быть близко к основному серверу.
• Версии, более старые, чем SQL Server 2017, требуют WSFC.

Следовательно, читаемые вторичные компьютеры AlwaysOn имеют свои плюсы и минусы по сравнению с доставкой журналов:

• Плюсы:
  • Нет необходимости прерывать соединения, потому что нет необходимости восстанавливать журналы
  • Данные могут иметь почти постоянную актуальность
• Минусы:
  • Только для Enterprise Edition
  • 14 байт для каждой измененной строки в первичной реплике, поэтому рекомендуется изменить коэффициент заполнения со 100 на 90, чтобы избежать затрат на разбиение страницы
  • Сложнее поддерживать

Относительно вашего вопроса:

Кто-нибудь знает, если это хорошая или ужасная идея?

AG читаемые вторичныеопределенно стоит PПробная версия OC, особенно если вашей компании требуются навыки / ресурсы

(Отказ от ответственности: этот пост основан на моем личном мнении)