зачем такие странные вопросы?

зачем такие странные вопросы?

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

cнимай таблицу маршрутиризации с роутера

мне кажется такого никто не даст ни один из сетевиков.

я сюда пришёл попакать по поводу того что постгрес не очень, а еще тут есть @pensnarik

Всё? PostgreSQL надо теперь покупать?

Вот почему: http://1c.ru/news/info.jsp?id=23569

при чем тут постгрес не очень

мне кажется такого никто не даст ни один из сетевиков.

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

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

ошибаетесь

все вопрос закрыт

при чем тут постгрес не очень

ну я не понимаю твоего подгарания, ну типа мы все в чатике с определенным названием что само по себе уже говорит, чуть меньше конечно чем если бы мы были в чатике про монгодб. И тут ты начинаешь защищать очень не адекватное по сравнению с другими решение что меня просто в тупик ставит.

мне кажется такого никто не даст ни один из сетевиков.

почему? всего то разрешить выполнять только одну команду show ip route

почему? всего то разрешить выполнять только одну команду show ip route

Спасибо, но мне кажется это не безопасное решение. Если безопасники на такое идут ,то мне нечего сказать.

когда кажется - креститься надо

пусть looking glass тебе сделают тогда

когда кажется - креститься надо

спасибо за ответ!

почему? всего то разрешить выполнять только одну команду show ip route

А чего небезопасного?

почему? всего то разрешить выполнять только одну команду show ip route

Ой, не тебе

Нувыпонелида

Предметный разговорчик

Вот думаю не поможет ли в организации ha - подтверждение на n реплик из?

что вы имеете ввиду?

Вот думаю не поможет ли в организации ha - подтверждение на n реплик из?

это используется для снижения затрат на ожидания от полного набора реплик

когда нет необходимости ждать ответа от всех

Это должно решить проблему изоляции мастера... Но не подойдёт для географически распределенных систем

Это должно решить проблему изоляции мастера... Но не подойдёт для географически распределенных систем

высокая доступность решается внешними по отношению к пг средствами

используя механизм потоковой репликации

плюс обвязка

это используется для снижения затрат на ожидания от полного набора реплик

могу попробовать ответить на твои вопросы: * если haproxy это одна точка входа, то фенсинг не нужен, клиенты на старом мастере не появятся * если точек входа для клиентов много, то можно делать lease по времени, типо демоут старого мастера делаем в течение 10 секунд после потери связи, а промоут слейва до мастера через 50 секунд. Это дает гарантию, что они не промоутятся одновременно в случае если чьи-то часы не идут в пять раз быстрее (при чем тут именно скорость, а не синхронизация дат, надо просто отсчитать время) * коросинк по сравнению с etd мягко говоря архаичен. Но имеет поддержку от редхата

Вообще на haproxy можно же сервер просто отключать - чем не фэнсинг

+2

Другое дело, что на том проекте где я автосвичовер делал - точек входа много - много haproxy (10 штук)

Хороший ответ

И тот и тот

Спасибо

В роли фенсинга используется сторонняя обвязка ввиде patroni, который и управляет pg. Так же и отдает ответ о состоянии - up down. А трафик с мертвого мастера уводит хапрокси на живой мастер

В роли фенсинга используется сторонняя обвязка ввиде patroni, который и управляет pg. Так же и отдает ответ о состоянии - up down. А трафик с мертвого мастера уводит хапрокси на живой мастер

как обеспечить ха хапрокси?

В роли фенсинга используется сторонняя обвязка ввиде patroni, который и управляет pg. Так же и отдает ответ о состоянии - up down. А трафик с мертвого мастера уводит хапрокси на живой мастер

По сравнению с физическим выключением ноды тут есть слабое место на которе указывал @slysha. Если старый мастер на самом деле жив и к нему имеют доступ какие-то системы, то отсутствие сплитбрейна гарантируется тем, что обвязка выключит этот постгрес. Но легко можно представить себе ситуацию, когда у неё это не получится — ну, например, OOM-killer убил процесс мониторилки. Тогда будет два рабочих мастера.

