21

Есть три базы на трёх хостах.(host1, host2 - debian, main - centos, postgress 9.4) Настроена репликация с помощью букардо тремя синками.

т.е. есть три базы

  • main

  • host1

  • host2

и синки

  • main:source host1:source

  • main:source host2:source

Сделано разными, т.к. если все объединить в одну, то при недоступности host1 или host2 отваливается вся цепочка синхронизации. (Это если настраивать как в примерах, одна группа main host1 host2 и один синк)

Есть следующая проблема - при изменении (не синхронизацией) main - host1 и host2 получают необходимые изменения, но при изменении только в host1 изменения получает только main, в host2 оно не идёт.

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

Saidolim
  • 8,341
  • 4
  • 26
  • 48
Чад
  • 9,073
  • В примерах приводят сначала добавление группы мульти-мастеров через bucardo add dbgroup, а потом создание одного синка для этой группы через bucardo add sync. – Visman Aug 09 '15 at 13:16
  • я думаю, стоит ещё указать в вопросе и используемые версии postgresql, и под управлением каких именно операционных систем (с уточнением версий) работают машины. – aleksandr barakin Aug 09 '15 at 15:47
  • Visman, по примерам и настроено. При этом происходит выше описанная проблема. – Чад Aug 09 '15 at 16:35
  • 1
    а что будет если синхронизацию следать по цепочки? main -> host1, host1->host2, host2->main ? и ставить глушители что бы остановилась? – Saidolim Aug 21 '15 at 11:45
  • 1
    Ну глушители не надо, изменения по синхронизации в одном синке не будут вызывать синхронизацию в другом. Добавить синки без мейна не пробывал, надо подумать, спасибо за идею – Чад Aug 21 '15 at 18:03
  • Saidolim Djuraev, оформите свою идею ответом, чтобы я мог присвоить конкурные очки. Ваша идея решает проблему синхронизации. Правда остаются ещё глюки букардо, по восстановлению при пропажи связи кусков звеньев, но это можно решать костылями в виде проверки статуса кроном и перезапуском синков – Чад Aug 24 '15 at 06:58
  • @Чад: вынес комментарий в общий ответ. Будет здорово, если вы добавите что-нибудь про детали реализации. – Nick Volynkin Aug 29 '15 at 08:02
  • Обязательно добавлю, как получится полное решение (с возобновлением синхронизации, пока это костылём - букардо не востанавливает звено если оно отвалилось) – Чад Aug 31 '15 at 08:45

2 Answers2

12

В итоге, для того чтобы независимо синхронизировать N узлов, необходимо создать парные звенья между всеми участниками (звезда, если не ошибаюсь то будет N*(N-1)/2 синков). Т.е. например для 4тырёх баз надо сделать следующие группы и синки:

dbgoups(и синки на них):

  • g_1_2 (db_1:source db_2:source)
  • g_1_3 (db_1:source db_3:source)
  • g_1_4 (db_1:source db_4:source)
  • g_2_3 (db_2:source db_3:source)
  • g_2_4 (db_2:source db_4:source)
  • g_3_4 (db_3:source db_4:source)

Правда остаются ещё глюки букардо, по восстановлению при пропажи связи кусков звеньев, но это можно решать костылями в виде проверки статуса кроном и перезапуском синков (bucardo activate/deactivate, причём, ещё заметил, чтобы выйти из статуса Stalled надо сначала сделать deactivate, дождаться Inactive, и потом сделать activate. При этом, если база не доступна, то он будет висеть на этом процессе и не активировать другие, пока статус самой базы не поставить в inactive. Т.е. по факту, прежде чем выводить из статуса Stalled, надо убедиться что база действительно доступна)

К сожалению их решить можно только крон скриптом который будет смотреть статус и пытаться их активировать заново. Текущая версия букардо имеет ряд ошибок которые это делают неправильно, как признаётся сам разработчик

Nick Volynkin
  • 34,094
Чад
  • 9,073
2

Немного практики к вышеозвученной теории:

http://goncharov.mobi/ru/posts/11-asinhronnaya-master-master-replikatsiya-v-postgresql-s-pomoschyu-bucardo

Мстислав Павлов
  • 6,777
  • К сожалению там мало чего интересного по теме вопроса, но ссылка пусть будет – Чад Sep 17 '15 at 05:52