я же привел пример, мы даже попытаемся что-то такое сделать (возможно)

просто не стоит делать распредленную фс

мастер-мастер ал-я оракл рак ты не получишь

а оракл-рак требует много денег

перкрна :D

и не работает нормально без нет-апп между цод (что требует тоже много денег)

CAS-теорему не наебёшь

percona*

хоть с раком хоть без рака

там хвалят xtradb

но ты в дата файлы будешь одним мастером или каша

cas - не наебешь, но тебе не нужно её наебывать-то

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

у тебя завалялось пару атомных часов?

на специальных мамках

(не будешь)

ну это кстати не обязательно

я про мамки

потому как стоковые мамки вносят в работу часов нехеровое лейтенси

тоже не совсем верно

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

что в принципе и для банка норм

98 - это очень мало же

если ты не биржа - нормально

ну вот у нас в базе 2% строк неконсистентно (разные на разных шардах)

не-не

у тебя такой херни не будет в эти 2% )

что - не-не

разные... mysql, postgre, redis, elastic

За постгрес скажу что единственное его требование чтобы он выполнял свою задачу как надежная датабаза это уверенный системный вызов fsync на данной фс. Если фс прикидывается что она его делает а на самом деле нет, то такую фс нельзя для pg использовать. Как файловая помойка норм, для дата базы нет. Лучше шардировать данные в приложении

у тебя распределенная база с возможностью конфликтов и алгоритмом решения

да

кассандра, например

кассандра - не дает тебе 100%

ну или spanner, если ближе к атомным часам

но spanner работает на специальном железе

да тебе вообще ничто не даст гарантии)

а на стоковом - работает херово (давно читал)

можно просто улучшать 9-ки

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

кассандра - не дает тебе 100%

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

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

Не надо. Быстро точно не будет. Некоторый опыт имеется. Для ha норм. Для скорости никак не получается

хорошо быть кассандрой

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

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

Прекрасная датабаза, я считаю =)

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

хер с ним с диском, даже в ram распределенные системы или используют честную распределенную транзакцию (cocroachdb for example), или не обспечивают консистентность

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

Прекрасная датабаза, я считаю =)

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

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

А где граница?

самый лучший режим ее использования - записал и читаешь

А где граница?

там, где разница во времени на разных нодах, синхронизирующихся с одного ntp сервера

в идеале - просто записал?)

ага

на чтение у нее бывают дикие тормоза :)

dev/null же отличная хранилка и чтение быстрое

хороших баз нет в принципе

не написали ишшо

есть

memcached

low expectations!

что бывает, когда один из шардов ляжет

там нет шардов

шарды только в твоем приложении)

это не редис)

но в приложении-то есть

ну проблемы твоего приложения

🙂 сделал бы два - нет проблем

что - два?

memcached вообще не субд

ну слава богу! а то подумал бы что идеальную написали

Вам надо посмотреть kubectl logs имяпода

тут все супер инормативно Error from server (BadRequest): container "mongo" in pod "techno3-prod-mongo-0" is waiting to start: PodInitializing что в принципе и так понятно из ситуации

@LuckySB в рамках того issues что ты писал, проблема там не с пингом контейнера, а в том, что сам контейнер с монгой не поднимается, висит в состоянии PodInitializing peer-finder его честно ждет

@LuckySB в рамках того issues что ты писал, проблема там не с пингом контейнера, а в том, что сам контейнер с монгой не поднимается, висит в состоянии PodInitializing peer-finder его честно ждет

согласись, что это неправильное поведение, когда первый под ждет кого-то

согласись, что это неправильное поведение, когда первый под ждет кого-то

соглашусь, в этом моменте нечего обсуждать

тебе удалось победить эту проблему?

нет. надо вот этот гошный бинарь собрать https://github.com/kubernetes/contrib/blob/master/peer-finder/peer-finder.go

нет. надо вот этот гошный бинарь собрать https://github.com/kubernetes/contrib/blob/master/peer-finder/peer-finder.go

собрать не проблема ты думаешь в нем уже есть решение?

там опция domain появилась

сейчас тогда Go поставлю, собиру

а потом свой образ для инит контейнера - name: install image: "{{ .Values.installImage.repository }}:{{ .Values.installImage.tag }}" args: - --work-dir=/work-dir imagePullPolicy: "{{ .Values.installImage.pullPolicy }}" volumeMounts: - name: workdir mountPath: /work-dir