Катастрофический отказ сервера репликации-> 18:39:32 UTC - mysqld получил сигнал 11

Ниже Вас видят часть журнала, показывающего катастрофический отказ. Сервер репликации 5.6 и ведущее устройство 5.5, но эта установка работала с предупреждениями в течение прошлой недели или около этого. Теперь, после попытки изменить некоторые полномочия пользователя, разрушенный сервер репликации и не загрузится снова. Какие-либо идеи о том, где запустить?

18:39:32 UTC - mysqld получило сигнал 11; Это могло быть то, потому что Вы поражаете ошибку. Также возможно, что этот двоичный файл или одна из библиотек, против которых это было связано, повреждены, неправильно созданные или неправильно сконфигурированные. Эта ошибка может также быть вызвана неправильно функционирующими аппаратными средствами. Мы будем стараться изо всех сил очищать некоторую информацию, которая, надо надеяться, поможет диагностировать проблему, но так как мы уже отказали, что-то определенно неправильно, и это может перестать работать.

key_buffer_size=262144 read_buffer_size=524288 max_used_connections=1 max_threads=200 thread_count=2 connection_count=0 Это возможен, что mysqld мог использовать до key_buffer_size + (read_buffer_size + sort_buffer_size) *max_threads = 156591 байт K памяти Hope, это в порядке; в противном случае уменьшите некоторые переменные в уравнении.

Указатель потока: след Попытки 0x7fb01c000990. Можно использовать следующую информацию для обнаружения, где mysqld умер. Если Вы не видите сообщений после этого что-то пошло ужасно неправильно... stack_bottom = 7fb0387649f0 thread_stack 0x40000/usr/sbin/mysqld (my_print_stacktrace+0x20) [0x83f710]/usr/sbin/mysqld (handle_fatal_signal+0x34d) [0x61fbbd]/lib64/libpthread.so.0 (+0x11240) [0x7fb2739b9240]/usr/sbin/mysqld[0x641849]/usr/sbin/mysqld (_Z17mysql_create_userP3THDR4ListI11st_lex_userE+0x25d) [0x6467bd]/usr/sbin/mysqld (_Z21mysql_execute_commandP3THD+0x201c) [0x68cc1c]/usr/sbin/mysqld (_Z11mysql_parseP3THDPcjP12Parser_state+0x328) [0x691858]/usr/sbin/mysqld (_ZN15Query_log_event14do_apply_eventEPK14Relay_log_infoPKcj+0xc75) [0x7e5e95]/usr/sbin/mysqld (_ZN9Log_event11apply_eventEP14Relay_log_info+0x6b) [0x7e3ecb]/usr/sbin/mysqld (_Z26apply_event_and_update_posPP9Log_eventP3THDP14Relay_log_info+0x25c) [0x813cbc]/usr/sbin/mysqld (handle_slave_sql+0xde9) [0x816dc9]/usr/sbin/mysqld (pfs_spawn_thread+0x123) [0xa224a3]/lib64/libpthread.so.0 (+0x91da) [0x7fb2739b11da]/lib64/libc.so.6 (clone+0x6d) [0x7fb2730ec9cd]

Попытка получить некоторые переменные. Некоторые указатели могут быть недопустимыми и заставить дамп прерываться. Запрос (7fb01c021a8a): идентификатор Соединения недопустимого указателя (идентификатор потока): 2 Состояния: NOT_KILLED

Страница руководства по http://dev.mysql.com/doc/mysql/en/crashing.html содержит информацию, которая должна помочь Вам узнать то, что вызывает катастрофический отказ.

0
задан 5 February 2015 в 07:56
2 ответа

Здесь помогло вернуться к версии 5.5 и позволить ведомому устройству выполнять запросы, которые ему не хватало. Кажется, что настройки репликации были потеряны, поэтому мне пришлось перезапустить репликацию. Следующим шагом будет обновление ведущего, а затем ведомого соответственно. Я предполагаю, что ошибка MySQL связана с неправильным форматом таблицы, поскольку эта репликация 5.6 не была должным образом обновлена.

0
ответ дан 24 November 2019 в 08:48

Если проблема не связана с распределением разделяемой памяти, как в вашем случае, хорошим местом для начала является трекер ошибок mysql или, по крайней мере, их специализированное сообщество.

I также посоветует вам:

  • проверить память вашего сервера с помощью memtest86
  • установить и попробовать более свежую версию сервера mysql 5.6.x
0
ответ дан 24 November 2019 в 08:48

Теги

Похожие вопросы