MySQL5.6 MySQL Cluster에서의 트랜잭션 처리에 관한 제한

18.1.6.3 MySQL Cluster에서의 트랜잭션 처리에 관한 제한

MySQL Cluster는 트랜잭션 처리에 관해서 몇 가지 제한이 있습니다. 여기에는 다음이 포함됩니다.

트랜잭션 격리 수준 NDBCLUSTER 스토리지 엔진은 READ COMMITTED 트랜잭션 격리 수준만을 지원합니다. (예를 들어, InnoDB 는 READ COMMITTED , READ UNCOMMITTED , REPEATABLE READ 및 SERIALIZABLE 을 지원합니다.) 이것이 클러스터 데이터베이스 백업 및 복원에 미치는 영향에 대해서는 섹션 18.5.3.4 "MySQL Cluster 백업 문제 해결" 을 참조 하십시오. )
트랜잭션 및 BLOB 또는 TEXT 컬럼 NDBCLUSTER 는 MySQL에서 인식 할 수있는 테이블에 MySQL의 BLOB 또는 TEXT 데이터 형식 중 하나를 사용하여 열 값의 일부만을 저장합니다. BLOB 또는 TEXT 의 나머지 부분은 MySQL에서 액세스 할 수없는 다른 내부 테이블에 저장됩니다. 이와 관련하여 이러한 유형의 컬럼을 포함하는 테이블에 대해 SELECT 문을 실행할 때 항상주의해야 할 두 가지 문제가 발생합니다.
1. MySQL Cluster 테이블에서 SELECT 의 경우 : SELECT 에 BLOB 또는 TEXT 컬럼이 포함되는 경우, READ COMMITTED 트랜잭션 격리 수준이 읽기 잠금 기능 읽기로 변환됩니다. 이것은 일관성을 보장하기 위해 이루어집니다.
2. 고유 키 조회를 사용하여 BLOB 또는 TEXT 데이터 형식 중 하나를 사용하는 열을 취득하고 하나의 트랜잭션 내에서 실행되는 SELECT 의 경우는 공유 읽기 잠금이 트랜잭션 기간 동안 (즉, 트랜잭션 이 커밋되거나 중단 될 때까지) 그 테이블에 유지됩니다.
  
  인덱스 또는 테이블 스캔을 사용하는 쿼리는 BLOB 또는 TEXT 컬럼을 포함 NDB 테이블이 대상에도이 문제가 발생하지 않습니다.
  
  예를 들어, 다음의 CREATE TABLE 문에 의해 정의 된 테이블 t 에 대해 생각합니다.
```
CREATE TABLE t (
    a INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    b INT NOT NULL,
    c INT NOT NULL,
    d TEXT,
    INDEX i(b),
    UNIQUE KEY u(c)
) ENGINE = NDB,
```
  t 에 대한 다음의 쿼리는 첫 번째 쿼리가 기본 키 조회를 사용하여 두 번째 고유 키 조회를 사용하고 있기 때문에, 모두 공유 읽기 잠금이 발생합니다.
```
SELECT * FROM t WHERE a = 1;

SELECT * FROM t WHERE c = 1;
```
  그러나 여기에 네 가지 쿼리는 모두 공유 읽기 잠금은 발생하지 않습니다.
```
SELECT * FROM t WHERE b = 1;

SELECT * FROM t WHERE d = '1';

SELECT * FROM t;

SELECT b,c WHERE a = 1;
```
  그 이유는이 4 개의 쿼리 중 1 번째 인덱스 스캔을 사용하여 두 번째와 세 번째는 테이블 스캔을 사용하고 4 번째는 (기본 키 조회를 사용하고 있습니다 만 ) BLOB 또는 TEXT 컬럼의 값을 취득하고 있지 않기 때문입니다.
  
  BLOB 또는 TEXT 컬럼을 얻을 고유 키 조회를 사용하는 쿼리를 회피하거나 이러한 쿼리를 피할 수없는 경우 트랜잭션의 커밋을 최대한 후에 실시하도록하면 공유 읽기 잠금으로 인한 문제를 최소화 억제 할 수 있습니다.
롤백 부분 트랜잭션 및 트랜잭션의 부분적인 롤백은 없습니다. 중복 키 또는 유사한 오류가 발생하면 전체 트랜잭션이 롤백됩니다.

이 동작은 개별 문을 롤백 할 수 InnoDB 등의 다른 트랜잭션이 지원하는 스토리지 엔진과 다릅니다.
트랜잭션 및 메모리 사용량 이 장의 다른 곳에서 설명했듯이, MySQL Cluster는 대규모 트랜잭션이 제대로 처리되지 않습니다. 다수의 작업을 포함하는 하나의 대규모 트랜잭션을 실행하는 것보다 약간 조작을 포함한 여러 개의 작은 트랜잭션을 실행하는 것이 좋습니다. 특히 고려해야 할 점은 대규모 트랜잭션이 매우 많은 양의 메모리를 필요로하는 것입니다. 이 때문에 일부 MySQL 문 트랜잭션 동작에 대해 다음 목록과 같이 영향이 있습니다.
- TRUNCATE TABLE 은 NDB 테이블에서 사용하면 트랜잭션 수 없습니다. TRUNCATE TABLE 로 테이블을 비울 수없는 경우, 성공할 때까지이를 다시 실행해야합니다.
- DELETE FROM ( WHERE 절이 내 경우도 포함)은 트랜잭션입니다. 테이블에 많은 행이 포함 된 경우 여러 DELETE FROM ... LIMIT ... 명령문을 사용하여 삭제 작업을 "한꺼번에"하면 성능을 향상시킬 수 있습니다. 테이블을 비울 수 목적인 경우는 대신 TRUNCATE TABLE 을 사용하는 것이 좋습니다.
- LOAD DATA 문 LOAD DATA INFILE 은 NDB 테이블에 사용하면 트랜잭션 수 없습니다.
  중요
  LOAD DATA INFILE 명령문을 실행하면 NDB 엔진은 통신 네트워크 활용도가 높도록 불규칙한 간격으로 커밋을 수행합니다. 이러한 위탁이 발생하는시기를 미리 알 수 없습니다.
- ALTER TABLE과 트랜잭션 ALTER TABLE 의 일부로 NDB 테이블을 복사하려면 복사 생성 트랜잭션 수 없습니다. (어쨌든도 복사본이 삭제 된 경우이 작업은 롤백됩니다.)
트랜잭션 및 COUNT () 함수 MySQL Cluster 복제를 사용하는 경우, 슬레이브에서 COUNT() 함수의 트랜잭션 일관성이 보장되지 않습니다. 즉, 하나의 트랜잭션에서 테이블의 행 수를 변경하는 일련의 문 ( INSERT , DELETE 또는 둘 다)를 마스터에서 실행하는 경우, 슬레이브로 SELECT COUNT(*) FROM table 쿼리를 실행하면 중간 결과가 반환 될 수 있습니다. 이것은 SELECT COUNT(...) 가 더티 읽기를 위해 발생하고 NDB 스토리지 엔진의 버그가 아닙니다. (자세한 내용은 Bug # 31321를 참조하십시오.)