не, тут гораздо интереснее чуть выше Operating system error number 11 in a file operation.
то есть ошибка вовсе не самого mysql, а ОС не даёт работать.
3. Да были ошибки в логах о недоступности для записи таблиц.
можно пару цитат?
То есть основная гипотеза, vacuum full писал что-то большое, но не смог удалить либо старые либо новые датафайлы.
База при этом не уходила ли вообще в crash recovery по какой-то причине? Там есть варианты при которых остаются осиротевшие датафайлы https://www.cybertec-postgresql.com/en/orphaned-fi...
- место занимает именно PGDATA/base/ ? PGDATA/pg_wal нормального размера?
- "Если сделать бэкап и развернуть на другом сервере" - какой именно бекап имеется в виду?
- ошибки в логах базы при снапшоте?
- как именно снапшот делался? (LXC на btrfs/zfs/etc тоже можно назвать виртуалкой, а вот грабли будут свои)
PS: vacuum full на 1,4тб базе это довольно неожиданная идея
посмотрите что dmesg про них писал. Сюда влезли ручки всякого systemd и сломали ранее исправно работавшее именование интерфейсов через udev при конфликтующих именах, когда надо поменять местами два имени между собой. Помогает использование имён не ethX, а, например, NAME="ethbond0" или NAME="ethlan"
NEW и OLD в триггерах - это предварительно объявленные переменные типа record.
select from не предполагает использование переменной в from и пытается искать таблицу/view/etc с таким именем.
Что означает "Перестаёт работать"? Если отказывается стартовать, то с какой формулировкой. Если стартует, то, опять же, что в логах и в чём выражается "Перестаёт работать"
Security through obscurity мало того что бессмысленный, так вы сами себя им и запутали.
Не понятно почему два разных списка.
Потому что это два разных postgres'а.
Создавал базы так:
Соответственно, не в том postgresql о котором думали, но не проверили, к какому именно подключаетесь.
Развели бардак и закономерно потеряли что у вас где. Соберите бардак воедино в нормальный 5432, а безопасность обеспечить нормальным закрытием порта через firewall.
Плюс revoke all on database .. from public;
Где именно и как именно создали базы? Внимание на себя обращает нестандартный порт. Значит чего-то нестандартного навертели уже. И стоит начать с вопроса, а сколько экземпляров postgresql вообще запущено, не запутались ли сами в том что уже навертели.
dyndns без белого IP бесполезен. dyndns поможет для белого динамического IP, который меняется по усмотрению провайдера, но маршрутизирует честно трафик из глобальных интернетов на ваш маршрутизатор.
Куда чаще пользователь за провайдерским NAT'ом, который не будет маршрутизировать входящий трафик вообще.
Дополнительная услуга провайдера - речь про белый статический IP, то есть за вашим договором закрепляется некий IP, который будет изменяться только в исключительных случаях. И, что ещё имеет смысл уточнить у провайдера, не фильтрует ли он какие-то порты даже при аренде статического IP.
вопрос ведь в допусках на всём диапазоне нагрузки и пульсациях. Я не удивлюсь, если конкретный ноутбук не увидит ничего плохого от питания в диапазоне этак 10-15В как допустимое отклонение от 12В. А вот HDD так питать... Насколько далеко от требуемого стандартом 12В +-5% приемлемо для входа на конкретных HDD?
может быть malware работающий через взломанный postgres.