а нужны ли мне эти ваши docker-контейнеры?

Вот я об этом и пишу — мускуль нельзя просто «запустить в некотором namespace», он должен быть сконфигурирован под конкретное окружение и иметь конкретный снимок данных.

Ну во-первых, что мешает переносить эту конфигурацию (и даже динамически ее создавать), а во-вторых современный web не ограничивается одним mysql'ем.

Я всего лишь о том, что копировать данные при пересоздании ноды не требуется. Вот об этом: потому что для «перезапуска на другом узле» нужно как-то перекинуть сотни гигабайт данных.
Ну, как минимум в пределах ДЦ не требуется

Давай я это опишу явно, сначала, и другими словами: постгрес не падает. То есть, если он падает, то это испорченная база, остановка всей системы, восстановление из бэкапов, и так далее. Потому смысла в «быстро перезапустить БД» нет вообще никакого. Если тебе нужно обновить конфиг, то в идеале опять-таки нужно сделать это без перезапуска сервера — причем, AWS RDS в это не умеет, насколько мне известно, и сервак таки придется перезапускать. Если тебе нужно проапгрейдить сервер, то это миграция БД, которая является проблемой на уровне хранилища, а не на уровне сервиса. То есть, для БД = информация на диске, а сервис для нее уже вторичен. Если у тебя отвалился хост с томом, на котором хранятся данные. то ты вообще не можешь его «перезапустить» на другом узле, потому что доступа к данным у тебя нет. В случае SQLite эта роль «прокладки к данным» еще более очевидна.

По моем сведениям на бэке ничего не поменялось:

У тебя неправильные сведения как и во всем остальном, впрочем.

Вот что говорит сотрудник Facebook-а: https://www.quora.com/When-did-Facebook-switch-away-from-using-Erlang-for-Facebook-Chat-What-was-the-reason-for-it-What-did-they-replace-it-with

У их монолита на эрланге были большие проблемы и они все переписали. ВСЕ.

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

И? В чем противоречие-то?

постгрес не падает.

ого. выше ты топил за mysql

если он падает, то это испорченная база, остановка всей системы, восстановление из бэкапов, и так далее. Потому смысла в «быстро перезапустить БД» нет вообще никакого.

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

А вот это уже не сюрприз. Это фейспалм

Погоди, то есть, для вас иметь централизированный костыль под эластик — это норм, а закладывать грамотную архитектуру логирования во все сервисы изначально — это фейспалм? Бинарные логи, динамически настраиваемые уровни логирования — это для лохов всё?

Микросервисы не могут позволить себе такой роскоши, поскольку у них, как известно, нет общей памяти — вместо этого кэшами становятся внешние сервисы.

Вот и решение

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

Расскажите чем вы таким важным занимаетесь?

Кэшами-роутерами и занимаюсь, бг-г-г.

Дешевле купить готовое, чем платить команде админов/кодеров/тестировщиков. Ну, если в вашей стране, конечно, рабство отменили. Если есть много бесплатной рабочей силы, то хоть что можно сделать, хоть свой AWS написать, хоть пирамиды возвести

А если AWS пришлет за месяц счет в $100-200k — это тоже «дешевле»?

Погоди, то есть, для вас иметь централизированный костыль под эластик — это норм, а закладывать грамотную архитектуру логирования во все сервисы изначально — это фейспалм? Бинарные логи, динамически настраиваемые уровни логирования — это для лохов всё?

а какая архитектура правильная? прямо интересно стало. и как ты используешь эти логи?

Но не все ли равно, хранить ли 30 миллиардов записей в одной базе или в трех?

ты серьезно сейчас?

Просто интересно: а если проект небольшой и ненагруженный, то бэкапы и остальное внезапно стали не нужны?

Ты столько значения придаешь сложности добавления одной строчки в кронтаб.

мне уже придется делать мониторинг для своей собственной системы, даже если она крутится на AWS, поскольку мне интересны метрики системы в целом, а не только отдельных служб

Это всё замечательно, только все эти (а также многие другие) задачи в AWS делаются легче и быстрее, чем без него

Ровно пока совпадают с заложенными в AWS сценариями. Если требования становятся нестандартными (а они станут), то неизбежно приходим к вариантам решения EC2/смириться. Мне странно, что ты сам не говоришь мне этого, а делаешь вид, будто в AWS заложено вообще всё, что только может пригодиться разрабу, мол «EC2 не нужен» и всё такое. Почему я и упрекал тебя в создании высоконагруженных систем под десяток пользователей.

