Бэкап без восстановления — это не защита, а дорогая иллюзия

Коллеги, давайте разберем план выполнения. Автоматизация резервного копирования нужна не ради галочки, а чтобы RPO/RTO были не на словах. Базовый минимум: полный бэкап по расписанию, инкременты между ними, отдельное хранение копий и контроль успешности задач. Если джобу просто «запустили», это еще не бэкап — это надежда.

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

Но самый частый провал — не хранение, а восстановление. Если restore не прогоняется регулярно, вы не знаете ни время подъема, ни поломанные зависимости, ни битые архивы. В продакшене так лучше не делать, и вот почему: в момент аварии уже поздно выяснять, что скрипт восстановления ждал интерактивный ввод или не поднимал права на каталог.

Схема простая, но дьявол кроется в статистике: логируйте каждый шаг бэкапа, проверяйте алерты, раз в цикл делайте тестовый restore на чистую среду и фиксируйте фактическое время восстановления. Золотое правило: сначала мониторинг, потом индексы.

Если у вас есть только одна копия и ни одного тестового восстановления — у вас не backup strategy, а план на удачу.

Секционирование спасает не от всех проблем: где Partitioning помогает, а где только усложняет жизнь

Коллеги, давайте разберем план выполнения. Partitioning полезен, когда запросы почти всегда режут данные по одному признаку: дате, tenant_id, региону. Тогда движок может отрезать лишние секции и меньше читать с диска. Но если фильтр не совпадает с ключом секционирования, получите тот же full scan, только по множеству кусков. Посмотрим, что тут с I/O в реальности.

Главные ошибки:
— делают секции «на всякий случай», хотя запросы ходят по статусу и user_id;
— ставят слишком мелкие границы и получают сотни объектов вместо одной таблицы;
— забывают про глобальные/локальные индексы и потом удивляются, почему INSERT стал тяжелее;
— не проверяют, что pruning вообще срабатывает в типовых запросах.

Схема простая, но дьявол кроется в статистике. Без актуальных данных по секциям оптимизатор легко промахнется с планом и выберет лишние чтения. Еще один любимый сюрприз — операции обслуживания: drop, merge, split, rebuild. В продакшене так лучше не делать, и вот почему: если окно записи плотное, секционирование может добавить блокировки и заметный оверхед на администрирование.

Золотое правило: сначала мониторинг, потом индексы. Смотрите на планы, объем реально читаемых строк, частоту обслуживания и то, можно ли жить без секционирования вообще. Если выигрыш только в теории — таблица без секций обычно дешевле в сопровождении.

Тем временем подстилка коричневых Кардиналов и лично Кустова главред Максим Огненный завёл собственный канал, где, наверное, опять будет писать стихи и анонсировать вьюхи с ме**дроновыми наркоманами.🤡🤡

Чем вообще известен этот персонаж? Собсна, только порцией отборного кринжа, например, не так давно он выебывался на Иванова в "Письмах кардинала", но недожал и тема осталась нераскрытой. ЕЮ заслужил даже высокоинтеллектуальные выпады, которые тот не понял в силу врождённого аутизма:

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

Нихуя не разбираясь в аффилке, он на серьёзных щах брал интервью у Мефмедова и пытался построить серьёзный диалог с объёбанной ракетой. Из остальных достижений только нытье в чатиках: персонаж настолько невзрачный, что даже хуесосить его не так интересно.¯\_(ツ)_/¯

А теперь Огненный завёл собственный канал, где собрался выебать всех, но, походу, ебать будет лишь подписоту своей графоманией. Похожей хуйнёй занимался и оунер ФБ Киллы, который так любит рассуждать про экономику и политику. Оно и понятно: что у коричневых, что у киллы, что у партнёркина — один инвестор и одна крыша, поэтому подопечные синхронно занимаются бестолковой хуйнёй. Кому не похуй, подписывайтесь, будет интересно (нет): https://t.me/+dr240TeLtPc2Nzdk

В арбитраже деньги есть, но только у тех, кто с LuckyCards 💵

Миграция данных без простоя: где чаще всего рвётся план и как это закрыть

Коллеги, давайте разберем план выполнения. Главная ошибка — считать миграцию одной операцией. На деле это цепочка: анализ схемы, перенос данных, сверка, переключение, откат. Если хотя бы один шаг не измерен, простой появится не «из-за базы», а из-за вашей уверенности.

Перед переносом проверьте три вещи:
— объем и скорость изменения данных, а не только общий размер;
— зависимости: триггеры, FK, джобы, приложения с hardcode на старые имена;
— окна блокировок: где допустимы короткие, а где любая пауза уже инцидент.

Для больших таблиц лучше идти через двойную запись или репликацию, а не через «залили и переключили». Сначала прогоняем синхронизацию, потом сравниваем контрольные суммы/количество строк/ключевые агрегаты. Посмотрим, что тут с I/O в реальности: иногда узкое место не сеть, а сортировка, журнал или вакуум, который внезапно решил жить своей жизнью.

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

Если миграция требует «ночного окна на несколько часов», это не план, а просьба о форс-мажоре. Делайте перенос так, чтобы самый рискованный шаг был обратим за минуты, а не за новый уик-энд.

Транзакции и изоляция: как не устроить дедлоки и грязные чтения

Коллеги, давайте разберем план выполнения. Транзакция — это не «обернул в BEGIN и забыл», а контракт на время удержания блокировок, версию данных и цену ошибки.