Другое дело, какая вероятность такого сценария.

oom-киллер кстати можно отключить для процесса мониторилки. https://backdrift.org/oom-killer-how-to-create-oom-exclusions-in-linux

сегодня как раз проверяли. systemd так просто не дает убить обвязку запускает сразу рестарт сервиса. правда можно еще убить и ее %)

так же есть например кейс оом киллера и процесса пг когда в момент рестарта инстанса обвязка думает что уже пора %)

По сравнению с физическим выключением ноды тут есть слабое место на которе указывал @slysha. Если старый мастер на самом деле жив и к нему имеют доступ какие-то системы, то отсутствие сплитбрейна гарантируется тем, что обвязка выключит этот постгрес. Но легко можно представить себе ситуацию, когда у неё это не получится — ну, например, OOM-killer убил процесс мониторилки. Тогда будет два рабочих мастера.

да, но patroni не допустит и этого) Так как новый мастер не появится пока не пропадет замок старого)

как обеспечить ха хапрокси?

на одном сервере - каруселью из iptables. Или чекалкой, чтоб сразу выводила весь фронт из балансировки

так же есть например кейс оом киллера и процесса пг когда в момент рестарта инстанса обвязка думает что уже пора %)

при этом можно не рестартит пг и переключится

мне кажется нодо чтобы ха была заложена в драйвер.

как в jdbc

для ado connect такого пока не нашли. кстати может кто знает?

ессли драйвер сам может выбирать то есму не надо сложного решения

это я в отношении ха для хапрокси

да, но patroni не допустит и этого) Так как новый мастер не появится пока не пропадет замок старого)

не знаю что такое замок, но ситуация принципиальная. Вот мы отрезали мастер по сети от остальных участников кластера и сразу же прибили на нем все процессы патрони/etcd. Что произойдет?

долго отвечать, я просто с домофона пишу. Но скажу что это самая благоприятная ситуация)

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

долго отвечать, я просто с домофона пишу. Но скажу что это самая благоприятная ситуация)

мы подождём %)

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

зачем?

зачем?

если не имеют, то мы просто на хапрокси выставим нового мастера, а в старого никто писать не будет

а

если не имеют, то мы просто на хапрокси выставим нового мастера, а в старого никто писать не будет

если что то выставлять на хапрокси то это не ха

не знаю что такое замок, но ситуация принципиальная. Вот мы отрезали мастер по сети от остальных участников кластера и сразу же прибили на нем все процессы патрони/etcd. Что произойдет?

Произойдет следующее (убивать etcd я не рассматриваю, так как это самый простой случай) убиваем patroni-master: 1) Остается работать PostgreSQL как и работал в режиме мастера, какое то время к нему приходят запросы на ЗАПИСЬ (это уже не отногсится к Patroni, а зависит от архитектуры. В моем случае через 3-8 секунд туда перестанет поступать трафик) 2) Эти записи будут реплицироваться в штатном режиме на replicas 3) По истечению 30 секунд (По умолчанию) - TTL записи в etcd замка мастера, он будет удален и втчение 10 секунд будет выбран новый replica В случае отсутствия haproxy будет split brain! Это верно. НО. Как вы попадете на новый мастер? Если ответите (кто-нибудь) на этот вопрос, дам вам печеньку. И даже для таких случаев (У меня было LA под 20 IO под 99%, oom убивал PG и Patroni работал) У Patroni есть watchdog, который убивает сервер при вылете patroni https://github.com/zalando/patroni/blob/master/docs/releases.rst#version-13

если не имеют, то мы просто на хапрокси выставим нового мастера, а в старого никто писать не будет

А что вы делаете, если умирает хапрокси?

