InnoDB 스토리지 엔진은 REDUNDANT, COMPACT, DYNAMIC, COMPRESSED의 네가지 Row 형식을 지원한다. 

REDUNDANT

- 이전 버전의 MySQL 과의 호환됨

  기존의 File Format Antelope 과 5.0 이후에 추가된 Barracuda 도 지원

- 가변 길이 컬럼값의 768 바이트까지는 B-Tree 노드의 인덱스에 저장하고 나머지는 Overflow Page에 저장한다. 

- 768 바이트보다 크거나 같은 고정길이 컬럼은 가변 길이 컬럼으로 인코딩되어 Off-Page 에 저장할 수 있다. 

- 컬럼값이 768 바이트 이하이면 Overflow Page를 사용하지 않고 값이 B-Tree 노드에 저장되어 I/O가 약간 절약될 수 있다. 이경우 상대적으로 짧은 BLOB 컬럼값에 적합 하지만 B-Tree 노드가 키 값이 아닌 데이터로 채워져 효율성이 떨어질 수 있다. 

- BLOB 컬럼이 많은 테이블은 B-Tree 노드가 너무 다득차고 너무 적은 행를 포함하여 행이 더 짧거나 컬럼 값이 off-page에 저장된 경우보다 전체 인덱스의 효율성이 떨어질 수 있다.

COMPACT

- 이전 버전의 MySQL 과의 호환됨

  기존의 File Format Antelope 과 5.0 이후에 추가된 Barracuda 도 지원

- COMPACT 은 일부 작업에 CPU 사용을 늘리는 대신 REDUNDANT 에 비해 행 저장 공간을 약 20% 줄여준다.

- 워크로드가 캐시 적중률과 디스크 속도에 의해 제한되는 일반적인 작업인 경우 COMPACT 가 더 빠를 수 있다.

  워크로드가 CPU 속도에 의해 제한되는 경우 COMPACT 이 느려질 수 있다.

- COMPACT 을 사용하는 테이블은 B 트리 노드 내의 인덱스 레코드에 처음 768바이트의 가변 길이 컬럼 값(VARCHAR, VARBINARY 및 BLOB 및 TEXT 형식)을 저장하고 나머지는 Overflow Page에 저장된다.

  768바이트보다 크거나 같을 수록 고정 길이 컬럼은 페이지 밖에서 저장할 수 있는 가변 길이 컬럼으로 인코딩된다.

  예를 들어, CHAR(255) 컬럼은 utf8mb4와 마찬가지로 문자 세트의 최대 바이트 길이가 3보다 큰 경우 768바이트를 초과할 수 있다. 

- 컬럼 값이 768바이트 이하인 경우 Overflow Page가 사용되지 않으며 값이 B-tree 노드에 완전히 저장되므로 I/O에서 일부 절감이 발생할 수 있다. 이는 비교적 짧은 BLOB 컬럼 값에 적합하지만 B-트리 노드가 키 값이 아닌 데이터로 채워지므로 효율성이 저하될 수 있다. BLOB 컬럼이 많은 테이블은 B-tree 노드가 너무 가득 차있고 Row가 너무 적어져 Row가 짧거나 컬럼 값이 페이지 밖에서 저장된 경우보다 전체 인덱스의 효율성이 떨어질 수 있다. 

DYNAMIC

- DYNAMIC Row Format 은 COMPACT Row Format과 동일한 저장소 특성을 제공하지만 긴 가변 길이 컬럼에 대한 향상된 스토리지 기능을 추가하고 큰 인덱스 키 접두사를 지원한다.
- Barracuda File Format은  DYNAMIC Row Format을 지원한다. 

