LINUX.ORG.RU

Репликация. Правильно ли я понимаю?

 


0

2

В highload решениях часто применяют такую вещь: пишем на master SQL (на который мы только пишем) данные с которого реплицируется на один или несколько slave SQL (с которых мы только читаем).

SQL (я использую Postgresql) гарантирует ACID где буква «C» означает Consistency — Согласованность. Представим ситуацию: есть сервера «A» (master), «B» (slave) и «C» (slave). На сервер «A» в транзакции заносятся атомарно два ключа «X» и «Y». Далее эти ключи с серера «A» должны реплицироваться на сервера «B» и «C». И будут реплицированны атомарно, оба.

Предположим вы читаем данные: случайно выбираем сервер «B» и читаем ключ «X», случайно выбираем сервер «С» и читаем ключ «Y».

Вопрос: возможна ли ситуация когда ключи «X» и «Y» уже реплицированны на сервер «B», но еще не реплицированны на сервер «C»? При асинхронной репликации? При синхронной репликации? Ведь это разные устройста и подобная несогласованность пусть очень короткое время по идее должна быть возможна. Гарантируется ли согласованность в системе из нескольких реплицируемых серверов?

При асинхронном может отставать, но это не противоречит целостности.

redixin ★★★★ ()
Ответ на: комментарий от redixin

это не противоречит целостности

В пределах одного сервера да, но в примере я показал два слейва

quester ★☆ ()
Ответ на: комментарий от quester

В пределах одного сервера да, но в примере я показал два слейва

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

Но какие могут быть проблемы между разными соединениями с БД? Одно соединение может получить более старые данные чем другое. Если это принципиально важно, то можно просто не юзать асинхронные репликации.

redixin ★★★★ ()

Очевидно, что согласованность будет гарантироваться только если хозяйский коммит будет ожидать ответа от всех рабов. Так же очевидно, что такая конфигурация сильно будет снижать производительность записи, поэтому такая цена согласованности мало кому интересна. Поэтому нет, в реальности не гарантируется, поэтому надо жить с меньшими гарантиями.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

+1

Еще добавлю, если при синхронной репликации раб упадет, то запись вообще встанет (мастер)

uspen ★★★★★ ()

Смотрите параметр synchronous_commit. Как указывали выше, будучи включенным, он сильно снижает производительность, но мастер тогда ждёт отклика слейвов.

sand_circle ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.