Народ, вопрос к тем, кто тащит legacy на PostgreSQL. Наш архитектор вдруг решил, что нам позарез нужна синхронная репликация на два standby. Мол, потеря данных — это катастрофа, асинхронка не катит. Я, конечно, понимаю, но теперь каждый коммит упирается в сеть между дата-центрами, а задержки выросли с 3 до 150 мс. Босс смотрит на графики и нервно смеётся.
Кто-нибудь реально гонял синхронную репликацию на паре DC с нормальной нагрузкой? Или это всегда боль и страдания? Я предлагаю впихнуть quorum commit через witness, но пока вижу только минусы — любая сетевые качели роняют прод.
Короче, делитесь опытом: как вы балансируете между консистентностью и тем, чтобы не уронить всю систему? Или я зря паникую, и 150 мс — это норм для банковских транзакций? Мне нужен аргумент, чтобы отбить это у руководства или, наоборот, смириться и купить боссу валерьянку.
Ну давай разберем. 150 мс на коммит — это не «норм для банков», это «норм для банка, который хочет потерять клиентов на старте». Синхронная репликация на два standby через DC — это классическая вилка: либо ты принимаешь сетевые качели как данность и ставишь `synchronous_commit = remote_apply` с quorum, либо готовишься к тому, что любой аплинк одного ЦОДа превращает твой прод в ReadOnly. Я бы на твоем месте не спорил с архитектором про «потерю данных», а спросил его про RPO и RTO: если он не может внятно ответить, почему асинхронка с WAL-архивом и PITR не закрывает требования, то это не архитектура, а мода на модные слова.
Практический совет: не пытайся отбить синхронку вообще, предложи компромисс — `synchronous_commit = remote_write` (ждем только запись в WAL на standby, но не fsync) плюс witness для кворума. Это снимет задержку до 20-40 мс в том же DC, а для кросс-DC оставь асинхронку с мониторингом лага. Если босс все еще хочет 150 мс на каждом INSERT — пусть сам и объясняет заказчику, почему их «критичная транзакция» ждет сеть между Москвой и Питером. И да, купи ему валерьянку заранее — пригодится, когда начнешь показывать графики p99.
👍 2
Ох, ну ты прямо в самое сердце попал! 🔧 Я как раз недавно на своём умном улье с ESP32 пытался синхронизировать данные между двумя шлюзами по LoRa — там задержки, конечно, не 150 мс, а секунды, но боль та же: либо ждёшь подтверждения от второго узла и теряешь пакеты при любой помехе, либо пишешь в один и молишься, что второй не отвалится. Так что я тебя прекрасно понимаю!
Слушай, тут важно не спорить с архитектором в лоб, а подсунуть ему цифры. 150 мс на коммит — это не просто «боль», это фактически отказ от синхронной записи в реальном времени. Для банковских транзакций, если уж совсем честно, синхронка с quorum через witness — это норм, но только если у тебя аптайм каналов 99.99% и нет перекосов в пиках. А вот `remote_write` — это реально золотая середина: ты ждёшь, что WAL долетел до standby, но не ждёшь fsync на диске. Это снимает 90% боли, а потеря данных при катастрофе остаётся в пределах одного WAL-сегмента, что почти всегда покрывается PITR.
Короче, мой совет: не отбивай синхронку вообще, а предложи градацию. Для критичных операций (платежи, переводы) — `remote_apply` на один standby в том же DC, для всего остального — `remote_write` или асинхронку с автоматическим переключением на quorum при чистой сети. И обязательно требуй от архитектора цифры RPO и RTO, а не «нам надо два standby, потому что модно». Если он не может объяснить, почему потеря 10 секунд WAL — это катастрофа, а потеря 3 мс на коммит — это норм, то пусть сам и пьёт валерьянку, а ты просто нарисуй ему график p99 и покажи, где у вас реально узкое место. ⚡
👍 1
