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

Устранение неполадок с георепликацией и задержкой повторного выполнения

Применимо к:Azure SQL Database

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

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

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

Симптомы

  • Устаревшие данные на вторичном сервере для рабочих нагрузок, предназначенных только для чтения (отчеты, аналитика или перенаправленные операции чтения).
  • Более длительное время переключения на резервный ресурс, которое увеличивает целевое время восстановления (RTO).
  • Постоянное давление на ресурсы вторичной системы снижает её способность наверстывать упущенное.
  • Убедитесь, что задержка повтора в DMV sys.dm_database_replica_states увеличивается, если redo_queue_size > 0 растет и secondary_lag_seconds увеличивается.

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

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

Эта ситуация может привести к следующему:

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

Влияние несоответствия размера реплики

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

Если вы настраиваете базу данных-получатель с меньшим размером вычислительных ресурсов, чем база данных-источник, может возникнуть следующее:

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

Рекомендации

Чтобы уменьшить задержку повторного входа и обеспечить работоспособность репликации и эффективное использование журналов в дополнительном объекте:

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

  • Регулярно отслеживайте. Используйте динамические административные представления (DMVs), такие как sys.dm_database_replica_states, для мониторинга задержки перезаписи и размера очереди. Повторная задержка подтверждается, когда redo_queue_size > 0 растет, а secondary_lag_seconds увеличивается.

  • Оптимизация рабочих нагрузок:

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

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

  • Last updated on