Если с базой в принципе все ясно, то как синкать фронт?

От задач зависит, можно статику частично в монго засунуть и там реплицировать. Можно на айнотифи накостылять, можно через р2р технологии на syncthing. Вариантов много, надо под задачу выбирать

Для этого придумали процессинговые центры. Которые обрабатывают все в 1 точке

Alexander: Как раз чтобы рассинхрона не было

Из-за этого до сих пор и мейнфреймы рулят финансами

Рады, что понравилось

да кстати, спс за митап)

Нет там асинхрона и геореплики

Для этого придумали процессинговые центры. Которые обрабатывают все в 1 точке

Идеальный мир недостижим. У всех разные потребности и возможности. У некоторых есть центры, у некоторых нет.

Да, Спасибо за митап!)

Идеальный мир недостижим. У всех разные потребности и возможности. У некоторых есть центры, у некоторых нет.

Говорю как есть

Пожалуйста. Вам тоже спасибо.

Ну ты сам пингани и увидишь, 0,7 сек пинг

Ну 0.7 что-то уж дофига)

Не то слово, до Америки 0.150 , а тут Владик 0,7

От задач зависит, можно статику частично в монго засунуть и там реплицировать. Можно на айнотифи накостылять, можно через р2р технологии на syncthing. Вариантов много, надо под задачу выбирать

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

Не то слово, до Америки 0.150 , а тут Владик 0,7

Ну вот проверил до инстанса в Японии, 0.3) Может у вас там во Владивостоке что-то с провайдером?)

вот-вот.

Ну вот проверил до инстанса в Японии, 0.3) Может у вас там во Владивостоке что-то с провайдером?)

там яровая трафик перехватывает))))

Это самый худший вариант, до Америки не всегда ровно 0.150 но и это уже большие цифры для синхронизации

Лить по такому каналу большой тср трафик всё равно сложно, а потом после задержки он ещё некоторое время обрабатываться и применятся будет и ваша реплика будет отставать на добрую секунду

Отставание равно неконсистентность

Отставание равно неконсистентность

оно в любом случае будет

оно в любом случае будет

В этом и была суть разговора что технически мы упираемся в скорость света и не можем предоставить консистентность

Простой холивар

В этом и была суть разговора что технически мы упираемся в скорость света и не можем предоставить консистентность

но это почти никому не нужно

Простой холивар

бургерная тема)))

но это почти никому не нужно

Ты хочешь продолжение холивара? Набрасываешь тут

Ты хочешь продолжение холивара? Набрасываешь тут

nope

Ну Alexey конечно тот ещё холиварщик!

Набросил так набросил

Вредно с вами бургеры есть?

Ну Alexey конечно тот ещё холиварщик!

Лана врать то :)

а че за подделка с безопасностью

както слишком Ъ

а не решение

Всё мы понимаем

а не решение

Хорошее решение это для rhel это redhat insight

В этом и была суть разговора что технически мы упираемся в скорость света и не можем предоставить консистентность

Не о чем холиварить. Почитайте о решениях НСИ с единым центром на досуге

Или вообще про транзакционные системы

Не о чем холиварить. Почитайте о решениях НСИ с единым центром на досуге

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

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

В общем вы хотите то, чего по сути никому не надо

Я не хочу, мне это и на работе не надо. Это холивар

VMWare умеет синхронизировать ВМ на блочном уровне и по памяти

Аминь

Баста, я пошёл отсюда. Такие холивары не имеют конца

Я хотела про СУБД похоливарить :) но у стойки было тихо и пусто, так что не случилось

Забавно получилось. Я на прошлом митапе спрашивал Алексея, что же всё-таки лучше в качестве СУБД - MySQL или PG. Он сказал, что всё равно, в обоих случаях можно добиться одинаковой производительности. А сегодня Олег однозначно рекомендовал MySQL, да ещё и её форк - MariaDB.

Забавно получилось. Я на прошлом митапе спрашивал Алексея, что же всё-таки лучше в качестве СУБД - MySQL или PG. Он сказал, что всё равно, в обоих случаях можно добиться одинаковой производительности. А сегодня Олег однозначно рекомендовал MySQL, да ещё и её форк - MariaDB.

Вот! А у нас платный саппорт Zabbix, и у нас PgSQL, и нам сказал сапорт что PgSQL - идеально. Падазрительнна?

Баста, я пошёл отсюда. Такие холивары не имеют конца

Уже написал решение

Забавно получилось. Я на прошлом митапе спрашивал Алексея, что же всё-таки лучше в качестве СУБД - MySQL или PG. Он сказал, что всё равно, в обоих случаях можно добиться одинаковой производительности. А сегодня Олег однозначно рекомендовал MySQL, да ещё и её форк - MariaDB.

Ну это Олег. А я бы рекомендовал то, что может подхватить твой коллега, а не ты один.

работать нужно, очевидно, с той базой, с которой ты (и команда) уже знаком и которую сможешь обслуживать в критических ситуациях; фундаментально и mysql, и pg, слишком схожи, чтобы руководствоваться чем-либо ещё

Забавно получилось. Я на прошлом митапе спрашивал Алексея, что же всё-таки лучше в качестве СУБД - MySQL или PG. Он сказал, что всё равно, в обоих случаях можно добиться одинаковой производительности. А сегодня Олег однозначно рекомендовал MySQL, да ещё и её форк - MariaDB.

