1. 트랜잭션 시작 (처음으로 트랜잭션 시작)

- 이 트랜잭션에 트랜잭션 ID(TRX_ID)를 할당한다. 트랜잭션 ID는 시스템 테이블 스페이스의 TRX_SYS 페이지에서 가장 큰 트랜잭션 ID필드에 기록될 수 있다. 

  - 시스템 테이블 스페이스의 TRX_SYS 페이지에서 가장 큰 트랜잭션 ID 필드가 업데이트되면 업데이트가 Redo Log에 기록된다. 

- 할당된 TRX_ID를 기반으로 read view를 만든다. 

 

2. 레코드 수정 (한번에 하나의 레코드 행만 수정됨)

2-1. Undo Log 로그 공간 할당 

2-2. 수정전 값을 Undo Log 로그에 복사 (실제 변경되는 컬럼의 이전 값과 PK 값만 저장)

2-3. 버퍼풀 데이터 페이지의 변경 대상 레코드의 메타 정보중에서 Roll-Point 값을 2-2에서 생성된 Undo Log의 주소 값으로 저장

2-4. 버퍼풀 데이터 페이지의 변경 대상 레코드의 컬럼 값을 새로운 값으로 변경하고, 변경되는 컬럼의 이후 값과 데이터 페이지 주소 및 Offset을 Redo 로그에 저장. 롤백 세그먼트 포인터는 Undo Log에 있는 레코드의 이전 버전을 가리킨다. 

2-5. 변경되는 컬럼을 이용한 인덱스가 있을 경우 인덱스의 값 변경 

      해당 인덱스 페이지가 버퍼풀에 없으면 Insert Buffer에 임시 저장한다. 

      - 인덱스 페이지는 단순히 기존 인덱스 키를 덮어쓰기 하는 것이 아니라, 기존 인덱스 키는 그대로 보존하고 새로운 키 값을 추가한다. 

      - 인덱스 키 하나는 트랜잭션 가시성에 관계없이 모든 값들을 다 가지고 있게된다. 

         (변경 전/후의 레코드 포인터 모두 가지고 있다.)

 

3. 다른 트랜잭션은 어떻게 되나요?

- 레코드가 수정되면 커밋되지 않더라도 다른 트랜잭션도 해당 트랜잭션 격리 수준에 따라 수정된 레코드를 볼 수 있다. 

  - RU 격리 수준인 경우 색인 페이지를 사용하여 최신 버전 기록을 읽는다.

  - RC 격리 수준인 경우 가정 최근에 제출된 레코드 버전 검색

  - RR 격리 수준인 경우 read view에 해당하는 레코드 버전을 찾는다. 

- 최신 버전 레코드보다 오래된 버전 레코드를 읽기 위해 인덱스 페이지를 사용해야하는 경우, 이전 버전 레코드를 다시 빌드하려면 Undo Log 를 사용해야한다. 

 

4. 트랜잭션 커밋

- 트랜잭션에 해당하는 Undo Log 페이지는 "purge"로 설정된다. 

  - Undo Log 페이지는 다른 트랜잭션에서 더이상 참조되지 않을때 지을 수 있다.

- Redo Log 버퍼가 디스크의 로그 파일로 기록된다. 

  - 디스크 플러시 여부는 innodb_flush_log_at_trx_commit 시스템 변수 값에 따라 다르다. 

- Redo Log의 더티페이지가 로그 파일에 기록되기 전에 이 더티 페이지를 만든 LSN 이전의 LSN의 Read Log는 반드시 먼저 디스크에 기록되어야 한다. 

 

5. 백그라운드 스레드가 다른 트리거 매카니즘에 따라 지속적으로 새로고침을 트리거함 

- 가장 오래된 더티 페이지를 찾아서 플러시 배치에 추가한다.

- 플러시 배치는 최신 LSN 번호가 리두 로그에 기록되고 배치되었는지 확인한다.

- duble write가 활성화 된 경우 더티 페이지는 먼저 duble write 버퍼로 플러시 되고 동기화를 기다린다. 

- 버퍼풀의 각 더티 페이지를 최종 목적지 (테이블 스페이스 파일)에 쓴다. 

 

6. 정기적으로 체크 포인트 수행

- 체크 포인트보다 오래된 더티 페이지(체크 포인트 LSN보다 작은)가 테이블 스페이스 파일로 기록됐는지 확인한다.  체크 포인트 LSN보다 큰 더티 페이지가 있는 경우 더티 페이지가 즉시 데이터 파일로 기록된다. 

  - 체크 포인터로 인해 디스크에 기록되는 데이터가 모두 Commit된 데이터가 아닐 수 있다.

 

7. 백그라운드 스레드 제거 

- 백그라운드 스레드는 Undo Log 및 히스토리 연결 목록을 포함하여 필요에 따라 주기적으로 지속적으로 제거를 실행함 

- 각 롤백 세그먼트에서 더이상 필요하지 않은 가장 오래된 Undo Log를 찾는다. 

- 실제로 인덱스에서 삭제 표시가 있는 레코드를 삭제한다. 

- Undo Log 페이지 해제 

 

참고

https://www.programmersought.com/article/49353530904/

http://intomysql.blogspot.com/2010/12/innodb-redoundo.html

https://m.blog.naver.com/PostView.nhn?isHttpsRedirect=true&blogId=lyh1620&logNo=220794460510&categoryNo=46 

 

'MySQL' 카테고리의 다른 글

Hash join in MySQL 8  (0) 2021.06.25
Redo Log  (0) 2021.06.25
OPTIMIZE TABLE Statement  (0) 2021.06.18
ANALYZE TABLE Statement  (0) 2021.06.17
GTID - 트랜잭션 건너뛰기  (0) 2021.06.13
OPTIMIZE [NO_WRITE_TO_BINLOG | LOCAL]
    TABLE tbl_name [, tbl_name] ...

- OPTIMIZE TABLE은 테이블 데이터 및 관련 인덱스 데이터의 물리적 저장소를 재구성하여 저장 공간을 줄이고 테이블에 액세스할때 I/O 효율성이 향상된다. 테이블의 스토리지 엔진에 따라 테이블의 변경사항이 달라진다. 

