Ну, и скрипт для удаления -
Зачем так сложно то?
Если цель контролировать/скрыть реальный адрес файла, то nginx понимает заголовок X-Accel-Redirect c помощью которого можно скрыто перенаправить скачивание на реальный адрес файла
Реальный адрес файла закрываем опцией internal, и по прямой ссылке будет ошибка 404
https://nginx.org/ru/docs/http/ngx_http_core_module.html#internal
Могли набежать боты/спаммеры/ддосеры и т.д.
Apache/php-fpm выделил много процессов, дабы всех обслужить
Памяти стало мало и oom kiiler отстрелил mysql как самого жирного
Решение простое
Правильное: Настроить лимиты на количество процессов/воркеров apache/php-fpm
Менее правильный вариант (но проще): Понизить коэффициент начисления очков для Mysql (oom_adj опция), тогда mysql будет позже остальных завершаться, и с большей вероятностью oom killer убъёт какой-то php процесс, что уже менее болезненно, чем отключённая БД
Вы серьёзно думаете, что на шареде Вам дадут 100% утилизировать NVME ?
А остальные XXX клиентов будут ждать, пока Вы запишете/прочитаете
https://rpms.remirepo.net/wizard/
remi позволяет обновить php как основную версию так и остановить дополнительные
proxy_pass http://192.168.50.101:80;
Второй nginx будет в $scheme видеть http
На втором nginx X-Forwarded-Proto нужно не $scheme передавать, а $http_x_forwarded_proto
числа разные
В Ваших примерах нет логики для работы регулярки
Откуда map узнает, на какое новое число редиректить?
Судя по логам, ошибка появилась в 31 версии и была пофикшена в 32
https://bugs.mysql.com/bug.php?id=109685
8.0.33
Fixed as of the upcoming MySQL Server 5.7.42 / 8.0.33 releases
Текущая версия в репозиториях 8.0.32
Я что-то провтыкал ошибку, смотрел сразу Ваши ссылки, в частности доку на mysqldump
security фикс тут не причём, связанный с tablespace
Возможно в этом дело
https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html#option_mysqldump_single-transaction
===========
============
Проверьте Выше указанные опции и версию mysql
Собственно я проверил на mysql Ver 8.0.30
Те же опции вызова mysqldump под юзером БД
Дамп проходит без проблем и ошибок нет
Т.е. выходит плагин не виноват..
Вы в коде посмотрите, есть ли эти изменения?
./classes/package/class.pack.database.php
Может у Вас старая версия
Ничего не дампится.
Как плагин может запускаться с системной командой? Вызвать mysqldump - это я ещё понимаю. Но запускаться..
Никакой очистки на данном этапе не происходит. Это происходит при создании бекапа.
Плагин скорей всего работает с mysqldump через exec, shell_exec и им подобные
Других вариантов вызвать mysqldump как бинарник - нет
Дописать в функцию вызова