гарантирует ACID где буква «C» означает Consistency — Согласованность.
В пределах одного кластера postgresql. Т.е. одного сервера.
возможна ли ситуация когда ключи «X» и «Y» уже реплицированны на сервер «B», но еще не реплицированны на сервер «C»? При асинхронной репликации?
By design. Потому это и названо асинхронной репликой. Между коммитом на мастере и приходом каждого отдельного асинхронного слейва в это состояние всегда будет какой-то временной лаг.
Но timeline один на всех, т.к. его ведёт мастер. Ситуация, что на B записан только X, а на C только Y - исключена.
Синхронная реплика - мастер не ответит клиенту "записано" пока не получит отклик от синхронных реплик из synchronous_standby_names, что те получили эти wal (дефолт, гарантирует, что данные есть минимум на двух машинах и при внезапном сбое вы их не потеряете), применили эти изменения (synchronous_commit=remote_write соответственно два кластера postgresql синхронны. Из-за CAP теоремы теоретически возможно, что при сбое мастера на слейве эта транзакция будет уже записана, а на мастере значится как прерванная. Не знаю, что именно по этому поводу сделано).
Внимание, что при потере работоспособности синхронной реплики мастер будет доступен только на чтение. Все пишущие транзакции будут ждать возвращения синхронной реплики.
Гарантируется ли согласованность в системе из нескольких реплицируемых серверов?
Смотря чем вам допустимо жертвовать для этого. См. CAP теорему.
Это, разумеется, справедливо только для встроенной бинарной потоковой репликации WAL. Логическая в 10 будет жить по своим особым правилам, как и сторонние триггерные решения.
Средний
