이 기사에서는 전역 잠금과 관련된 문제를 주로 소개하는 mysql에 대한 관련 지식을 제공합니다. 데이터베이스에 읽기 잠금을 추가한 후에는 다른 요청이 데이터베이스에 쓰기 잠금을 추가할 수 없습니다. 모두에게 도움이 되기를 바랍니다.

추천 학습: mysql 비디오 튜토리얼

데이터베이스 설계의 원래 의도는 동시성 문제를 처리하는 것입니다. 여러 사용자가 공유하는 리소스이므로 동시 액세스가 발생할 때 데이터베이스는 액세스 규칙을 합리적으로 제어해야 합니다. 자원의. 잠금은 이 액세스 규칙을 구현하는 데 사용되는 중요한 데이터 구조입니다.

먼저 일반적인 잠금 분류 다이어그램을 게시하겠습니다

MySQL의 잠금은 잠금 범위에 따라 크게 전역 잠금, 테이블 잠금, 행 잠금으로 나눌 수 있습니다. 먼저 이러한 유형의 잠금에 대해 알아보겠습니다. 이번 글에서는 전역 잠금에 대해 알아 보겠습니다.

글로벌 잠금

글로벌 잠금은 전체 데이터베이스를 잠그는 것입니다. 데이터베이스에 읽기 잠금을 추가한 후에는 다른 요청이 데이터베이스에 쓰기 잠금을 추가할 수 없습니다. 데이터베이스에 쓰기 잠금을 추가하면 다른 후속 요청이 데이터베이스에 읽기 또는 쓰기 잠금을 추가할 수 없습니다.

FTWRL

MySQL은 전역 읽기 잠금, FTWRL(읽기 잠금이 있는 테이블 플러시)을 추가하는 방법을 제공합니다. 전체 라이브러리를 읽기 전용 상태로 만들어야 하는 경우 이 명령을 사용할 수 있습니다. 그러면 다른 스레드의 다음 명령문이 차단됩니다: 데이터 업데이트 명령문(추가, 삭제, 수정), 데이터 정의 명령문(테이블 생성 포함) , 테이블 구조 수정 등) 및 업데이트 클래스 트랜잭션에 대한 커밋 문입니다.

글로벌 잠금 사용 시나리오

글로벌 잠금 사용 시나리오: 전체 데이터베이스에 대한 논리적 백업을 만듭니다. 논리적 백업이란 전체 데이터베이스의 모든 테이블을 선택하여 텍스트로 저장하는 것을 의미합니다. 즉, 글로벌 잠금은 마스터-슬레이브 백업 데이터를 수행하거나 데이터를 가져오고 내보낼 때만 사용됩니다.

그렇다면 왜 전역 잠금이 필요한가요?

데이터 백업을 하거나 데이터를 가져오고 내보낼 때 이 기간 동안 데이터의 추가, 삭제, 수정이 동시에 가능하면 데이터 불일치가 발생하기 때문입니다.

과거에는 백업 중에 다른 스레드가 데이터베이스를 업데이트하지 않도록 위에서 언급한 FTWRL을 사용하는 방법이 있었습니다. 참고: 백업 프로세스 중에는 전체 라이브러리가 완전히 읽기 전용입니다.

글로벌 잠금이 이 데이터베이스를 지향하기 때문에 글로벌 잠금을 추가하는 것은 매우 위험할 것 같습니다.

• 메인 데이터베이스에 백업을 하면 백업 기간 동안 업데이트가 불가능해 기본적으로 모든 업무가 중단됩니다.
• 슬레이브 데이터베이스에 백업할 경우 백업 기간 동안 마스터 데이터베이스에서 동기화된 binlog가 실행되지 않아 마스터-슬레이브 지연 및 데이터 불일치가 발생합니다.

잠금을 방지하는 방법

전역 잠금을 추가하면 큰 영향을 미치므로 잠금을 피할 수 있나요?

위의 소개를 통해 우리는 잠금이 데이터 불일치 문제를 해결하기 위한 것임을 알고 있습니다. 따라서 데이터 불일치 문제를 해결할 수 있는 한 전역 잠금을 추가할 필요는 없습니다. 그런 생각이 있습니다. 데이터 백업을 시작할 때 작업 로그를 기록하면 백업 과정에서 데이터베이스의 추가, 삭제, 수정 및 쿼리가 잠금 없이 허용되고, 백업 과정에서는 추가 작업 기록이 허용됩니다. , 삭제, 수정 및 쿼리는 하나의 로그 파일에 기록됩니다. 백업이 완료된 후 이 기간 동안 로그 파일의 모든 작업을 실행합니다. 이렇게 하면 백업 전후의 데이터 일관성이 보장됩니다.