- ROW_FORMAT=DYNAMIC로 테이블이 만들어지면 InnoDB는 Overflow Page에 20바이트 포인터만 포함하는 클러스터된 인덱스 레코드를 사용하여 긴 가변 길이 컬럼 값(VARCHAR, VARBINARY 및 BLOB 및 TEXT 형식의 경우)을 완전히 Off-Page 로 저장할 수 있다. 768바이트보다 크거나 같을 수 있는 고정 길이 필드는 가변 길이 필드로 인코딩된다. 예를 들어, CHAR(255) 컬럼은 utf8mb4와 마찬가지로 문자 세트의 최대 바이트 길이가 3보다 큰 경우 768바이트를 초과할 수 있다.
- 컬럼이 페이지 밖에서 저장되는지 여부는 페이지 크기와 Row의 총 크기에 따라 다릅니다. Row가 너무 길면 클러스터드 인덱스 레코드가 B 트리 페이지에 맞을 때까지 페이지 밖에서 가장 긴 열이 선택된다. 40바이트 미만이거나 동일한 텍스트 및 BLOB 컬럼은 Line에 저장된다. 

- DYNAMIC Row Format 은 COMPACT,  REDUNDANT Format과 마찬가지로 인덱스 노드에 전체 Row를 저장하는 효율성을 유지하지만 DYNAMIC Row Format은 많은 수의 데이터 바이트의 데이터 바이트로 B-트리 노드를 채우는 문제를 방지한다. DYNAMIC Row Format은 긴 데이터 값의 일부가 페이지 밖에서 저장되는 경우 일반적으로 전체 값을 페이지 밖에서 저장하는 것이 가장 효율적이라는 생각을 기반으로 한다. DYNAMIC Format을 사용하면 짧은 컬럼이 B 트리 노드에 남아 있는 경우 지정된 Row에 필요한 Overflow Page 수를 최소화할 수 있다.

- DYNAMIC Row Format은 인덱스 키 접두사를 최대 3072바이트까지 지원한다. 이 기능은 기본적으로 활성화되는 innodb_large_prefix 변수에 의해 제어된다.

- DYNAMIC Row Foramt을 사용하는 테이블은 시스템 테이블스페이스, 테이블당 파일 테이블 스페이스 및 일반 테이블스페이스에 저장할 수 있다. 시스템 테이블 스페이스에 DYNAMIC 테이블을 저장하려면 innodb_file_per_table 사용하지 않도록 설정하고 테이블 만들기 또는 테이블 변경 문을 사용하거나 테이블 만들기 또는 테이블 변경과 함께 테이블스페이스 [=] innodb_system 테이블 옵션을 사용한다. innodb_file_per_table 및 innodb_file_format 변수는 일반 테이블스페이스에 적용되지 않으며, 테이블스페이스 [=] innodb_system 테이블 옵션을 사용하여 시스템 테이블스페이스에 DYNAMIC 테이블을 저장할 때는 적용할 수 없다.

COMPRESSED 

- COMPRESSED Rwo Format은 DYNAMIC 과 동일한 저장소 특성 및 기능을 제공하지만 테이블 및 인덱스 데이터 압축에 대한 지원을 추가한다.

- Barracuda File Format은  COMPRESSED Row Format을 지원한다. 

- COMPRESSED Rwo Format은 테이블 및 인덱스 데이터의 추가 저장소 및 성능 고려 사항이 압축되고 더 작은 페이지 크기를 사용하여 DYNAMIC Row Foramt 과 유사한 내부 세부 정보를 사용한다. COMPRESSED Rwo Format을 사용하면 KEY_BLOCK_SIZE 옵션으로 클러스터된 인덱스에 저장된 컬럼 데이터의 양과 Overflow Page에 배치되는 양을 제어한다. 

- COMPRESSED  Row Format은 인덱스 키 접두사를 최대 3072바이트까지 지원한다. 이 기능은 기본적으로 활성화되는 innodb_large_prefix 변수에 의해 제어된다.

- COMPRESSED  Row Format을 사용하는 테이블은 테이블당 파일 테이블 스페이스 또는 일반 테이블 스페이스에서 만들 수 있다. 시스템 테이블 스페이스는 압축행 형식을 지원하지 않는다. 압축테이블을 테이블당 파일 테이블에 저장하려면 innodb_file_per_table 변수를 사용하도록 설정해야 하며 innodb_file_format을 Barracuda 로 설정해야 한다. innodb_file_per_table 및 innodb_file_format 변수는 일반 테이블 스페이스에 적용되지 않는다. 일반 테이블 스페이스는 압축 및 압축되지 않은 테이블이 서로 다른 물리적 페이지 크기로 인해 동일한 일반 테이블 스페이스에 공존할 수 없는 주의 사항으로 모든 Row Format 을 지원한다. 