- OPTIMIZE TABLE은 테이블 유형에 따라 다음과 같은 경우에 사용한다. 

  - innodb_file_per_table 옵션이 활성화된 상태에서 자체 .ibd 파일이 있는 InnoDB 테이블에서

    대량 삽입, 업데이트 또는 삭제작업을 수행한 후 테이블과 인덱스가 재구성되고 운영 체제에서 사용하기 위해

    디스크 공간을 재확보 할 수 있다.

  - InnoDB 테이블의 Fulltext 인덱스의 일부인 컬럼에 대량의 삽입, 업데이트 또는 삭제 작업을 수행한 후

    innodb_optimize_fulltext_only=1 옵션을 설정한다. 색인 유지 보수 기간을 적절한 시간으로 유지하기 위해

    검색 인덱스에서 업데이트하는 단어 개수를 지정하는 innodb_ft_num_word_optimize 옵션을 설정하고

    검색 인덱스가 완전히 업데이트 될때까지 OPTIMIZE TABLE문을 순차적으로 실행한다.

  - MyISAM 또는 ARCHIVE 테이블의 큰 부분을 삭제하거나 가변 길이 행

    (VARCHAR, VARBINARY, BLOB 또는 TEXT 컬럼이 있는 테이블)이 있는 MyISAM 또는 ARCHIVE 테이블을

    많이 변경한후 삭제된 행은 연결된 목록에서 유지 관리되고 후속 INSERT 작업은 이전 행 위치를 재사용한다. 

    OPTIMIZE TABLE 을 사용하여 사용되지 않는 공간을 회수하고 데이터 파일의 조각 모음을 만들수 있다.

    테이블에 대한 광범위한 변경이 있을 경우 OPTIMIZE TABLE 문을 실행하여 성능을 향상시킬수 도 있다. 

- OPTIMIZE TABLE 은 테이블에 대한 SELECT, INSERT 권한이 필요하다.

- OPTIMIZE TABLE 은 InnoDB, MyISAM 및 ARCHIVE 테이블에서 동작한다. 

  OPTIMIZE TABLE 은 in-memory NDB 테이블의 동적 컬럼도 지원한다. in-memory 테이블의 고정 너비 컬럼에는

  작동하지 않으며 디스크 데이터 테이블에서도 작동하지 않는다. NDB 클러스터 테이블의 최적화 성능은

  최적화 테이블을 통해 행 처리 배치 간에 대기하는 시간을 제어하는  --ndb-optimization-delay 을 사용하여

  조정할 수 있다. 

- NDB 클러스터 테이블의 경우 OPTIMIZE TABLE은 최적화 작업을 수행하는 SQL Thread 를 Kill 해서 중단할 수 있다.

  기본적으로 OPTIMIZE TABLE은 다른 저장소 엔진을 사용하여 만든 테이블에 대해 작동하지 않으며 이러한 지원이

  부족하다는 결과를 반환한다. -skip-new 옵션으로 mysqld를 시작하여 다른 스토리지 엔진에 OPTIMIZE TABLE 작업을

  수행할 수 있다. 이경우 OPTIMIZE TABLE은 ALTER TABLE에 매핑된다. 

- OPTIMIZE TABLE 은 뷰에서는 작동하지 않는다. 

- OPTIMIZE TABLE 은 파티션 테이블을 지원한다. 

- OPTIMIZE TABLE 은 바이너리 로그에 기록되어 복제본에 반영된다. 

 

OPTIMIZE TABLE Output

- OPTIMIZE TABLE 은 다음표에 표시된 컬럼로 결과 집합을 반환한다. 

Column Value
Table 테이블 이름
Op 항상 최작화
Msg_type 상태, 오류, 정보, 참고 또는 경고
Msg_text 정보 메시지

- OPTIMIZE TABLE은 테이블을 최적화하여 이전 파일에서 새로 생성된 파일에 테이블 통계를 복사하는 동안 발생하는 오류를 예외처리한다. 예를 들어 .MYD 또는 .MYI 파일의 소유자 사용자ID와 mysqld 프로세스의 사용자ID가 다른 경우 OPTIMIZE TABLE은 root 사용자로 mysqld를 실행하지 않는한 "파일 소유권을 변경할 수 없음"오류를 생성한다.

 

InnoDB 세부 정보 

- 테이블의 경우 OPTIMIZE TABLE은 TABLE ALTER ... FORCE 에 매핑된다. 

  인덱스 통계를 업데이트하고 클러스터된 인덱스에서 사용하지 않은 공간을 해제한다. 

- OPTIMIZE TABLE을 테이블에서 실행할때 다음과 같이 출력된다. 

mysql> OPTIMIZE TABLE foo;
+----------+----------+----------+-------------------------------------------------------------------+
| Table    | Op       | Msg_type | Msg_text                                                          |
+----------+----------+----------+-------------------------------------------------------------------+
| test.foo | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.foo | optimize | status   | OK                                                                |
+----------+----------+----------+-------------------------------------------------------------------+

- OPTIMIZE TABLE은 일반, 파티션 테이블을 OLINE DDL을 사용여 동시 DML 작업에 대한 가동 중지시간을 줄인다. 

  OPTIMIZE TABLE로 트리거되는 테이블 재구축이 완료된다. exclusive table lock은 준비 단계와 작업의 commit 단계에서만 간단히 수행된다. 준비 단계에서 마타데이터가 업데이트되고 중간 테이블이 만들어진다. commit 단계에서 테이블 메타데이터 변경이 commit 된다. 

- OPTIMIZE TABLE은 다음 조건에서 테이블을 copy 방식으로 테이블을 다시 빌드한다. 

  - old_alter_table 시스템 변수가 활성화된 경우

  - 서버 시작시 --skip-new 옵션이 적용된경우 

- OPTIMIZE TABLE은 Full Text Index가 포함된 테이블은 Online DDL을 지원하지 않고 테이블 copy 방식이 사용된다. 

- InnoDB는 페이지 할당 방법을 사용하여 데이터를 저장하며 레거시 스토리지 엔진과 동일한 방식으로 조각화가 발생하지 않는다. 

- OPTIMIZE TABLE을 실행할지 여부를 고려할때 서버가 처리할것으로 예상되는 트랜잭션 워크로드를 고려한다. 

  - 일정 수준의 조각화가 예상되어 page 를 93%까지 채워 page 를 분할하지 않고도 update 할수 있는 공간을 남겨둔다.

  - delete 작업은 page를 원하는것보다 덜 채워 간격을 남길수 있으므로 OPTIMIZE TABLE을 수행하는것이 좋다. 

  - 행에 대한 update 는 일반적으로 충분한 공간을 사용할 수 있는 경우 data type, row format에 따라 동일한 page 내에서 데이터를 다시 작성한다. 

   - 동시성 워크로드가 많기 때문에 MVCC 메커니즘을 통해 동일한 데이터의 여러버전을 유지하므로 시간이 지남에 따라 인덱스의 간격 생길수 있다. 

 