결론적으로, 잠금이 없으면 백업 데이터와 메인 데이터가 논리적인 시점에 있지 않으며, 이러한 관점은 논리적으로 불일치합니다. 논리적 시점의 일관성, 즉 논리적 뷰의 일관성을 보장하면 데이터 일관성을 보장할 수 있습니다. 이를 통해 이전에 배운 트랜잭션 격리 수준을 반복 가능한 격리 수준으로 생각합니다. 일관된 견해.

MySQL의 기본 엔진인 InnoDB에는 데이터 일관성을 보장하는 메커니즘이 있습니다. InnoDB 엔진에는 데이터 스냅샷 버전 기능이 있습니다. MVCC는 기록 버전의 스냅샷을 유지하므로 각 스냅샷은 데이터를 백업할 때 트랜잭션 버전 번호를 적용합니다. 데이터를 가져오려면 자신의 트랜잭션 버전 번호보다 작은 트랜잭션 버전 번호의 데이터만 읽어야 합니다.

–단일 트랜잭션 명령 잠금

공식 논리적 백업 도구는 mysqldump입니다. mysqldump가 –single-transaction 매개변수를 사용하는 경우 일관된 보기를 얻을 수 있도록 데이터를 가져오기 전에 트랜잭션이 시작됩니다. MVCC 지원으로 인해 이 과정에서 데이터가 정상적으로 업데이트될 수 있습니다.

--single-transaction 매개변수의 역할은 트랜잭션의 격리 수준을 반복 가능한 읽기, 즉 REPEATABLE READ로 설정하는 것입니다. 이는 트랜잭션의 모든 동일한 쿼리가 동일한 데이터를 읽도록 보장합니다. 덤프 기간 동안 다른 InnoDB 엔진 스레드가 테이블 데이터를 수정하여 제출하더라도 덤프 스레드의 데이터에는 영향을 미치지 않습니다.

그리고 일관된 스냅샷 사용을 스냅샷 수준으로 설정하세요. 반복 읽기만 가능한 경우 트랜잭션 시작 시 데이터가 덤프되기 전에 다른 스레드가 데이터를 수정하여 제출하면 이때 첫 번째 쿼리의 결과는 다른 스레드에서 제출한 결과이고 WITH CONSISTENT SNAPSHOT은 트랜잭션이 시작될 때 첫 번째 쿼리의 결과가 트랜잭션 시작 시의 데이터 A임을 보장합니다. 이때 다른 스레드가 해당 데이터를 B로 수정하더라도 쿼리 결과는 여전히 A입니다.

단일 트랜잭션 방식은 모든 테이블에 트랜잭션 엔진을 사용하는 라이브러리에만 적용됩니다. mysqldump 프로세스에서 --single-transaction을 추가하면 InnoDB 데이터의 완전한 일관성을 보장할 수 있습니다. 트랜잭션을 지원하지 않는 MyISAM과 같은 엔진의 경우 백업 프로세스 중에 업데이트가 있으면 항상 최신 데이터만 얻을 수 있습니다. 이는 백업의 일관성을 파괴합니다. 이때 여전히 전역 잠금이 필요하므로 FTWRL 명령을 사용해야 합니다.

읽기 전용 설정

전체 라이브러리가 읽기 전용이어야 하므로 set global readonly = true를 사용하면 어떨까요? 이런 질문이 있을 수도 있습니다.

읽기 전용 방법이 전체 라이브러리를 읽기 전용 상태로 만들 수도 있다는 것은 사실이지만, 주로 두 가지 이유로 FTWRL 방법을 사용하는 것이 좋습니다.

• 일부 시스템에서는 읽기 전용 값이 다음과 같습니다. 데이터베이스가 기본 데이터베이스인지 대기 데이터베이스인지 결정하는 등의 다른 논리에 사용됩니다. 따라서 전역 변수를 수정하면 더 큰 영향을 미칩니다.
• 예외 처리 메커니즘에는 차이가 있습니다. FTWRL 명령을 실행한 후 클라이언트의 연결이 비정상적으로 끊어지면 MySQL은 자동으로 전역 잠금을 해제하고 전체 라이브러리는 정상적으로 업데이트할 수 있는 상태로 돌아갑니다.

전체 라이브러리를 읽기 전용으로 설정한 후 클라이언트에서 예외가 발생하면 데이터베이스가 읽기 전용 상태로 유지되므로 전체 라이브러리가 오랫동안 쓸 수 없는 상태가 되어 위험이 높습니다.

추천 학습: mysql 비디오 튜토리얼

위 내용은 MySQL 전역 잠금에 대해 이야기해 보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!