초콜릿 MySQL 학습'3차'거래 소개 & 왜 MySQL의 기본 분리 단계가 Repeatable Read
3456 단어 MySQL
입문
거래하면 알고 싶은 사람이 많아요.한마디로'분리할 수 없는 일련의 조작'이다.가장 흔히 볼 수 있는 예는 송금이다.
A 계좌에서 B 계좌로 1만 엔을 송금할 때 DB를 사용하려면 다음 2단계가 필요합니다.
① A계좌 잔액 1만을 공제
② B 계좌 잔액 1만 기록 추가
①이 끝나는 순간 시스템 장애로 ②가 실행되지 않으면 힘들어진다.그래서 ①과 ②는 분리할 수 없는 두 가지 조작이다.
모두 성공하거나 실패할 수밖에 없다.
나는 거래가 매우 어렵고 재미있는 화제라고 생각한다.
이번에는 MySQL의 거래 지원 기능에 따라 간단한 소개와 제목에 재미있는 문제를 해결해 보겠습니다.
InnoDB만
MySQL을 사용하여 트랜잭션을 지원하지만 모든 스토리지 엔터티에서 지금까지 InnoDB만 지원됩니다.기본 스토리지가 MyISAM에서 InnoDB로 변경되는 가장 중요한 이유입니다.
ACID
거래하면 ACID도 자연스럽게 나오죠.'관련성','일치성','고립성'과'지속성'은 신뢰할 수 있는 사무 시스템이 갖춰야 할 성질이다.구체적으로 말하면 여기서 전개되지 않기 때문에 할애위키백과.현재의 예는 원자성이다.
격리 수준
ACID의 ACD는 확실히 만족해야 하지만, I(분리성)가 엄격하게 준수되면 시스템의 병행 처리도 성능을 대폭 줄일 수 없다.따라서 통상적으로 데이터베이스의 사무 기능은 일부 격리성을 희생하여 성능을 향상시키는 선택을 제공한다.ySQL은 분리 수준입니다.
분리 레벨은 RU(Read Uncommitted), RC(Read Committed), RR(Rereatable Read) 및 SI(Serializable) 네 가지로 서로 다른 레벨에서는 더러운 읽기, 모호한 읽기, 가상 읽기 문제가 발생할 수 있다.구체적으로 설명하는 기사가 많기 때문에 여기도 전개되지 않지만 흥미가 있거나 해보고 싶다면 @PruneMazui 글 와 @song_ss씨의 보도 를 추천한다.
왜 MySQL의 기본 격리 수준이 RR입니까?
우리는 정식 공연에 들어가야 한다.모두가 알다시피 PostgreSQL, Oracle 및 SQL Server의 기본 격리 수준은 RC입니다. 왜 MySQL의 기본 격리 수준은 RC로 설정되지 않습니까?
RU는 데이터에 대한 분리성이 너무 떨어지고 SI는 성능이 너무 떨어지기 때문에 우선 대화에서 제외합니다.
RR을 사용하지 않는 이유는 마지막으로 설명한 바이너리 로그와 관련이 있습니다.정확히 말하면, 그것은 이전의 2진 로그와 관련이 있다.
이진 로그의 형식은 다음과 같은 세 가지가 있다
· STATEMENT-에서 실행한 SQL 문구를 직접 기록합니다.
· ROWS에서 실행되는 SQL 문장에 따른 데이터 변화를 기록합니다.
· MIXED-STATEMENT와 ROW의 조합.
단, MySQL5.0 이전에는 STATEMENT만 지원됩니다.
그럼 2진 로그에 무슨 문제가 있습니까?
ySQL의 종속 복제는 덤프 + 바이너리 로그를 실행하여 수행됩니다.
업무의 분리 단계를 Read Committed로 설정하면 STATEMENT 형식의 바이너리 로그에서 복사할 때 호스트와 종속 데이터가 일치하지 않는 문제가 발생합니다.
아래의 예를 보십시오.(위부터 시간 순서)
만약 MySQL이 주종 구조라면, binlog_하면, 만약, 만약...
주인과 종속mysql> select * from t;
하면, 만약, 만약...
마스터
+---+---+
| c1 |c2
+---+---+
| 2 | 2
+---+---+
1 row in set
종속파
Empty set
사용자 정의 모양새를 정의합니다.
세션 2의 삽입 데이터는 RC로 분리되므로 세션 1을 볼 수 없습니다(자세한 내용은 나중에 설명). 따라서 세션 1의 삭제 범위에 없습니다.단, 주 제출 순서는 세션 2 → 세션 1이기 때문에 바이너리 로그는 보조 서버에서 같은 순서로 실행됩니다.
따라서 세션 2에 삽입된 레코드는 세션 1로 삭제됩니다.
이 문제를 피할 수 있는 두 가지 방법이 있다
1. 바이너리 로그의 형식을 ROW 또는 MIXED로 설정합니다.SQL 문장 대신 데이터 변경을 사용하여 복제하면 위의 데이터 불일치 문제가 사라집니다.
2. 트랜잭션 격리 수준을 반복 읽기 가능하도록 설정합니다.
반복 읽기 가능 기능(GAP 잠금)에서 세션 2의 삽입을 막고 세션 1 → 세션 2에서 제출 순서를 지정합니다.GAP 록에 관해서는 잠시 후에 전개될 것이기 때문에 이번에 통과되었다.
역사적으로 MySQL(5.0 이전)의 바이너리 로그 형식은 STATEMENT만 있었기 때문에 두 번째 방법으로 문제를 피했습니다.
총결산
이번에는 거래와 분리 수준을 소개했다.
격리 수준은 RU, Read Committed, RR 및 SI 네 가지 수준입니다.ySQL의 기본 격리 수준은 반복 읽기입니다.
이유는 Read Committed 및 binlog_format=STATEMENT 조합, 종속 복제를 통해 데이터가 일치하지 않는 문제가 발생합니다.해결 방법은 반복 읽기(GAP 잠금) 또는 바이너리 로그 형식을 ROW 또는 MIXED(MySQL5.1 이상)로 설정하는 것입니다.
Reference
이 문제에 관하여(초콜릿 MySQL 학습'3차'거래 소개 & 왜 MySQL의 기본 분리 단계가 Repeatable Read), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/philipsli/items/b7d66a46b9bd1f114408
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
MySQL을 사용하여 트랜잭션을 지원하지만 모든 스토리지 엔터티에서 지금까지 InnoDB만 지원됩니다.기본 스토리지가 MyISAM에서 InnoDB로 변경되는 가장 중요한 이유입니다.
ACID
거래하면 ACID도 자연스럽게 나오죠.'관련성','일치성','고립성'과'지속성'은 신뢰할 수 있는 사무 시스템이 갖춰야 할 성질이다.구체적으로 말하면 여기서 전개되지 않기 때문에 할애위키백과.현재의 예는 원자성이다.
격리 수준
ACID의 ACD는 확실히 만족해야 하지만, I(분리성)가 엄격하게 준수되면 시스템의 병행 처리도 성능을 대폭 줄일 수 없다.따라서 통상적으로 데이터베이스의 사무 기능은 일부 격리성을 희생하여 성능을 향상시키는 선택을 제공한다.ySQL은 분리 수준입니다.
분리 레벨은 RU(Read Uncommitted), RC(Read Committed), RR(Rereatable Read) 및 SI(Serializable) 네 가지로 서로 다른 레벨에서는 더러운 읽기, 모호한 읽기, 가상 읽기 문제가 발생할 수 있다.구체적으로 설명하는 기사가 많기 때문에 여기도 전개되지 않지만 흥미가 있거나 해보고 싶다면 @PruneMazui 글 와 @song_ss씨의 보도 를 추천한다.
왜 MySQL의 기본 격리 수준이 RR입니까?
우리는 정식 공연에 들어가야 한다.모두가 알다시피 PostgreSQL, Oracle 및 SQL Server의 기본 격리 수준은 RC입니다. 왜 MySQL의 기본 격리 수준은 RC로 설정되지 않습니까?
RU는 데이터에 대한 분리성이 너무 떨어지고 SI는 성능이 너무 떨어지기 때문에 우선 대화에서 제외합니다.
RR을 사용하지 않는 이유는 마지막으로 설명한 바이너리 로그와 관련이 있습니다.정확히 말하면, 그것은 이전의 2진 로그와 관련이 있다.
이진 로그의 형식은 다음과 같은 세 가지가 있다
· STATEMENT-에서 실행한 SQL 문구를 직접 기록합니다.
· ROWS에서 실행되는 SQL 문장에 따른 데이터 변화를 기록합니다.
· MIXED-STATEMENT와 ROW의 조합.
단, MySQL5.0 이전에는 STATEMENT만 지원됩니다.
그럼 2진 로그에 무슨 문제가 있습니까?
ySQL의 종속 복제는 덤프 + 바이너리 로그를 실행하여 수행됩니다.
업무의 분리 단계를 Read Committed로 설정하면 STATEMENT 형식의 바이너리 로그에서 복사할 때 호스트와 종속 데이터가 일치하지 않는 문제가 발생합니다.
아래의 예를 보십시오.(위부터 시간 순서)
만약 MySQL이 주종 구조라면, binlog_하면, 만약, 만약...
주인과 종속mysql> select * from t;
하면, 만약, 만약...
마스터
+---+---+
| c1 |c2
+---+---+
| 2 | 2
+---+---+
1 row in set
종속파
Empty set
사용자 정의 모양새를 정의합니다.
세션 2의 삽입 데이터는 RC로 분리되므로 세션 1을 볼 수 없습니다(자세한 내용은 나중에 설명). 따라서 세션 1의 삭제 범위에 없습니다.단, 주 제출 순서는 세션 2 → 세션 1이기 때문에 바이너리 로그는 보조 서버에서 같은 순서로 실행됩니다.
따라서 세션 2에 삽입된 레코드는 세션 1로 삭제됩니다.
이 문제를 피할 수 있는 두 가지 방법이 있다
1. 바이너리 로그의 형식을 ROW 또는 MIXED로 설정합니다.SQL 문장 대신 데이터 변경을 사용하여 복제하면 위의 데이터 불일치 문제가 사라집니다.
2. 트랜잭션 격리 수준을 반복 읽기 가능하도록 설정합니다.
반복 읽기 가능 기능(GAP 잠금)에서 세션 2의 삽입을 막고 세션 1 → 세션 2에서 제출 순서를 지정합니다.GAP 록에 관해서는 잠시 후에 전개될 것이기 때문에 이번에 통과되었다.
역사적으로 MySQL(5.0 이전)의 바이너리 로그 형식은 STATEMENT만 있었기 때문에 두 번째 방법으로 문제를 피했습니다.
총결산
이번에는 거래와 분리 수준을 소개했다.
격리 수준은 RU, Read Committed, RR 및 SI 네 가지 수준입니다.ySQL의 기본 격리 수준은 반복 읽기입니다.
이유는 Read Committed 및 binlog_format=STATEMENT 조합, 종속 복제를 통해 데이터가 일치하지 않는 문제가 발생합니다.해결 방법은 반복 읽기(GAP 잠금) 또는 바이너리 로그 형식을 ROW 또는 MIXED(MySQL5.1 이상)로 설정하는 것입니다.
Reference
이 문제에 관하여(초콜릿 MySQL 학습'3차'거래 소개 & 왜 MySQL의 기본 분리 단계가 Repeatable Read), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/philipsli/items/b7d66a46b9bd1f114408
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
ACID의 ACD는 확실히 만족해야 하지만, I(분리성)가 엄격하게 준수되면 시스템의 병행 처리도 성능을 대폭 줄일 수 없다.따라서 통상적으로 데이터베이스의 사무 기능은 일부 격리성을 희생하여 성능을 향상시키는 선택을 제공한다.ySQL은 분리 수준입니다.
분리 레벨은 RU(Read Uncommitted), RC(Read Committed), RR(Rereatable Read) 및 SI(Serializable) 네 가지로 서로 다른 레벨에서는 더러운 읽기, 모호한 읽기, 가상 읽기 문제가 발생할 수 있다.구체적으로 설명하는 기사가 많기 때문에 여기도 전개되지 않지만 흥미가 있거나 해보고 싶다면 @PruneMazui 글 와 @song_ss씨의 보도 를 추천한다.
왜 MySQL의 기본 격리 수준이 RR입니까?
우리는 정식 공연에 들어가야 한다.모두가 알다시피 PostgreSQL, Oracle 및 SQL Server의 기본 격리 수준은 RC입니다. 왜 MySQL의 기본 격리 수준은 RC로 설정되지 않습니까?
RU는 데이터에 대한 분리성이 너무 떨어지고 SI는 성능이 너무 떨어지기 때문에 우선 대화에서 제외합니다.
RR을 사용하지 않는 이유는 마지막으로 설명한 바이너리 로그와 관련이 있습니다.정확히 말하면, 그것은 이전의 2진 로그와 관련이 있다.
이진 로그의 형식은 다음과 같은 세 가지가 있다
· STATEMENT-에서 실행한 SQL 문구를 직접 기록합니다.
· ROWS에서 실행되는 SQL 문장에 따른 데이터 변화를 기록합니다.
· MIXED-STATEMENT와 ROW의 조합.
단, MySQL5.0 이전에는 STATEMENT만 지원됩니다.
그럼 2진 로그에 무슨 문제가 있습니까?
ySQL의 종속 복제는 덤프 + 바이너리 로그를 실행하여 수행됩니다.
업무의 분리 단계를 Read Committed로 설정하면 STATEMENT 형식의 바이너리 로그에서 복사할 때 호스트와 종속 데이터가 일치하지 않는 문제가 발생합니다.
아래의 예를 보십시오.(위부터 시간 순서)
만약 MySQL이 주종 구조라면, binlog_하면, 만약, 만약...
주인과 종속mysql> select * from t;
하면, 만약, 만약...
마스터
+---+---+
| c1 |c2
+---+---+
| 2 | 2
+---+---+
1 row in set
종속파
Empty set
사용자 정의 모양새를 정의합니다.
세션 2의 삽입 데이터는 RC로 분리되므로 세션 1을 볼 수 없습니다(자세한 내용은 나중에 설명). 따라서 세션 1의 삭제 범위에 없습니다.단, 주 제출 순서는 세션 2 → 세션 1이기 때문에 바이너리 로그는 보조 서버에서 같은 순서로 실행됩니다.
따라서 세션 2에 삽입된 레코드는 세션 1로 삭제됩니다.
이 문제를 피할 수 있는 두 가지 방법이 있다
1. 바이너리 로그의 형식을 ROW 또는 MIXED로 설정합니다.SQL 문장 대신 데이터 변경을 사용하여 복제하면 위의 데이터 불일치 문제가 사라집니다.
2. 트랜잭션 격리 수준을 반복 읽기 가능하도록 설정합니다.
반복 읽기 가능 기능(GAP 잠금)에서 세션 2의 삽입을 막고 세션 1 → 세션 2에서 제출 순서를 지정합니다.GAP 록에 관해서는 잠시 후에 전개될 것이기 때문에 이번에 통과되었다.
역사적으로 MySQL(5.0 이전)의 바이너리 로그 형식은 STATEMENT만 있었기 때문에 두 번째 방법으로 문제를 피했습니다.
총결산
이번에는 거래와 분리 수준을 소개했다.
격리 수준은 RU, Read Committed, RR 및 SI 네 가지 수준입니다.ySQL의 기본 격리 수준은 반복 읽기입니다.
이유는 Read Committed 및 binlog_format=STATEMENT 조합, 종속 복제를 통해 데이터가 일치하지 않는 문제가 발생합니다.해결 방법은 반복 읽기(GAP 잠금) 또는 바이너리 로그 형식을 ROW 또는 MIXED(MySQL5.1 이상)로 설정하는 것입니다.
Reference
이 문제에 관하여(초콜릿 MySQL 학습'3차'거래 소개 & 왜 MySQL의 기본 분리 단계가 Repeatable Read), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/philipsli/items/b7d66a46b9bd1f114408
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
mysql> select * from t;
+---+---+
| c1 |c2
+---+---+
| 2 | 2
+---+---+
1 row in set
Empty set
이번에는 거래와 분리 수준을 소개했다.
격리 수준은 RU, Read Committed, RR 및 SI 네 가지 수준입니다.ySQL의 기본 격리 수준은 반복 읽기입니다.
이유는 Read Committed 및 binlog_format=STATEMENT 조합, 종속 복제를 통해 데이터가 일치하지 않는 문제가 발생합니다.해결 방법은 반복 읽기(GAP 잠금) 또는 바이너리 로그 형식을 ROW 또는 MIXED(MySQL5.1 이상)로 설정하는 것입니다.
Reference
이 문제에 관하여(초콜릿 MySQL 학습'3차'거래 소개 & 왜 MySQL의 기본 분리 단계가 Repeatable Read), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/philipsli/items/b7d66a46b9bd1f114408텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)