MyISAM 세부 정보 

- MyISAM 테이블의 경우 OPTIMIZE TABLE이 다음과 같이 작동한다.

  - 테이블이 삭제되거나 행을 분할할 경우 테이블을 복구한다. 

  - 인덱스 페이지가 정렬되지 않은 경우 정렬한다.

  - 테이블의 통계가 최시 상태이고 인덱스를 정렬하여 복수를 수행할 수 없는 경우 업데이트한다. 

 

 

참고

https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html

 

'MySQL' 카테고리의 다른 글

Redo Log  (0) 2021.06.25
Update process  (0) 2021.06.19
ANALYZE TABLE Statement  (0) 2021.06.17
GTID - 트랜잭션 건너뛰기  (0) 2021.06.13
GTID 복제 상태 확인  (0) 2021.06.12

ANALYZE TABLE

ANALYZE [NO_WRITE_TO_BINLOG | LOCAL]
    TABLE tbl_name [, tbl_name] ...

ANALYZE [NO_WRITE_TO_BINLOG | LOCAL]
    TABLE tbl_name
    UPDATE HISTOGRAM ON col_name [, col_name] ...
        [WITH N BUCKETS]

ANALYZE [NO_WRITE_TO_BINLOG | LOCAL]
    TABLE tbl_name
    DROP HISTOGRAM ON col_name [, col_name] ...

- 테이블 통계 생성

- HISOGRAM 절이 없는 ANALYZE TABLE 은 키 분포 분석을 수행하고 명명된 테이블에 대한 분포를 저장한다. 

- UPDATE HISTOGRAM 절이 있는 ANALYZE TABLE은 명명된 테이블 컬럼에 대한 HISTOGRAM 통계를 생성하고

  이를 Data Dictionary 에 저장한다. 

- DROP HISTOGRAM 절이 있는 ANALYZE TABLE은 Data Dictionary에서 명명된 테이블 컬럼에 대한 HISTOGRAM 통계를 제거한다. 

- ANALYZE TABLE 을 실행하기위해 테이블에 대한 SELECT, INSERT 권한이 필요하다. 

- ANALYZE TABLE 은 InnoDB, NDB, MyISAM 테이블에서 작동함, 뷰에서는 작동안함 

- innodb_read_only 시스템 변수가 설정되어 있는 경우 ANALYZE TABLE 시 Data Dictionary, 사용 통계 테이블을 업데이트 할수 없기 때문에 실패할 수 있다. 

- 업데이트된 분산 통계를 검색 하려면 information_schema_stats_expiry=0 를 설정한다.

- ANALYZE TABLE 은 파티션 테이블을 지원하며 , ALTER TABLE ... ANALYZE PARTITION을 사용하여 하나 이상의 파티션을 분석할 수 있다. 

- 분석중 InnoDB, MySAM 테이블은 읽기 잠금이 발생한다. 

- ANALYZE TABLE 은 플러시 잠금이 필요한 경우 테이블 정의 캐시에서 테이블을 제거한다. 

- 장시간 실행되는 쿼리, 트랜잭션이 아직 테이블을 사용하는 경우 후속 쿼리, 트랜잭션은 플러시 잠금이 해제되기전에 해당 작업이 완료될때까지 기다려야 한다. 

- ANALYZE TABLE 은 일반적으로 빠르게 완료되기 때문에 지연된 트랜잭션이나 동일한 테이블을 포함하는 명령문이 플러시 잠금으로 인한것인지 알 수 없다. 

- ANALYZE TABLE은 복제본에도 복제되게 바이너리 로그에 기록된다. (기본설정)

 

키 분포 분석

- 이전 키 분산 분석 이후 테이블이 변경되지 않은 경우, 테이블은 다시 분석되지 않는다.

- 저장된 키 배포 카디널리티를 확인하면 SWHO INDEX, INFORMATION_SCHEMA_STATISTICS 테이블 확인

- InnoDB 테이블의 경우 ANALYZE TABLE은 각 인덱스 트리에서 랜덤 검색을 수행하고 이에 따라 인덱스 카디널리티 추정치를 업데이트한다. 이는 추정치로 반복적으로 ANALYZE TABLE을 수행하면 다른 수치의 카디널리티가 생성될 수 있다. 이는 InnoDB 테이블에서 ANALYZE TABLE을 빠르게 실행하기 위해서 모든 행을 고려하지 않는것으로 인해 카디널리티가 100% 정확할 수 없다. 

- innodb_stats_persistent 가 활성화된 경우 통계를 주기적으로 수집하지 않기 때문에 서버 재부팅 또는 인덱스 컬럼에 대한 큰 변경후에 ANALYZE TABLE을 수행하는것이 좋다. 

- innodb_stats_persistent이 활성화된 경우 innodb_stats_persistent_sample_pages 시스템 변수를 변경하여 ANALYZE TABLE시 랜덤 검색수를 변경할 수 있다. innodb_stats_persistent가 비활성화된 경우 innodb_stats_transient_sample_pages 시스템 변수를 사용한다. 

 

HISTOGRAM 통계 분석 

- ANALYZE TABLE 문에서 HISTOGRAM 절을 사용하면 테이블 컬럼에 대한 HISTOGRAM 통계를 관리할 수 있다.

- ANALYZE TABLE 문에서 UPDATE HISTOGRAM 절을 사용하면 지정된 테이블 컬럼의 HISTOGRAM 통계가 생성된 Data Dictionary에 저장된다. 

- ANALYZE TABLE 문에서 DROP HISTOGRAM 절을 사용하면 지정된 테이블 컬럼의 HISTOGRAM 통계가 Data Dictionary 에서 삭제된다. 

- 저장된 히스토그램 관리문은 명명된 컬럼에만 영향을 준다. 

ANALYZE TABLE t UPDATE HISTOGRAM ON c1, c2, c3 WITH 10 BUCKETS;
ANALYZE TABLE t UPDATE HISTOGRAM ON c1, c3 WITH 10 BUCKETS;
ANALYZE TABLE t DROP HISTOGRAM ON c2;

- 암호화된 테이블, TEMPORARY 테이블은 HISTOGRAM 생성이 지원되지 않는다. 

- HISTOGRAM 생성은 지오메트리 유형(공간 데이터), JSON을 제외한 모든 데이터 유형의 컬럼에 적용된다. 

