Отмена инструкции из-за конфликта с восстановлением

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

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

Симптомы

1. При попытке выполнить запрос на реплике чтения запрос неожиданно завершается.
2. Сообщения об ошибках, такие как "Отмена инструкции из-за конфликта с восстановлением", отображаются в журналах или в выходных данных запроса.
3. Может возникнуть заметный задержка или задержка репликации из основной реплики чтения.

На приведенном снимке экрана слева находится основной База данных Azure для PostgreSQL гибкий экземпляр сервера, а справа — реплика чтения.

• Считывать консоль реплики (справа от экрана выше)
  • Мы можем наблюдать за длительным SELECT оператором. Важным аспектом, который следует отметить о SQL, является его согласованное представление данных. При выполнении инструкции SQL она фактически "зависает" в представлении данных. Во время выполнения инструкция SQL всегда видит согласованный моментальный снимок данных, даже если изменения происходят одновременно в другом месте.
• Основная консоль (слева от приведенного выше снимка экрана)
  • Выполнена UPDATE операция. UPDATE Хотя само по себе не обязательно нарушает поведение реплики чтения, следующая операция выполняется. После обновления VACUUM операция (в данном случае вручную активируется для демонстрационных целей, но следует отметить, что процесс автоматической очистки также может быть инициирован автоматически) выполняется.
  • Роль VACUUMзаключается в том, чтобы освободить пространство, удалив старые версии строк. Учитывая, что реплика чтения выполняет длинную SELECT инструкцию, она в настоящее время обращается к некоторым из этих строк, предназначенных VACUUM для удаления.
  • Эти изменения, инициированные VACUUM операцией, включая удаление строк, вошли в журнал записи (WAL). Так как гибкие реплики чтения сервера База данных Azure для PostgreSQL используют собственную физическую репликацию PostgreSQL, эти изменения позже отправляются в реплику чтения.
  • Ниже приведена проблема: VACUUM операция, не зная о текущей SELECT инструкции на реплике чтения, удаляет строки, которые реплика чтения по-прежнему нуждается. Этот сценарий приводит к конфликту репликации.

Последствия этого сценария заключается в том, что реплика чтения испытывает конфликт репликации из-за строк, удаленных операцией VACUUM . По умолчанию реплика чтения пытается устранить этот конфликт в течение 30 секунд, так как значение max_standby_streaming_delay по умолчанию равно 30 секундам. После этого периода, если конфликт остается неразрешенным, запрос на реплике чтения отменяется.

Причина

Основная причина этой проблемы заключается в том, что реплика чтения в База данных Azure для PostgreSQL гибком сервере является непрерывно восстанавливающейся системой. Эта ситуация означает, что в то время как реплика догоняет основной объект, он, по сути, находится в состоянии постоянного восстановления. Если запрос на реплику чтения пытается считывать строку, которая одновременно обновляется процессом восстановления (так как основной сделал изменение), База данных Azure для PostgreSQL гибкий сервер может отменить запрос, чтобы разрешить восстановление продолжаться без прерывания.

Разрешение

1. Изменение: увеличьте max_standby_streaming_delaymax_standby_streaming_delay параметр в реплике чтения. Увеличение значения параметра позволяет реплике больше времени разрешать конфликты, прежде чем он решит отменить запрос. Однако это также может увеличить задержку репликации, поэтому это компромисс. Этот параметр является динамическим, что означает, что изменения вступили в силу без необходимости перезапуска сервера.
2. Мониторинг и оптимизация запросов. Проверьте типы и частоты запросов, выполняемых в реплике чтения. Длительные или сложные запросы могут быть более подвержены конфликтам. Оптимизация или планирование их по-разному может помочь.
3. Выполнение запросов вне пикового уровня. Рассмотрите возможность выполнения тяжелых или длительных запросов во время внепиковой нагрузки, чтобы снизить вероятность конфликта.
4. Включениеhot_standby_feedback: рекомендуется on задать значение hot_standby_feedback для реплики чтения. При включении сервер-источник сообщает о запросах, выполняемых репликой. Это предотвращает удаление основных строк, которые по-прежнему необходимы реплике, что снижает вероятность конфликта репликации. Этот параметр является динамическим, что означает, что изменения вступили в силу без необходимости перезапуска сервера.

Внимание

Включение hot_standby_feedback может привести к следующим потенциальным проблемам:

• Этот параметр может предотвратить некоторые необходимые операции очистки на первичном объекте, что может привести к больших двоичных объектов таблицы (увеличение потребления дискового пространства из-за отмены старых версий строк).
• Регулярный мониторинг места на диске основного и размера таблицы является важным. Дополнительные сведения о мониторинге База данных Azure для PostgreSQL гибкого сервера см. здесь.
• Будьте готовы управлять потенциальными большими двоичными объектами вручную, если это становится проблематичным. Рассмотрите возможность включения автоматической настройки в База данных Azure для PostgreSQL гибкого сервера, чтобы устранить эту проблему.

5. Корректировка max_standby_archive_delay. Параметр max_standby_archive_delay сервера указывает максимальную задержку, которую сервер разрешает при чтении архивированных WAL данных. Если реплика База данных Azure для PostgreSQL гибкого экземпляра сервера когда-либо переключается с режима потоковой передачи на доставку журналов на основе файлов (хотя и редко), это значение может помочь устранить проблему отмены запроса.