15.1.1 Atomic Data Definition Statement Support

15.1.1 Atomic Data Definition Statement Support

MySQL 9.5는 atomic Data Definition Language (DDL) statement를 지원합니다. 이 기능은 atomic _DDL_이라고 합니다. Atomic DDL statement는 DDL operation과 관련된 data dictionary update, 스토리지 엔진 operation, binary log 쓰기 작업을 하나의 atomic operation으로 결합합니다. 이 operation은 적용 가능한 변경 사항이 data dictionary, 스토리지 엔진, binary log에 영구 반영되어 commit되거나, 서버가 operation 도중 중단되더라도 rollback됩니다.

참고

_Atomic DDL_은 transactional _DDL_이 아닙니다. DDL statement는 atomic이든 아니든 관계없이, 현재 session에서 활성 상태인 모든 트랜잭션을 암묵적으로 종료합니다. 이는 statement를 실행하기 전에 COMMIT을 수행한 것과 같습니다. 이는 DDL statement가 다른 트랜잭션 안에서, 즉 START TRANSACTION ... COMMIT과 같은 트랜잭션 제어 statement 안에서 수행되거나 같은 트랜잭션 내에서 다른 statement와 결합될 수 없음을 의미합니다.

Atomic DDL은 중앙집중식 트랜잭션 메타데이터 저장소를 제공하는 MySQL data dictionary에 의해 가능해집니다.

Atomic DDL 기능은 이 절에서 다음 주제들로 설명됩니다:

• Supported DDL Statements

• Atomic DDL Characteristics

• DDL Statement Behavior

• Storage Engine Support

• Viewing DDL Logs

Supported DDL Statements

Atomic DDL 기능은 table 및 non-table DDL statement를 모두 지원합니다. Table 관련 DDL operation에는 스토리지 엔진 지원이 필요하지만, non-table DDL operation에는 필요하지 않습니다. 현재로서는 InnoDB 스토리지 엔진만 atomic DDL을 지원합니다.

• 지원되는 table DDL statement에는 database, tablespace, table, index에 대한 CREATE, ALTER, DROP statement와 TRUNCATE TABLE statement가 포함됩니다.

• 지원되는 non-table DDL statement에는 다음이 포함됩니다:

  • Stored program, trigger, view, loadable function에 대한 CREATE 및 DROP statement와, 필요한 경우 ALTER statement.

  • Account management statement: 사용자와 role에 대한 CREATE, ALTER, DROP 및 필요한 경우 RENAME statement, 그리고 GRANT 및 REVOKE statement.

다음 statement는 atomic DDL 기능에서 지원되지 않습니다:

• InnoDB 이외의 스토리지 엔진이 관련된 table 관련 DDL statement.

• INSTALL PLUGIN 및 UNINSTALL PLUGIN statement.

• INSTALL COMPONENT 및 UNINSTALL COMPONENT statement.

• CREATE SERVER, ALTER SERVER, DROP SERVER statement.

Atomic DDL Characteristics

Atomic DDL statement의 특성은 다음과 같습니다:

• Metadata update, binary log 쓰기, 그리고 필요한 경우 스토리지 엔진 operation이 단일 atomic operation으로 결합됩니다.

• DDL operation 동안 SQL 레이어에서 중간 commit이 발생하지 않습니다.

• 적용 가능한 경우:

  • Data dictionary, routine, event, loadable function cache의 상태는 DDL operation의 상태와 일치합니다. 즉, cache는 DDL operation이 성공적으로 완료되었는지 또는 rollback되었는지를 반영하도록 갱신됩니다.

  • DDL operation에 관련된 스토리지 엔진 메서드는 중간 commit을 수행하지 않으며, 스토리지 엔진은 DDL operation의 일부로 자신을 등록합니다.

  • 스토리지 엔진은 DDL operation의 redo 및 rollback을 지원하며, 이는 DDL operation의 Post-DDL 단계에서 수행됩니다.

• DDL operation의 외형적인 동작은 atomic합니다.

DDL Statement Behavior

이 절에서는 InnoDB와 같이 atomic DDL을 지원하는 스토리지 엔진을 사용할 때 DDL statement 동작의 중요한 측면을 설명합니다.

• 모든 지정된 table이 atomic DDL을 지원하는 스토리지 엔진을 사용할 경우 DROP TABLE operation은 완전히 atomic합니다. 이 statement는 모든 table을 성공적으로 drop하거나 rollback됩니다.

DROP TABLE은 지정된 table이 존재하지 않으면 error와 함께 실패하며, 스토리지 엔진에 관계없이 어떤 변경도 이루어지지 않습니다.

• CREATE DATABASE 및 DROP DATABASE는, 지정된 database의 모든 table이 atomic DDL을 지원하는 스토리지 엔진을 사용하는 경우, 완전한 atomic성과 crash-safe 특성을 가집니다. 이때 statement는 모든 object를 성공적으로 추가 또는 제거하거나 rollback됩니다.

