programing

'고정' Mysql 테이블에 대해 "잠금 대기 시간 초과. 트랜잭션 재시작 시도"를 수정하시겠습니까?

goodcopy 2023. 1. 10. 21:30
반응형

'고정' Mysql 테이블에 대해 "잠금 대기 시간 초과. 트랜잭션 재시작 시도"를 수정하시겠습니까?

스크립트에서 다음과 같은 쿼리를 수천 번 로컬 데이터베이스로 전송했습니다.

update some_table set some_column = some_value

where 부분을 추가하는 것을 잊어버렸기 때문에 테이블의 모든 행에 대해 같은 컬럼이 같은 값으로 설정되어 수천 번 실행되어 컬럼이 색인화되었기 때문에 대응하는 인덱스가 너무 많이 갱신되었을 가능성이 있습니다.

너무 오래 걸려서 뭔가 이상하다는 걸 눈치채고 대본을 죽였어요.그 후 컴퓨터를 재부팅했지만 테이블에 뭔가 남아 있었습니다.심플한 쿼리를 실행하는 데 시간이 오래 걸리고 관련 인덱스를 삭제하려고 하면 실패하고 다음 메시지가 나타납니다.

Lock wait timeout exceeded; try restarting transaction

빈정대는 테이블이기 때문에 거래가 암묵적인 것일 수 있습니다.이 테이블을 수리하고 트랜잭션에서 고착을 제거하려면 어떻게 해야 합니까?

저도 비슷한 문제가 있어서 진행 중인 스레드를 확인하면서 해결했습니다.실행 중인 스레드를 표시하려면 mysql 명령줄 인터페이스에서 다음 명령을 사용합니다.

SHOW PROCESSLIST;

interfacemysql에 없는 수.
그러면 대응하는 ID와 실행 시간이 포함된 스레드 목록이 표시되므로 실행에 너무 많은 시간이 걸리는 스레드를 KILL할 수 있습니다.KILL을 하고 있는 는, , ID 를 합니다.phpMyAdmin은 KILL을 합니다.명령줄 인터페이스를 사용하는 경우 다음 예시와 같이 KILL 명령 뒤에 스레드 ID를 사용합니다.

KILL 115;

그러면 해당 스레드에 대한 연결이 종료됩니다.

현재 실행 중인 트랜잭션을 확인할 수 있습니다.

SELECT * FROM `information_schema`.`innodb_trx` ORDER BY `trx_started`

트랜잭션은 목록에서 가장 오래된 트랜잭션이기 때문에 첫 번째 트랜잭션 중 하나여야 합니다., 그럼 이 값을 .trx_mysql_thread_id 감사하겠습니다.KILL★★★★★★★★★★★★★★★★★★:

KILL 1234;

어떤 트랜잭션이 사용자의 것인지 잘 모를 경우 첫 번째 쿼리를 자주 반복하여 어떤 트랜잭션이 지속되는지 확인하십시오.

InnoDB 상태 잠금 확인

SHOW ENGINE InnoDB STATUS;

MySQL 테이블 열기 확인

SHOW OPEN TABLES WHERE In_use > 0;

보류 중인 InnoDB 트랜잭션 확인

SELECT * FROM `information_schema`.`innodb_trx` ORDER BY `trx_started`; 

잠금 종속성 확인 - 차단 항목

SELECT * FROM `information_schema`.`innodb_locks`;

위의 결과를 조사하면 무엇이 무엇을 잠그고 있는지 알 수 있습니다.

문제의 근본 원인은 코드에도 있을 수 있습니다.특히 휴지 상태 등의 JPA를 사용하고 있는 경우는, 관련 함수의 주석을 확인해 주세요.

예를 들어, 여기서 설명한 바와 같이 다음 주석을 잘못 사용하면 데이터베이스가 잠길 수 있습니다.

@Transactional(propagation = Propagation.REQUIRES_NEW) 

데이터베이스 크기가 커지고 많은 트랜잭션을 수행하던 중 이 문제가 발생하기 시작했습니다.

사실 쿼리 또는 DB를 최적화할 수 있는 방법이 있을 수 있지만 수정 작업을 위해 이 두 가지 쿼리를 사용해 보십시오.

다음을 수행합니다.

SET GLOBAL innodb_lock_wait_timeout = 5000; 

그리고 이건...

SET innodb_lock_wait_timeout = 5000; 

트랜잭션에 대한 연결을 설정할 때 트랜잭션을 수행하기 전에 잠금을 획득합니다.잠금을 취득할 수 없는 경우는, 잠시 시도합니다.그래도 잠금을 얻을 수 없는 경우 잠금 대기 시간 초과 오류가 발생합니다.잠금을 획득할 수 없는 이유는 연결을 닫지 않기 때문입니다.따라서 두 번째로 잠금을 받으려고 할 때 이전 연결이 여전히 닫혀 있지 않고 잠금을 유지하고 있기 때문에 잠금을 획득할 수 없습니다.

해결 방법: 연결 닫기 또는setAutoCommit(true)이데올로기 때문에