- HISTOGRAM은 저장된 컬럼 및 가상 컬럼에 대해 생성할 수 있다.

- 단일 컬럼 유니크 인덱스 컬럼에 대해서는 HISTOGRAM을 생성할 수 없다.

- HISTOGRAM 관리문은 요청된 작업을 가능한 많이 수행하고 나머지에 대한 진단 메시지를 보고한다. 

  예를 들어 UPDATE HISTOGRAM 명령문에 여러 컬럼을 지정했지만 일부 컬럼이 없거나 지원되지 않는 데이터 유형이 

  있는 경우 다른 컬럼에 대해 HISTOGRAM 이 생성되고 유효하지 않은 열에 대해 메시지가 생성된다.

- HISTOGRAM은 다음 DDL문에 영향을 받는다.

  - DROP TABLE 에서 삭제된 테이블 컬럼의 HISTOGRAM을 제거한다.

  - DROP DATABASE 문이 데이터베이스의 모든 테이블을 삭제하기 때문에 삭제된 데이터베이스의 모든 테이블에

    대한 HISTOGRAM을 제거한다. 

  - RENAME TABLE 은 HISTOGRAM을 제거하지 않는다. 

    새 테이블 이름과 연결되도록 이름이 바뀐 테이블의 HISTOGRAM 이름을 바꾼다. 

  - ALTER TABLE 문에서 컬럼을 삭제, 수정할경우 해당 컬럼에 대한 HISTOGRAM을 제거한다. 

  - ALTER TABLE ... CONVERT TO CHARACTER SET 은 문자 집합 변경의 영향을 받기 때문에

    문자열에 대한 HISTOGRAM을 제거한다. 비 문저열에 대한 HISTOGRAM은 영향을 받지 않는다. 

- histogram_generation_max_mem_size 시스템 변수는 HISTOGRAM 생성에 사용할 수 있는 최대 메모리 크기를 제어한다. 

- HISTOGRAM 생성을 위해 메모리로 읽을 예상 데이터량이 histogram_generation_max_mem_size 에서

  정의한 제한을 초과하면 MySQL은 모든 데이터를 메모리로 읽는 대신 샘플링을 사용한다. 

  샘플링은 전체 테이블에 균등하게 분산된다. MySQL은 페이지 수준 샘플링 메서드인 SYSTEM 샘플링을 사용합니다.

- INFORMATION_SCHEMA.COLUMN_STATISTICS 테이블의 sampling-rate 컬럼을 조회하여 HISTOGRAM을 생성하는 샘플링된 데이터의 비율값을 확인할 수 있다.

 

예제) 데이터 량이 histogram_generation_max_mem_size 제한을 초과하도록 하기 위해 employees 테이블의 birth_date컬럼의 히스토그램 통계를 생성하기 전에 제한은 낮은 값 (2000000 바이트)로 설정한다. 

mysql> SET histogram_generation_max_mem_size = 2000000;

mysql> USE employees;

mysql> ANALYZE TABLE employees UPDATE HISTOGRAM ON birth_date WITH 16 BUCKETS\G
*************************** 1. row ***************************
   Table: employees.employees
      Op: histogram
Msg_type: status
Msg_text: Histogram statistics created for column 'birth_date'.

mysql> SELECT HISTOGRAM->>'$."sampling-rate"'
       FROM INFORMATION_SCHEMA.COLUMN_STATISTICS
       WHERE TABLE_NAME = "employees"
       AND COLUMN_NAME = "birth_date";
+---------------------------------+
| HISTOGRAM->>'$."sampling-rate"' |
+---------------------------------+
| 0.0491431208869665              |
+---------------------------------+

sampling-rate 값이 0.0491431208869665의 경우 birth_date 컬럼에 있는 데이터의 약 4.9 %가 HISTOGRAM 통계를 생성하기 위해 메모리에 읽혀 졌음을 의미한다. 

 

- MySQL 8.0.19 부터 InnoDB스토리지 엔진은 InnoDB 테이블에 저장되어 있는 데이터에 대한 자체 샘플링 구현을 제공한다. 스토리지 엔진이 자체 샘플링을 제공하지 않는 경우 MySQL에서 사용되는 기본 샘플링 구현에서는 Full Table Scan 이 필요하며 큰 테이블의 경우 비용이 많이 발생한다. InnoDB 샘플링의 구현은 Full Table Sacn 을 방지하여 샘플링 성능이 향상된다. 

- sampled_pages_read, sampled_pages_skipped INNODB_METRICS 카운터를 사용하여 InnoDB 데이터 페이지의 샘플링을 모니터링 할 수 있다. 

 

예제) HISTOGRAM 통계를 생성하기 전에 카운터를 활성화해야하는 샘플링 카운터 사용을 보여준다. 

mysql> SET GLOBAL innodb_monitor_enable = 'sampled%';

mysql> USE employees;

mysql> ANALYZE TABLE employees UPDATE HISTOGRAM ON birth_date WITH 16 BUCKETS\G
*************************** 1. row ***************************
   Table: employees.employees
      Op: histogram
Msg_type: status
Msg_text: Histogram statistics created for column 'birth_date'.

mysql> USE INFORMATION_SCHEMA;

mysql> SELECT NAME, COUNT FROM INNODB_METRICS WHERE NAME LIKE 'sampled%'\G
*************************** 1. row ***************************
 NAME: sampled_pages_read
COUNT: 43
*************************** 2. row ***************************
 NAME: sampled_pages_skipped
COUNT: 843

 

이 공식은 샘플링 카운터 데이터 기반으로 샘플링 속도를 추정한다.

sampling rate = sampled_page_read/(sampled_pages_read + sampled_pages_skipped)

- 샘플링 카운터 데이터를 기반으로 샘플링 속도는 INFORMATION_SCHEMA.COLUMN_STATISTICS 테이블의 sampling-rate값과 거의 동일하다.

 

- HISTOGRAM 생성을 위해 수행된 메모리 할당에 대한 정보는 성능 스키마  memory/sql/histograms 계측기를 모니터링 한다.

 

기타 고려 사항

- ANALYZE TABLE은 INFORMATION_SCHEMA.INNODB_TABLESTATS 테이블에서 테이블 통계를 지우고

  STATS_INITIALIZED 컬럼을 초기화되지 않은 상태로 만든다. 통계는 다음 테이블에 액세스 할 때 다시 수집된다. 

 

참고 

https://dev.mysql.com/doc/refman/8.0/en/analyze-table.html