А что там 8 мускул не рекомендовали?

А что там 8 мускул не рекомендовали?

Только 10 Марию упомянули.

Забавно получилось. Я на прошлом митапе спрашивал Алексея, что же всё-таки лучше в качестве СУБД - MySQL или PG. Он сказал, что всё равно, в обоих случаях можно добиться одинаковой производительности. А сегодня Олег однозначно рекомендовал MySQL, да ещё и её форк - MariaDB.

Он вроде с оговоркой, что на больших инсталляциях mysql рекомендуют, если я не путаю На средних/маленьких в целом без разницы

Ненене. Только не Мария

имхо, саппорт будет рекомендовать то, на чем можно поиметь профит, оно и логично. Никаких претензий. ПРосто забавно наблюдать, что одни кричат что всем MySQL, другие кричат, вы чтоо, не вздумацте, всем PgSQL. Никакого холивара, просто наблюдения.

Ну это Олег. А я бы рекомендовал то, что может подхватить твой коллега, а не ты один.

Ну это не затрагивает вопроса производительности. Это просто разумно. :)

Он вроде с оговоркой, что на больших инсталляциях mysql рекомендуют, если я не путаю На средних/маленьких в целом без разницы

есть одинаково успешные кейсы больших инсталляций на pg, есть одинаково успешные кейсы больших инсталляций на mysql

Ну это не затрагивает вопроса производительности. Это просто разумно. :)

она условно одинакова

Он вроде с оговоркой, что на больших инсталляциях mysql рекомендуют, если я не путаю На средних/маленьких в целом без разницы

Не припомню, но я это в вопросе не уточнял.

она условно одинакова

Не

Не

практика показывает, что да

Идеология разная

Не припомню, но я это в вопросе не уточнял.

Может путаю

Не успел на митапе спросить: при создании зависимых метрик, данные мастер-метрики остаются храниться, занимая место?

работать нужно, очевидно, с той базой, с которой ты (и команда) уже знаком и которую сможешь обслуживать в критических ситуациях; фундаментально и mysql, и pg, слишком схожи, чтобы руководствоваться чем-либо ещё

Например ?)

Не успел на митапе спросить: при создании зависимых метрик, данные мастер-метрики остаются храниться, занимая место?

да

Не успел на митапе спросить: при создании зависимых метрик, данные мастер-метрики остаются храниться, занимая место?

Да, ровно то время, которые ты указал в истории мастер метрики

Да, ровно то время, которые ты указал в истории мастер метрики

Что не работает, если использовать партицирование, ага?(

ERROR: S client not available

Не успел на митапе спросить: при создании зависимых метрик, данные мастер-метрики остаются храниться, занимая место?

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

Что не работает, если использовать партицирование, ага?(

Работает даже с партицированием

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

Всё верно

Т.е. зависимые не ссылаются на мастер, а копируют в себя данные.

Работает даже с партицированием

Так если отключать хаускипер, кто их удалит?

Т.е. зависимые не ссылаются на мастер, а копируют в себя данные.

Ага

Так если отключать хаускипер, кто их удалит?

Никто

Сами ручками например

Сами ручками например

Ну если только так, да

Было бы здорово, если бы сервер не кладя в базу раскидывал по зависимым. Ну или кладя, но в отдельную таблицу, для которой можно было бы отдельно настроить партицирование/хаускипинг

Было бы здорово, если бы сервер не кладя в базу раскидывал по зависимым. Ну или кладя, но в отдельную таблицу, для которой можно было бы отдельно настроить партицирование/хаускипинг

Зачем?

Зачем?

Если делать много метрик по такой схеме - большой оверхед будет по ресурсам

Зачем хранить то, что не будешь использовать?

Тем более текст

Та хоть видео

Нет, несколько тысяч текстовых записей, которые хаускипером красиво чистятся и при этом может и партиционирование работать

Никто вопрос не задавал, заббикс будет микросервисным и есть ли задумка полностью уйти на TSDB?

Если делать много метрик по такой схеме - большой оверхед будет по ресурсам

Ровно в два раза получается.

Ровно в два раза получается.

В целых два раза!

Ровно в два раза получается.

Нет не в 2. У тебя мастер хранится день, а зависимый неделя. Так что не ровно в 2

Никто вопрос не задавал, заббикс будет микросервисным и есть ли задумка полностью уйти на TSDB?

Нет, такого не будет до версии 5.0 точно

Нет не в 2. У тебя мастер хранится день, а зависимый неделя. Так что не ровно в 2

Это если хаускипер работает.

Это если хаускипер работает.

Настраивать надо под требования, я как и Илья за хаускипер

Олег четко сказал что советуют MySQL на тяжёлых и больших инсталяциях

Олег четко сказал что советуют MySQL на тяжёлых и больших инсталяциях

А причины?

Никто вопрос не задавал, заббикс будет микросервисным и есть ли задумка полностью уйти на TSDB?

Я задал

А причины?

Я так понял у них больше опыта и компетенции

А причины?

Исторически сложилось. )

То есть субъективно

То есть субъективно

Нет

Можно и на оракле построить если крутой дба есть

У pg более избыточная запись