• Atomic DDL을 지원하지 않는 스토리지 엔진을 사용하는 table의 경우, table 삭제는 atomic DROP TABLE 또는 DROP DATABASE 트랜잭션 밖에서 발생합니다. 이러한 table 삭제는 binary log에 개별적으로 기록되므로, operation이 중단된 DROP TABLE 또는 DROP DATABASE의 경우 스토리지 엔진, data dictionary, binary log 간의 불일치는 최대 한 개의 table로 제한됩니다. 여러 table을 drop하는 operation의 경우, atomic DDL을 지원하지 않는 스토리지 엔진을 사용하는 table이 이를 지원하는 table보다 먼저 drop됩니다.

• Atomic DDL을 지원하는 스토리지 엔진을 사용하는 table에 대한 CREATE TABLE, ALTER TABLE, RENAME TABLE, TRUNCATE TABLE, CREATE TABLESPACE, DROP TABLESPACE operation은 서버가 operation 도중 중단되더라도 완전히 commit되거나 rollback됩니다. RENAME TABLE operation은 모든 지정된 table이 atomic DDL을 지원하는 스토리지 엔진을 사용할 때만 atomic합니다.

• Atomic DDL과 row-based replication을 모두 지원하는 스토리지 엔진의 경우, CREATE TABLE ... SELECT statement는 binary log에 하나의 트랜잭션으로 기록됩니다.

Atomic DDL과 foreign key 제약조건을 모두 지원하는 스토리지 엔진에서는, row-based replication이 사용되는 경우 CREATE TABLE ... SELECT statement에서 foreign key 생성이 허용되지 않습니다. Foreign key 제약조건은 이후 ALTER TABLE을 사용하여 추가할 수 있습니다.

CREATE TABLE ... SELECT이 atomic operation으로 적용될 때, 데이터를 insert하는 동안 table에 metadata lock이 유지되어, operation이 수행되는 동안 table에 대한 동시 접근이 방지됩니다.

• DROP VIEW는 지정된 view가 존재하지 않으면 실패하며, 어떠한 변경도 발생하지 않습니다.

• Account management statement는 모든 지정된 user에 대해 성공하거나, error가 발생하면 rollback되어 아무런 영향을 미치지 않습니다.

Storage Engine Support

현재 InnoDB 스토리지 엔진만 atomic DDL을 지원합니다. Atomic DDL을 지원하지 않는 스토리지 엔진은 DDL atomicity에서 제외됩니다. 제외된 스토리지 엔진이 포함된 DDL operation은 여전히 operation이 중단되거나 부분적으로만 완료될 때 발생할 수 있는 불일치를 초래할 수 있습니다.

DDL operation의 redo 및 rollback을 지원하기 위해, InnoDB는 mysql.innodb_ddl_log table에 DDL log를 기록합니다. 이 table은 mysql.ibd data dictionary tablespace에 존재하는 숨겨진 data dictionary table입니다.

DDL operation 동안 mysql.innodb_ddl_log table에 기록되는 DDL log를 확인하려면, innodb_print_ddl_logs configuration option을 활성화하십시오. 자세한 내용은 Viewing DDL Logs를 참조하십시오.

참고

mysql.innodb_ddl_log table 변경에 대한 redo log는 innodb_flush_log_at_trx_commit 설정과 관계없이 즉시 디스크로 flush됩니다. Redo log를 즉시 flush하는 것은 DDL operation에 의해 data file이 수정되었지만, 그 operation으로 인해 발생한 mysql.innodb_ddl_log table 변경에 대한 redo log가 디스크에 영구 저장되지 않는 상황을 방지합니다. 이러한 상황은 rollback 또는 recovery 중 error를 유발할 수 있습니다.

InnoDB 스토리지 엔진은 DDL operation을 여러 단계로 수행합니다. ALTER TABLE과 같은 DDL operation은 Commit 단계 전에 Prepare 및 Perform 단계를 여러 번 수행할 수 있습니다.

1. Prepare: 필요한 object를 생성하고 mysql.innodb_ddl_log table에 DDL log를 기록합니다. DDL log는 DDL operation을 roll forward 및 rollback하는 방법을 정의합니다.

2. Perform: DDL operation을 수행합니다. 예를 들어, CREATE TABLE operation에 대한 create routine을 수행합니다.

3. Commit: Data dictionary를 업데이트하고 data dictionary 트랜잭션을 commit합니다.

4. Post-DDL: mysql.innodb_ddl_log table에서 DDL log를 재생(replay)하고 제거합니다. Rollback이 불일치를 초래하지 않고 안전하게 수행될 수 있도록, data file의 rename이나 제거와 같은 file operation은 이 마지막 단계에서 수행됩니다. 이 단계는 또한 DROP TABLE, TRUNCATE TABLE 및 table을 재구성(rebuild)하는 기타 DDL operation에 대해 mysql.innodb_dynamic_metadata data dictionary table에서 dynamic metadata를 제거합니다.

