MySQL 아티팩트는 전체 프로세스 목록을 표시합니다.

오늘 테스트 데이터 동기화를 하다가 갑자기 네트워크 연결이 끊겼는데, 다시 연결해보니 테이블을 열 수 없는 걸 발견했습니다.

테이블의 데이터 길이가 112192kb인 것을 볼 수 있는데 아쉽게도 열 수 없습니다.

열리지 않으면 삭제할 준비를 하고 다시 시도해 보세요.

일이 그렇게 간단하지 않은 경우가 많습니다. 당연히 삭제할 수도 없고, truncate를 사용할 수도 없습니다. 그러다가 navicat이 멈춰서 데이터베이스에 로그인하여 dorp 작업을 수행했지만 여전히 작동하지 않았습니다.

아마도 네트워크 오류로 인해 이상한 일이 발생했을 것입니다.

그럼 무슨 일이 일어났는지 살펴보겠습니다.

아티팩트가 여기에 있습니다.

show full processlist;

show full processlist 결과는 실시간으로 변경 사항을 반환했으며 mysql 링크 실행의 라이브 스냅샷이므로 긴급 상황 처리에 매우 유용합니다.

이 SQL은 일반적으로 갑작스러운 문제를 해결하기 위해 소방관 역할을 합니다.

현재 mysql의 일부 작동 조건, 압력이 있는지, 어떤 SQL이 실행되고 있는지, 명령문이 얼마나 오래 걸리는지, 느린 SQL이 실행되고 있는지 등을 확인할 수 있습니다.

실행 시간이 오래 걸리는 SQL을 발견하면, 필요한 경우 해당 SQL을 종료하고 먼저 문제를 해결해야 합니다.

명령에는 세 가지 실행 방법이 있습니다.

1 명령줄에서 직접 쿼리하는 것입니다. 끝에 있는 G는 쿼리 결과가 열에 인쇄되므로 각 필드를 별도의 줄에 인쇄할 수 있음을 의미합니다. .

mysql> show full processlist;
+--------+------+----------------------+-------+---------+------+----------+-----------------------+
| Id     | User | Host                 | db    | Command | Time | State    | Info                  |
+--------+------+----------------------+-------+---------+------+----------+-----------------------+
| 449000 | root | 127.123.213.11:59828 | stark | Sleep   | 1270 |          | NULL                  |
| 449001 | root | 127.123.213.11:59900 | stark | Sleep   | 1241 |          | NULL                  |
| 449002 | root | 127.123.213.11:59958 | stark | Sleep   | 1216 |          | NULL                  |
| 449003 | root | 127.123.213.11:60088 | stark | Sleep   | 1159 |          | NULL                  |
| 449004 | root | 127.123.213.11:60108 | stark | Sleep   | 1151 |          | NULL                  |
| 449005 | root | 127.123.213.11:60280 | stark | Sleep   | 1076 |          | NULL                  |
| 449006 | root | 127.123.213.11:60286 | stark | Sleep   | 1074 |          | NULL                  |
| 449007 | root | 127.123.213.11:60344 | stark | Sleep   | 1052 |          | NULL                  |
| 449008 | root | 127.123.213.11:60450 | stark | Sleep   | 1005 |          | NULL                  |
| 449009 | root | 127.123.213.11:60498 | stark | Sleep   |  986 |          | NULL                  |
| 449013 | root | localhost            | NULL  | Query   |    0 | starting | show full processlist |
+--------+------+----------------------+-------+---------+------+----------+-----------------------+
11 rows in set (0.01 sec)
mysql> show full processlist\G;
*************************** 1. row ***************************
     Id: 449000
   User: root
   Host: 127.123.213.11:59828
     db: stark
Command: Sleep
   Time: 1283
  State: 
   Info: NULL
*************************** 2. row ***************************
     Id: 449001
   User: root
   Host: 127.123.213.11:59900
     db: stark
Command: Sleep
   Time: 1254
  State: 
   Info: NULL

2. 링크 스레드와 관련된 테이블을 쿼리하여 스냅샷을 봅니다.

SELECT id, db, USER, HOST, command, time, state, info FROM information_schema. PROCESSLIST WHERE command != 'Sleep' ORDER BY time DESC ;

3. navicat에서 [도구] => [서버 모니터링]을 통해 확인하세요.

