MySQL: Невозможно создать/записать в файл '/tmp/#sql_3c6_0.MYI' (Errcode: 2). Что это значит?

Ответ 1

Часто это означает, что ваш раздел /tmp не имеет места и файл не может быть создан или по какой-либо причине процесс mysqld не может записать в этот каталог из-за проблем с разрешением. Иногда это происходит, когда selinux идет дождь на вашем параде.

Любая операция, которая запрашивает "временный файл", по умолчанию переходит в каталог /tmp. Имя, которое вы видите, - это просто внутреннее случайное имя.

Ответ 2

Я тоже встречаю эту ошибку, когда запускаю Wordpress в своей системе Fedora.

Я искал его и нашел способ исправить это.

Возможно, это тоже поможет.

• проверить mysql config: my.cnf

   cat /etc/my.cnf | grep tmpdir
  

  Я ничего не вижу в своем my.cnf

• добавить tmpdir=/tmp в my.cnf в [mysqld]

• перезапустить веб-приложение и сервер mysql

  /etc/init.d/mysqld restart

Ответ 3

В Fedora с systemd MySQL получает частную/tmp-директорию. В /proc/PID _of_MySQL/mountinfo вы найдете следующую строку:

156 129 8: 1/tmp/systemd-namespace-AN7vo9/private/tmp rw, relatime - ext4/dev/sda1 rw, seclabel, data = ordered

Это означает, что временная папка /tmp/systemd -namespace-AN7vo9/private устанавливается как /tmp в частном пространстве имен процесса MySQL. К сожалению, эта папка удаляется tmpwatch, если она не используется часто.

Я изменил /etc/cron.daily/tmpwatch и вставил шаблон exclude -X '/tmp/systemd-namespace*' следующим образом:

/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
        -x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
        -X '/tmp/systemd-namespace*' \
        -X '/tmp/hsperfdata_*' 10d /tmp

Побочным эффектом является то, что неиспользуемые частные папки пространства имен не будут удалены автоматически.

Ответ 4

Имя файла выглядит как временная таблица, созданная запросом в MySQL. Эти файлы часто очень недолговечны, они создаются во время одного конкретного запроса и сразу же очищаются.

Однако они могут быть очень большими, в зависимости от объема данных, которые запрос должен обрабатывать в таблице temp. Или у вас может быть несколько одновременных запросов, создающих временные таблицы, и если их количество будет выполняться одновременно, они могут исчерпать дисковое пространство.

Я консультирую MySQL, и я помог клиенту, у которого в его корневом разделе были ошибки с прерывистым диском, хотя каждый раз, когда он смотрел, у него было около 6 ГБ бесплатно. После того, как мы исследовали его журналы запросов, мы обнаружили, что у него иногда было четыре или более запросов, выполняемых одновременно, каждый из которых создавал временную таблицу 1,5 ГБ в /tmp, которая находилась в его корневом разделе. Boom!

Решения, которые я ему дал:

• Увеличьте переменные конфигурации MySQL tmp_table_size и max_heap_table_size, чтобы MySQL мог создавать действительно большие временные таблицы в памяти. Но это не очень хорошая идея, чтобы позволить MySQL создавать временные таблицы на 1,5 ГБ в памяти, потому что нет возможности ограничить, сколько из них создается одновременно. Вы можете исчерпать свою память довольно быстро таким образом.

• Задайте конфигурационную переменную MySQL tmpdir в каталог на другом диске с большим объемом.

• Выясните, какой из ваших запросов создает такие большие временные таблицы и оптимизирует запрос. Например, используйте индексы, чтобы помочь этому запросу уменьшить его сканирование до меньшего фрагмента таблицы. Или архивируйте некоторые данные в истории, чтобы в запросе не было так много строк для сканирования.

Ответ 5

Огромное спасибо ArturZ за то, что он указал мне в правильном направлении. У меня нет tmpwatch, установленного в моей системе, поэтому это не является причиной проблемы в моем случае. Но конечный результат тот же: частный /tmp, который создает systemd, удаляется. Вот что происходит:

• systemd создает новый процесс через clone() с CLONE_NEWNS чтобы получить частное пространство имен. Или, может быть, он вызывает unshare() с CLONE_NEWNS. То же самое.

• systemd создает подкаталог в /tmp (например, /tmp/systemd -namespace-XRiWad/private) и монтирует его на /tmp. Поскольку CLONE_NEWNS был установлен в # 1, эта точка монтирования невидима для все остальные процессы.

• systemd затем вызывает mysqld в этом закрытом пространстве имен.

• Некоторые конкретные операции с базой данных (например, "описать;" ) создают & Амп; удалить временные файлы, что имеет побочный эффект обновления timestamp on/tmp/systemd-namespace-XRiWad/private. Другая база данных операции выполняются без использования /tmp вообще.