'MySQL' 카테고리의 다른 글

Update process  (0) 2021.06.19
OPTIMIZE TABLE Statement  (0) 2021.06.18
GTID - 트랜잭션 건너뛰기  (0) 2021.06.13
GTID 복제 상태 확인  (0) 2021.06.12
GTID 사용시 복제본 복구  (0) 2021.06.10

- 복제된 트랜잭션의 이벤트 문제로 인해 복제가 중단된 경우 북제에 실패한 트랜잭션을 생략하고 복제를 시작할 수 있다. 

- 트랜잭션을 생략하기 전에 복제서버의 I/O 쓰레드와 SQL 쓰레드가 정지하고 있는지 확인한다.

- 오류의 원인이 된 복제 이벤트 확인 

  - 오류정보와 최근에 성공적으로 적용된 트랜잭션은 performance_schema 의 replication_applier_status_by_worker 테이블에 기록된다. 

  - mysqlbinlog 를 사용하여 오류 발생시 기록된 이벤트를 검색하고 확인할 수 있다. 

Relay_Master_Log_File: binlog.000010
...
Exec_Master_Log_Pos: 194
          
mysqlbinlog --start-position=194 binlog.000010

# at 194
#180710  9:47:54 server id 572238408  end_log_pos 259 CRC32 0x83a04322  GTID    last_committed=0        sequence_number=1       rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= '4ab8feff-5272-11e8-9320-08002715584a:201840'/*!*/;

  - 복제서버 또는 원본서버에서 SHOW BINLOG EVENTS, SHOW RELAYLOG EVENTS 로 확인할 수 있다.

GTID 사용시 트랜잭션 건너뛰기 

- GTID 사용시 sql_slave_skip_counter  를 사용할 수 없다. 

- 에러가 발생한 트랜잭션을 빈 트랜잭션으로 만들어서 커밋한다.

SET GTID_NEXT='4ab8feff-5272-11e8-9320-08002715584a:201840';
BEGIN;
COMMIT;
SET GTID_NEXT='AUTOMATIC';

 

GITD 사용안할때 트랜잭션 건너뛰기 

- SET GLOBAL sql_slave_skip_counter 를 사용

   - N 은 건너 뛸 원본 서버의 이벤트 수 

SET GLOBAL sql_slave_skip_counter = N

- 주의사항

  - 이벤트는 일반적으로 바이너리 로그에서 하나의 SQL문을 지원하지만 AUTO_INCREMENT 또는 LAST_INSERT_ID()를 사용하는 경우 바이너리 로그에서 두개의 이벤트로 계산된다. 

  - 바이너리 로그의 트랜잭션 압축이 사용되는 경우, 압축 된 트랜잭션 페이로드(Transaction_payload_event)는 하나의 카운터 값으로 계산되기 때문에 그 내부의 모든 이벤트는 하나의 이벤트로 계산된다.

 

참고

https://dev.mysql.com/doc/refman/8.0/en/replication-administration-skip.html

'MySQL' 카테고리의 다른 글

OPTIMIZE TABLE Statement  (0) 2021.06.18
ANALYZE TABLE Statement  (0) 2021.06.17
GTID 복제 상태 확인  (0) 2021.06.12
GTID 사용시 복제본 복구  (0) 2021.06.10
GTID를 사용한 복제구성  (0) 2021.06.09

- SHOW RELICA STATUS, SHOW SLAVE STATUS  문으로 원본서버, 복제서버간의 연결 구성 및 상태 정보 확인 가능

- MySQL 8.0.22 부터 SHOW SLAVE STATUS 문은 사용되지 않는다. 

  대신 SHOW REPLICA STATUS 를 사용

- PERFORMANCE_SCHEMA 에 replication_ 로 시작하는 테이블에서 복제 관련 정보를 확인할 수 있다. 

  - 원본서버는 하트 비트 간격보다 긴 기간동안 바이너리 로그에 업데이트 겂어 보내지 않는 이벤트가 없는 경우 하트 비트 신호를 복제본으로 전송한다. 

    CHANGE MASTER TO 문의 MASTER_HEARTBEAT_PERIOD 설정은 하트 비트 빈도를 지정한다. (기본값 slave_net_timeout의 1/2)

  - replication_connection_status 테이블에는 복제가 최선 하트 비트 신호를 언제 수신했는지 여부와 하트 비트 신호 수가 표시된다. 

 

SHOW RELICA STATUS, SHOW SLAVE STATUS 에서 제공하는 정보 중 주요정보 

- Replica_IO_State : 복제의 현재 상태
- Replica_IO_Running : 원본 바이너리 로그를 읽기위한 I/O 스레드 실행 상태 
- Replica_SQL_Running : 릴레이 로그의 이벤트를 실행하는 SQL 쓰레드 실행 상태 
- Last_IO_Error, Last_SQL_Error : 릴레이 로그를 처리 할 때 I/O 및 SQL 쓰레드에 의해 등록 된 마지막 오류
- Seconds_Behind_Source : 복제 SQL 쓰레드가 원본 바이너리 로그의 처리를 지연 시간 (초)
  - Seconds_Behind_Source값 0은 일반적으로 복제가 소스에 따라 잡았다는 것을 의미하는 것으로 해석 할 수 있지만, 엄밀하게는 true가 아닌 경우도 있다.

    예를 들어 원본과 복제본 간의 네트워크 연결이 끊어졌지만, 복제 I / O thread가 아직 이를 모르고 ( slave_net_timeout이 아직 경과하지 않은) 경우에 발생할 수 있다.

  - Seconds_Behind_Source임시 값이 상황을 정확히 반영하지 않을 수도 있다.

    복제 I/O thread가 아직 새로운 이벤트를 대기하는 경우 복제 SQL 쓰레드가 새로운 이벤트의 실행을

    종료 할 때까지 , Seconds_Behind_Source큰 값이 표시 될 수 있다. 이것은 이벤트에 오래된 타임 스탬프가있는

   경우에 문제가 발생할 수 있다. 이런 경우 비교적 짧은 기간에 SHOW REPLICA STATUS,  SHOW SLAVE STATUS 를

   여러 번 실행하면이 값이 0에서 비교적 큰 값까지 반복적으로 변경 될 수 있다. 

 

두가지를 같이 확인해야되는 정보

- show replica status, show slave status 에서 출력되는 값은 같으나 아래와 같이 다르게 나오는 부분이 있다. 

  - show slave status 에서 Master, Slave 로 출력되는 항목이 show replica status 에서는 Source, Replica 로 출력된다.

