📚 Как мы разрешили чтение с реплик PostgreSQL — и почему шесть лет говорили «нет» Авитовская статья про чтение с PostgreSQL-реплик. Долгое время приложениям вообще запрещали читать с реплик. Причина простая: реплика — это не «бесплатный дополнительный сервер», а часть запаса на failover. Если заранее загрузить её пользовательскими SELECT, то после переключения она может стать новым primary уже под высокой нагрузкой. Однако, нагрузка росла и банальное увеличение CPU и RAM уже не помогало. Шардировать систему никто не хотел. Поэтому команда DBA сдалась и всё-таки дала возможность читать с реплик. Но на своих условиях. ➖ можно читать только с реплик; ➖ можно читать с реплик с fallback на primary; ➖ приложение само должно понимать, допустимы ли eventual consistency и отсутствие read-your-writes. Если реплики деградировали и были исключены из пула, вся вынесенная нагрузка возвращается на primary - ровно в тот момент, когда системе и без того может быть плохо. Получается характерная цепочка: replica degraded → replica исключена → fallback на primary → primary перегружен Хороший пример того, как автоматика локально делает всё "правильно", но глобально способна ухудшить состояние системы. Однако всё вывернуто так, что ответственным за всё считается приложение. DBA предоставили возможности, а как ей распоряжаться уже решает приклад. Разумно 😉

⚡️ На правах бесплатной рекламы ⚡️ Завтра 27 октября, 14:00–23:00 пройдет "День СУБД 2026" от компании Диасофт. Москва, Кибердом. Офлайн, участие бесплатное, нужна регистрация. Я постараюсь быть там к началу, но может чуть задержусь. По докладам весьма простенько, но думаю будут интересны эти: 👉 Digital Q.DataBase: стратегия и направления развития. Послушаем роадмап вендора 👉 СУБД заменили. Что дальше? Как построить единый контур аналитики с Digital Q.DataFactory (форк Айсберга?) 👉 Опыт заказчиков: переход на Digital Q.DataBase в разных отраслях. После прочтения названия вспоминаются шоу "магов и фокусников" с НЕпроплаченными посетителями из зала.

📚 WordPress Backdoor Rebuilds Itself After Cleanup Using Files, Database, and Shared Memory Опять в статье есть слово "self-healing". Я не специально выбирал эту статью по данному тегу. Все совпадения случайны 😊 Исследователи Sucuri разобрали любопытный WordPress-бэкдор, который они сами называют self-healing mesh. Зловред раскладывает копии себя сразу по нескольким слоям: файлам, базе данных и shared memory. Компоненты умеют восстанавливать друг друга. Удалили плагин - его перепишет drop-in. Почистили файлы — следующая загрузка страницы может собрать систему заново из БД или shared memory. Получается почти образцовая автономная recovery-система 👍: есть резервные представления состояния, несколько независимых механизмов восстановления, периодический миграция и отсутствие единой точки, удаление которой гарантированно остановит процесс. И это хороший контрпример к самому термину self-healing. Мы привыкли воспринимать «самовосстановление» как положительное свойство➕. Но механизм восстановления ничего не знает о добре 😇 и зле😈. Он лишь возвращает систему к некоторому состоянию, которое считает правильным. Для владельца сайта инвариант примерно такой: backdoor_present = false Для вредоносной системы - ровно противоположный: backdoor_present = true Поэтому главный вопрос к self-healing-системе — не «умеет ли она восстановиться?», а: «какое состояние она восстанавливает, кто объявил его правильным и чем мы проверяем, что после recovery система действительно безопасна?» Автоматическое восстановление ещё не гарантия корректности. Иногда оно как раз и есть проблема 😵‍💫. Мой вывод по статье следующий: Self-healing сам по себе не является положительным свойством системы. Вот и живите с этим 🤡