да ладно, БД же начали ложить внутрь виртуальных машин

далёкий город в Оренбургской области что бы это могло значить?

Это уже закономерность - шумные противники DB в докере почти всегда считают , что оно с базами через storage driver работает

не ложить, а класть

drbd сам по себе является сетевым raid1. Если сдыхает диск, drbd переключается на другую реплику. Если сдыхает нода, fencing-controller ее добивает

K8s кластер следует рассматривать как один большой сервер для вашего приложения. А держать на одном сервере приложение и его БД - плохая практика

K8s кластер следует рассматривать как один большой сервер для вашего приложения. А держать на одном сервере приложение и его БД - плохая практика

Видимо из-за меньшей распределённости данных таких рисков как с ceph нет(ну или как минимум их меньше) так? ибо это страшно при size 2 потерять ноду

K8s кластер следует рассматривать как один большой сервер для вашего приложения. А держать на одном сервере приложение и его БД - плохая практика

K8s кластер следует рассматривать как один большой сервер для вашего приложения. А держать на одном сервере приложение и его БД - плохая практика

с чего бы? риски как у raid 1. у ceph с size 3 риски меньше

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

Шах и мат!

в ceph если выйдет нода в окно, то начнётся рекавери который запросто сможет запинать до смерти как минимум 1 диск. RAID1 сам по себе рекавериться не станет(в миссионерском исполнении)

Холм битвы за stateless усеян трупами, но БД-ковбои не сдаются

ребилдить рэйд не собираетесь, будете смотреть на единственный диск, хранить его и изолируете ноду что бы не дай бог в неё кто нибудь не стал писать? :) В реалиях шанс что при ребилде сдохнет единственный диск высок, в raid 1 при двух дисках он выше чем в ceph при 3х.

в ceph если выйдет нода в окно, то начнётся рекавери который запросто сможет запинать до смерти как минимум 1 диск. RAID1 сам по себе рекавериться не станет(в миссионерском исполнении)

Я бы рассматривал конкретные кейсы, если база одна - то вопросов нет, но что делать когда баз 500 шт?

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

а постгрес масштабируется?

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

ммм, бизнес-логика в процедурах

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

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

@vrutkovs астрологи объявили неделю луддитов в @kuberentes_ru - количество упоминаний древнего говна увеличено втрое

Это голоса из вселенной, где кубер остановился на 1.5

вторая копия восстанавливается автоматически?

он же тоже не умеет масштабироваться горизонтально, я прав?

это особенности архитектуры или просто наблюдения? - я просто не вижу чем принципиально отличается постгрес от того же mysql, за исключением расширенного функционала и простоты архитектуры

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

вторая копия не восстанавливается, все данные пишутся синхронно в обе реплики, как только одна становится недоступна, весь i/o осуществляется только со второй репликой

Я бы рассматривал конкретные кейсы, если база одна - то вопросов нет, но что делать когда баз 500 шт?

и что дальше? так и живёте пока последняя не сдохнет или как-то ручками восстанавливаете?

как только вышедшая из строя нода оживает, начинается recovery - он недолгий, так как drbd имеет некий механизм, который сравнивает хэши и синкает только измененные данные, после этого она переходит в UpToDate и снова становится доступна

ну а если не поднялась нода?

ну тогда у тебя на реплику меньше :)

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

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

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

ну как и с любым raid1

не нравится - можно использовать replication factor 3, там можно и кворум включить

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

я лет 7 назад на drbd 2х нодах split brain схватил :)

так вот я и хотел выяснить как иметь rf2 и спать при этом спокойно, а не перекусывать арматуры теми мистами, которые для этого не созданы

часто у вас в raid1 дохли два диска?

клаудмаус наверное тоже так думали

клаудмаус наверное тоже так думали

нужно быть совсем невезучим. У меня в raid-1 ток 1 диск сдох. И перед тем, как сдохнуть, он мне об этом орал в течении 2х недель. Своевременная замена дисков помогает (диск был не enterprise, и ему шел 6й год). Сейчас куда интереснее, когда не raid дохнет, а кабель с браком или контроллер начитает чудить. Но, это все ловится через dmesg.

контроллер raid? сейчас кто-то ещё использует железные контроллеры?

https://ceph-docs.readthedocs.io/ru/latest/cloudmouse.html