- Master_Log_file, Read_Master_Log_Pos 또는 Source_Log_file, Read_Source_Log_Pos : 복제 I/O thread가 원본 로그에서 이벤트를 읽을 위치 (원본 바이너리 로그 파일과 포지션)
- Relay_Master_Log_File, Exec_Master_Log_Pos 또는 Relay_Source_Log_File, Exec_Source_Log_Pos: 복제 SQL 쓰레드가 로그에서 받은 이벤트를 실행 한 위치 (원본 바이너리 로그 파일과 포지션)
- Relay_Log_File, Relay_Log_Pos : 복제 SQL 쓰레드가 릴레이 로그를 실행 한 위치 

 

 

원본에서 연결 복제 상태 확인

- SHOW PROCESSLIST 문

mysql> show processlist\G;
     Id: 8
   User: repl
   Host: 192.168.137.12:32796
     db: NULL
Command: Binlog Dump GTID
   Time: 1645
  State: Master has sent all binlog to slave; waiting for more updates
   Info: NULL

- SHOW REPLICAS, SHOW SLAVE HOSTS 문 

mysql> show replicas;
+-----------+------+------+-----------+--------------------------------------+
| Server_Id | Host | Port | Source_Id | Replica_UUID                         |
+-----------+------+------+-----------+--------------------------------------+
|        12 |      | 3306 |        11 | f6d4ffe7-bbd7-11eb-8dde-00155ddba00e |
+-----------+------+------+-----------+--------------------------------------+
1 row in set (0.00 sec)

mysql> show slave hosts;
+-----------+------+------+-----------+--------------------------------------+
| Server_id | Host | Port | Master_id | Slave_UUID                           |
+-----------+------+------+-----------+--------------------------------------+
|        12 |      | 3306 |        11 | f6d4ffe7-bbd7-11eb-8dde-00155ddba00e |
+-----------+------+------+-----------+--------------------------------------+
1 row in set, 1 warning (0.00 sec)

 

참고

https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html

 

'MySQL' 카테고리의 다른 글

ANALYZE TABLE Statement  (0) 2021.06.17
GTID - 트랜잭션 건너뛰기  (0) 2021.06.13
GTID 사용시 복제본 복구  (0) 2021.06.10
GTID를 사용한 복제구성  (0) 2021.06.09
GTID  (0) 2021.06.09

- my.cnf 기준 필요한 설정값.

  -  현재 원본 서버는 구동되는 상태이므로, 원본 서버에 my.cnf 를 복하여 server-id만 변경해서 복제본에서 사용

gtid-mode = on
enforce-gtid-consistency=on
binlog-checksum=NONE
log-slave-updates=on
server-id = 1234  # 복제를 구성하는 서버간의 값이 달라야함

 

- 복제용 계정, 원본서버에 생성 

CREATE USER 'repl'@'복제본서버 IP' IDENTIFIED BY '패스워드';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'복제본서버 IP';

-  슬레이브 장비에서 마스터 서버를 대상으로 아래의 복제 설정을 추가.

change master to
master_host = '원본 서버 IP',
master_port =원본 서버 Port,
MASTER_USER='repl',
MASTER_PASSWORD='패스워드',
MASTER_AUTO_POSITION =1; 

-  원본 서버에서 백업 수행.

  -  gtid사용시 --all-databases --triggers --routines --events  옵션 권장

  - 개별 디비 백업 시 경고 발생. (개별 디비 백업 수행 대신 디비 전체 백업을 사용)

mysqldump --default-character-set=utf8mb4 -u아이디 -p패스워드 --single-transaction --all-databases --triggers --routines --events -S "mysql.sock 파일위치" | gzip > backup.sql.gz

- 슬레이브에서 백업 데이터 임포트 전 gtid관련 정보 퍼지.

show global variables like 'gtid_executed';
+-----------------+-------------------------------------------------------+
| Variable_name   | Value                                                 |
+-----------------+-------------------------------------------------------+
| gtid_executed   | 027f123c-51b5-22ef-eeb3-225056ac2425:1-1322           |
+-----------------+-------------------------------------------------------+
1 row in set (0.01 sec)

show global variables like 'gtid_purged';
+-----------------+-------------------------------------------------------+
| Variable_name   | Value                                                 |
+-----------------+-------------------------------------------------------+
| gtid_purged     | 019f728c-52b5-11ea-aeb3-005056ac2425:1-1520           |
+-----------------+-------------------------------------------------------+

reset master;

show global variables like 'gtid_executed';
+-----------------+-------------+
| Variable_name   | Value       |
+-----------------+-------------+
| gtid_executed   |             |
+-----------------+-------------+
1 row in set (0.00 sec)

show global variables like 'gtid_purged';
+-----------------+-------------+
| Variable_name   | Value       |
+-----------------+-------------+
| gtid_purged     |             |
+-----------------+-------------+
1 row in set (0.00 sec)

 

- 백업 데이터 임포트

mysql --default-character-set=utf8mb4 -u아이디 -p패스워드 -S "mysql.sock 파일위치" < backup.sql

- 복제 시작 설정

start slave;

- 정상상태 확인

  - 원본, 복제본 비교

show global variables like 'gtid_executed';
show global variables like 'gtid_purged';

 

  - 복제 상태 확인 (Slave_IO_Running, Slave_SQL_Running 이 Yes 인지 확인)

show slave status\G

- 원본 서버에서 테스트 DB 생성후 복제본 DB에 생성되는지 확인 

create database test_db;

 

 

참고

- slave장비 붙이기

https://minsugamin.tistory.com/entry/MySQL-57-GTID

- 에러메세지 관련

https://www.percona.com/blog/2013/02/08/how-to-createrestore-a-slave-using-gtid-replication-in-mysql-5-6/

'MySQL' 카테고리의 다른 글

GTID - 트랜잭션 건너뛰기  (0) 2021.06.13
GTID 복제 상태 확인  (0) 2021.06.12
GTID를 사용한 복제구성  (0) 2021.06.09
GTID  (0) 2021.06.09
MySQL InnoDB Row 형식  (0) 2021.06.04

원본-복제본 1:1 로 구성되어 있는 경우 GTID를 적용하기 위한 방법은 아래와 같다. 

1. 서버 동기화 

- GTID를 사용하지 않고 복제 구성이 되어 있는 경우에만 필요

- 신규 서버의 경우 3단계부터 진행 

- 각 서버를 읽기 전용으로 설정 

mysql> SET @@GLOBAL.read_only = ON;

