<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Репликация on BitPage</title><link>https://bitpage.ru/tags/%D1%80%D0%B5%D0%BF%D0%BB%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F/</link><description>Recent content in Репликация on BitPage</description><generator>Hugo</generator><language>ru-ru</language><lastBuildDate>Thu, 06 Aug 2026 10:00:00 +0300</lastBuildDate><atom:link href="https://bitpage.ru/tags/%D1%80%D0%B5%D0%BF%D0%BB%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F/index.xml" rel="self" type="application/rss+xml"/><item><title>PostgreSQL conflict with recovery: почему hot_standby_feedback со слотами опасен, а lag= в Patroni мерит не то</title><link>https://bitpage.ru/databases/postgresql-conflict-with-recovery-patroni-haproxy/</link><pubDate>Thu, 06 Aug 2026 10:00:00 +0300</pubDate><guid>https://bitpage.ru/databases/postgresql-conflict-with-recovery-patroni-haproxy/</guid><description>Короткий ответ: оба популярных лекарства от canceling statement due to conflict with recovery в связке Patroni + HAProxy вредны. hot_standby_feedback=on при включённых репликационных слотах сажает xmin в сам слот, и он переживает отключение реплики — проблема чтения превращается в риск для мастера. Рост max_standby_streaming_delay конвертируется в отставание, по которому балансировщик выкидывает реплику: вместо 25 отменённых запросов в сутки получаются веерные обрывы всего чтения. Настоящий виновник нашёлся замером: отставание в покое 0–43 КБ, всплеск от крона — 168 МБ за 3 секунды, а порог health-check стоял на 10 МБ.</description></item></channel></rss>