MySQL을 재부팅하면 정상적으로 동작합니다.

다만, 이러한 문의가 막혀 있는 경우는, 어딘가에 문제가 있는 것에 주의해 주세요.

  • 질의(문자, 데카르트 곱 등)
  • 편집해야 할 레코드가 매우 많다
  • 테스트 "MD5, "MD", "MD5, "MD",LIKE %...%의 개요)
  • 데이터 구조 문제
  • 외부 키 모델(체인/루프 잠금)
  • 잘못 색인화된 데이터

@syedrakib의 말처럼, 이것은 효과가 있지만 오래 지속되는 생산 솔루션은 아닙니다.

주의: 재기동하면, 데이터에 부정합한 상태로 영향을 줄 수 있습니다.

또한 DESPLINE 키워드를 사용하여 MySQL이 쿼리를 처리하는 방법을 확인하고 쿼리 속도를 높일 수 있는 방법(인덱스, 복잡한 테스트 등)을 확인할 수 있습니다.

mysql에 Goto 프로세스가 있습니다.

작업이 아직 진행 중임을 알 수 있습니다.

특정 프로세스를 종료하거나 프로세스가 완료될 때까지 기다립니다.

저도 "업데이트" 스테이트먼트에서 같은 문제에 봉착했습니다.저의 솔루션은 단순히 테이블에 대해 phpMyAdmin에서 사용할 수 있는 작업을 실행하는 것이었습니다.테이블을 최적화, 플래시 및 디플래그했습니다(순서가 아닙니다).테이블을 떨어뜨려 백업에서 복원할 필요가 없습니다.:)

저도 같은 문제가 있었어요.SQL의 교착 상태였던 것 같습니다.태스크 관리자에서 SQL 프로세스를 강제로 닫을 수 있습니다.그래도 해결되지 않으면 컴퓨터를 다시 시작합니다.테이블을 드롭하여 데이터를 새로고침할 필요가 없습니다.

특정 레코드 그룹을 삭제하려고 할 때 이 문제가 발생했습니다(웹 서버상의 MySQL에 대한 ODBC 접속으로 MS Access 2007을 사용).일반적으로 MySQL에서 특정 레코드를 삭제한 후 업데이트된 레코드로 대체합니다(캐스케이드는 여러 관련 레코드를 삭제하므로 단일 레코드 삭제를 위해 모든 관련 레코드를 쉽게 삭제할 수 있습니다).

테이블(optimize, flush 등)에 대해 phpMyAdmin에서 사용할 수 있는 조작을 실행하려고 했지만 플러시를 시도했을 때 RELOAD 에러가 발생하였습니다.데이터베이스가 웹 서버에 있으므로 데이터베이스를 다시 시작할 수 없습니다.백업에서 복원하는 것은 선택사항이 아닙니다.

웹상의 cPanel mySQL 액세스에서 이 레코드 그룹에 대해 삭제 쿼리를 실행해 보았습니다.같은 에러 메세지가 표시된다.

솔루션:이전에 컴퓨터에 설치한 Sun(Oracle)의 무료 MySQL Query Browser를 사용하여 삭제 쿼리를 실행했습니다.바로 작동했고, 문제는 해결됐어요.그런 다음 다시 MySQL에 대한 ODBC 액세스를 사용하여 Access 스크립트를 사용하여 기능을 수행할 수 있었습니다.

내 경우 문제:트랜잭션 내의 일부 행이 업데이트되었으며 트랜잭션이 커밋되기 전에 다른 장소에서 이 트랜잭션 외부에서 동일한 행이 업데이트되었습니다. Ensuring that all the updates to the rows are made within the same transaction resolved my issue.

제 경우 변경으로 해결된 문제delete로.truncate

문제 - 쿼리:

delete from Survey1.sr_survey_generic_details
mycursor.execute(query)

수정 쿼리:

truncate table Survey1.sr_survey_generic_details
mycursor.execute(query)

이 문제는 dbeaver 및 제어판 등 여러 플랫폼에서 데이터베이스에 액세스할 때 발생했습니다.어느 시점에서 dbeaver가 막혀 다른 패널에서는 추가 정보를 처리할 수 없었습니다.해결책은 데이터베이스에 대한 모든 접근포인트를 reboot 하는 것입니다.모두 닫고 다시 시작합니다.

고쳤다.

쿼리에 일치하지 않는 데이터 유형이 삽입되지 않았는지 확인하십시오."사용자 브라우저 에이전트 데이터"를 사용하여VARCHAR(255)이 잠금장치에 문제가 생겼는데, 제가 이 잠금장치로 바꾸었을 때TEXT(255)바로 잡았어요.

따라서 데이터 유형의 불일치일 가능성이 높습니다.

테이블을 삭제하고 백업에서 복원하여 문제를 해결했습니다.

언급URL : https://stackoverflow.com/questions/2766785/fixing-lock-wait-timeout-exceeded-try-restarting-transaction-for-a-stuck-my

반응형