Ага. Причём со знанием дела пишу, а не фантазирую как некоторые
А это всегда так. Кажется, что надо просто «сделать apt-get и прописать конфиги», а потом куда-то пара человекомесяцев девается. Прямо магия

Тебе достаточно было написать пару конкретных тезисов по поводу трудностей собственноручной поддержки этой системы. Бэкапы для мускуля — это наименее проблемная штука, если ты не записал их в /dev/null, как челы из гитлаба. С асинхронной репликацией не всё ровно у тебя будет даже на RDS, так что проблема сама по себе не развеивается.

Тут уместна цитата:
Ну да, как-то так.

Сам дурак.

Чтобы уменьшить зону поражения, если злые хакеры поломают ваш прекрасный сервер. Безопасность часто вредит скорости, но это жертва, которую вы должны принять (или свалить из бизнеса по-хорошему)

Я сейчас пытаюсь придумать, каким образом другой сегмент сети поможет, когда хакер получил доступ к приложению, которое имеет прямой доступ к БД, и не вижу, где эта дополнительная безопасность. Это что-то вроде «сплюнуть через левое плечо — чтобы хакеры не поломали».

Ты столько значения придаешь сложности добавления одной строчки в кронтаб.

И что будет в этой строчке?

Бэкапы для мускуля — это наименее проблемная штука

При терабайтных базах о которых ты говорил?

Я сейчас пытаюсь придумать, каким образом другой сегмент сети поможет, когда хакер получил доступ к приложению, которое имеет прямой доступ к БД

Вот. И мы пришли к микросервисам, которые напрямую с базой не общаются.

Не просто же так услуги CDN востребованы

CDN нужны ровно по одной причине — трафик гонять по всему миру дорого. В остальном нет проблем с тем, чтобы кинуть все сервера в один датацентр.

И конечно смешно читать, что 99% проектов это php+mysql

Я такого никогда не писал.

Микросервисы удобны - програмистам проще сопровождать их. Проще масштабировать и добавлять новую функциональность

«Программистов» не смущает, что их «проще» почему-то представляет из себя «в пять раз дольше сроки»? (множитель взят от балды) А «проще добавлять функциональность» почему-то значит «в рамках одного сервиса», поскольку перекинуть пол-системы на новую архитектуру чудовищно долго и сложно.

Биткоин не пирамида, а в МММ индустрия не вкладывалась. Ещё примеры у вас будут?

«Индустрия» — это та же тётя Зина, подружка тёти Томы, торгующей семками на рынке, только тётя Зина нынче «inc.», но мозгов от этого у нее больше не стало, число руки и ног не поменялось.

Нет, там было вот что:

А там уже не бывает такого, что «у меня упал контейнер с мускулем, Nomad его автоматически перезапустил на другой ноде, как мне найти новый экземпляр мускуля, чтобы нарисовать ему красивые графики в графане?», потому что для «перезапуска на другом узле» нужно как-то перекинуть сотни гигабайт данных.

Все, что я говорю, это то, что перекидывать сотни гигабайт данных не требуется. Ну и мускуль (начиналось-то с мускуля, см. цитату) таки падает, по крайней мере год назад он тек и падал, на репликации чсх.

Еще раз. Там поменялось все. Весь стэк поменяли. То что ты пишешь - было в 2009-ом году.
I’m a former WhatsApp server engineer[1]. WhatsApp primarily moved from bare metal hosting running FreeBSD to Facebook’s owned and operating containerized management system which incidentally runs Linux.

https://www.infoq.com/presentations/whatsapp-services/ — 2016 год, по прежнему erlang на bare metal. И я не вижу никаких тезисов про смену архитектуры — да, они перешли с фряхи на линуксовые контейнеры, потому что фейсбуку так захотелось. Но все эти годы прекрасно работали — не вижу ни слова про переход на PHP.

Вот что говорит сотрудник Facebook-а: https://www.quora.com/When-did-Facebook-switch-away-from-using-Erlang-for-Fac...

При чем тут WhatsApp?

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

О чём речь?

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

Это и есть грамотная архитектура логгирования.

Я уже ответил, что это просто перекладывание проблемы на другой узел.