DDL log는 DDL operation이 commit되었는지 rollback되었는지에 관계없이 Post-DDL 단계 동안 mysql.innodb_ddl_log table에서 재생되고 제거됩니다. DDL operation 도중 서버가 중단된 경우에만 mysql.innodb_ddl_log table에 DDL log가 남아 있어야 합니다. 이 경우, recovery 이후에 DDL log가 재생되고 제거됩니다.

Recovery 상황에서는, 서버가 재시작될 때 DDL operation이 commit되거나 rollback될 수 있습니다. DDL operation의 Commit 단계 동안 수행된 data dictionary 트랜잭션이 redo log와 binary log에 존재하면, 그 operation은 성공한 것으로 간주되어 roll forward됩니다. 그렇지 않으면, InnoDB가 data dictionary redo log를 재생할 때 해당 미완료 data dictionary 트랜잭션이 rollback되며, DDL operation도 rollback됩니다.

Viewing DDL Logs

Atomic DDL operation 중 InnoDB 스토리지 엔진이 관련될 때 mysql.innodb_ddl_log data dictionary table에 기록되는 DDL log를 보려면, innodb_print_ddl_logs를 활성화하여 MySQL이 DDL log를 stderr에 기록하도록 합니다. Host 운영 체제 및 MySQL configuration에 따라 stderr는 error log, 터미널 또는 콘솔 윈도우가 될 수 있습니다. Section 7.4.2.2, “Default Error Log Destination Configuration”을 참조하십시오.

InnoDB는 DDL operation의 redo 및 rollback을 지원하기 위해 mysql.innodb_ddl_log table에 DDL log를 기록합니다. mysql.innodb_ddl_log table은 mysql.ibd data dictionary tablespace에 존재하는 숨겨진 data dictionary table입니다. 다른 숨겨진 data dictionary table과 마찬가지로, mysql.innodb_ddl_log table은 non-debug 버전의 MySQL에서는 직접 접근할 수 없습니다. (Section 16.1, “Data Dictionary Schema” 참조.) mysql.innodb_ddl_log table의 구조는 다음 정의에 해당합니다:

1CREATE TABLE mysql.innodb_ddl_log (
2  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
3  thread_id BIGINT UNSIGNED NOT NULL,
4  type INT UNSIGNED NOT NULL,
5  space_id INT UNSIGNED,
6  page_no INT UNSIGNED,
7  index_id BIGINT UNSIGNED,
8  table_id BIGINT UNSIGNED,
9  old_file_path VARCHAR(512) COLLATE utf8mb4_bin,
10  new_file_path VARCHAR(512) COLLATE utf8mb4_bin,
11  KEY(thread_id)
12);

• id: DDL log record에 대한 고유 식별자입니다.

• thread_id: 각 DDL log record에는 thread_id가 할당되며, 이는 특정 DDL operation에 속하는 DDL log를 재생하고 제거하는 데 사용됩니다. 여러 data file operation이 포함된 DDL operation은 여러 개의 DDL log record를 생성합니다.

• type: DDL operation의 type입니다. Type에는 FREE(index tree 삭제), DELETE(file 삭제), RENAME(file 이름 변경), DROP( mysql.innodb_dynamic_metadata data dictionary table에서 metadata 삭제)이 포함됩니다.

• space_id: Tablespace ID입니다.

• page_no: Allocation 정보를 포함하는 page입니다. 예를 들어 index tree root page입니다.

• index_id: Index ID입니다.

• table_id: Table ID입니다.

• old_file_path: 이전 tablespace file path입니다. Tablespace file을 생성 또는 삭제하는 DDL operation과, tablespace의 이름을 변경하는 DDL operation에서 사용됩니다.

• new_file_path: 새로운 tablespace file path입니다. Tablespace file의 이름을 변경하는 DDL operation에서 사용됩니다.

다음 예제는 innodb_print_ddl_logs를 활성화하여 CREATE TABLE operation에 대해 strderr에 기록된 DDL log를 확인하는 방법을 보여줍니다.

1mysql> SET GLOBAL innodb_print_ddl_logs=1;
2mysql> CREATE TABLE t1 (c1 INT) ENGINE = InnoDB;

1[Note] [000000] InnoDB: DDL log insert : [DDL record: DELETE SPACE, id=18, thread_id=7,\
2space_id=5, old_file_path=./test/t1.ibd]
3[Note] [000000] InnoDB: DDL log delete : by id 18
4[Note] [000000] InnoDB: DDL log insert : [DDL record: REMOVE CACHE, id=19, thread_id=7,\
5table_id=1058, new_file_path=test/t1]
6[Note] [000000] InnoDB: DDL log delete : by id 19
7[Note] [000000] InnoDB: DDL log insert : [DDL record: FREE, id=20, thread_id=7,\
8space_id=5, index_id=132, page_no=4]
9[Note] [000000] InnoDB: DDL log delete : by id 20
10[Note] [000000] InnoDB: DDL log post ddl : begin for thread id : 7
11[Note] [000000] InnoDB: DDL log post ddl : end for thread id : 7