при выполнении простого запроса к 4 внутренним объединенным таблицам происходит сбой сервера, и в файле mysql .err появляется приведенный ниже вывод.
например. выберите * из table1 внутреннее соединение table2 в table1.a = table2.a и table1.b = table2.b внутреннее соединение table3 в table2.a = table3.a и table2.c = table3.c внутреннее соединение table4 в table3.a = таблица4.а и таблица3.d = таблица4.d
Если я удаляю одну из таблиц, она выполняется нормально. Точно так же, если я удаляю другую таблицу, она выполняется нормально. Хотя все таблицы в любом случае были проверены, это говорит о том, что проблема не в одной из таблиц.
трассировка mysql.err:
100503 18:13:19 - mysqld получил сигнал 11 ; Это может быть потому, что вы наткнулись на ошибку. Также возможно, что этот двоичный файл или одна из библиотек, с которыми он был связан, повреждены, неправильно собраны или неправильно сконфигурированы. Эта ошибка также может быть вызвана неисправностью оборудования. Мы постараемся собрать некоторую информацию, которая, надеюсь, поможет диагностировать проблему, но, поскольку мы уже разбились, что-то определенно не так, и это может привести к сбою.
key_buffer_size=1572864000 read_buffer_size=2097152 max_used_connections=11 max_threads=151 threads_connected=10 Возможно, mysqld может использовать до key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2155437 Кбайт памяти Надеюсь, это нормально; если нет, уменьшите некоторые переменные в уравнении.
thd: 0x72febda8 Попытка обратной трассировки. Вы можете использовать следующую информацию, чтобы узнать, где умер mysqld. Если после этого вы не видите сообщений, что-то пошло не так... stack_bottom = fe07efb0 thread_stack 0x40000 Попытка получить некоторые переменные. Некоторые указатели могут быть недействительными и привести к прерыванию дампа... thd->query at be1021f0 = объясните выбор * из расписания внутреннего соединения бизнеса на business.id = timetable.business_id timetableentry внутреннего соединения на timetable.business_id = timetableentry.business_id and timetable .kid = timetableentry.parent внутреннее объединение персонала в timetable.business_id = staff.business_id и timetable.staf f_person = staff.kid где business.id = '3050bb04fda41df64a9c1c149150026c' thd->thread_id=9 thd->killed=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: неподходящий ioctl для устройства, все равно продолжается 100503 18:13:20 InnoDB: не удалось установить DIRECTIO_ON на файл ./ibdata1: ОТКРЫТО: Неподходящий ioctl для устройства, все равно продолжается InnoDB: Порядковый номер журнала в файлах ibdata не соответствует InnoDB: Порядковый номер журнала в ib_logfiles! 100503 18:13:20 InnoDB: база данных не была нормально закрыта! InnoDB: Запуск аварийного восстановления. InnoDB: Чтение информации о табличном пространстве из файлов .ibd... InnoDB: Восстановление возможных наполовину записанных страниц данных из буфера doublewrite InnoDB:... InnoDB: Последняя позиция файла бинарного журнала 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 thread_stack = 256K 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, но не раньше заполнения данными.
CREATE DATABASE test НАБОР СИМВОЛОВ ПО УМОЛЧАНИЮ latin1 COLLATE latin1_swedish_ci; ИСПОЛЬЗОВАТЬ test;
СОЗДАТЬ ТАБЛИЦУ, ЕСЛИ НЕ СУЩЕСТВУЕТ table1 ( a bigint(20) NOT NULL, b bigint(20) NOT NULL, PRIMARY KEY (a,b)) ENGINE=MyISAM DEFAULT CHARSET=latin1;
CREATE TABLE IF NOT EXISTS table2 ( a bigint(20) NOT NULL, b bigint(20) NOT NULL, c bigint(20) NOT NULL, PRIMARY KEY (a,b), KEY c (c)) ENGINE=MyISAM DEFAULT CHARSET =латиница1;
СОЗДАТЬ ТАБЛИЦУ, ЕСЛИ НЕ СУЩЕСТВУЕТ table3 ( a bigint(20) NOT NULL, c bigint(20) NOT NULL, d bigint(20) NOT NULL, PRIMARY KEY (a,c), KEY d (d)) ENGINE=MyISAM DEFAULT CHARSET =латиница1;
СОЗДАТЬ ТАБЛИЦУ, ЕСЛИ НЕ СУЩЕСТВУЕТ table4 ( a bigint(20) НЕ NULL, d bigint(20) НЕ NULL, PRIMARY KEY (a,d)) ENGINE=MyISAM DEFAULT CHARSET=latin1;
ВСТАВИТЬ В table1 (a, b) ЗНАЧЕНИЯ (10001, 20001), (10002, 20002); ВСТАВИТЬ В table2 (a, b, c) ЗНАЧЕНИЯ (10001, 20001, 30001), (10002, 20002, 30002); ВСТАВИТЬ В table3 (a, c, d) ЗНАЧЕНИЯ (10001, 30001, 40001), (10002, 30002, 40002); ВСТАВИТЬ В table4 (a, d) ЗНАЧЕНИЯ (10001, 40001), (10002, 40002);
выберите * из table1 внутреннее соединение table2 в table1.a = table2.a и table1.b = table2.b внутреннее соединение table3 в table2.a = table3.a и table2.c = table3.c внутреннее соединение table4 в table3.a = таблица4.а и таблица3.d = таблица4.d