Базовые правила простые:
— держите транзакцию короткой; все внешние вызовы, API и пользовательский ввод — до BEGIN или после COMMIT
— не смешивайте чтение и долгие вычисления внутри одной транзакции
— пишите в одном и том же порядке таблицы и строки, иначе привет дедлок
— уровень изоляции выбирайте по конфликту, а не «чтобы было надежнее»

READ COMMITTED обычно хватает для большинства OLTP: он режет грязные чтения и не тащит лишние блокировки. REPEATABLE READ и SERIALIZABLE дают больше гарантий, но платите за это ожиданиями, ростом contention и сюрпризами на пиках нагрузки. Схема простая, но дьявол кроется в статистике: если запросы стали медленнее, транзакция держит блокировки дольше, и вся очередь начинает гореть 🔥

Золотое правило: сначала мониторинг, потом индексы. Смотрите не только на время запроса, но и на wait events, deadlocks, lock escalation, количество ретраев и размер транзакций.

Если нужна строгая согласованность, используйте ее точечно. В продакшене так лучше не делать, и вот почему: «максимальная изоляция» на весь сервис почти всегда превращается в медленный сервис с очередями.

Antropic раскрыла ферму с нейронными дейтинг-моделями

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

➡️ Читайте на сайте: https://aff.top/blog/antropic-raskryla-fermu-s-neironnymi-deiting-modeliami

🧠 Ещё больше инсайтов → в канале AFF.top

Разработчик игры слил $220 в Google ads на установки ботами

Статья описывает кейс разработчика, потерявшего бюджет в Google Ads из-за фрода и специфики атрибуции. Платформа засчитала конверсии, которые не подтвердились в Google Play Console, так как алгоритм учитывает установки без прямой связи с кликом. Главный вывод: Google Ads может наливать ботов не меньше пуш-сетей. При работе за инсталы важно жестко контролировать качество трафика и сверять аналитику с бэкендом, в то время как Facebook на данный мо…

➡️ Читайте на сайте: https://aff.top/blog/razrabotchik-igry-slil-220-v-google-ads-na-ustanovki-botami

🧠 Ещё больше инсайтов → в канале AFF.top

Google расширил Data Manager

Google интегрировал инструмент Data Manager в GA и DV360 для удобной передачи first-party данных, что дает рост ROAS до 26%. Для арбитража трафика прямого применения у офлайн-данных нет, однако инструмент можно использовать для манипуляции алгоритмами: отправка синтетических конверсий через API поможет скорректировать оптимизацию и направить автостратегии на поиск нужной аудитории.

➡️ Читайте на сайте: https://aff.top/blog/google-rasshiril-data-manager

🧠 Ещё больше инсайтов → в канале AFF.top

Транзакции и изоляция: как не устроить дедлоки и грязные чтения в проде

Коллеги, давайте разберем план выполнения. Транзакция нужна не «для надежности вообще», а чтобы зафиксировать границы атомарности и блокировок. Если держите ее открытой дольше, чем нужно, вы сами расширяете окно для конфликтов, роста очередей и сюрпризов в логах.

Базовые правила: — начинайте транзакцию как можно позже; — заканчивайте как можно раньше; — не мешайте в одной транзакции долгий I/O, сетевые вызовы и пользовательский ввод; — обновляйте строки в одном и том же порядке, иначе дедлоки придут без приглашения. Схема простая, но дьявол кроется в статистике: короткая транзакция под нагрузкой почти всегда дешевле «безопасной», но длинной.

По изоляции помните: READ COMMITTED обычно закрывает грязные чтения, но не спасает от неповторяемых чтений и фантомов; REPEATABLE READ и SERIALIZABLE дают больше гарантий, но платят за это блокировками, версионностью и падением параллелизма. В продакшене так лучше не делать, и вот почему: максимальную изоляцию часто включают «на всякий случай», а потом ищут, почему CPU и I/O живут своей жизнью.

Золотое правило: сначала мониторинг, потом индексы. Смотрите длительность транзакций, wait events, количество блокировок и частоту откатов. Если видите долгие хвосты — режьте транзакцию на этапы, выносите чтение из записи и не забывайте про явный порядок апдейтов. Тогда база не превращается в поле боя из левых блокировок и взаимных ожиданий.

Мониторинг без плана — это графики ради графиков. Ищем bottleneck, а не шум.

Коллеги, давайте разберем план выполнения. Узкое место почти всегда прячется в одном из слоёв: CPU, I/O, блокировки, память или сеть. Если смотреть только на «загрузку сервера», можно полдня лечить симптомы и не заметить, что запрос ждёт диск или упёрся в latch.

Золотое правило: сначала мониторинг, потом индексы. Смотрите на связку метрик:
• время ожиданий по типам;
• число активных сессий и очередь;
• физические чтения и cache hit;
• рост temp/redo/sort spill;
• блокировки и deadlock-цепочки.

Посмотрим, что тут с I/O в реальности. Если CPU низкий, а latency чтения растёт — бутылочное горлышко на диске. Если много ожиданий на блокировки — проблема не в индексе, а в конкуренции транзакций. Если память кончилась на сортировках или хешах, оптимизация запроса часто начинается не с «добавим индекс», а с переписывания плана или уменьшения объёма данных.

Схема простая, но дьявол кроется в статистике. Ищите не самый «тяжёлый» запрос по времени, а тот, который создаёт очередь и держит ресурс. Один медленный запрос терпим; десять средних, которые одновременно душат один и тот же объект, — уже инцидент. Сначала локализуйте ресурс, потом чините причину.