- 진행중인 모든 트랜잭션이 커밋 또는 롤백 될때까지 기다린다. 

  복제본에 모든 트랜잭션이 적용되었느지 확인한다. 

 

2. 두 서버 중지 

- mysqladmin 을 사용하여 각 서버를 중지한다.

  그런데 mysqladmin 으로 서버 내려본적이 없네 ㅋㅋㅋ 

shell> mysqladmin -uusername -p shutdown

 

3. GTID 에 필요한 옵션을 적용하여 서버 구동 

gtid_mode=ON
enforce-gtid-consistency=ON

- 복제 설정을 구성하기전에 --skip-slave-start 옵션을 사용하여 복제본을 시작한다. 

  --skip-slave-start 옵션 적용시 복제본이 시작될때 복제시작을 하지 않는다. 

- 복제 구성을 위해서 원본서버는 바이너리 로그가 활성화되어 있어야한다. 복제본은 바이너리 로그 없이 GTID를 사용할수 있다. 복제본 서버에서 바이너리 로그를 비활성화 해야되는 경우 --skip-log-bin, --log-slave-updates=OFF옵션을 지정하여 바이너리 로그ㄹ르 비활성화할 수 있다.

 

4. GTID 기반의 자동 위치 지젖을 사용하도록 복제본 구성 

mysql> CHANGE MASTER TO
     >     MASTER_HOST = host,
     >     MASTER_PORT = port,
     >     MASTER_USER = user,
     >     MASTER_PASSWORD = password,
     >     MASTER_AUTO_POSITION = 1;

Or from MySQL 8.0.23:

mysql> CHANGE REPLICATION SOURCE TO
     >     SOURCE_HOST = host,
     >     SOURCE_PORT = port,
     >     SOURCE_USER = user,
     >     SOURCE_PASSWORD = password,
     >     SOURCE_AUTO_POSITION = 1;

- 원본서버의 호스트 이름 또는 IP, 포트 번호에 적절한 값을 지정하여 원본서버에 연결하는데 사용할 수 있는 복제 사용자 계정의 사용자 이름과 암호를 지정해야 한다. 

 

5. GTID가 적용된 백업 생성 

- GTID 를 적용하기전에 생성된 백업은 GTID가 적용된 서버에 사용할 수 없기 때문에 이시점에서 새로운 백업을 한다. 

 

6. 복제를 시작하고 읽기 전용 모드 해제

mysql> START SLAVE;
Or from MySQL 8.0.22:
mysql> START REPLICA;

- 1단계에서 서버를 읽기 전용으로 구성한 경우 서버가 업데이트를 적용할 수 있도록 다음 명령문을 실행한다. 

mysql> SET @@GLOBAL.read_only = OFF;

 

참고

https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-howto.html

'MySQL' 카테고리의 다른 글

GTID 복제 상태 확인  (0) 2021.06.12
GTID 사용시 복제본 복구  (0) 2021.06.10
GTID  (0) 2021.06.09
MySQL InnoDB Row 형식  (0) 2021.06.04
online ddl 알고리즘  (0) 2021.05.27

GTID 개념

- GTID(Global Transaction Identifiler)는 원본 서버(Source)에서 Commit된 각각의 트랜잭션들이 가지게되는 고유한 전역 식별자로 원본 서버에만 고유한것이 아니라 복제 설정의 모든 서버에서 고유한 값을 가진다. 

- 모든 트랜잭션과 모든 GITD 사이에는 일대일 매핑이 있다. 

 

GITD 부여 방식 

- auto.cnf 파일에 설정된 server-uuid:transaction_id 로 표시 되며 transaction_id는 트랜잭션이 Commit된 순서에 의해 결정된다. (server-uuid 로 원본서버를 식별한다.)

 

GTID 확인 

- Binary Log, SHOW SLAVE STATUS 문에서 확인 가능

- mysqlbinlog --base64-output=DECODE-ROWS 문으로 log file에서 확인하거나 SHOW BINLOG EVENTS의 결과에서도 확인 가능

- SHOW MASTER STATUS, SHOW SLAVE STATUS 문의 결과와 같이 동일한 서버에서 생성된 GTID의 순서는 아래와 같이 단문으로 축소되어 보여진다. 

  3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5

- MySQL 5.6.6 이상부터 START SLAVE 문에 SQL_BEFORE_GITDS, SQL_AFTER_GTIDS 옵션을 제공한다. 

 

GTID 세트 

- GTID 세트는 다음과 같이 표시되는 글로벌 트랜잭션 식별자 세트 

gtid_set:
    uuid_set [, uuid_set] ...
    | ''

uuid_set:
    uuid:interval[:interval]...

uuid:
    hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh

h:
    [0-9|A-F]

interval:
    n[-n]

    (n >= 1)

- GTID 세트는 MySQL 서버에서 여러가지 방식으로 사용된다. 

  - EX) gtid_executed, gtid_purged 시스템 변수로 저장된 값은 GTID 세트로 표시된다.

         GTID_SUBSET(), GTID_SUBTRACT() 함수는 GTID 세트 입력값이 필요하다.

- GTID 는 항상 원본(소스)와 복제본간에 유지된다. 

   바이너리 로그를 검사하여 복제본에 적용된 모든 트랜잭션의 원본(소스)를 항상 확인할 수 있다. 

- 주어진 GTID를 가진 트랜잭션이 주어진 서버에서 Commit 되면 동일한 GTID를 가진 모든 후속 트랜잭션이 해당 서버에서 무시된다. 원본(소스)에서 커밋 된 트랜잭션은 복제본에 한번만 적용될 수 있으므로 일관성이 보장된다. 

- GTID를 사용할때 복제본에는 소스의 파일 이름 및 해당 파일 내의 위치와 같은 비 로컬 데이터가 필요하지 않다. 

- 소스와 동기화하는데 필요한 모든 정보는 복제 데이터 스트림에서 직접 가져온다. 

- 원본, 복제본 간의 데이터 흐름의 시작, 중지 또는 재게하는 시점을 결정하는데 필요했던 file-offset pairs를 대체한다. 

- 복제를 위해서 GTID를 사용할때 CHNAGE MASTER TO 구문에서 MASTER_LOG_FILE, MASTER_LOG_POS 옵션을 사용할 필요가 없다. 대신 MASTER_AUTO_POSITION 옵션을 사용한다. 

 

GTID의 생성 및 수명주기는 다음 단계로 구성된다. 

