Нашёл я тут значит свои наработки 8-летней давности на #bash и немножко причесал.

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

Заточена под то, чтобы хранилось не больше 42 + лет эксплуатации резервных копий при ежедневном копировании и не больше 66 + лет эксплуатации - при ежечасном.

Найти #бэкап легко. Один и тот же бэкап может одновременно лежать в ежегодных, ежемесячных, ежедневных и ежечасных копиях, но, благодаря хардлинкам, это будет один файл. И создаваться он будет всего один раз. В итоге экономится дисковое I/O.

А самая прелесть - офигенно простая очистка лишнего. Просто ищем файлы с одной единственной ссылкой.

#бэкапы

https://github.com/strizhechenko/backup_scheme/tree/master

#ФедиЧитальня #PostgreSQL15 не совсем из книги, но по той же теме.

Глянул кусочек highload.guide, выцепил хорошую выжимку про классификацию репликаций:

- логическая - работает с кортежами; пример - row based binary log в MySQL; бутылочное горлышко - процессор slave.
- физическая - работает со страницами; примеры - pg_wal, innodb undo-redo; бутылочное горлышко - диск (не совсем понял master'а или slave'а, не совсем понял, а как же буферы; возможно дело в большей степени касается MySQL с несколькими журналами одновременно)
- statement based - сплошная боль, есть места где можно получить неконсистентные данные между master и slave, но в случае условной бигдаты - очень низкие накладные расходы на передачу данных по сети, большой update на всю таблицу прилетит практически одним запросом; разве что выполнять его придётся заново на slave, из-за этого может быть длинный лаг репликации.

Если slave может блокировать удаление журнала master'ом, чтобы догнаться в случае ребута, чем больше отставание, тем больше размер журнала. Если slave вообще не догоняет master в принципе и отставание только нарастает - со временем это закончится забитым дисковым хранилищем.

В PostgreSQL есть Logical Log Streaming Replication, который позволяет не миррорить часть таблиц на slave. Как это применять - я не придумал. В теории можно не хранить на слейвах для актуальных данных архивные данные, что позволит немного сэкономить на дисковом пространстве, особенно если slave'ов много.

P.S:
- Раньше жил в прекрасном мире, где БД находится на том же сервере, где и приложение, ни о какой репликации и не думал.
- Сейчас живу в прекрасном мире, где БД поддерживает отдельная команда, репликация уже готова, хоть и без гарантии синхронных записи на мастер и чтения со слэйва (а я и не против), бери да пользуйся.

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

1. Личный пользовательский десктопный компьютер, на который легко переключаться с рабочего ноутбука, которые находятся на одном и том же рабочем столе. Из-за этого часть личных дел "протекла" на рабочий ноутбук. Вряд ли на нём есть много чего для слежки за сотрудниками, тут базовые рабочие процессы-то на линуксах не особо поддерживают, на входе я пару часов ёбся с интранет SSL-сертификатами и сменой пароля к SSL-сертификату для VPN (в итоге сделал это внутри контейнера с предыдущей Ubuntu LTS). У всех маки. Возможно переключаться будет впадлу и здесь меня может спасти nextcloud. А может и не спасти.