• В конце концов, 10 дней проходят, где даже сама база данных остается активным, никаких операций не происходит, чтобы обновить метку времени /TMP/Systemd -имен-XRiWad/частный.

• /bin/systemd-tmpfiles приходит и удаляет "старые" /tmp/systemd -namespace-XRiWad/private, эффективно рендеринг private/tmp неприменимо для mysqld, в то время как public/tmp остается доступным для всего остального в системе.

Перезапуск mysqld работает, потому что он снова запускается на шаге 1 с новым личным/tmp-каталогом. Однако проблема в конечном итоге возвращается снова. И снова.

Простым решением является настройка /bin/systemd -tmpfiles, так что он сохраняет что-либо в /tmp с именем /tmp/systemd -namespace- *. Я сделал это, создав файл /etc/tmpfiles.d/privatetmp.conf со следующим содержимым:

x   /tmp/systemd-namespace-*
x   /tmp/systemd-namespace-*/private

Проблема решена.

Ответ 6

Для меня эта проблема возникла после длительного периода использования mysql и веб-сервера. Поэтому я был уверен, что мои настройки правильны; Просто перезагрузка службы исправляет эту проблему; Странная часть проблемы заключается в том, что все еще можно подключиться к базе данных и даже запросить/добавить таблицы с помощью инструмента mysql. например:

mysql -u root -p

Я перезапустил, используя:

systemctl start mysqld.service

или   перезагрузка службы mysqld или   /etc/init.d/mysqld restart

Примечание: в зависимости от машины/среды этих команд необходимо перезапустить службу.

Ответ 7

Лучший способ работал у меня.

    chown root:root /tmp
  chmod 1777 /tmp
  /etc/init.d/mysqld restart

Вот и все.

Смотрите здесь: http://nixcraft.com/databases-servers/14260-error-1-hy000-cant-create-write-file-tmp-sql_9f3_0-myi-errcode-13-a.html

http://smashingweb.info/solved-mysql-tmp-error-cant-createwrite-to-file-tmpmykbo3bl-errcode-13/

Ответ 8

это очень просто, вы просто предоставляете папку /tmp как разрешение 777. просто введите:

chmod -R 777 /tmp

Ответ 9

В поле Ubuntu я начал получать эту ошибку после перемещения /tmp на другой том (символическая ссылка). Даже после установки разрешения 1777 проблема не была решена.

MySQL защищен AppArmor, который запрещает запись в новое местоположение tmp/mnt/tmp. Я должен был добавить следующие строки в /etc/apparmor.d/abstractions/user-tmp, чтобы исправить это.

владелец/mnt/tmp/** rwkl,

/mnt/tmp/rw,

Ответ 10

В debian 7.5 у меня такая же ошибка. Я понял, что владелец папки /tmp и разрешения отключены. В качестве другого ответа я предположил следующее (должно быть root):

chown root:root /tmp && chmod 1777 /tmp

Мне даже не пришлось перезапускать демон mysql.

Ответ 11

Благодаря политикам безопасности управления доступом, особенно когда SELinux включен, он не позволяет внешним исполняемым файлам создавать временные файлы в локациях системы.

Отключите SELinux, выполнив команду ниже:

echo 0 > /selinux/enforce

Теперь вы можете запустить mysql, он не даст никакого разрешенного разрешения при чтении/записи в /tmp или системных каталогах.

В случае, если вы хотите включить изменение возврата безопасности SELinux от 0 до 1 в приведенной выше команде.

Ответ 12

Проверьте разрешения, mysql config.

Также проверьте, не достигли ли вы дискового пространства, ограничений квот.

Примечание. Некоторые системы ограничивают количество файлов (а не просто), удаление некоторых старых файлов сеансов помогло устранить проблему в моем случае.

Ответ 13

Я использую Мариадб. Когда я пытаюсь поместить эту строку в /etc/my.cnf:

[mysqld]
tmpdir=/tmp 

Устранена ошибка, сгенерированная веб-интерфейсом веб-сайта, связанным с /tmp. Но у него есть проблема с /tmp. Например, когда я пытаюсь пересобрать mariadb из бэкэнда, он не может прочитать каталог /tmp, а затем сгенерировал похожую ошибку.

mysqldump: Couldn't execute 'show fields from 'wp_autoupdate'': Can't create/write to file '/tmp/#sql_1680_0.MAI' (Errcode: 2 "No such file or directory") (1)

Так что это работает и для переднего и заднего конца:

1. mkdir/var/lib/mysql/tmp

2. chmod mysql: mysql/var/lib/mysql/tmp

3. Добавьте следующую строку в раздел [mysqld]:

    tmpdir = /var/lib/mysql/tmp

4. Перезапустите mysqld (например, Centos7: systemctl перезапустите mysqld)