Мой веб-сайт находится на VPS с 1 ГБ ОЗУ, и по какой-то причине он иногда автоматически вылетает. Я могу открыть error.log, но не могу понять, что означает ошибка и что может быть настоящей причиной. Ниже приведены журналы, созданные при последнем сбое сервера mysql.
[Warning] Changed limits: max_open_files: 1024 (requested 5000)
[Warning] Changed limits: table_open_cache: 431 (requested 2000)
[Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
[Note] /usr/sbin/mysqld (mysqld 5.7.18-0ubuntu0.16.04.1) starting as process 27819 ...
[Note] InnoDB: PUNCH HOLE support available
[Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
[Note] InnoDB: Uses event mutexes
[Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
[Note] InnoDB: Compressed tables use zlib 1.2.8
[Note] InnoDB: Using Linux native AIO
[Note] InnoDB: Number of pools: 1
[Note] InnoDB: Using CPU crc32 instructions
[Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
[Note] InnoDB: Completed initialization of buffer pool
[Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
[Note] InnoDB: Highest supported file format is Barracuda.
[Note] InnoDB: Log scan progressed past the checkpoint lsn 599964175
[Note] InnoDB: Doing recovery: scanned up to log sequence number 599964380
[Note] InnoDB: Doing recovery: scanned up to log sequence number 599964380
[Note] InnoDB: Database was not shutdown normally!
[Note] InnoDB: Starting crash recovery.
[Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
[Note] InnoDB: Apply batch completed
[Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
[Note] InnoDB: Creating shared tablespace for temporary tables
[Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
[Note] InnoDB: File './ibtmp1' size is now 12 MB.
[Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
[Note] InnoDB: 32 non-redo rollback segment(s) are active.
[Note] InnoDB: Waiting for purge to start
[Note] InnoDB: 5.7.18 started; log sequence number 599964380
[Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
[Note] Plugin 'FEDERATED' is disabled.
[Warning] Failed to set up SSL because of the following SSL library error: SSL context is not usable without certificate and private key
[Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
[Note] - '127.0.0.1' resolves to '127.0.0.1';
[Note] Server socket created on IP: '127.0.0.1'.
[Note] InnoDB: Buffer pool(s) load completed at 170609 9:13:52
[Note] Event Scheduler: Loaded 0 events
[Note] /usr/sbin/mysqld: ready for connections.
Version: '5.7.18-0ubuntu0.16.04.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
[Note] Executing 'SELECT * FROM INFORMATION_SCHEMA.TABLES;' to get a list of tables using the deprecated partition engine. You may use the startup option '--disable-partition-engine-check' to skip this check
[Note] Beginning of list of non-natively partitioned tables
[Note] End of list of non-natively partitioned tables
[Note] Access denied for user 'root'@'localhost' (using password: NO)
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_posts' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_posts'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_postmeta' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_postmeta'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_comments' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_comments'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_commentmeta' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_commentmeta'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_options' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_options'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_term_taxonomy' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_term_taxonomy'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_term_relationships' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_term_relationships'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_termmeta' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_termmeta'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_users' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_users'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_usermeta' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_usermeta'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_woocommerce_order_items' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_woocommerce_order_items'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_woocommerce_order_itemmeta' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_woocommerce_order_itemmeta'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_woocommerce_sessions' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_woocommerce_sessions'
Не могли бы вы помочь мне расшифровать журналы и подсказать решение. Спасибо!!
Возможно, сервер MySQL был убит убийцей OOM. Посмотри на dmesg | grep -i memory чтобы проверить вмешательство OOM.
я согласен с шоданшок. Ваш MySQL убит OOM-killer. Если вы не включили свопинг и не используете Apache на своем VPS, он может занять всю память и вызвать OOM-killer, а иногда и убить MySQL. Чтобы проверить это, вы можете запустить cat /var/log/syslog | grep kill
Пожалуйста, проверьте самую большую базу данных в MySQL. Вы можете использовать команду du внутри каталога данных MySQL. И попробуйте отключить базу данных на рабочем сервере. Скорее всего, причиной этого является одна из крупнейших баз данных. Всякий раз, когда есть попытка использовать конкретную БД, это может вызвать это. Кроме того, вы можете отслеживать любую конкретную таблицу внутри БД, которая может быть повреждена или содержит недопустимые данные.
Я также согласен с тем, что здесь было сказано, вот кое-что я прочитал.
OOM убийца
В ядре Linux есть функция Out Of Memory Killer (или OOM Killer), отвечающая за устранение нехватки памяти. Если система достигает точки, когда она может скоро исчерпать всю память, OOM Killer ищет процесс, который он может убить, и завершает свою жизнь.
May 16 00:12:33 mysql-server-01 kernel: Out of Memory: Killed process 3154 (mysqld).Как это работает и почему часто убивает MySQL?
OOM Killer использует эвристическую систему для выбора процессов для завершения. Он основан на оценке, связанной с каждым запущенным приложением, которая вычисляется с помощью вызова oom_badness (), ранее называвшегося badness (), внутри ядра Linux. Те, кто интересуется более подробной информацией, могут проверить исходный код в mm / oom_kill.c.
Алгоритм относительно прост, и, как правило, чем больше памяти использует процесс, тем выше он получает оценку, что увеличивает вероятность его гибели. Но на самом деле учитываются и другие факторы:
потребление памяти
владение процессом
возраст процесса (только старшие кенерлы)
Используемое процессорное время (только старые ядра)
обработать хорошее значение (только старые ядра)
флаги процесса
oom_adj / oom_score_adj настройка
Полный список может отличаться для разных версий Linux, так как алгоритм был в основном переписан в ядре 2.6.29.
Раньше модификаторы, используемые для значительного влияния на оценку, например, если задача имела приятность выше нуля, ее оценка удваивалась. Если он принадлежал привилегированному пользователю, результат делился на восемь. В новых ядрах это уже не так. Например, процесс, принадлежащий root, теперь получает только очень небольшой бонус в 30 баллов из возможных 1000. С этими изменениями разработчики хотели более предсказуемый алгоритм, и, очевидно, это был способ добиться этого.
Так почему это убивает MySQL так часто? Ответ прост - потому что MySQL обычно использует больше всего памяти из всех процессов, запущенных в системе.
Вот ссылка, откуда я это читал. https://www.psce.com/blog/2012/05/31/mysql-oom-killer-and-everything-related/