MySQL *

Привет, Хабр! Сегодня на связи Илья Ищенко, руководитель группы администраторов хостинга Рег.ру и Роман Рогов, старший системный инженер.

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

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

Базы данных прибыльнее нефти? В 2025 году Ларри Эллисон стал самым богатым человеком в истории человечества, обойдя Рокфеллера. Тем временем на рынке M&A настоящий пожар: миллиардные сделки, банкротства и судебные иски MongoDB против конкурентов. Перевели подробный разбор того, кто выиграл, а кто проиграл в битве за данные в этом году.

В этом руководстве я расскажу о практическом опыте переноса базы данных из MySQL 8 в PostgreSQL 16 с использованием Pgloader.

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

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

В этой статье речь пойдёт о менее заезженной, но не менее актуальной теме – как ИИ уже сейчас помогает проектировать базы данных.

Приветствие

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

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

В этой статье мы покажем вам, как перенести базу данных Zabbix из MySQL в PostgreSQL на Rocky Linux 9. Заодно покажем, как включить TimescaleDB, а также выполним некоторые базовые настройки производительности.

В статье предполагается, что если доступны необязательные патчи (ключи с плавающей точкой и первичные ключи ), то они уже применены к базе данных.
Если вы в этом не уверены, информация об этом статусе также отображается во фронтенде в разделе System information, например, «Database history tables upgraded: No».

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

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

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

В Kubernetes короткий жизненный цикл подов — норма. Но когда лидер-узел MySQL внезапно исчезает, рискуешь потерять не только доступность, но и согласованность данных. Оператор Moco предлагает решение: полусинхронная репликация, автоматический failover и восстановление с PITR — всё это без боли миграции на полностью синхронную репликацию.

В статье — детали репликации, бэкапов, PITR, switchover и нюансов работы с пользовательскими образами. А также честно — чем он лучше (и хуже) альтернатив, и стоит ли его рассматривать для продакшена.

JOIN vs коррелированный подзапрос: мой разбор мифа «JOIN всегда быстрее»

Я проверил оба подхода (JOIN + GROUP BY и коррелированный подзапрос) на маленьком датасете и в ряде СУБД. Иногда подзапрос быстрее. Всё зависит от плана (Nested Loop vs Hash) и индексов. Слепо верить «JOIN всегда быстрее» не стоит. Смотрите EXPLAIN.

Первая часть статьи

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

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

Игра на 80% сделана с помощью вайб кодинга, но это не так просто как звучит.

Под катом расскажу, как реализовал свою web-панель для управления Amnezia AWG (WireGuard) VPN на Ubuntu 22–24. Почему не хватило официального приложения, какие задачи решил с помощью простого PHP-интерфейса и чем это может быть полезно другим компаниям или разработчикам. Код и инструкции — в открытом доступе.

Проект на GitHub: amneziavpnphp

Когда мы пишем запрос, СУБД делает гораздо больше, чем просто ищет данные. Она оценивает десятки сценариев выполнения, сравнивает стоимость операций и выбирает оптимальный путь к результату. От этого выбора зависит, будет ли запрос выполняться секунду или минуту. Почему одни системы находят лучший план, а другие выстраивают менее эффективный алгоритм? Попробуем разобраться, как планировщики СУБД принимают решения и что определяет их эффективность.

Мой отец — человек, переживший несколько сложнейших операций на сердце. Жизнь с хроническим заболеванием — это бесконечный поток анализов, заключений и схем приёма лекарств. Находясь далеко (я живу во Вьетнаме), я постоянно волновался: не забудет ли он про дозу, правильно ли понял назначение, задал ли все нужные вопросы врачу?

Мне нужен был не просто бот-напоминалка, а второй пилот — умный, конфиденциальный и мультимодальный AI-Кардиолог. Ассистент, который знает его анамнез наизусть, понимает голосовые команды и может «прочитать» фотографию свежего анализа.

Я решил собрать полноценный автономный агент с возможностью вызова внешних инструментов (Tool‑Calling) и локальной базой знаний (RAG), но без использования громоздких фреймворков вроде LangChain или LlamaIndex.

Транзакции — не про «магическое ACID», а про конкретную механику согласованного доступа к данным под нагрузкой.

Эта статья объясняет как реально работают уровни изоляции и чем отличаются популярные СУБД на практике.

Мы разберём:

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

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

За первый месяц сервис использовали более 1000 человек. Ниже — выводы и результаты.

Привет, Хабр!

Сегодня мы рассмотрим Resource Groups в MySQL — и перестанем жить на одной CPU.

Resource Groups — это контроль над CPU прямо из SQL. Вы создаёте логическую группу, говорите «эта группа может использовать только 2 CPU и работать на низком приоритете», и назначаете туда тяжелые, но второстепенные задачи. Всё. Дальше MySQL сам всё регулирует.

Всем привет!

Экспериментировал с оптимизацией SQL запросов в ChatGPT и Claude. В какой-то момент понял, что это превращается в одно и то же: Напиши промт → вставь SQL → подожди → поправь → повтори

Можно ли хранить данные, строить по ним отчетность, при этом обходясь без ETL процессов? Технически — да. Практически — только до первого серьезного роста данных.

Привет, Хабр! Меня зовут Алина, и в этой статье я расскажу о критически важном этапе, через который проходит любая data-driven компания.

Речь о переходе:
от построения отчетности напрямую из операционных баз (или через примитивное копирование в STG)
к структурированным ETL-процессам на специализированном ПО.

В нашем случае этим ПО стал SSIS — но важно подчеркнуть: сейчас мы используем NiFi с [N] процессорами для управления data pipeline. Однако именно опыт с SSIS стал для нас тем самым «мостиком» между хаотичным и осознанным подходом к данным.

P.S. Если хотите узнать про то, как мы организовали работу в NiFi — пишите в комментах, сделаем отдельный материал!

В этой статье — только про этап с SSIS. Не потому что он «лучший», а потому что: