MySQL: '/tmp/#sql_3c6_0' 파일을 만들거나 쓸 수 없습니다.MYI' (Errcode: 2) - 그게 무슨 뜻입니까?
어떤 이유에서인지 나의 프로덕션 DB는 이 메시지를 쏟아내기로 결정했습니다.모든 애플리케이션 호출이 DB에 실패하고 다음 오류가 발생합니다.
PreparedStatementCallback; SQL [ /*long sql statement here*/ ];
Can't create/write to file '/tmp/#sql_3c6_0.MYI' (Errcode: 2);
nested exception is java.sql.SQLException: Can't create/write to file '/tmp/#sql_3c6_0.MYI' (Errcode: 2)
이게 무슨 뜻인지 전혀 모르겠어요파일이 없습니다.#sql_3c6_0.MYI인에/tmp그리고 나는 그것을 만들 수 없습니다.#어떤 이유에서인지는 몰라도이에 대해 들어보거나 이 오류를 본 사람이 있습니까?무엇이 잘못되었을 수 있고 몇 가지 가능한 것들을 살펴볼 수 있습니까?
MySQL DB가 실행 중이며 콘솔을 통해 조회할 수 있지만 응용 프로그램이 연결되지 않는 것 같습니다.응용프로그램 코드/파일에 변경사항이 없습니다.갑자기 일어난 일입니다.그래서 어디서부터 살펴봐야 할지, 어떤 해결책을 적용해야 할지조차 잘 모르겠습니다.무슨 생각 있어요?
페도라 시스템에서 워드프레스를 실행할 때도 이 오류가 발생합니다.
구글 검색을 해봤는데, 이걸 고칠 방법을 찾더군요.
아마 이것도 당신에게 도움이 될 겁니다.
mysql config : my.cnf를 확인합니다.
cat /etc/my.cnf | grep tmpdir내 안에 아무것도 안 보여요.
my.cnf더하다
tmpdir=/tmp.my.cnf아래[mysqld]웹/앱 및 mysql 서버 다시 시작
/etc/init.d/mysqld restart
종종 이것은 당신의/tmp파티션 공간이 부족하여 파일을 만들 수 없습니다. 또는 어떤 이유로mysqld권한 문제로 인해 프로세스가 해당 디렉토리에 쓸 수 없습니다.때때로 이런 경우가 있습니다.selinux당신의 퍼레이드에 비가 내립니다.
"템프 파일"이 필요한 모든 작업은/tmp기본적으로 디렉토리입니다.지금 보시는 이름은 내부의 무작위 이름일 뿐입니다.
systemd MySQL이 있는 Fedora에서 private /tmp 디렉토리를 가져옵니다./proc/PID_of_MySQL/mountinfo에서 다음과 같은 행을 찾을 수 있습니다.
156 1298:1 /tmp/systemd-name space-AN7vo9/private/tmprw, relatime - ext4 /dev/sda1rw, seclabel, data=순서화
임시 폴더 /tmp/systemd-namespace-AN7vo9/private가 MySQL 프로세스의 개인 네임스페이스에 /tmp로 마운트됨을 의미합니다.유감스럽게도 이 폴더는 자주 사용하지 않으면 tmpwatch에 의해 삭제됩니다.
/etc/cron.daily/tmpwatch를 수정하고 제외 패턴을 삽입했습니다.-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
사용하지 않는 개인 네임스페이스 폴더가 자동으로 삭제되지 않는 부작용이 있습니다.
이 문제에 대해 올바른 방향을 제시해 준 ArturZ에게 정말 감사드립니다.제 시스템에 tmpwatch가 설치되어 있지 않아서 제 경우에는 문제가 되지 않습니다.하지만 결과는 같습니다.systemd가 생성하는 개인/tmp가 제거되고 있습니다.다음과 같은 일이 발생합니다.
systemd는 CLON_NEWNS 플래그를 사용하여 clone()을 통해 새 프로세스를 생성하여 개인 네임스페이스를 가져옵니다.또는 CLON_NEWNS에서 unshare()를 호출할 수도 있습니다.마찬가지입니다.
systemd는 /tmp에 하위 디렉토리(예: /tmp/systemd-namespace-XRiWad/private)를 생성하고 /tmp에 마운트합니다.CLON_NEWNS가 #1에 설정되었기 때문에 이 마운트 지점은 다른 모든 프로세스에서 볼 수 없습니다.
그런 다음 systemd는 이 개인 네임스페이스에서 mysqld를 호출합니다.
일부 특정 데이터베이스 작업(예: "description ;")은 임시 파일을 생성하고 제거하는데, 이는 /tmp/systemd-namespace-XRiWad/private에서 타임스탬프를 업데이트하는 부작용이 있습니다.다른 데이터베이스 작업은 /tmp를 전혀 사용하지 않고 실행됩니다.
결국 데이터베이스 자체가 활성 상태로 남아 있더라도 /tmp/systemd-namespace-XRiWad/private에서 타임스탬프를 업데이트하는 작업은 발생하지 않습니다.
/bin/systemd-tmp 파일이 함께 제공되어 "오래된" /tmp/systemd-namespace-XRiWad/private 디렉토리를 제거하여 시스템의 다른 모든 것에 대해 public/tmp를 사용할 수 있는 상태로 유지하면서 mysqld에 대해 private/tmp를 효과적으로 사용할 수 없게 만듭니다.
mysqld를 재시작하는 것은 새로운 개인/tmp 디렉토리를 사용하여 #1 단계에서 모든 것을 다시 시작하기 때문에 작동합니다.하지만 결국 문제는 다시 찾아옵니다.그리고 또.
간단한 솔루션은 /bin/systemd-tmp 파일을 구성하여 /tmp/systemd-namespace-*라는 이름으로 /tmp에 있는 모든 파일을 보존하는 것입니다.다음 내용으로 /etc/tmpfiles.d/privatetmp.conf를 만들어 이 작업을 수행했습니다.
x /tmp/systemd-namespace-*
x /tmp/systemd-namespace-*/private
문제는 해결됐습니다.
파일 이름은 MySQL의 쿼리에 의해 만들어진 임시 테이블처럼 보입니다.이러한 파일은 수명이 매우 짧은 경우가 많으며, 특정 쿼리 중에 생성되어 즉시 정리됩니다.
그러나 쿼리가 임시 테이블에서 처리해야 하는 데이터의 양에 따라 매우 커질 수 있습니다.또는 여러 개의 동시 쿼리를 사용하여 임시 테이블을 만들 수 있으며, 이러한 쿼리가 동시에 충분히 실행되면 디스크 공간이 고갈될 수 있습니다.
MySQL 컨설팅을 하고, 간헐적으로 루트 파티션에 디스크가 가득 차는 오류가 발생한 고객을 도와주었는데, 그는 매번 볼 때마다 약 6GB의 여유 공간이 있었습니다.그의 쿼리 로그를 조사한 후, 우리는 그가 때때로 4개 이상의 쿼리를 동시에 실행하고, 각각 1.5개의 쿼리를 생성한다는 것을 발견했습니다.루트 파티션에 있던 /tmp의 GB 임시 테이블입니다.쾅!
그에게 제시한 해결책:
MySQL을 .
tmp_table_size그리고.max_heap_table_size그래서 MySQL은 메모리에 아주 큰 임시 테이블을 만들 수 있습니다.그러나 MySQL에서 1.5를 생성하도록 허용하는 것은 좋지 않습니다.동시에 생성되는 GB 임시 테이블의 수를 제한할 방법이 없기 때문에 메모리의 GB 임시 테이블.이렇게 하면 기억력이 금방 고갈될 수 있습니다.MySQL
tmpdir더 많은 공간이 있는 다른 디스크 파티션의 디렉토리로 이동할 수 있습니다.이렇게 큰 임시 테이블을 생성하는 쿼리를 파악하고 쿼리를 최적화합니다.예를 들어, 인덱스를 사용하여 해당 쿼리의 검색을 테이블의 더 작은 조각으로 줄일 수 있습니다.또는 쿼리에 검색할 행이 너무 많지 않도록 이야기의 일부 데이터를 보관할 수 있습니다.
제게 있어서 이 문제는 오랜 시간 동안 mysql이나 웹서버를 사용하지 않은 후에 발생했습니다.따라서 설정이 올바른지 확신했습니다. 서비스를 다시 시작하기만 하면 이 문제가 해결됩니다.이 문제의 이상한 점은 데이터베이스에 연결할 수 있고, 심지어 mysql 도구를 사용하여 테이블을 쿼리/추가할 수도 있다는 것입니다.예를 들어 다음과 같습니다.
mysql -u root -p
다음을 사용하여 다시 시작했습니다.
systemctl start mysqld.service
또는 service mysqld restart 또는 /etc/init.d/mysqld restart
참고: 이러한 명령의 컴퓨터/환경에 따라 서비스를 다시 시작해야 합니다.
더 나은 방법이 제게 효과가 있었습니다.
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/
매우 쉽습니다. /tmp 폴더에 777 권한만 부여하면 됩니다.유형만 입력:
chmod -R 777 /tmp
Ubuntu 박스에서 /tmp를 다른 볼륨(symlink)으로 이동한 후 이 오류가 발생하기 시작했습니다.필요한 권한을 설정한 1777에도 문제가 해결되지 않았습니다.
MySQL은 새 tmp 위치 /mnt/tmp에 쓰기를 허용하지 않았던 AppArmor에 의해 보호됩니다.이 문제를 해결하기 위해 /etc/apparmor.d/추상/user-tmp에 다음 줄을 추가해야 했습니다.
소유자 /mnt/tmp/**rwkl,
/mnt/tmp/rw,
데비안 7.5에서도 같은 오류가 발생했습니다.나는 그것을 깨달았습니다./tmp폴더 소유자와 권한이 꺼져 있습니다.다른 대답이 제시되었듯이, 나는 다음과 같이 했습니다. (반드시 뿌리가 되어야 합니다.
chown root:root /tmp && chmod 1777 /tmp
mysql 데몬을 다시 시작할 필요도 없었습니다.
mariadb를 사용하고 있습니다.이 줄을 /etc/my.cnf에 놓으려고 하면:
[mysqld]
tmpdir=/tmp
/tmp와 관련된 웹사이트 프론트엔드에서 발생한 오류를 해결하였습니다.그러나 /tmp에 백엔드 문제가 있습니다.예를 들어, 백엔드에서 mariadb를 재구축하려고 하면 /tmp dir를 읽을 수 없고, 그 다음에 비슷한 오류가 발생했습니다.
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. chown mysql: mysql /var/lib/ mysql/tmp
3. [mysqld] 섹션에 다음 행을 추가합니다.
tmpdir = /var/lib/mysql/tmp
4. 내 sqld를 다시 시작합니다(예:Centos7: systemctl restart mysqld)
특히 SELinux가 활성화된 경우 액세스 제어 보안 정책으로 인해 외부 실행 파일이 시스템 위치에 임시 파일을 생성할 수 없습니다.
다음 명령을 실행하여 SELinux를 사용하지 않도록 설정합니다.
echo 0 >/selinux/
이제 mysql을 시작할 수 있습니다. /tmp 또는 시스템 디렉토리를 읽고 쓰는 동안 사용 권한과 관련된 오류가 발생하지 않습니다.
위 명령에서 SELinux security back change 0 to 1을 활성화하고자 하는 경우.
권한 문제를 확인합니다, mysql config.
또한 디스크 공간, 할당량 제한에 도달하지 않았는지 확인합니다.
참고: 일부 시스템은 파일의 수를 제한하고 있으며(공간뿐만 아니라), 일부 오래된 세션 파일을 삭제하면 문제를 해결하는 데 도움이 되었습니다.
VPS/가상 호스팅을 사용하는 사용자에게 적합합니다.
나는 VPS를 사용하고 있었고 MySQL이 /tmp에 쓸 수 없는 오류가 발생했고 모든 것이 정확해 보였습니다.여유 공간이 충분했고, 충분한 여유 공간이 있었고, 정확한 권한이 있었습니다.문제가 제 VPS 외부에 있는 것으로 드러났는데, VPS를 호스팅하는 기계가 가득 찼습니다.파일 시스템에는 "가상 공간"만 있었지만, VPS를 호스팅하는 백그라운드 시스템에는 "물리적 공간"이 남아 있지 않았습니다.VPS 회사에서 수리할 경우 연락을 해야 했습니다.
이 문제가 문제라고 생각되는 경우 /tmp(1GB)에 더 큰 파일을 쓰는 것을 테스트해 볼 수 있습니다.
dd if=/dev/zero of=/tmp/file.txt count=1024 bs=1048576
나는.No space left on device오류 메시지. 백그라운드에 있는 디스크/볼륨이 가득 찼다는 것을 알려주는 것입니다.
저도 같은 문제가 있었는데 저희 DB 서버의 공간이 부족해서 발생했습니다.일부 디스크 공간을 정리하면 문제가 해결되었습니다.
언급URL : https://stackoverflow.com/questions/11997012/mysql-cant-create-write-to-file-tmp-sql-3c6-0-myi-errcode-2-what-does
'programing' 카테고리의 다른 글
| MariaDB 10.1 도커 충돌 InnoDB (0) | 2023.10.24 |
|---|---|
| 각진 것JS 기능 반응형 프로그래밍? (0) | 2023.10.24 |
| Google+ 사용자 ID에 가장 적합한 열 유형은 무엇입니까? (0) | 2023.10.24 |
| 위젯 카테고리 워드프레스, 디스플레이 수 변경 (0) | 2023.10.24 |
| Oracle 데이터 유형:VARCHAR2를 사용해야 합니까 아니면 CHAR를 사용해야 합니까? (0) | 2023.10.24 |