Postgres синхронная репликация?

Question

[Devtime]

Добрый день.
В PostgreSQL есть синхронная репликация через настройку synchronous_commit = on (https://postgrespro.ru/docs/postgrespro/12/runtime... на мастере.
Поднял 1 мастер ноду и 2 слейва. Настроил репликацию корректно postgres говорит что оба слейва работают через синхронную репликацию.
Для проверки написал скрипт который делает вставку в мастер и потом извлекает данные из двух слейвов.
Для теста вставляю подряд 1000 записей. При поиске их в слейвах иногда находит не все записи. Например находит 998 из 1000 вставленных. Если добавить небольшую задержку, то находятся все записи стабильно.
При synchronous_commit = on мастер должен ждать подтверждения что данные сохранены на диск от каждого синхронного слейва и только после этого отвечать клиенту об успешной вставке.
Может кто сталкивался с подобной проблемой?

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

Для теста поднимал в контейнерах и задавал вопросы на гитхабе. Возможно более детальное описание проблемы будет там https://github.com/bitnami/bitnami-docker-postgres...

Answer 1

[Melkij]

Момент первый: какой synchronous_standby_names?
Момент второй:

репликация через настройку synchronous_commit = on

https://www.postgresql.org/docs/current/runtime-co...

When set to on, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and flushed it to disk.

When set to remote_apply, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and applied it, so that it has become visible to queries on the standby(s).

Разницу чувствуете?

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

Очень необычный workload. Ни разу такого не встречал.
Мне любопытно, что вы такое делаете, что вам неважна латентность записи, у вас тяжёлая пишущая нагрузка (не путать с объёмом пишущей нагрузки - репликам это всё писать придётся так же, но ещё и читать), очень много крайне критичного к лагу асинхронной репликации чтения.

Comments

[Devtime]

Спасибо большое за ответ.
remote_apply помог при решении проблемы. Я по неопытности думал что после сохранения на жесткий диск все транзакции уже применены (до этого они лежат в оперативной памяти)

Хочу попробовать поднять 1 мастер и две синхронные репликации. Балансировать нагрузку на мастер + 2 реплики на чтение, но т.к. в программе могут идти запись и затем сразу чтение данных реплики к моменту чтения обязательно должны быть синхронны с мастером, иначе возможны ошибки при запросах.

Вопрос немного не по теме. Можете посоветовать хороший балансировщик, который можно дополнительно настроить скриптами правила маршрутизации запроса? В нашем проекте используются в данный момент очень много хранимых процедур, отказаться от которых мы сейчас не можем. Поэтому в правила необходимо указать что вызов хранимой процедуры всегда отправлять в мастер, т.к. там часто бывают процедуры с изменением данных.

[Melkij]

Я по неопытности думал что после сохранения на жесткий диск все транзакции уже применены (до этого они лежат в оперативной памяти)

Здесь нюанс - сохранение чего именно.
Получение потока изменений - это один процесс, walreceiver. WAL он получает с primary, пишет на диск (synchronous_commit = remote_write), дёргает fsync для гарантии того что в случае краха эта транзакция уже сохранена локально (on)
применение изменений к базе - выполняется полностью отдельно и асинхронно от получения данных - процесс startup (remote_apply)
И оба они имеют лишь опосредованное отношения к записи применённых изменений непосредственно в базе на диск - этим занимаются отдельные процессы bgwriter и checkpointer (ну, в норме, если успевают - если не успевают то и startup придётся писать датафайлы)

Можете посоветовать хороший балансировщик, который можно дополнительно настроить скриптами правила маршрутизации запроса?

select * from something;
Это запрос читающий или пишущий? Да неизвестно! Что даёт вам основание решить, что something - это таблица, а не, например, view поверх пишущей хранимки?
Кто это знает наверняка? Разработчик приложения. Следовательно наиболее корректное место для деления запросов по серверам - это само приложение.
Делить запросы необходимо на следующие группы:
- запись и чтение критичное к лагу
- чтение oltp, быстрые запросы, малое отставание реплик
- чтение olap некритичное к лагу. Долгие запросы, реплики могут отставать заметно

Балансировать по наборам равнозначных серверов - например, haproxy. Но выбор на какую группу серверов отправлять - задача приложения.

Чтение с синхронной реплики... Ну, попробуйте. Есть большие опасения что хорошо это работать не будет. Синхронные реплики они в первую очередь про "не потерять транзакцию" чем про лаг репликации.

Фанатично убирать всё чтение с мастера только потому что это чтение, а это - мастер - бесполезные хлопоты, будете героически решать несуществующие проблемы. (ну да, понимаю, это в традициях IT - искать проблемы где их никогда не было и героически решать) Когда команда только начинает упираться в один сервер - понятное дело что приложение рассчитано на работу на одном сервере СУБД. Но очень хорошего результата можно достичь убрав на реплику всего несколько запросов точечно. Включите pg_stat_satements, через сутки посмотрите что у вас в топе по нагрузке и наверняка увидите то, что можете легко унести на обычную асинхронную реплику. Может быть настроенную на малое отставание, а может - отдельно для тяжёлых запросов некритичных к лагу вообще.

[Devtime]

Melkij, спасибо за ответ. Почти все этапы описание Вами у нас стоят в плане. Метрики собираем в данный момент для анализа.
Но инфраструктурой занимается сам клиент, поэтому хотим обкатать самый простой вариант масштабирования системы.
В данный момент он работает на своём железе 64 ядер на sql сервере. База около 1.7 ТБ. Планирует уход в «облака» (выбор пал на Ростелеком, т.к. пдн важные хранятся). А Ростелеком по словам клиента максимум даст машины 16 ядер. Процентов 80 запросов это чтение по количеству. По трафику 95%+ чтение.
Сервер 64 ядра загружен процентов 20-30 большую часть времени.

По поводу вьюшек и т.п. у нас проблем нет. Главная проблема это наследие хранимых процедур (порядка 1700 в данный момент) рефакторить их не планируем, будет серьезная переделка сервера приложений с попутным удалением почти всех хранимок. Поэтому повышение времени записи скорее всего скажется не значительно, а размазывание чтения может помочь пройти в ограничения Ростелекома.

[Melkij]

Devtime,

хотим обкатать самый простой вариант масштабирования системы.

Но смотрите как раз на самый сложный.

Ростелеком, мда. А селектел какие-нибудь чего? Хорошее железо под базу у них есть.

[Devtime]

Melkij, У клиента требования от ФСБ и кроме Ростелекома они отказываются кого-то рассматривать.

По затратам на разработку самый простой. Переписывания кода не требуется.

В администрировании в принципе тоже не проблема поднять реплики. балансировщика 1 раз настроил и забыл (если получим какой-то эффект от подобной схемы работы).

[Melkij]

Простой, ага, как бы не так. Если бы это было просто.