Хикмат Абдунабиев

Вы должны разрабатывать и деплоить приложение соответствующим образом. Так, чтобы старая версия приложения могла работать с новой версией схемы базы. Или наоборот, новая версия приложения могла работать со старой схемой базы.
То есть удаление таблички: сначала деплоите приложение, которое уже не работает с этой таблицей, потом удаляете таблицу
Новая табличка: сначала миграция, затем приложение
Новое поле в таблице с default значением: сначала поле, затем приложение
Новое поле без default: сначала новое поле с default null, затем релиз приложения которое обязано писать новое поле, но ещё не читать его (либо приводить null к нужному если это возможно на приложении), затем миграция с проставлением нужного значения (и, блин, не одним update по всей большой таблице), drop default, set not null, деплой приложения со всей логикой
И так далее. Во время разработки думаем, а как, когда и в сколько итераций это можно будет задеплоить.

Ну и, разумеется, DBA (или заменяющий его обязанности человек) думает над тем, как именно вносить нужную миграцию в базу

поставить и запустить ncdu
посмотреть где что лишнего валяется.
в нем же можно и удалить лишнее, но осторожно.
/var/cache, var/log, и много где чего лишнего может лежать.

server_name дожен быть разным.

Вопрос решил тем, что почистил директорию /run , ибо проблема была в недостаточном кол-ве места в ней.

Мультимастер СУБД - это такая замечательная штука, которую все хотят и ни у кого пока не получилось.
Потому что есть такая штука как CAP теорема, весьма мешающая сделать серебряную пулю.

Ладно, ближе к делу.
Самая большая проблема с автоматическим failover СУБД - решить, что уже пора переключаться. Для чего необходимо выяснить, а что вообще происходит, не развалилась ли сеть, не вернётся ли через пару секунд мастер обратно - если в сети в результате окажется два мастера, то нет никакого разумного способа определить, где данные актуальны. Худшее что можно представить - это split brain: когда часть приложений ходит в один мастер, часть в другой и данные стремительно расходятся в разные стороны. Есть такая байка про гуглдиск "у нас всё отказоустойчиво, все данные хранятся в 4 экземплярах. Правда, у нас была авария и мы теперь понятий не имеем, какая из копий актуальная"
Переключение мастера на 90% - решение административное и человеческое. Автоматика же добавляет головной боли. Зачастую - больше головной боли, чем без неё. Особенно если железо адекватное серверное, которое "вдруг" выпадает очень редко.

Обычно автоматики нет, и есть детальная инструкция по переключению мастера БД, по которой и в ночи можно переключиться.

Если всё ещё хочется походить по граблям - посмотрите patroni. Есть пара кластеров с ним на поддержке, при наличии мониторинга особых проблем не припоминаю. До split brain по крайней мере не придумал как довести, вроде все варианты прикрыты. В худшем случае в readonly уходит.

Model.object.filter(color__in=["red","green","yellow"])

Из документации:
EXPOSE <port> [<port>/<protocol>...]
VOLUME ["/data"]

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

Удалите то, что лежит в db_data

Если мы говорим о Docker на Linux, то все процессы контейнеров будут отображаться в ps auxf в виде обычных процессов, из этого списка можно найти тот процесс который грузит систему, после чего по иерархии можно найти идентификатор контейнера, по нему конкретный контейнер.

Разница между дистрибами конечно есть. Но для VPS она никакого рояля не играет. Если не знаете ни один - ставьте тот, по которому проще будет проконсультироваться.
На самом деле, когда нет каких-то жестких критериев типа "этот софт работает только в дистрибе N" (вариант - есть пакет только под дистриб M), выбор обычно делают из личных предпочтений :) Как они складываются? Ну вот как получилось, что моим первым дистрибом стал CentOS? На прежней работе сказали - нам все равно что это будет за дистриб, если это будет CentOS :D
Вся разница проявится при админстве системы и установке программ - у каждого дистриба свой пакетный менеджер и свои приколы в этой области - в работе сайта разницы не будет никакой.

Не обязательно запоминать номера для каждого флага:
chmod u=rwx,g=rs,o=rx /usr/bin/crontab

Как выяснилось, самый простой и надежный способ - Сделать второй сериализатор, который бы отдавал все объекты. а в представлении переопределить метод get_serializer, который бы подсовывал нужный сериализатор

500 строк в секунду - это не мощно и, вероятно, даже не DDoS. Если адрес один, то просто закройте ему доступ брандмауэром, а если адреса разные, то настройте лимит запросов в Nginx.

nginx.conf

http {
    ...
    limit_req_zone $binary_remote_addr zone=reqlimit:10m rate=30r/s;
    ...
}

some_site.conf

server {
    ...
    location / {
        ...
        limit_req zone=reqlimit burst=10 nodelay;
    }
}

После этого запросы с одного ip-адреса начиная с 31-го в секунду будут отбрасываться.

Как вишенку на торт, можно добавить ещё фильтр для fail2ban:

nginx-req-limit.conf

[Definition]

failregex = limiting requests, excess: .* by zone .*, client: <HOST>
ignoreregex =

и правило в jail.local

[nginx-req-limit]
enabled = true
port = http,https
filter = nginx-req-limit
logpath = /var/www/*/*/logs/error.log # Здесь укажите свой путь к логам виртуального хоста
findtime = 600
maxretry = 10
bantime = 7200

После этого адреса DoS'еров будут автоматически блокироваться брандмауэром на два часа. Что разгрузит Nginx от обработки паразитного трафика.