참고 

https://dev.mysql.com/doc/refman/5.7/en/innodb-row-format.html

차산지 3년이 되어가는구나
메모리 카드를 교체하다 우연히 액정하단 터치가 안되는걸 발견
찾아보니 이모델에선 흔히 발생하는 문제
이번기회에 블랙박스 바꿀까 고민하다 as받기로 결정!
차 점검을 맡겨놓고 아이트로닉스로 출발

아이트로닉스는 기흥에 있다.
폭스바겐 판교정비센터에서 기흥은 택시타고 갈만하다.

도착해서 증상진단해보니 액정을 교체해야되는데 28000원을 내면 새걸로 바꾸어준다.

이건 고장없이 오래 쓰고 싶다

mysql 5.6 부터 online ddl이 추가 되었다.

각 버전별 online ddl 지원 범위가 다르다 메뉴얼을 한번 읽어보자.
https://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl.html
https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl.html
https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl.html

InnoDB에서 지원하는 online ddl 알고리즘 

- copy

- inplace 

- instant (mysql 8.0)

copy 

- 변경된 스키마가 적용된 임시 테이블을 생성하여 기존 테이블의 데이터를 복사한 후 테이블 이름을 변경하는 방식

- ALGORITHM 구문 미사용시 INPLACE -> COPY 순으로 처리됨 

  INPLACE 로 처리 가능한 경우 INPLACE 를 사용하고 처리 불가능시 COPY 사용

단점 

- DDL 작업 일시중지, 작업중 I/O, CPU 사용제한 메커니즘 없음

- 작업중 롤백이 발생할 수 있으며, 롤백시 많은 비용이 소모됨 

- ALTER TABLE 작업 동안 Concurrent DML (inserts,updates,deletes) 이 차단됨

  LOCK = SHARED 일 때 Select는 가능함 

- 복제 지연이 발생 가능성 있음 

inplace

- 원본 테이블에 직접 변경작업을 적용함 

- 작업 준비(during perparation) 실행단계(executioin pahases of the operation)에서 테이블에 대한 배타적 메다 데이터 잠금(exclusive metadata lock)이 잠깐 동안 수행될 수 있다.

- 일반적으로 Concurrent DML 을 지원함 

단점

- 지원하지 않는 DDL 구문이 있음 

  지원여부 확인을 위해 ALGORITHM=INPLACE 구문을 사용해서 확인 가능 

- 테이블을 수정하는 동안 변경된 데이터량이 innodb_online_alter_log_max_size 를 초과할 경우 

  online ddl 이 실패하고 변경된 데이터는 롤백된다. 

  2시간 정도 돌아가다 에러나면서 롤백되면 환장한다... (경험담)

- 장기간 실행되는 DLL 작업은 슬레이브에서 복제 지연을 유발할 수있다.

  ALTER TABLE 작업은 마스터에서 작업이 완료되면 슬레이브로 전달된다. 

- 동시성이 높은 서버의 큰 테이블에 대해 높은 I/O 사용량을 유발할 수 있다. 

instant 

- mysql 8.0 에서 추가됨

- 메타 정보만 수정하여 변경 사항 반영

  스키마 변경중에 메타 데이터 잠금을 획득하지 않으며, 테이블의 데이터 파일도 건드리지 않는다. 

- ALGORITHM 구문 미사용시 INSTANT -> INPLACE -> COPY 순으로 처리됨 

단점

- 컬럼 추가시 테이블의 마지막 열로만 추가 가능, 컬럼 위치 지정 불가 

- ROW_FORMAT=COMPRESSED 를 사용하는 테이블에는 컬럼 추가 불가 

- FULLTEXT 인덱스를 포함하는 테이블에는 컬럼 추가 불가

- 임시 테이블에는 컬럼 추가 불가 

  임시테이블은 ALGORITHM=COPY 만 지원 

