при выполнении простого запроса к 4 внутренним объединенным таблицам сервер аварийно завершает работу с выводом ниже, появляющимся в файле mysql .err.
например. выбрать * из таблицы1
внутреннее соединение table2 на table1.a = table2.a и table1.b = table2.b
внутреннее соединение table3 на table2.a = table3.a и table2.c = table3.c
внутреннее соединение table4 на table3.a = table4.a и table3.d = table4.d
Если я удаляю одну из таблиц, она выполняется нормально. Аналогично, если я удаляю другую таблицу, она выполняется нормально. Несмотря на то, что все таблицы были проверены в любом случае, можно предположить, что это не является проблемой конкретно для одной из таблиц.
mysql.err trace:
100503 18:13:19 - mysqld получил сигнал 11;
Это может быть потому, что вы нажали ошибку. Также возможно, что этот двоичный файл
или одна из библиотек, с которыми она была связана, повреждена, неправильно построена,
или неправильно настроен. Эта ошибка также может быть вызвана неисправностью оборудования.
Мы сделаем все возможное, чтобы собрать некоторую информацию, которая, мы надеемся, поможет диагностировать
проблема, но так как мы уже разбились, что-то определенно не так
и это может потерпеть неудачу.
key_buffer_size = 1572864000
read_buffer_size = 2097152
max_used_connections = 11
max_threads = 151
threads_connected = 10
Возможно, что MySQL может использовать до
key_buffer_size + (read_buffer_size + sort_buffer_size) * max_threads = 2155437 K
байты памяти
Надеюсь, что все в порядке; если нет, уменьшите некоторые переменные в уравнении.
thd: 0x72febda8
Попытка возврата. Вы можете использовать следующую информацию, чтобы узнать
где умер. Если вы не видите сообщений после этого, что-то пошло
ужасно неправильно ...
stack_bottom = fe07efb0 thread_stack 0x40000
Попытка получить некоторые переменные.
Некоторые указатели могут быть недействительными и привести к прерыванию дампа ...
thd-> query at be1021f0 = объяснить, выбрать * из бизнеса
внутреннее расписание присоединения на business.id = schedule.business_id
внутреннее объединение scheduleentry в schedule.business_id = scheduleentry.business_id и schedule.kid = scheduleentry.parent
внутреннее объединение персонала на schedule.business_id = staff.business_id и schedule.staf f_person = staff.kid
где business.id = '3050bb04fda41df64a9c1c149150026c'
thd-> thread_id = 9
thd-> убил = NOT_KILLED
Страница руководства на http://dev.mysql.com/doc/mysql/en/crashing.html содержит
информация, которая должна помочь вам выяснить, что является причиной аварии.
100503 18:13:19 mysqld_safe mysqld перезапущен
100503 18:13:20 InnoDB: не удалось установить DIRECTIO_ON для файла ./ibdata1: OPEN: Inap собственный ioctl для устройства, продолжая в любом случае
100503 18:13:20 InnoDB: не удалось установить DIRECTIO_ON для файла ./ibdata1: OPEN: Inap собственный ioctl для устройства, продолжая в любом случае
InnoDB: порядковый номер журнала в файлах ibdata не совпадает
InnoDB: порядковый номер журнала в ib_logfiles!
100503 18:13:20 InnoDB: База данных не была нормально закрыта!
InnoDB: запуск восстановления после сбоя.
InnoDB: чтение информации табличного пространства из файлов .ibd ...
InnoDB: восстановление возможных наполовину записанных страниц данных из двойной записи
InnoDB: буфер ...
InnoDB: Последняя позиция файла binlog MySQL 0 2731, имя файла ./mysql-bin.000093
100503 18:13:20 InnoDB: началось; порядковый номер журнала 0 2650338426
100503 18:13:20 [Примечание] Восстановление после сбоя с помощью mysql-bin
100503 18:13:20 [Примечание] Запуск восстановления после сбоя ...
100503 18:13:20 [Примечание] Восстановление после сбоя завершено.
Это на opensolaris
SunOS 5.11 snv_111b i86pc i386 i86pc
Mysql 5.1.30
Вот фрагмент из файла my.cnf:
key_buffer = 1500M
max_allowed_packet = 1M
нить стека = 256 КБ
thread_cache_size = 8
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
table_cache = 512
tmp_table_size = 400M
max_heap_table_size = 64M
query_cache_limit = 20M
query_cache_size = 200M
Это ошибка или проблема конфигурации?
Данные испытаний:
У меня такая же проблема на двух почти точных установках mysql.
В основном две зоны на сервере opensolaris, одна из которых была клонирована от другой.
Считается ли это другой машиной, я не знаю.
После заполнения тестовыми данными запрос в конце действительно приводит к сбою на сервере MySQL, но не раньше, чем заполняется данными.
СОЗДАТЬ БАЗУ ДАННЫХ test УСТАНОВКА ХАРАКТЕРА ПО УМОЛЧАНИЮ latin1 COLLATE latin1_swedish_ci;
ИСПОЛЬЗОВАНИЕ test;
СОЗДАТЬ ТАБЛИЦУ, ЕСЛИ НЕ СУЩЕСТВУЕТ table1 (
a bigint (20) NOT NULL,
b bigint (20) NOT NULL,
ПЕРВИЧНЫЙ КЛЮЧ (a, b)
) ENGINE = MySAM CHARSET ПО УМОЛЧАНИЮ = latin1;
СОЗДАТЬ ТАБЛИЦУ, ЕСЛИ НЕ СУЩЕСТВУЕТ table2 (
a bigint (20) NOT NULL,
b bigint (20) NOT NULL,
c bigint (20) NOT NULL,
ПЕРВИЧНЫЙ КЛЮЧ (a, b),
КЛЮЧ c (c)
) ENGINE = MySAM CHARSET ПО УМОЛЧАНИЮ = latin1;
СОЗДАТЬ ТАБЛИЦУ, ЕСЛИ НЕ СУЩЕСТВУЕТ table3 (
a bigint (20) NOT NULL,
c bigint (20) NOT NULL,
d bigint (20) NOT NULL,
ПЕРВИЧНЫЙ КЛЮЧ (a, c),
КЛЮЧ d (d)
) ENGINE = MySAM CHARSET ПО УМОЛЧАНИЮ = latin1;
СОЗДАТЬ ТАБЛИЦУ, ЕСЛИ НЕ СУЩЕСТВУЕТ table4 (
a bigint (20) NOT NULL,
d bigint (20) NOT NULL,
ПЕРВИЧНЫЙ КЛЮЧ (a, d)
) ДВИГАТЕЛЬ = CHISSET ПО УМОЛЧАНИЮ MyISAM = latin1;
INSERT INTO table1 (a, b) ЗНАЧЕНИЯ
(10001, 20001),
(10002, 20002);
INSERT INTO table2 (a, b, c) ЗНАЧЕНИЯ
(10001, 20001, 30001),
(10002, 20002, 30002);
INSERT INTO table3 (a, c, d) ЗНАЧЕНИЯ
(10001, 30001, 40001),
(10002, 30002, 40002);
INSERT INTO table4 (a, d) ЗНАЧЕНИЯ
(10001, 40001),
(10002, 40002);
выбрать * из таблицы1
внутреннее соединение table2 на table1.a = table2.a и table1.b = table2.b
внутреннее соединение table3 на table2.a = table3.a и table2.c = table3.c
внутреннее соединение table4 на table3.a = table4.a и table3.d = table4.d