DROP DATABASE가 왜 그렇게 오래 걸립니까? (MySQL)

새로운 CentOS 설치.

큰 DB (2GB SQL 파일) 가져 오기를 실행 중이었고 문제가있었습니다. SSH 클라이언트가 연결이 끊어졌고 가져 오기가 정지 된 것 같습니다. 다른 창을 사용하여 mysql에 로그인했으며 가져 오기가 종료되어 특정 3M 행 테이블에 붙어있는 것처럼 보입니다.

그래서 나는 시도했다

DROP DATABASE huge_db;

15-20 분 후 다른 창에서 나는 :

/etc/init.d/mysqld restart

DROP DB 창에 SERVER SHUTDOWN 메시지가 표시되었습니다. 그런 다음 실제 서버를 다시 시작했습니다.

mysql에 다시 로그인하고 확인했지만 db가 여전히 존재했습니다.

DROP DATABASE huge_db;

다시 한 번, 나는 이미 약 5 분을 기다리고 있습니다.

다시 한 번 새로 설치했습니다. 는 huge_db(시스템 DBS 이외의) 유일한 dB이다. 맹세합니다.이 DB를 크고 빠르게 떨어 뜨 렸지만 어쩌면 틀릴 수도 있습니다.

데이터베이스를 성공적으로 삭제했습니다. 30 분 정도 걸렸습니다. 또한 mysqldump 가져 오기가 종료되었다고 생각했을 때 실수했다고 생각합니다. 터미널 연결이 끊어졌지만 프로세스가 여전히 실행 중이라고 생각합니다. 아마도 가져 오기 미드 테이블 (3M 행 테이블)과 아마도 전체 DB를 통해 3/4의 길을 죽였습니다. "맨 위"가 더 많은 메모리를 사용해야하는 것처럼 보일 때 메모리의 3 % 만 사용하여 mysql을 표시 한 것은 잘못된 것입니다.

DB를 삭제하는 데 30 분이 걸렸으므로 다시 서버를 다시 시작하지 않았을 수도 있고 DROP이 끝날 때까지 기다릴 수도 있지만 mysql이 DROP 쿼리를 얻는 데 어떻게 반응하는지 알 수 없습니다. mysqldump를 통해 가져 오는 것과 동일한 db.

여전히 문제는 여전히 남아 있습니다. 왜 모든 db 파일을 삭제하고 information_schema에서 DB에 대한 모든 참조를 제거하기 만하면 2GB 데이터베이스를 삭제하는 데 30 분 이상이 걸립니까? 큰 문제는 무엇입니까?

프로세스를 종료하는 대신 MySQL 내에서 프로세스를 수행하면 더 안전합니다.

$ mysqladmin processlist -u root -p
Enter password: 
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| Id  | User | Host      | db                | Command | Time | State | Info             |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| 174 | root | localhost | example           | Sleep   | 297  |       |                  |
| 407 | root | localhost |                   | Query   | 0    |       | show processlist |
+-----+------+-----------+-------------------+---------+------+-------+------------------+

ID가 174 인 쿼리는 'example'데이터베이스의 삭제를 차단하는 프로세스이므로 프로세스를 종료하기 전에 먼저 MySQL이 쿼리를 종료하도록하십시오.

$ mysqladmin kill 174

processlist위 명령을 다시 실행하여 종료 되었는지 확인하십시오.

이것이 작동하지 않으면 잘못된 프로세스를 종료하는 것을 볼 수 있지만 그 전에 MySQL 서버를 다시 시작하십시오.

예를 들어 MySQL 클라이언트 만 설치 한 경우 MySQL 쉘에서 'SHOW FULL PROCESSLIST'및 'KILL 174'와 같은 명령을 실행할 수도 있습니다. 요점은 꼭 필요한 경우가 아니라면 쉘에서 'kill'을 사용하여 프로세스를 종료하지 않는 것입니다.

일반적으로 말하면 mysql또는을 사용할 수 있습니다 mysqladmin. 그래도 이와 같은 명령을 자주 실행할 필요는 없습니다. 일단 쿼리를 정기적으로 종료하기 시작하면 문제가 발생하고 해당 문제를 해결하는 것이 좋습니다 (쿼리 프로세스 종료는 증상을 처리하는 것임).

가져 오기 프로세스가 종료되었다고 생각했지만 여전히 실행 중일 수 있습니다.

이 DROP DATABASE명령은 데이터베이스가 실행되기 전에 데이터베이스 가져 오기가 완료되기를 기다렸습니다.

따라서 DROP DATABASE시간이 오래 걸리기 보다는 아마도 수입품 일 것입니다.

다른 사람이 이것을 읽고 데이터베이스 가져 오기를 취소하고 데이터베이스를 삭제하려는 경우 먼저 가져 오기에 대한 PID (프로세스 ID)를 찾아서 다른 터미널에서 실행하는 것이 좋습니다.

$ kill [PID]

... [PID]는 프로세스의 실제 PID입니다.

다른 터미널이 여전히 연결되어 있으면 가져 오기가 즉시 중단됩니다.

SHOW PROCESSLISTphpMyAdmin SQL 탭에서 실행할 수도 있습니다 . 결과 표에는 실행중인 프로세스가 표시되며 종료하려는 행 옆의 'x'를 클릭하면 트릭이 발생합니다.

그런 다음 실행

DROP DATABASE `database_name`;

그리고 모든 것이 깨끗해야합니다.

또 다른 대답은 mysql 내에서 프로세스를 종료하는 것이 외부에서 수행하는 것보다 낫다는 것을 제안했습니다. 나는 그 대답을 테스트하지는 않았지만 매우 그럴듯하게 들립니다. 그래서 나는 이것을 이것 대신에 "허용 된 대답"으로 표시했습니다.

데이터베이스를 삭제하기 전에 데이터베이스에서 가장 큰 테이블을 잘라내십시오. 방화벽 트래픽의 MySQL 아카이브로 작업 할 때 매우 유사한 동작을 보았는데 이는 엄청난 도움이되었습니다.

가장 먼저 떠오르는 것은 상태입니다 Checking Permissions...

DROP DATABASE mydb;/ var / lib / mysql / mydb 내부의 모든 것을 발행하면 모든 파일을 삭제할 권한에 대한 OS 권한이 있는지 확인합니다.

일부는 MySQL 사용자 수를 줄이는 것이 도움이 될 수 있다고 생각했습니다.

나는 같은 문제에 직면했다. 그러나 이번에는 show processlist를 확인했습니다. 더 오랜 시간 동안 권한을 확인한다고 말했습니다. 그런 다음 mysqld_safe가 루트로 실행되는 반면 폴더 수준 권한은 mysql 사용자에게만 해당됩니다. 따라서 쿼리를 종료했습니다. 물론 종료 상태라고 말하는 데 오랜 시간이 걸렸지 만 응답하기를 기다렸다가 쿼리를 종료하고 그룹 및 chmod를 770에 추가하여 폴더 수준 권한을 루트로 변경했습니다. 동일한 드롭 데이터베이스 blah; 20GB 데이터베이스의 경우 2 초 만에 작동했습니다.