- 데이터 딕셔너리 테이블 스페이스 (공유 테이블 스페이스)에 있는 테이블에는 컬럼 추가 불가 

LOCK 

- 테이블에 대한 동시 엑세스 수준을 조정

- mysql은 ddl 작업시 가능한 작은 level 의 lock을 사용한다. 

  더 제한적인 감금을 적용하기 위해서 LOCK 절을 지정함 

- 특정 DDL 조작에서 허용되는 lock 레벨보다 더 적은 제한 레벨 lock을 지정하면 SQL Statement는 오류와 함께 실패한다. 

- LOCK=NONE

  Concurrent query,  Concurrent DML 허용

- LOCK=SHARED

  Concurrent query 허용,  Concurrent DML 불가

- LOCK=DEFAULT

  수행 가능한 동시성 작업에 대해서 허용 

- LOCK=EXCLUSIVE

  Concurrent query 불가,  Concurrent DML 불가

  빠른 시간내에 DDL 이 완료되거나, 동시 쿼리나 DML 이 없을 경우 사용

oline ddl 단계

- Initializaton

  Storage Engine 기능, 명령문으로 지정된 작업, 사용자 지정의 ALGORITHM 및 Lock 옵션을 고려하여 

  작업에 허용가능한 옵션 결정

  테이블 정의를 보호하기 위해 가능한 Shared Upgradeable Metadata Lock 을 수행

- Execution

  명령문이 준비되고 실행됨 

  Metadata Lock의 Exclusive 여부는 Initializaton 단계에서 평가된 내역에 따라 다르며, Exclusive Metadata Lock 이 필요한 경우 Alter 문을 주비하는 동안 잠깐 수행됨 

- Commit Table Definition

  테이블의 구조가 완료됨 

  Metadata Lock은 테이블 정의를 커밋하기 위해 Exclusive 로 업그레이드됨 

  Exclusive Metadata Lock 은 짧은 시간동안 잡힘

데이터 파일 48G짜리 테이블의 컬럼 데이터 타입 수정 작업을 해야된다. 

online ddl 이 된다고 해도 table rebuild 가 발생하는 작업으로 생각을 좀 해보자.

다행이 서비스를 다 내리고 점검중에 진행하는 작업이다. 

1안 pt-online-schema-change 사용 (점검 없이 한다고 했으면 1안으로 선택했을듯)

2안 컬럼 데이터 타입이 변경이 적용된 임시 테이블을 만들어서 데이터 INSERT 하고 테이블 이름 변경 (복제가 걸려 있어서 선택안함)

3안 SET SQL_LOG_BIN=Off 로 지정하고 마스터/슬레이브 각각에서 데이터 타입 변경 (선택)

백업을 했으니 복원을 해야지.. 

너무나 당연한 것

util.loadDump 로 복원한다. 

주의사항 

- 복원할 MySQL 인스턴스는 5.7 이상이 필요하다.

- 복원시 LOAD DATA LOCAL INFILE 명령문을 사용함으로 local_infile 시스템 변수가 ON으로 설정되어 있어야한다.

- sql_require_primary_key 시스템 변수가 ON 으로 설정되어 있는 경우 덤프 파일에 PK가 없는 테이블이 있을 경우 오류를 반환한다. 

특이사항 및 특징

- waitDumpTimeout 옵션 사용시 덤프중인 덤프를 복원할 수 있다. 

  - 테이블이 사용가능 해지면 로드되고 새 데이터가 덤프될때까지 지정된 시간(초) 동안 대기한다. 

    제한 시간이 경과하면 덤프가 완료된것으로 판단하고 가져오기를 중단한다. 

- 복구 상태를 진행 상태 파일에 저장한다. 

  - 진행 상태 파일 저장 위치는 기본적으로 덤프 디렉토리에  생성된다. 

    load-process.server_uuid.json 파일 형태로 저장되며 저장위치, 파일명을 설정할 수 있다.

  - 복원을 재개하거나 재시도 할때 진행 상태 파일을 참조하고 완료된 단계를 건너뛴다. 

    부분적으로 로드된 테이블에 대해 중복 제거가 자동으로 관리된다. 

  - Ctrl + C 로 중단후 대시 복원할때 중지된 단계에서 다시 진행된다. 