Вы ещё на стек TCP/IP начните жаловаться, что там постоянно перекладывают проблемы на другой уровень.

А если AWS пришлет за месяц счет в $100-200k — это тоже «дешевле»?

Да. Вы в курсе сколько вообще грамотные специалисты получают?

CDN нужны ровно по одной причине — трафик гонять по всему миру дорого.

В смысле? Кому дорого? Ты платишь за расстояния в интернете?

«Программистов» не смущает, что их «проще» почему-то представляет из себя «в пять раз дольше сроки»?

В смысле? Не понял этого момента.

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

Какую новую архитектуру? Ты о чем?

а какая архитектура правильная? прямо интересно стало. и как ты используешь эти логи?

Напоминаю, что я фанат монолитов. В монолитах централизация-кастомизация логирования производится намного проще. Захотел — подключил отладку и шерсти мегабайты логов чуть на уровне отдельных вызовов функций. Перехотел — выключил, смотришь только важные оповещения.

Но не все ли равно, хранить ли 30 миллиардов записей в одной базе или в трех?

ты серьезно сейчас?

Да. Разница в два-три раза погоды не делает.

Ты столько значения придаешь сложности добавления одной строчки в кронтаб.

А-ха-ха-ха.

Ровно пока совпадают с заложенными в AWS сценариями.

Расскажите случай из личного опыта.

Бэкапы для мускуля — это наименее проблемная штука,

Пока у вас база в пару десятков гигабайт укладывается, так и есть.

Сам дурак.

Интересный разговор получается, я с вами согласился, а вы за это меня дураком называете. Что-то подозрительно.

Я сейчас пытаюсь придумать,

Удачи.

Напоминаю, что я фанат монолитов. В монолитах централизация-кастомизация логирования производится намного проще. Захотел — подключил отладку и шерсти мегабайты логов чуть на уровне отдельных вызовов функций.

Перезапустив целый монолит. Похрену на бедных клиентов. Подождут.
Но ты не ответил про правильную архитектуру и использования. Ты на сервере логи собираешься что-ли хранить? И смысл тогда в них?

Судя по остальным комментариям, правильная архитектура логгирования это класть логи в /var/log/service_name и ротировать их логротэйтом.

Да. Разница в два-три раза погоды не делает.

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

/var/log/service_name и ротировать их логротэйтом.

Он там выше что-то про бинарные логи писал. Хотя возможно он имел в виду bin-log его любимого mysql и вообще не в теме зачем нужны логи.

И что будет в этой строчке?

Дергаться скрипт с

mysqldump -uuser -ppass --single-transaction --routines --triggers --all-databases | lz4 - backup_$(date).sql.lz4

или что-то похожее.

При терабайтных базах о которых ты говорил?

При терабайтных это уже будет напрягать, но все равно выполнимо.

Я сейчас пытаюсь придумать, каким образом другой сегмент сети поможет, когда хакер получил доступ к приложению, которое имеет прямой доступ к БД

И мы пришли к микросервисам, которые напрямую с базой не общаются

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

Ну и мускуль (начиналось-то с мускуля, см. цитату) таки падает, по крайней мере год назад он тек и падал, на репликации чсх

Я уже ответил — ты рискуешь словить повреждение БД, причем, неизвестных масштабов: может потеряться одна строка, может пропасть половина пользователей из системы.

Ну да, если БД в произвольный момент встает раком, то мы рискуем данными, это не новость. Ты зачем это сообщаешь в текущем контексте, пытаешься меня втянуть в пучину безумия? Так я в ней давно освоился и живу.

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

Вот. И мы пришли к микросервисам, которые напрямую с базой не общаются.

Но так и не поняли, зачем относить БД в другой сегмент.

являются лохами в той или иной степени, даже если по итогу выходят в плюсе

Любопытный стиль мышления, где-то я его уже видел.

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

или что-то похожее

Правильно и залочить на запись всю базу. Отличное решение. И на тот же сервер, где база. И восстановление из бэкапа 1Gb базы - сутки.

При терабайтных это уже будет напрягать, но все равно выполнимо.

Черт, ты похоже даже с гигабайтными базами дела не имел.

Грубо выражаясь, это будет еле ползать.

С чего вдруг? Если это баллансировщик, то там обычный tcp proxy, если sql-proxy или proxysql, то он еще и кэшировать будет.

