Мой MySQL падал много раз за месяц
Мой веб-сайт (Wordpress) когда-то перестал работать с сообщением об ошибке ниже"
не могу подключиться к Datatabse
Я проверил файл журнала MySQL и обнаружил информацию о сбое, как показано ниже:
----------
2021-01-21 0:44:59 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2021-01-21 0:44:59 0 [Note] InnoDB: Uses event mutexes
2021-01-21 0:44:59 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2021-01-21 0:44:59 0 [Note] InnoDB: Number of pools: 1
2021-01-21 0:45:00 0 [Note] InnoDB: Using SSE2 crc32 instructions
2021-01-21 0:45:00 0 [Note] InnoDB: Initializing buffer pool, total size = 16M, instances = 1, chunk size = 16M
2021-01-21 0:45:00 0 [Note] InnoDB: Completed initialization of buffer pool
2021-01-21 0:45:00 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2021-01-21 0:45:00 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=215993122
2021-01-21 0:45:07 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2021-01-21 0:45:07 0 [Note] InnoDB: Uses event mutexes
2021-01-21 0:45:07 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2021-01-21 0:45:07 0 [Note] InnoDB: Number of pools: 1
2021-01-21 0:45:07 0 [Note] InnoDB: Using SSE2 crc32 instructions
2021-01-21 0:45:07 0 [Note] InnoDB: Initializing buffer pool, total size = 16M, instances = 1, chunk size = 16M
2021-01-21 0:45:07 0 [Note] InnoDB: Completed initialization of buffer pool
2021-01-21 0:45:07 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2021-01-21 0:45:07 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=215993122
2021-01-21 0:50:02 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2021-01-21 0:50:02 0 [Note] InnoDB: Uses event mutexes
2021-01-21 0:50:02 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2021-01-21 0:50:02 0 [Note] InnoDB: Number of pools: 1
2021-01-21 0:50:02 0 [Note] InnoDB: Using SSE2 crc32 instructions
2021-01-21 0:50:02 0 [Note] InnoDB: Initializing buffer pool, total size = 16M, instances = 1, chunk size = 16M
2021-01-21 0:50:02 0 [Note] InnoDB: Completed initialization of buffer pool
2021-01-21 0:50:02 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2021-01-21 0:50:02 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=215993122
2021-01-21 0:50:02 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2021-01-21 0:50:02 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2021-01-21 0:50:02 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2021-01-21 0:50:02 0 [Note] InnoDB: Setting file '/opt/lampp/var/mysql/ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2021-01-21 0:50:02 0 [Note] InnoDB: File '/opt/lampp/var/mysql/ibtmp1' size is now 12 MB.
2021-01-21 0:50:02 0 [Note] InnoDB: Waiting for purge to start
2021-01-21 0:50:02 0 [Note] InnoDB: 10.4.11 started; log sequence number 215993131; transaction id 221150
2021-01-21 0:50:02 0 [Note] Plugin 'FEEDBACK' is disabled.
2021-01-21 0:50:02 0 [Note] InnoDB: Loading buffer pool(s) from /opt/lampp/var/mysql/ib_buffer_pool
2021-01-21 0:50:02 0 [Note] Server socket created on IP: '::'.
----------
Я перезапустил MySQL, и мой сайт заработал хорошо. Версия моего MySQL: Distrib 10.4.11-MariaDB, для Linux (x86_64)Ubuntu версии 20.
Такая ситуация возникала несколько раз за месяц назад.
Раньше я искал решение в некоторых сообщениях, но до сих пор не могу решить эту проблему,
Сервер MySQL выходит из строя как минимум 2 раза в неделю
Wordpress + PHP+ Apache +mysql, сбой MySQL каждые 1 месяц
Кто-нибудь застрял в этом деле и знает, как это исправить?
3 ответа
16М слишком мал дляinnodb_buffer_pool_size
; попробуй 50М. 1 ГБ виртуальной машины — это совсем крошечно.
Также нижеmax_connections
до 10.
Запустите MySQL на панели управления XAMPP.
Проверьте журнал ошибок My SQL «mysql_error.log», нажав кнопку «Журналы» на панели управления XAMPP.
Перейдите в каталог «data» в базе данных MySQL. Я установил XAMPP на диск D: на своем компьютере, а каталог «данных» MySQL на моем компьютере был «/opt/lampp/var/mysql/». У вас может быть другое местоположение.
Сделайте резервную копию папки «данных» MySQL
Прежде всего, вам следует создать резервную копию папки «data» с помощью любого программного обеспечения для сжатия.
Дайте имя, например «data_backup.zip», или используйте любой тип сжатия, который вы пожелаете. Я использовал программное обеспечение для сжатия WinRAR для сжатия и резервного копирования папки «данных» MySQL.
Переименуйте папку «data»
Переименуйте папку «data» в «data-oldfiles». Очень важно переименовать каталог данных в любое новое имя каталога. Создайте новую папку «data».
Создайте новую папку и укажите имя папки «данные».
Чтобы решить проблему, нам нужно создать новый каталог «данных» в базе данных MySQL. Скопируйте содержимое из папки «резервная копия»
Перейдите в папку «резервная копия» и скопируйте все файлы.
Вставьте файлы из папки резервной копии в папку данных.
Теперь запустите базу данных MySQL из XAMPP.
Теперь ваша база данных MySQL запустится правильно, без каких-либо ошибок.
Перенос всех проектов MySQL. База данных, файлы данных и файлы журналов.
Если у вас много баз данных, которые использовались для различных проектов, вам необходимо перенести всю базу данных из папки «data-oldfiles» в папку «data».
Скопируйте все базы данных из старых файлов данных и вставьте в папку данных.
Теперь вам нужно скопировать файл данных «ibdata1» и все файлы журналов «ib_logfile0, ib_logfile1» из папки старых файлов данных в папку данных. Если у вас много файлов id_logile, скопируйте их все.
Ошибка MySQL. Это может быть связано с заблокированным портом, отсутствием зависимостей, неправильными привилегиями, сбоем или завершением работы другим методом. Запустите MySQL из XAMPP
Теперь запустите MySQL из XAMPP.
Перейдите в phpMyAdmin, чтобы проверить, что все базы данных доступны и работают.
Из комментария Дома и инструкций эксперта @Kemmut из WordPress.
Я проверил все журналы моего LAMPP с прошлого месяца (PHP, MySQL и Apache).
Я резюмирую причину многократных сбоев MySQL, как показано ниже:
Вы правы, в моем случае причина в том, что ОС убила службу MySQL, поскольку она занимала много памяти (превышает возможности моего сервера: 1 ГБ ОЗУ).
Журнал ошибок MySQL:
2021-01-21 0:50:02 0 [Note] InnoDB: Setting file '/opt/lampp/var/mysql/ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2021-01-21 0:50:02 0 [Note] InnoDB: File '/opt/lampp/var/mysql/ibtmp1' size is now 12 MB.
Журнал ошибок PHP:
[mpm_prefork:error] [pid 11556] (12)Cannot allocate memory: AH00159: fork: Unable to fork new process [mpm_prefork:error] [pid 11556] (12)Cannot allocate memory: AH00159: fork: Unable to fork new process mmap() failed: [12] Cannot allocate memory mmap() failed: [12] Cannot allocate memory
Причина, по которой MySql потребовал много MEM, заключается в следующем: множество неожиданных запросов на сканирование поступило с неизвестного сервера (с прошлого месяца мой сервер получил наибольшее количество запросов - 27 запросов в секунду с одного IP !!!).
Apache access_log
"POST /bbs/index.php HTTP/1.1" 302 - "POST /forum/index.php HTTP/1.1" 302 - "POST /forums/index.php HTTP/1.1" 302 - "POST /cgi-bin/php?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 758 "POST /cgi-bin/php5?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 758 "POST /cgi-bin/php-cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 758 "POST /cgi-bin/php.cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 758 "POST /cgi-bin/php4?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 758 "POST /%62%61%73%65/%70%6F%73%74%2E%70%68%70 HTTP/1.1" 302 - "GET /webdav/ HTTP/1.1" 302 - "GET /%69%73%70%69%72%69%74/%69%6D/%75%70%6C%6F%61%64%2E%70%68%70 HTTP/1.1" 302 - "GET /help.php HTTP/1.1" 302 - "GET /java.php HTTP/1.1" 302 - "GET /_query.php HTTP/1.1" 302 - "GET /test.php HTTP/1.1" 302
Чтобы справиться с этой ситуацией, существует несколько бесплатных сценариев Linux, основанных на iptables и ufw из этой статьи, которые можно использовать для блокировки такого рода нежелательных запросов.
https://vivustandard.com/fix-mysql-stops-or-crashes-randomly/
- Сценарий оболочки: block_ip.sh
- Сценарий оболочки: Remove_ip.sh
- Сценарий оболочки: run_anti_ddos.sh