- resetProgress 옵션으로 처음부터 다시 복원가능

  이전에 로드된 모든 객체(디비, 테이블, 사용자, 뷰, 트리거 등등)을 수동으로 제거해야함.

- DDL 파일은 단일 스레드로 로드, 데이터는 지정한 스레드 수로 병렬 로드됨 (기본값 : 4)

  덤프가 생성될때 테이블 데이터가 청크된 경우 여러 스레드를 사용가능

  그렇지 않은 경우 각 스레드가 한번에 하나의 테이블을 로드함 

- 병렬 처리 최대화를 위해 스레드간에 데이터 가져오기를 예약함 

- 덤프시 mysql shell 에서 압축된 경우 별도의 압축 해제 옵션 필요 없음 (자동 해제)

주요 옵션

- dryRun : 지정된 옵션에 따라 복원시 노출되는 오류 및 단계를 보여준다. 

              단 실제 복원은 하지 않는다. (기본값 false)

- threads : 복원시 사용할 스레드 수 (기본값 4)

- progressFile : 덤프 로드 유틸리티의 진행 생태 저장 파일의 위치 

- showProgress : 복원 진행 정보를 표시할지 여부 (기본값 true)

- resetProgress : true 로 지정시 복원을 처음부터 다시 한다. 

                      복원시 미리 생성되어 있는 중복 오브젝트(디비, 테이블 등등)에 대한 제거를 하지 않는다.

                      수동으로 지워줘야 한다. 

- waitDumpTimeout : 덤프 위치에 업로드된 모든 데이터 청크를 처리후 유틸리티가 추가 데이터를 기다리는

                             제한 시간(초)을 지정하여 동시 로드 활성화 (기본값 0)

- ignoreExistingObjects : true 로 지정시 복원중 중복객체 발견시 계속 진행 (기본값 false)

                                 false 로 지정시 중복 객체 발견시 오류가 발생하고 복원을 중지한다. 

- ignoreVersion : 덤프된 MySQL 과, 복원할 MySQL 의 주 버전 번호가 다를 경우 덤프를 가져올지 여부 (기본값 false)

- showMetadata : 덤프에 포함된 덤프 메타 데이터를 출력할지 여부 

- updateGtidSet [off, append, replace] : 덤프 메타 데이터에 기록된 GTID 를 적용할지 여부 및 적용 방식 (기본값 off)

- skipBinlog : true 로 지정시 SET sql_log_bin=0  를 실행하여 복원시에 사용되는 명령어를

                  바이너리 로그에 저장하지 않는다. (기본값 false)

- loadIndexes : false 지정시 복원 대상 테이블의 보조 인덱스를 생성하지 않는다. (기본값 true)

- deferTableIndexes : 보조 인덱스 생성 시점 

                            off : 테이블 로드중에 모든 인덱스 생성 

                            fulltext : fulltext 인덱스만 테이블 로드후 인덱스 생성 

                            all : 테이블 로드시에는 pk 만 생성하고 나머지 인덱스는 로드후 생성 

- analyzeTables : 테이블 로드 후 ANALYZE TABLE 실행 여부 (기본값 off)

- characterSet : 복원시 사용할 캐릭터 셋 

- schema : 덤프시 사용할 기본 스키마 

- excludeSchemas : 복원시 제외할 스키마 지정

- includeSchemas : 지정된 스키마만 복원 

- excludeTables : 복원시 제외할 테이블 지정

- includeTables : 지정된 테이블만 복원

- loadDdl : true 로 지정시 DDL 만 복원, 데이터는 복원 안함

- loadData : true 로 지정시 데이터만 복원, DDL 복원 안함 

- loadUsers : 계정 복원 여부 

- excludeUsers : 복원시 제외할 계정 지정

- includeUsers : 지정한 계정만 복원 

- createInvisiblePKs : true 로 지정시 PK 가 없는 테이블 복원시 PK 추가 

복원 테스트 

이전에 백업한것으로 복원테스트 (역시 백업/복원 속도는 xtrabackup 이 최고다. util.loadDump 는 복원 속도가 아쉽다.)

