Если мы сравним несколько типов репликации (с одним лидером, с несколькими лидерами или без лидера), то репликация с одним лидером может быть линеаризуемой. В моем понимании линеаризуемость означает, что после завершения записи все последующие чтения должны возвращать это значение или более позднюю запись. Другими словами, должно быть впечатление, если есть только одна база данных, но не больше. Так что, я думаю, устаревших чтений нет.
PostgreSQL в своей потоковой репликации имеет возможность делать все свои реплики синхронными, используя synchronous_standby_names
а также имеет возможность тонкой настройки с synchronous_commit
вариант, где он может быть установлен на remote_apply
, поэтому лидер ждет, пока транзакция не будет воспроизведена на резервном сервере (что сделает ее видимой для запросов). в документацияв абзаце, где говорится о параметре remote_apply, говорится, что он позволяет балансировать нагрузку в простых случаях с причинной согласованностью.
Несколько страниц назад сказано этот:
,, Некоторые решения являются синхронными, что означает, что транзакция изменения данных не считается подтвержденной, пока все серверы не подтвердят транзакцию. Это гарантирует, что при аварийном переключении не будут потеряны никакие данные и что все серверы с балансировкой нагрузки будут возвращать согласованные результаты независимо от того, какой сервер запрашивается,
Поэтому я изо всех сил пытаюсь понять, что может быть гарантировано и какие аномалии могут произойти, если мы балансируем нагрузку на запросы чтения к репликам чтения. Могут ли еще быть устаревшие чтения? Может ли это случиться, когда я запрашиваю разные реплики, чтобы получить разные результаты, даже если после этого не происходит запись на лидере? Мое впечатление - да, но я не совсем уверен.
Если нет, как PostgreSQL предотвращает чтение устаревших данных? Я не нашел ничего более подробного, как это полностью работает под капотом. Использует ли он двухфазную фиксацию или какую-то ее модификацию, или использует какой-либо другой алгоритм для предотвращения устаревшего чтения?
Если он не предоставляет возможность не читать устаревшие данные, есть ли способ сделать это? Я видел, что PgPool должен иметь возможность балансировать нагрузку на реплики, которые не превышают определенный порог, но я не понимал, можно ли определить балансировку нагрузки на реплики, которые идут с лидером.
Мне действительно сложно понять, могут ли возникнуть аномалии при полностью синхронной репликации в PostgreSQL.
Я понимаю, что при такой настройке есть проблемы с доступностью, но теперь это не проблема.