Я исследовал это несколько часов безуспешно. По сути, похоже, что файл my.cnf моего сервера вообще не читается.
Я обыскал свой сервер, и на нем есть только один файл my.cnf, расположенный по адресу /etc/mysql/my.cnf. Его владельцем является root: root.
Я использую Ubuntu 10.04 64bit на сервере Linode.com. У меня установлены последние версии MySQL и PHP.
Я отредактировал файл my.cnf, закомментировал "skip-innodb" и установил innodb в качестве механизма хранения по умолчанию, используя
default-storage-engine = innodb
А затем перезапустил mysql.
Но когда я показываю движки, MyISAM по-прежнему используется как движок по умолчанию.
Также - ни одна из настроек innodb, которые я добавил в файл my.cnf, не читается. Например, у меня в my.cnf есть:
innodb_buffer_pool_size=4G
Но в phpmyadmin InnoDB показывает размер буферного пула 8192 КиБ.
Точно так же у меня это в my.cnf:
innodb_data-file_path = ibdata1:500M:autoextend
Но в phpmyadmin он читается как ibdata1: 10M: autoextend.
Не похоже, что информация MyISAM считывается из файла my.cnf. Файл my.cnf запрошен с пропуском внешней блокировки, но в phpmyadmin он отображается как «включен».
Итак - да, похоже, что в файле my.cnf вообще ничего не читается.
Но сервер по-прежнему работает. Я запустил на нем сайт Drupal, и, похоже, он работает нормально. Итак, похоже, что mysql извлекает настройки по умолчанию из ... какого-то таинственного секретного места.
Есть идеи, как заставить mysql видеть и использовать этот файл my.cnf?
Собственно, подождите - похоже, его читают, не уверен. Я проверил error.log и нашел следующее:
101128 4:28:52 [ERROR] Cannot find or open table databasename/cache_apachesolr from
the internal data dictionary of InnoDB though the .frm file for the
table exists. Maybe you have deleted and recreated InnoDB data
files but have forgotten to delete the corresponding .frm files
of InnoDB tables, or you have moved .frm files to another database?
or, the table contains indexes that this version of the engine
doesn't support.
See http://dev.mysql.com/doc/refman/5.1/en/innodb-troubleshooting.html
how you can resolve the problem.
InnoDB: Error: auto-extending data file ./ibdata1 is of a different size
InnoDB: 640 pages (rounded down to MB) than specified in the .cnf file:
InnoDB: initial 32000 pages, max 0 (relevant if non-zero) pages!
InnoDB: Could not open or create data files.
InnoDB: If you tried to add new data files, and it failed here,
InnoDB: you should now edit innodb_data_file_path in my.cnf back
InnoDB: to what it was, and remove the new ibdata files InnoDB created
InnoDB: in this failed attempt. InnoDB only wrote those files full of
InnoDB: zeros, but did not yet use them in any way. But be careful: do not
InnoDB: remove old data files which contain your precious data!
101128 4:28:52 [ERROR] Plugin 'InnoDB' init function returned error.
101128 4:28:52 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
101128 4:28:52 [ERROR] /usr/sbin/mysqld: unknown variable 'innodb_lock_wait_timout=50'
101128 4:28:52 [ERROR] Aborting
101128 4:28:52 [Note] /usr/sbin/mysqld: Shutdown complete
Подобно тому, как вы не можете изменить размер файла журнала без повторного создания журналов innodb, вы также не можете повторно указать размер файла ibdata без его повторного создания. Кроме того, нет необходимости увеличивать его размер, так как по умолчанию используется автоматически расширяемый файл. Вот соответствующий фрагмент ошибки, который говорит вам, что это проблема:
InnoDB: Error: auto-extending data file ./ibdata1 is of a different size
InnoDB: 640 pages (rounded down to MB) than specified in the .cnf file
Я бы удалил это из my.cnf. Также у вас может быть опечатка где-то в вашей конфигурации, так как в журнале ошибок также указано, что "innodb_lock_wait_timout" является недопустимой переменной, но она не кажется недействительной согласно руководству.
Однако загадочно, как вообще работает mysql, когда он явно прерывается во время запуска из-за недопустимого my.cnf.
Если вы добавляете новый путь к данным в my.cnf, вам может потребоваться отредактировать конфигурацию вашего приложения, чтобы разрешить это изменение. Вы видите какие-либо ошибки типа «аудит» в своих файлах журнала?
Когда я изменил data_dir в моем my.cnf, он не уловил изменения, пока я не отредактировал
/etc/apparmor.d/usr.sbin.mysqld
И добавил новый путь к каталогу данных с помощью rw.
вы можете проверить / var / lib / mysql, /etc/mysql/my.cnf (или ваш каталог mysql) для файла
Сервер не поддерживает файл ~ / .my.cnf, если есть /etc/mysql/my.cnf
Обычно my.cnf находится в следующих местах:
/etc/my.cnf Global options
/etc/mysql/my.cnf Global options (as of MySQL 5.1.15)
SYSCONFDIR/my.cnf Global options
$MYSQL_HOME/my.cnf Server-specific options
defaults-extra-file The file specified with --defaults-extra-file=path, if any
~/.my.cnf User-specific options
~ представляет домашний каталог текущего пользователя (значение $ HOME).
SYSCONFDIR представляет каталог, указанный с помощью параметра --sysconfdir, который нужно настроить при сборке MySQL. По умолчанию это каталог etc, расположенный в каталоге скомпилированной установки. Это местоположение используется начиная с MySQL 5.1.10. (С 5.1.10 по 5.1.22 он читался последним, после ~ / .my.cnf.)
MYSQL_HOME - это переменная среды, содержащая путь к каталогу, в котором находится специфичный для сервера файл my.cnf.
Думаю, в этом виноват:
innodb_buffer_pool_size = 4G
У меня была такая же проблема на Ubuntu 10.10 (64 бит). Очевидно, mysql, по крайней мере, тот, который скомпилирован для этого Ubuntu, не поддерживает buffer_pool_size больше 1000M. И, как ни странно, это событие не жалуется на это. Так что уменьшите размер буфера, перезапустите сервер и посмотрите, что произойдет.
вам нужно поместить переменные innodb mysql в блок [mysql] в my.cnf, иначе он не будет прочитан