local_infile 이 on 으로 지정안되서 에러 발생 

set global general_log = on; 후 다시 시도

4 thds loading 지정한 thread 수만큼 덤프 파일을 로딩한다. (PC에 hyper-v로 테스트 하는거라 thread 4로 지정)

VM 인거 감안하고 3시간 39분..  ㅡ_ㅡ);;

general_log 와 진행 상태 파일을 열어보자

먼저 진행 상태 파일  DDL , DATA 로드 등의 정보가 기록되어 있다. 

general_log  특별한게 없다. 

참고 

https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-load-dump.html

나의 잔차 삼천리자전거 칼라스 20의 크랭크 3단이 휘어서 교체하기로 맘먹고

알리익스프레이스에서 크랭크, 패달, 스프라켓, 관련된 공구를 구매하고 

외장형 비비는 시마노 sm-bb52 로 구매

알리에서 구매한 물품들이 하나씩 도착하고 드디어 패달, 크랭크 분리완료!

문제는 사각 비비가 안풀렸다. 

자전거 동호회에 찾아보니 자전거 공구는 대만산정도는 써야된다고 한다.

그래 공구를 다시 사는거야.

비비푸는 공구를 대만산으로 구매하고 도전!!!!! 

안된다. ㅡ_ㅡ);; 

결국 카센터에 가서 임팩렌치로 한방에 풀었다. 

이때만해도 모든게 쉽게 될것 같았다.

문제는 외장형 비비 장착이 안된다.

돌려서 끼우는데 완전히 안들어간다.

기존의 사각 비비와 크기 비교를 해봤는데 크기는 동일하다.

그런데 나사산의 모양이 미묘하게 다르다.

외장형 비비를 다른걸로 주문하고 다시 시도하기로 

오늘은 접자..

util.dumpInstance 을 사용할때 pk가 없는경우 chunk 단위가 병렬 dump 가 아니라 하나의 파일로 dump 한다고 했다.

진짜 그런지 해보자.

먼저 테스트용으로 조금 큰 DB가 필요하다. 

아래 링크에서 다운받은 파일들로 14G 짜리 DB를 만들 수 있다. 

https://northcoder.com/post/using-imdb-as-test-data-set/

title 테이블의 데이터로 pk, 인덱스가 없는 title_bak 테이블을 만든다.

util.dumpInstance('/root/backup',{threads:4}) 로 백업을 하면 아래와 같은 메시지가 나온다. 

사요할 수 있는 인덱스가 없어서 Chunking 을 못한다. 

thread 4개로 덤프한다는 메시지 이외에는 특별한 메시지는 없다. 

제러럴 로그를 보면 dump 하면서 아래의 항목들을 확인한다. 

- DB

- 테이블

- 테이블 정보 (컬럼명, 데이터 타입)

- 테이블 PK 

- 컬럼 통계

- DB 계정

- 사용하지 않는 DB계정 (패스워드 미설정, 만료상태, 잠금상태)

- 이벤트

- 프로시저, 함수

- 트리거 

- 백업 실행 계정의 보유 권한

- 플러그인 상태 

- NDBCLUSTER 사용 여부

- 백업 실행 계정의 스키마, 테이블 권한 

- 백업 실행 계정의 기본 role 

이제 백업을 시작한다. 

- SHOW CREATE USER 계정
- SHOW GRANTS FOR  계정
- SHOW CREATE DATABASE IF NOT EXISTS 디비

여기서 부터는 지정한 thread 수의 thread 가 진행한다. 

- show create table 테이블

- show fields from 테이블 

※ pk가 있고 없는 title, title_bak 테이블을 비교한다. 

title 테이블 

- 테이블 PK 의 MIN/MAX 값 확인 

- SELECT SQL_NO_CACHE MIN(`title_id`), MAX(`title_id`) FROM `imdb`.`title`
- SELECT SQL_NO_CACHE `title_id` FROM `imdb`.`title` ORDER BY `title_id` LIMIT 0,1 /* mysqlsh dumpInstance, chunking table `imdb`.`title`, chunk ID: 0 */