mysqldump -uuser -ppass --single-transaction --routines --triggers --all-databases | lz4 - backup_$(date).sql.lz4

Как бы вам объяснить: вы напоминаете студента, который недоумевает зачем нужны всякие системы контроля версий, неперерывной интеграции и прочие хранилища артифактов, когда он и без всего этого ненужно отлично сдаёт лабы.

Я сразу написал, что это не 100%, а 99%

Скромняшечка.

Ладно, он хотя бы --single-transaction указал. Хоть база консистентна и то хлеб. А так весело он конечно живет. Бэкапов нормальных нет, логирования его чудесного монолита тоже. И больше того, и монолита никакого у него тоже нет - разрозненные php файлы без какого-то состояния и данных в памяти, которые запускаются в момент обращения к ним, инициализируют все соединения, подключают все библиотеки, что-то рендерят и умирают. А все данные передают друг другу через get и post запросы.

Друзья мои, простите за оффтоп, но я анонимус и не могу создавать треды.

Посоветуйте сервис под бэкапы, для личного использования (немного баз, немного файлов, гигабайт на 50-100 в сумме).

Отстал от жизни, не знаю что используют кроме своих серверов - backblaze, crashplan?

Безлимитное место не нужно.

И восстановление из бэкапа 1Gb базы - сутки.

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

Безотносительно вашей беседы, можете объяснить на пальцах, почему так?

Потому что dump - это куча insert'ов, а они очень медленные, особенно если в таблице есть индексы.

Поэтому и используют костыли типа xtrabackup, которые копируют файлы, а потом отматывают транзакции на определенную точку во времени по bin-log'у. В итоге восстановление из бэкапа сводится к простому копированию.

Потому что dump - это куча insert'ов, а они очень медленные, особенно если в таблице есть индексы.

Это понятно, но это:

восстановление из бэкапа 1Gb базы - сутки.

По моему перебор.

По моему перебор.

Очень зависит от структуры базы, но это все-равно часы.
1GB - это чаще всего миллионы записей.

Ты серьезно? Ты реально не понимаешь даже что такое докер и зачем он нужен.

Прекрасно понятно зачем нужен этот докер: макака сидит, ваяет из кучи разношерстного мусора, говна и палок сервис/приложение, любовно собирая это у себя на локалхосте. Работать это будет только у него на локалхосте. А нужно чтоб запускалось где-то ещё: на сервере, в облаке etc. И тут пригождается этот докер как способ упаковать всю эту дымящуюся кучу в некий контейнер, и отправить исполняться этот контейнер куда угодно. Все адепты докера-это такие вот макаки-говноделы. А распространённость докера показывает лишь насколько велико их количество в индустрии на текущий момент.

Ну, замените на 10Gb/сутки. Это всё равно мало, когда реальные данные на полтерабайта идут.

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

(кроме совета про сервис бекапов выше)

Самое дешёвое это https://aws.amazon.com/s3/glacier/pricing/ но там, говорят, опухнешь ждать, пока обратно свои файлы выкачаешь.

Мне энтерпрайз не нужен всякий, проще тогда это https://www.scaleway.com/en/c14-cold-storage/ взять

Говорю же - для личных целей. С амазоном не хочу связываться совсем.

тогда флешку купить большую.

Ну сервер далеко от меня, да и бекапить локально - так себе затея. Сколько дц погорело уже на моей памяти.

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

О чём речь?

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

Это и есть грамотная архитектура логгирования

Просто ответь: как мне на работающей системе к набору сервисов временно подключить логирование без нарушения работы системы? Как залогировать некий интенсивный процесс, который через GELF нагнул бы раком всю сеть?

Вы ещё на стек TCP/IP начните жаловаться, что там постоянно перекладывают проблемы на другой уровень

Начну. Сеть не бесплатна. Для распределенных систем минимизация трафика между датацентрами — это одна из ключевых задач. «У нас есть роут между датацентрами, а там пусть админы парятся про ширину канала» — это плохое оправдание для плодителя сервисов.

Да. Вы в курсе сколько вообще грамотные специалисты получают?

Где? Даже в силиконовой долине AWS может потопить стартап, хотя там даже дошлый айтишник зарабатывает $15k/мес — просто потому, что за те деньги, которые уплачены AWS, можно было несколько таких нанять. Не говоря уже про глобальный найм, где $30/час — это очень даже солидный уровень.