смерть мастера все-равно все убъет

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

по идее, запросы распределяются на балансировшике за пределами облака, они тупо там разбиваются на 3 сервера, на каждом сервере копия всех контейнеров

если nginx на одном из них не отвечает - запрос уйдёт на другой сервер, где будет свой nginx, свой код и своя субд, к которой код и полезет с запросом

это если запросы на чтение

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

никак

ну, 1 из вариантов - писать сразу во все 3 базы

если 1 из них недоступна - возвращать 500

другой вариант - выбрать мастер и писать в него, если мастер недоступен - возвращать 500

какие-то варианты всё равно есть

ну а дальше-то что делать?

третий вариант - сделать сетевую файловую систему и туда поставить контейнер с базой

вот у тебя выбранный мастер сломался

и?

тут или 500 (ждём, пока он починится) или переключаем слейв в мастер

и потом после восстановления мастера синхронизируем его

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

и старый мастер тоже становится слейвом

где тут про отказоустойчивость-то?

это же часы ручной работы

эту синхронизацию нельзя автоматизировать?

как те же хостеры, например, делают?

какие хостеры?

ну, какие-нибудь облачные

хероку там какой-нибудь

я работал в подобном "хостере"

там круглые сутки сидит грядка S2L'ей и смотрит в заббикс

https://www.heroku.com/

мм

дада, я знаю, что такое хероку

но у них не три сервера

и они могут себе позволить круглосуточный мониторинг инфраструктуры

а вариант с объединить SSD в сетевую ФС (Ceph какой-нибудь) и там запускать контейнер с PostgreSQL, 1 на облако?

он нормальный?

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

ну, просто для удобства

доставки

и еще помимо устойчивости многих интересует перфоманс и вот тут-то все начинают советовать так не делать

не городить сетевых файловых систем и вот этого всего

производительность сильно падает даже если NVMe диски?

да хоть в памяти держи

ты в сеть упрешься

даже если 10гигабитка?

у тебя 10гбс между серверами?

ну я планирую элтекс купить, там 4 порта будет

мне 3 надо)

мне советовали недорогие свитчи элтекса

http://eltex-msk.ru/catalog/ethernet/ethernet-kommutatoryi-agregaczii/mes3124.html

вот эти вроде

> наличие 2 интерфейсов 10Гбит/с (SFP+),

SFP - это оптические интерфейсы

не медь

у тебя в сервера оптика заходит?

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

я сначала гигабитку сделаю в любом случае

но дальше если нужно будет - сделаю апгрейд сети

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

если нет - то и смысла не будет обновлять гигабитную сеть

пока ты не можешь четко обозначить проблему, решить ее невозможно

так я обозначил - работа PostgreSQL на Ceph

при какой нагрузке 10 гигабитки будет не хватать?

вот если обычные Xeon E5 серверы (ну, супермикра), тот элтексный свитч и интеловские сетевые карточки

а мы вообще точно еще в канале про кубернетес?

это слегка оффтопик, но я хотел бы понять, как пользователи Kubernetes эти проблемы решают

вам ведь тоже СУБД в облаке нужно запускать как-то

я в чём вижу главный плюс систем типа Kubernetes - сломался 1 сервак, а проект работает

если с базой ничего не делать - смысла от Kubernetes не будет

разве нет?

так же, как и не пользователи кубернетес резервирование и отказоустойчивость классических РСУБД имеет очень мало общего с контейнерной виртуализацией и системами оркестрации

я в чём вижу главный плюс систем типа Kubernetes - сломался 1 сервак, а проект работает

это когда у тебя stateless приложений вагон

у меня 20-30 проектов почти без нагрузки

но как только ты приносишь stateful-базу, сказка кончается и приходится решать те же вопросы, которые были без контейнеров

главная цель, чего я хочу от облака - отказоустойчивость

только еще и с контейнерами

у меня 20-30 проектов почти без нагрузки

ты понимаешь, в чем отличие stateful приложений от stateless?

у меня есть stateless приложения с чудовищной нагрузкой, если что

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

что не мешает им оставаться stateless

и они - главные "потребители" систем оркестрации контейнеров