Comments 4
Если синхронная реплика окажется недоступной, primary не будет писать в себя изменения, он будет доступен только на чтение.
Вот это самая неприятная часть с синхронной репликацией. Везде пишут, что primary не будет писать в себя изменения, но проблема в том, что он будет это (писать и даже коммитить) делать, но не будет отправлять подтверждение клиенту о том, что он записал и закоммитил, а клиент будет ждать ответа до таймаута (или бесконечно, если таймаута нет). И даже если клиента убить pg_terminate_backend, данные, подтверждения записи которых клиент не получил, на мастере останутся и отправятся на синхронную реплику, когда она оживёт.
Да, правильно — primary будет и писать изменения, и коммитить их, будет ждать до бесконечности возврата синхронной реплики в строй, чтобы передать туда накопленные изменения. Это с точки зрения самой СУБД. Но с точки зрения приложения, все будет выглядеть так, что записать изменения в базу не получается — работа приложения прервется. Избежать потери данных, безусловно, важно, но есть и другая сторона медали — доступность информационной системы. Подозреваю, что «везде пишут» именно о доступности записи для приложения.
Джет, с разморозкой вас)
Sign up to leave a comment.
Нерушимая PostgreSQL, или Как обеспечить отказоустойчивость для «открытой» СУБД