이 방법이 더 편리하고 정렬도 가능합니다.

각 열의 의미에 대한 간략한 소개:

Id: 링크 mysql 서버 스레드의 고유 식별자입니다. kill을 통해 이 스레드의 링크를 종료할 수 있습니다.

User: 데이터베이스에 연결하는 현재 스레드의 사용자

Host: 이 명령문이 전송된 IP와 포트를 표시합니다. 문제가 있는 진술을 발행한 사용자를 추적하는 데 사용할 수 있습니다

db: 스레드 링크의 데이터베이스, 사용할 수 없는 경우 null

Command: 현재 연결의 실행된 명령을 표시합니다. 일반적으로 절전 또는 유휴(휴면), 쿼리( query), 연결( 연결)

Time : 스레드가 현재 상태에 있는 시간, 단위는 초

State : 현재 연결을 이용한 sql 문의 상태를 표시하는데, 매우 중요한 컬럼으로 설명이 있을 예정입니다. 나중에 모든 상태 중에서 상태는 단지 명령문 실행의 특정 상태인 SQL 문이 쿼리되었습니다. 예를 들어 tmp 테이블로 복사, 결과 정렬, 데이터 전송 및 기타 상태를 거쳐야 할 수도 있습니다. becomplete

Info: 스레드에 의해 실행된 SQL 문, 실행된 문이 없으면 null입니다. 이 명령문은 클라이언트가 보낸 실행 명령문일 수도 있고, 문제를 발견한 후 어떻게 해결해야 할까요?

1. 위의 문제가 있는 라인을 개별적으로 삭제할 수 있습니다

kill 449000

2. 3분 이상 걸리는 스레드를 일괄 종료할 수도 있습니다

--실행하는 데 3분 이상 걸리는 스레드를 쿼리한 다음 그것들을 kill 문으로 연결하세요

select concat('kill', id, ';')

from information_schema.processlist

where command != 'Sleep'

and time > desc;

물론 질문이 옵니다. 이것은 일반적으로 해결될 수 있지만 이번에는 show processlist 프로세스 중에 이전의 truncate 및 drop 작업만 보고 이 두 스레드를 종료했는데 아무 소용이 없었습니다. . . .

물론 위의 내용이 헛소리는 아니고, 방법론과 비슷한 내용입니다. 처럼 비행 사고가 발생하면 먼저 매뉴얼에 따라 확인하고, 원인을 조사하고, 문제를 해결해야 합니다.

Continue

직후 navicat을 사용하여 테이블 복구 작업을 수행했는데 결과는 Waiting for table Metadata lock

MySQL이 테이블 변경 등 일부 DDL 작업을 수행할 때 테이블에 커밋되지 않은 트랜잭션이 있는 경우, 테이블 메타데이터 잠금이 발생하기를 기다리고, 메타데이터 잠금이 발생하면 테이블에 대한 후속 작업이 차단됩니다.

해결책:

1 information_schema.innodb_trx 테이블에서 현재 커밋되지 않은 트랜잭션을 봅니다.

information_schema.innodb_trxG

에서 trx_state, trx_started, trx_mysql_thread_id, trx_query를 선택합니다. 필드 의미:

tr x_state : 거래 상태, 일반적으로 RUNNING

trx_started : 트랜잭션 실행 시작 시간. 시간이 길면 트랜잭션이 합리적인지 분석합니다.

trx_mysql_thread_id: kill에 사용되는 MySQL 스레드 ID. 일반적으로 트랜잭션의 SQL입니다. DDL 작업은 테이블 메타데이터 잠금을 기다리지 않습니다.

2. 잠금 시간 초과 임계값 조정

lock_wait_timeout은 메타데이터 잠금 획득에 대한 시간 초과(초)를 나타냅니다. 허용되는 값 범위는 1~31536000(1년)입니다. 기본값은 31536000입니다.

https://dev.mysql.com/doc/refman/5.6/en/se...를 참고하세요.

기본값은 1년입니다. . . .

30분으로 조정하세요

set session lock_wait_timeout = 1800;

set global lock_wait_timeout = 1800;

이 문제가 발생할 경우 빠르게 실패하도록 설정하세요.

추천 튜토리얼: "MySQL Tutorial" "Navicat"

위 내용은 MySQL 아티팩트는 전체 프로세스 목록을 표시합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!