1. 트랜잭션이 원본(소스)에서 실행되고 Commit

   이 트랜잭션에는 원본(소스)의 UUID와 서버에서 사용되지 않은 가장 작은 트랜잭션 시퀀스 번호(0보다 큰)를 사용하여 GTID가 할당된다. GTID는 원본(소스)의 바이너리 로그에 기록된다. 

2. 바이너리 로그 데이터가 복제본으로 전송되고 복제본의 릴레이 로그에 저장되면 복제본은 GTID를 읽어서 gtid_next 시스템 변수값으로 설정한다. 

3. 복제본은 이 GTID가 잔체 바이너리 로그에 트랜잭션을 기록하는데 아직 사용되지 않았는지 확인한다. 

   이 GTID가 사용되지 않은 경우에만 복제본은 GTID를 사용하여 트랜잭션을 적용한다. (그리고 트랜잭션을 바이너리 로그에 기록한다.) 

   트랜잭션을 실행하기 전에 트랜잭션의 GTID를 먼저 읽고 확인하는것은, 아직 Commit되거나 적용되지 않은 트랜잭션에 대해 복제본은 이 GTID가 있는 이전 트랜잭션이 복제본에 적용되지 않았을뿐만 아니라 다른 세션이 GTID를 읽지 않았음을 보장한다. 

4. gtid_next 값이 비어있지 않기 때문에 복제본은 이 트랜잭션에 대한 GTID를 생성하려고 시도하지 않고 이 변수에 저장된 GTID(원본에서 얻은 GTID)의 트랜잭션(바이너리 로그에 저정된)을 실행한다. 

 

mysql.gtid_executed 테이블 (5.7 에서 추가됨)

- 현재 활성화된 바이너리 로그 파일에 저장된 트랜잭션을 제외하고 MySQL 서버에 적용된 모든 트랜잭션에 할당된 GTID를 저장하는데 사용되는 테이블 

- 이 테이블의 행에는 각 GTID 또는 GTID 집합에 대해 원본 서버의 UUID와 집합의 시작 및 종료, 트랜잭션 ID가 포함된다. 단일 GTID만 참조하는 행의 경우 마지막 두 값은 동일하다. 

- 이 테이블은 복제본에서 바이너리 로깅이 비활성화 된 경우 복제본이 GTID를 사용할 수 있드록 하고 바이너리 로그가 손실된 경우 GTID를 유지할 수 있게 해준다. 

- RESET MASTER 문을 실행할 경우 mysql.gtid_executed 테이블은 초기화된다.

- gtid_mode 가 ON 또는 ON_PERMISSIVE 모드일 때만 GTID가 mysql.gtid_executed 테이블에 저장된다. 

 

 

GTID 의 Life Cycle

1. 트랜잭션이 커밋되면 GTID를 할당 받고 원본의 바이너리 로그에 기록된다. 

2. 할당된 GTID는 gtid_executed 시스템 변수(@@GLOBAL.gtid_executed)와 mysql.gtid_executed 테이블에 저장된다. 

3. 원본의 바이너리 로그 데이터가 복제본의 릴레이 로그에 저장되면 복제본은 GTID를 읽고 gtid_next 시스템 변수를 설정한다. 

4. 복제본에서 gtid_next 에 설정된 GTID의 트랜잭션이 반영되지 않았을 경우 반영한다. 

5. 복제본에 바이너리 로그가 활성화된 경우 커밋후 GTID를 바이너리 로그에 기록하고 복제본의 gtid_executed 시스템 변수(@@GLOBAL.gtid_executed)와 mysql.gtid_executed 테이블에 저장된다.  바이너리 로그가 비활성화된 경우 바이너로 로그에 기록하는 부분을 제외하고는 동일하게 처리된다. 

 

GTID Auto-Positioning

- 복제구성시 GTID를 사용할 경우 복제본이 원본과 동기화하는데 필요한 모든 정보를 복제 데이터 스트림에서 직접 가져온다. 

- 복제 구성시 MySQL 8.0.23 버전부터는 CHANGE REPLICATION SOURCE TO  문을 사용한다. 이전 버전의 경우 CHANGE MASTER TO 문을 사용한다. GTID 사용시  SOURCE_AUTO_POSITION  또는 MASTER_AUTO_POSITION 옵션을 사용한다.  SOURCE_LOG_FILE, MASTER_LOG_FILE, SOURCE_LOG_POS, MASTER_LOG_POS 등의 옵션을 사용하지 않는다. 

- 복제본에 GTID가 활성화 (GTID_MODE=ON, ON_PERMISSIVE,또는 OFF_PERMISSIVE) 되고 MASTER_AUTO_POSITION 옵션이 활성화되면 원본에 연결하기 위한 바이너리 파일의 위치를 찾는다. 

- 복제본은 원본에 수신, 커밋 또는 둘다 수행한 트랜잭션이 포함된 GTID 세트를 보내고 원본 서버는 이 GTID 세트에 포함되지 않은 바이너리 로그의 모든 트랜잭션을 전송한다. 이때 원본에서 전송해야되는 트랜잭션이 바이너리 로그에서 제거되었거나 다른 방법으로 gtid_purged 시스템 변수에 GTID가 추가된 경우 복제본에 ER_MASTER_HAS_PURGED_REQUIRED_GTIDS 오류를 전송하고 복제는 시작되지 않는다. 

- 누락된 트랜잭션의 GTID는 원본서버의 에러로그에 warning message ER_FOUND_MISSING_GTIDS 에 기록된다.

- 이 상황에서 MASTER_AUTO_POSITION 옵션을 사용하여 복제를 구성하기 위해 복제본을 복구하려면 다른 원본에서 ER_FOUND_MISSING_GTIDS에 기록된 GTID의 트랜잭션을 복제하거나 원본서버를 백업받아 복제본을 새로 구성해야 한다. ( binlog_expire_logs_seconds 가 발생하지 않도록 바이너리 로그 보관기간을 조정한다.)

 

 

참고

https://dev.mysql.com/doc/refman/5.6/en/replication-gtids-concepts.html

https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-concepts.html

https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-concepts.html

https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-lifecycle.html

https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-auto-positioning.html

 

 

 

 

'MySQL' 카테고리의 다른 글

GTID 사용시 복제본 복구  (0) 2021.06.10
GTID를 사용한 복제구성  (0) 2021.06.09
MySQL InnoDB Row 형식  (0) 2021.06.04
online ddl 알고리즘  (0) 2021.05.27
binlog format  (0) 2021.05.15

+ Recent posts