- SELECT SQL_NO_CACHE `title_id` FROM `imdb`.`title` ORDER BY `title_id` LIMIT 695651,1 /* mysqlsh dumpInstance, chunking table `imdb`.`title`, chunk ID: 0 */

chunk ID: 1 ~ 11까지 아래와 같은 쿼리가 실행된다. 

pk 값으로 chunk 를 나눌 범위를 구하는듯.

SELECT SQL_NO_CACHE `title_id` FROM `imdb`.`title` WHERE `title_id` > 'tt0718077' ORDER BY `title_id` LIMIT 0,1 /* mysqlsh dumpInstance, chunking table `imdb`.`title`, chunk ID: 1 */
SELECT SQL_NO_CACHE `title_id` FROM `imdb`.`title` WHERE `title_id` > 'tt0718077' ORDER BY `title_id` LIMIT 695651,1 /* mysqlsh dumpInstance, chunking table `imdb`.`title`, chunk ID: 1 */

SELECT SQL_NO_CACHE `title_id` FROM `imdb`.`title` WHERE `title_id` > 'tt10740924' ORDER BY `title_id` LIMIT 0,1 /* mysqlsh dumpInstance, chunking table `imdb`.`title`, chunk ID: 2 */
SELECT SQL_NO_CACHE `title_id` FROM `imdb`.`title` WHERE `title_id` > 'tt10740924' ORDER BY `title_id` LIMIT 695651,1 /* mysqlsh dumpInstance, chunking table `imdb`.`title`, chunk ID: 2 */

....

SELECT SQL_NO_CACHE `title_id` FROM `imdb`.`title` WHERE `title_id` > 'tt9348300' ORDER BY `title_id` LIMIT 0,1 /* mysqlsh dumpInstance, chunking table `imdb`.`title`, chunk ID: 11 */
SELECT SQL_NO_CACHE `title_id` FROM `imdb`.`title` WHERE `title_id` > 'tt9348300' ORDER BY `title_id` LIMIT 695651,1 /* mysqlsh dumpInstance, chunking table `imdb`.`title`, chunk ID: 11 */

위에서 확인한 pk 값으로 chunk 를 나누어서 덤프 

SELECT SQL_NO_CACHE `title_id`,`content_type_id`,`primary_title`,`original_title`,`is_adult`,`start_year`,`end_year`,`runtime_minutes` FROM `imdb`.`title` WHERE `title_id` BETWEEN 'tt0000001' AND 'tt0718077' OR `title_id` IS NULL ORDER BY `title_id` /* mysqlsh dumpInstance, dumping table `imdb`.`title`, chunk ID: 0 */
SELECT SQL_NO_CACHE `title_id`,`content_type_id`,`primary_title`,`original_title`,`is_adult`,`start_year`,`end_year`,`runtime_minutes` FROM `imdb`.`title` WHERE `title_id` BETWEEN 'tt0718078' AND 'tt10740924' ORDER BY `title_id` /* mysqlsh dumpInstance, dumping table `imdb`.`title`, chunk ID: 1 */

....

SELECT SQL_NO_CACHE `title_id`,`content_type_id`,`primary_title`,`original_title`,`is_adult`,`start_year`,`end_year`,`runtime_minutes` FROM `imdb`.`title` WHERE `title_id` BETWEEN 'tt9348302' AND 'tt9916880' ORDER BY `title_id` /* mysqlsh dumpInstance, dumping table `imdb`.`title`, chunk ID: 11 */

백업 디렉토리에는 아래와 같이 11개의 파일이 생성되었다. 

title_bak 테이블 

title_bak 테이블은 그냥 전체 덤프한다. 

SELECT SQL_NO_CACHE `title_id`,`content_type_id`,`primary_title`,`original_title`,`is_adult`,`start_year`,`end_year`,`runtime_minutes` FROM `imdb`.`title_bak` /* mysqlsh dumpInstance, dumping table `imdb`.`title_bak`, chunk ID: 1 */

백업 파일도 아래와 같이 1개로 생성된다. (데이터 파일 기준)

테스트한 general log와 util.dumpInstance log