Вообще переключение у меня устроено так - есть usb-свитч, есть два HDMI-провода, воткнутые в большой монитор. Для переключения надо нажать кнопочку на USB-свитче, а потом кнопочку на мониторе для переключения источника. Такое себе удобства. Так-то второй монитор есть, но я его чот не использую, хотя казалось бы - разберись уже с usb type-c -> displayport и будет тебе счастье. Глядишь, ещё и заряжаться от монитора можно будет. Или монитор питать. Но эт не точно. А пока блок питания ноута (гигантский, сука, весит больше чем макбук про 15' наверное) прикрутил стяжками к столу и мне норм.

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

У меня в целом есть где-то на 60% дописанный планировщик поддерживающий нужный мне подход, я бы кое-где поэкспериментировал ещё с подходом, но чтобы двигаться нормально нужно менять архитектуру, очень многое зависит от удобства интерфейса, а на формах, которые рендерятся на бэкенде далеко не уедешь. Наверное за день реально распилить проект на бэк, состоящий из API и фронт на реакте (заодно, глядишь, на работе смогу фронтам ТЗ мерж-реквестами ставить, пока я в режиме read-only там, потому что даже не ебу как это всё протестировать).

3. Дневник, чтобы спускать пар, поэтому у меня стала всё чаще взрываться жопа. Куда-то просрал свой контейнер с мастодоном, надо ещё раз порыться по /var/lib/lxc на трёх железках.

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

Сходил вчера к нутрициологу. Теперь у меня в жизни появилась женщина, которая спрашивает как я покушал и как я покакал. Аж на слезу пробило, лол.

По её словам, в принципе если процентов на 5 скорректировать мои пищевые привычки и чуток дожать дисциплину, усвоение пищи и витаминов подрастут процентов на 15, можно будет меньше хавать, а я слегка схудну и её приёмы отобьются по баблу за счёт экономии на продуктах за 2-3 месяца :D

Самое сложное это, конечно, правильно жрать колёса. Те, которые я ем за полчаса до еды ещё ладно. Но тут она чот парочку ещё накинула, хотя у меня свои уже в таблетницу не влезают. Сейчас я иногда такой "бляяя колёса" и просто закидываю всю дневную пачку в себя. Плохо, но всяко лучше, чем не закинуть. А тут "это за полчаса до еды утром, после нельзя; это между приёмами пищи, но перекусы можно игнорировать, это через полчаса после еды, а это прямо с едой, но только если она достаточно жирная".

Ещё сейчас смотрю на результаты анализов и прям вижу, как дисциплина, в теории, позволяет сократить дозировку колёс. И это тоже, сука, экономит бабки! Вот думаю, стоит ли с этой идеей к эндокринологу идти (по ДМС, конечно, а то его приём 2к стоит почти уже, без ДМС я бы даже не сомневался) или развлекаться самолечением.

Смущает то, что мы проворачиваем три эксперимента одновременно - снижаем кислотность желудка, докидываем лёгкое желчегонное и меняем 10% сливки в кофе на 3.2% молоко. Из-за этого не можем точно определить, что было эффективно, а что нет.

#дед #кряхтит на #ЗОЖ

Подумал тут, а ведь корелляции в трафике можно выявлять через эдакое подобие производных функций, не держа вообще всё в памяти. Берём 1000 пакетов. Накладываем 128 байт payload ethernet фрейма первого пакета на 128 таких же байт второго, совпадающая битмаска будет хэш-ключиком счётчика. Читаем третий, забываем первый, сравниваем со вторым. Повторяем. Берём топ счётчика и если он больше 50% то что-то тут не так. Так #ддосы можно в 99% случаев вообще вслепую выявлять, вообще не парся пакеты.

При хайлоадах можно просто 5-10-50-500 пакетов/сек хватать и как-нибудь скользящее окно замутить, чтобы всегда актуальная инфа была. Или 2 счётчика иметь, заполнять сперва один, потом второй, сравнивать между собой, потом первый занулять, заполнять заново. Ух бля, статистикал лёрнинг, нахуй.

Записался на сдачу грейдов, но ощущаю это гиблым делом.

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

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

Тут заметил упоминание ЧПУ.

Вспомнил, как я в 2012 мастерил "убийцу микротика" для провайдеров - дистрибутив Linux для небольших провайдеров, заточенный под работу 10гбит/сек, назвали его XGE, типа X Gigabit Ethernet. В неправильной раскладке получалось ЧПУ, за что меня коллеги прозвали оператором ЧПУ.

В целом колхоз-колхозом, но опыт интересный. Много ядерного программирования, не только ОБЫЧНЫЙ ЛИНУКС ВЗЯЛ И НАСТРОИЛ И ДЕНЕГ ХОЧЕТ, а прям побитый продакшном проект, вот прям из коробки хоба и взлетает многое. Единый конфиг опять же, копию развернуть - буквально _один_ файл скинуть на новую установку, IP-адреса поменять и погнали. Да и в целом после предыдущей версии нашего роутера без ipset - это был глоток свежего воздуха в вопросе масштабирования, раньше на дереве цепочек iptables что acl, что NAT, что шейперы работали и это была жопа где-то после 2000 абонентов.

Увы, проект не взлетел, потому что небольшие провайдеры зажимают любую копеечку, а большие хотят большой американский вендор аппаратного решения. В целом, если бы в проект вложили где-то в 6-7 раз больше денег (и наняли в 3-4 раза больше людей, а не одного человека на полставки, потому что появился ещё один более выгодный проект), может быть что-то из этого и получилось. Но вышло немного иначе.

Решение о том, чтобы его похоронить принимали слишком долго и откладывали на потом. Даже на то, чтобы внятно опубликовать наработки ресурсов не нашлось, это ж время, и по истории коммитов пробежаться, понять в каком виде вообще выкладывать - в виде отдельных патчей или целиком всё дерево ядра, брендинг опять же пришлось бы делать, да и просто публикации мало, надо было бы людям которые зачем-то в issues пришли отвечать, ну и статейки на хабр, опеннет и ЛОР прости-господи клепать. В итоге так и забили болт.

Такая вот грустная история импортозамещения.

#ФедиЧитальня
Предлагаю кому-нибудь присоединиться ко мне в чтении либо про кишочки постгреса (в открытом доступе легально): https://postgrespro.ru/education/books/internals
либо про высоконагруженные приложения, но мутите её где-нибудь сами (дорогобогато).
Я читаю такие вещи медленно и редко, поэтому предлагаю ритм для синхронизации – главу или 10-15 страниц в неделю (что меньше), но компания для чтения звучит как неплохой мотиватор не забить и дожать и мб в процессе ускориться.
О процессе: предлагаю просто раз в неделю под этим постом делать ветку дерева посвящённую прочитанной главе. Мне будет приятно послушать и поделиться мыслями как бы прочитанное применить в рабочем или пет-проекте.