Произойдет следующее (убивать etcd я не рассматриваю, так как это самый простой случай) убиваем patroni-master: 1) Остается работать PostgreSQL как и работал в режиме мастера, какое то время к нему приходят запросы на ЗАПИСЬ (это уже не отногсится к Patroni, а зависит от архитектуры. В моем случае через 3-8 секунд туда перестанет поступать трафик) 2) Эти записи будут реплицироваться в штатном режиме на replicas 3) По истечению 30 секунд (По умолчанию) - TTL записи в etcd замка мастера, он будет удален и втчение 10 секунд будет выбран новый replica В случае отсутствия haproxy будет split brain! Это верно. НО. Как вы попадете на новый мастер? Если ответите (кто-нибудь) на этот вопрос, дам вам печеньку. И даже для таких случаев (У меня было LA под 20 IO под 99%, oom убивал PG и Patroni работал) У Patroni есть watchdog, который убивает сервер при вылете patroni https://github.com/zalando/patroni/blob/master/docs/releases.rst#version-13

Чтот странное вы написали. Как трафик узнает что через 3-8 секунд ему туда поступать не надо?

Чтот странное вы написали. Как трафик узнает что через 3-8 секунд ему туда поступать не надо?

у хапрокси не пройдет чек

А что вы делаете, если умирает хапрокси?

бегаю вокруг и кричу: ааа

бегаю вокруг и кричу: ааа

Помогает поднятию? )

очень, наганяй от руководства очень

Я у себя сейчас строю консул и хелс чеки на всю кухню

у хапрокси не пройдет чек

Ладно, надо рисовать ситуацию про которую я говорю, если так не понятно. Но лень уже)

лучше etcd. patroni с ним лучше дружит. с консулом баги были, недавно решили

Ладно, надо рисовать ситуацию про которую я говорю, если так не понятно. Но лень уже)

поверь мне. все ситуации нарисованы. протестированы. Если ты сомневаешься, то это от неправильной архитектуры.

хапрокси чекает патрони. патрони убит - ходить не будет

это про 6 сек

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

Могу завтра нарисовать, если интересно.

нужен рапределенный хапрокси

иначе городить огород когда опять единая точка отказа мне непонятно

virtual ip не не слышал

это про 6 сек

Мы бы кстати у себя в офисе с удовольствием бы послушали какуюнибудь презенташку про Ваш кейс. Приходите как-нибудь к нам в ПостгресПро у нас есть печеньки и куча благодарных слушателей =)

virtual ip не не слышал

в распределенных цодах это проблема

эт другой вопрос

самый первый

на нем обычно заканчивается выбор решения

чатик не читай, камменты оставляй!

:)

откуда начинать? с самого сначала? спасибо за предложение!

нет, я извиняюсь что влез в тред не прочитав.

тык ну так как мне устроить вирт айпе когда у меня например между цодами нету l2?

иначе городить огород когда опять единая точка отказа мне непонятно

где точка отказа? 12 pgbouncer, over 30 haproxy, 3 Дата Центра?

нужен рапределенный хапрокси

Есть платный с vrrp

тык ну так как мне устроить вирт айпе когда у меня например между цодами нету l2?

динамическая маршрутизация. не, не слышал

почемуж слышал даже экзамены сдавал.

Мы бы кстати у себя в офисе с удовольствием бы послушали какуюнибудь презенташку про Ваш кейс. Приходите как-нибудь к нам в ПостгресПро у нас есть печеньки и куча благодарных слушателей =)

тут в чатике есть человек у которого есть опыт создания "шардированного" кластера из 90+ серверов.

где точка отказа? 12 pgbouncer, over 30 haproxy, 3 Дата Центра?

Я думаю просто не совсем понимают как проходит чек на haproxy

На самом деле нет разницы сколько их - хоть у каждого приложения свой - лишь бы чек мертвой ноды провалился и haproxy переключил на живую. Как раз за чек отвечает - получение статуса с patroni - не получил - или получил статус - реплика - трафик не шлешь

тут в чатике есть человек у которого есть опыт создания "шардированного" кластера из 90+ серверов.

смотря как шардировать. в пределах одного дц не проблема

Ну шардинг это насколько я понимаю - anti HA

Распределенка просто