■ mysqlsh를 이용한 데이터 덤프 및 엑스포트 방법
앞에서 util.dumpTable, util.exportTable 이 2가지를 이용하여 엑스포트 및 로드를 해보았습니다.
https://myinfrabox.tistory.com/278
[MySQL] mysqlsh의 util.exportTable, util.importTable를 이용하여 덤프 및 임포트하기
■ mysqlsh를 이용한 데이터 덤프 및 엑스포트 방법 테이블 엑스포트 및 덤프 방법은 util.exportTable 및 util.importTable을 이용하여 하는 방법이 있습니다. 참고로 util.dumpTable(), util.dumpTable(), util.exportTabl
myinfrabox.tistory.com
이번에는 레벨별로 덤프가 가능한 util.dumpInstance, util.dumpSchemas, util.dumpTables를 알아보고 덤프한 내용들을 로드하는 util.loadDump에 대해 알아보겠습니다.
참고로 util.dumpTable(), util.dumpTable(), util.exportTable()을 이용하는 방법보다 더 최근의 방법입니다.
레벨별로 덤프하는 옵션이나 방법은 크게 다르지 않습니다. 원하는 레벨에 맞춰 덤프 후 로드하면 됩니다.
■ util.dumpInstance, util.dumpSchemas, util.dumpTables 및 util.loadDump을 이용하여 데이터 엑스포트 및 로드를 할시 장점
select... into outfile로 엑스포트 하는것보다 속도가 훨씬 더 빠릅니다.
마찬가지로 로드시 스레드를 몇개 만들어 병렬로 로드하기 때문에 로드또한 훨씬 빠릅니다.
또한 레벨별로 덤프를 지원하기 때문에 훨씬 더 덤프 전략에 맞게 최적화하여 사용할 수 있습니다.
그리고 멀티스레드로 동작이 가능합니다.
■ 테스트 환경
참고로 모든 데이터 및 덤프는 sysbench에서 생성한 sbtest로 테스트합니다. 사용방법은 다음 포스트의 맨아래 벤치마크 방법을 참고해서 생성합니다.
https://myinfrabox.tistory.com/65
■ 덤프 프로그램 소개
명령어는 다음과 같습니다. 그리고 명령문은 어떤 레벨로 덤프를 실행하는지 유추해 볼 수 있습니다.
util.dumpInstance(outputUrl[, options]) : 전체 인스턴스 레벨
util.dumpSchemas(schemas, outputUrl[, options]) : 스키마 레벨
util.dumpTables(schema, tables, outputUrl[, options]) : 테이블 레벨
■ 옵션 설명
먼저 옵션을 설명 후 사용방법에 대해 알아보겠습니다.
▶︎ 덤프 제어를 위한 옵션
• dryRun: [ true | false ]
지정된 옵션 세트로 덤프될 내용에 대한 정보를 표시하지만 덤프를 진행하지는 않습니다. 이 옵션을 설정하면 덤프를 시작하기 전에 모든 호환성 문제를 나열할 수 있습니다. 기본값은 false입니다.
• showProgress: [ true | false ]
덤프에 대한 진행 정보를 표시(true)하거나 숨기기(false)합니다. MySQL Shell이 대화형 모드일 때와 같이 stdout이 터미널(tty)인 경우 기본값은 true이고, 그렇지 않은 경우 false입니다. 진행률 정보에는 덤프할 예상 총 행수, 지금까지 덤프된 행 수, 완료율, 초당 행 및 바이트 단위의 처리량이 표시됩니다.
• thread: int
MySQL 인스턴스에서 데이터 청크를 덤프하는 데 사용할 병렬 스레드 수입니다. 각 스레드에는 MySQL 인스턴스에 대한 자체 연결이 있습니다. 기본값은 4입니다.
• maxRate: "string"
덤프중 데이터 읽기 처리량에 대한 스레드당 초당 최대 바이트 수입니다. 단위 접미사 k는 킬로바이트, M은 메가바이트, G는 기가바이트를 사용할 수 있습니다. 예를 들어 100M을 설정하면 처리량이 스레드당 초당 100MB로 제한됩니다. 0(기본값)을 설정하거나 옵션을 빈 문자열로 설정하면 제한이 설정되지 않음을 의미합니다.
• defaultCharacterSet: "string"
덤프를 위해 MySQL Shell에서 서버로 열리는 세션 연결 중에 사용되는 문자 집합입니다. 기본값은 utf8mb4입니다. 시스템 변수 Character_set_client, Character_set_connection 및 Character_set_results의 세션 값은 각 연결에 대해 이 값으로 설정됩니다. 문자 세트는 Character_set_client 시스템 변수에서 허용되고 MySQL 인스턴스에서 지원되어야 합니다.
• consistent: [ true | false ]
덤프 중에 백업을 위해 인스턴스를 잠가 일관된 데이터 덤프를 활성화(true)하거나 비활성화(false)합니다. 기본값은 true입니다.
true가 설정된 경우 유틸리티는 FLUSH TABLES WITH READ LOCK 문(유틸리티를 실행하는 데 사용된 사용자 ID에 RELOAD 권한이 있는 경우)을 사용하여 전역 읽기 잠금을 설정하거나 LOCK TABLES 문(사용자가 ID에는 RELOAD 권한이 없지만 LOCK TABLES 권한이 있습니다. 각 스레드에 대한 트랜잭션은 SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 및 START TRANSACTION WITH CONSISTENT SNAPSHOT 문을 사용하여 시작됩니다. 모든 스레드가 트랜잭션을 시작하면 백업을 위해 인스턴스가 잠기고(LOCK INSTANCE FOR BACKUP 및 UNLOCK INSTANCE 문에 설명된 대로) 전역 읽기 잠금이 해제됩니다.
MySQL Shell 8.0.29부터 사용자 계정에 BACKUP_ADMIN 권한이 없고 LOCK INSTANCE FOR BACKUP을 실행할 수 없는 경우 유틸리티는 덤프 중에 추가 일관성 검사를 수행합니다. 이 확인이 실패하면 인스턴스 덤프는 중지되지만 스키마 덤프 또는 테이블 덤프는 계속되고 오류 메시지를 반환하여 일관성 확인이 실패했음을 사용자에게 알립니다.
• SkipConsistencyChecks: [ true | false ]
consistent : true 있을 때 수행되는 추가 일관성 확인을 활성화(true) 또는 비활성화(false)합니다. 기본값은 false입니다.
consistent : false일 경우 이 옵션은 무시됩니다.
▶︎ 덤프 출력 옵션
• tzUtc: [ true | false ]
덤프 시작 부분에 명령문을 포함하여 시간대를 UTC로 설정합니다. 덤프 출력의 모든 타임스탬프 데이터는 이 시간대로 변환됩니다. 기본값은 true이므로 타임스탬프 데이터는 기본적으로 변환됩니다. 시간대를 UTC로 설정하면 시간대가 다른 서버 간에 데이터를 이동하거나 시간대가 여러 개인 데이터 세트를 처리하는 것이 쉬워집니다. 원하는 경우 원래 타임스탬프를 유지하려면 이 옵션을 false로 설정하세요.
• compression: "string"
덤프용 데이터 파일을 쓸 때 사용할 압축 유형입니다. 기본값은 zstd 압축(zstd)을 사용하는 것입니다. 대안은 gzip 압축(gzip)을 사용하거나 압축하지 않음(none)을 사용하는 것입니다.
• chunking: [ true | false ]
각 테이블의 데이터를 여러 파일로 분할하는 테이블 데이터 chunking을 활성화(true)하거나 비활성화(false)합니다. 기본값은 true이므로 기본적으로 chunking이 활성화됩니다. chunk 크기를 지정하려면 bytesPerChunk를 사용하세요. 청킹 옵션을 false로 설정하면 청킹이 발생하지 않으며 유틸리티는 각 테이블에 대해 하나의 데이터 파일을 생성합니다.
MySQL Shell 8.0.32 이전에는 테이블 데이터를 별도의 파일로 chunk하려면 유틸리티가 데이터를 정렬하고 chunking하기 위해 인덱스 열을 선택하는 데 사용하는 테이블에 대해 Primary Key 또는 Unique 인덱스를 정의해야 합니다. 테이블에 이들중 어느 것도 포함되어 있지 않으면 경고가 표시되고 테이블 데이터가 단일 파일에 기록됩니다.
MySQL Shell 8.0.32부터 테이블에 Primary 키나 Unique 인덱스가 없는 경우 테이블의 행 수, 평균 행 길이 및 bytesPerChunk 값을 기반으로 청킹이 수행됩니다.
• bytesPerChunk: "string"
chunking이 활성화된 경우 각 데이터 파일에 기록될 대략적인 바이트 수를 설정합니다. 단위 접미사 k는 킬로바이트, M은 메가바이트, G는 기가바이트를 의미합니다. 기본값은 MySQL Shell 8.0.22에서 64MB(64M)(MySQL Shell 8.0.21에서는 32MB)이고 최소값은 128KB(128k)입니다. 이 옵션을 지정하면 chunking이 암시적으로 true로 설정됩니다. 이 유틸리티는 압축이 적용되기 전에 각 테이블의 데이터를 이 양의 데이터가 포함된 파일로 chunk하는 것을 목표로 합니다. chunk 크기는 평균이며 테이블 통계 및 계획 설명 설명을 기반으로 계산됩니다.
• dialect: [default|csv|csv-unix|tsv]
(MySQL Shell 8.0.32에 추가됨) 내보낸 데이터 파일의 형식에 대한 필드 및 줄 처리 옵션 세트를 지정합니다. 설정을 변경하기 위해 lineTerminatingBy, fieldsTerminatingBy, fieldsEnclosedBy, fieldsOptionallyEnclosed 및 fieldsEscapedBy 옵션 중 하나 이상을 지정하여 선택한 dialect에 추가 사용자 정의를 위한 기반으로 사용할 수도 있습니다.
기본 dialect는 해당 문의 기본 설정과 함께 SELECT...INTO OUTFILE 문을 사용하여 생성된 것과 일치하는 데이터 파일을 생성합니다. .txt는 이러한 출력 파일에 할당하기에 적합한 파일 확장자입니다. DOS 또는 UNIX 시스템용 CSV 파일(.csv) 및 TSV 파일(.tsv)을 내보내는 데 다른 방언을 사용할 수 있습니다.
각 dialect에 적용되는 설정은 다음과 같습니다.
표. 테이블 덤프 유틸리티의 dialect 설정
| dialect | linesTerminatedBy | fieldsTerminatedBy | fieldsEnclosedBy | fieldsOptionallyEnclosed | fieldsEscapedBy |
| default | [LF] | [TAB] | [empty] | false | \ |
| csv | [CR][LF] | , | '' | ture | \ |
| csv-unix | [LF] | , | '' | false | \ |
| tsv | [CR][LF] | [TAB] | '' | true | \ |
• lineTerminatingBy: "string"
(MySQL Shell 8.0.32에 추가됨) 유틸리티가 내보낸 데이터 파일의 각 줄을 종료하는 데 사용되는 하나 이상의 문자(또는 빈 문자열)입니다. 기본값은 지정된 dialect와 동일하며, dialect 옵션이 생략된 경우 줄 바꿈 문자(\n)입니다. 이 옵션은 SELECT...INTO OUTFILE 문의 LINES TERMINATED BY 옵션과 동일합니다. 유틸리티는 빈 문자열로 설정된 SELECT...INTO OUTFILE 문의 LINES STARTING BY 옵션에 해당하는 옵션을 제공하지 않습니다.
• fieldsTerminatingBy: "string"
(MySQL Shell 8.0.32에 추가됨) 유틸리티가 내보낸 데이터 파일의 각 필드를 종료하는 데 사용되는 하나 이상의 문자(또는 빈 문자열)입니다. 기본값은 지정된 dialect와 동일하며, 방언 옵션이 생략된 경우 탭 문자(\t)입니다. 이 옵션은 SELECT...INTO OUTFILE 문의 FIELDS TERMINATED BY 옵션과 동일합니다.
• fieldsEnclosedBy: "string"
(MySQL Shell 8.0.32에 추가됨) 유틸리티가 내보낸 데이터 파일의 각 필드를 묶는 단일 문자(또는 빈 문자열)입니다. 기본값은 지정된 dialect와 동일하며, dialect 옵션이 생략된 경우 빈 문자열입니다. 이 옵션은 SELECT...INTO OUTFILE 문의 FIELDS ENCLOSED BY 옵션과 동일합니다.
• fieldsOptionallyEnclosed: [ true | false ]
(MySQL Shell 8.0.32에 추가됨) fieldsEnclosedBy에 지정된 문자가 내보낸 데이터 파일의 모든 필드를 묶는 것인지(false), 아니면 CHAR, BINARY와 같은 문자열 데이터 유형이 있는 경우에만 필드를 묶는 것인지 여부입니다. TEXT 또는 ENUM(참). 기본값은 지정된 dialect과 동일하며, dialect 옵션이 생략된 경우 false입니다. 이 옵션을 사용하면 fieldsEnclosedBy 옵션이 SELECT...INTO OUTFILE 문의 FIELDS OPTIONALLY ENCLOSED BY 옵션과 동일해집니다.
• fieldsEscapedBy: "string"
(MySQL Shell 8.0.32에 추가됨) 내보낸 데이터 파일에서 이스케이프 시퀀스를 시작하는 문자입니다. 기본값은 지정된 dialect와 동일하며, dialect 옵션이 생략된 경우 백슬래시(\)입니다. 이 옵션은 SELECT...INTO OUTFILE 문의 FIELDS ESCAPED BY 옵션과 동일합니다. 이 옵션을 빈 문자열로 설정하면 문자가 이스케이프되지 않습니다. 이는 SELECT...INTO OUTFILE에서 사용하는 특수 문자를 이스케이프해야 하기 때문에 권장되지 않습니다.
▶︎ 필터링 옵션
• where :
유효한 테이블 식별자(schemaName.tableName 형식)와 내보내는 데이터를 필터링하는 데 사용되는 유효한 SQL 조건 표현식으로 구성된 키-값 쌍입니다.
참고로 SQL은 실행될 때만 유효성이 검사됩니다. 많은 테이블을 내보내는 경우 SQL 구문 관련 문제는 프로세스 후반에만 표시됩니다. 따라서 장기 실행 내보내기 프로세스에서 SQL 조건을 사용하기 전에 SQL 조건을 테스트하는 것이 좋습니다.
다음 예에서는 actor_id 값이 150보다 큰 tablesakila.actor 및 sakila.actor_info의 행만 이름이 지정된 로컬 폴더로 내보냅니다.
util.dumpTables("sakila", ["actor","actor_info"], "out",
{"where" :
{"sakila.actor": "actor_id > 150", "sakila.actor_info": "actor_id > 150"}})
• partition : ["string","string",..]
지정된 파티션으로 내보내기를 제한하는 유효한 파티션 이름 목록입니다.
예를 들어 p1 및 p2라는 파티션만 내보내려면 partitions: ["p1", "p2"]
다음 예에서는 table1에서 파티션 p1 및 p2를 내보내고 table2에서 파티션 p2를 내보냅니다.
util.dumpTables("schema", ["table","table2"], "out", {"partitions" :
{ "schema.table1": ["p1", "p2"],"schema.table2": ["p1"]}})
• ddlOnly: [ true | false ]
이 옵션을 true로 설정하면 덤프안에 덤프된 항목에 대한 DDL 파일만 포함되고 데이터는 덤프되지 않습니다. 기본값은 false입니다.
• dataOnly: [ true | false ]
이 옵션을 true로 설정하면 덤프에안에 덤프된 항목에 대한 데이터 파일만 포함되고 DDL 파일은 포함되지 않습니다. 기본값은 false입니다.
• users: [ true | false ]
(인스턴스 덤프 유틸리티에만 해당) 덤프에 user와 해당 role 및 grant를 포함(true)하거나 제외(false)합니다. 기본값은 true이므로 기본적으로 user가 포함됩니다. 스키마 덤프 유틸리티 및 테이블 덤프 유틸리티는 user, role 및 grant를 덤프에 포함하지 않습니다.
MySQL Shell 8.0.22에서는 extraUsers 또는 includeUsers 옵션을 사용하여 덤프 파일에서 제외하거나 포함할 개별 사용자 계정을 지정할 수 있습니다. 이러한 옵션은 대상 MySQL 인스턴스의 요구 사항에 따라 가져오기 시점에 개별 사용자 계정을 제외하거나 포함하기 위해 MySQL 셸의 덤프 로딩 유틸리티 util.loadDump()와 함께 사용할 수도 있습니다.
• excludeUsers: array of strings (인스턴스 덤프 유틸리티에만 해당)
덤프 파일에서 작성된 사용자 계정을 제외합니다. 이 옵션은 MySQL Shell 8.0.22에서 사용할 수 있으며, 이를 사용하여 MySQL DB 시스템으로 가져오기가 허용되지 않거나 대상 MySQL 인스턴스에 이미 존재하거나 원하지 않는 사용자 계정을 제외할 수 있습니다. 사용자 이름과 호스트 이름으로 정의된 계정의 경우 "'user_name'@'host_name'" 형식으로, 사용자 이름만으로 정의된 계정의 경우 "'user_name'" 형식으로 각 사용자 계정 문자열을 지정합니다. 호스트 이름을 제공하지 않으면 해당 사용자 이름을 가진 모든 계정이 제외됩니다.
• includeUsers: array of strings (인스턴스 덤프 유틸리티에만 해당)
덤프 파일에는 작성된 사용자 계정만 포함됩니다. 제외사용자 옵션과 마찬가지로 각 사용자 계정 문자열을 지정합니다. 이 옵션은 MySQL Shell 8.0.22에서 사용할 수 있으며, 덤프에 소수의 사용자 계정만 필요한 경우excludeUsers 대신 사용할 수 있습니다. 일부 계정을 포함하고 다른 계정을 제외하도록 두 옵션을 모두 지정할 수도 있습니다.
• excludeSchemas: array of strings (인스턴스 덤프 유틸리티에만 해당)
덤프에서 작성된 스키마를 제외합니다. information_schema, mysql, ndbinfo,performance_schema 및 sys 스키마는 항상 인스턴스 덤프에서 제외됩니다.
• includeSchemas: array of strings (인스턴스 덤프 유틸리티에만 해당)
덤프에는 작성된 스키마만 포함됩니다. 이 옵션은 MySQL Shell 8.0.28에서 사용할 수 있습니다. 이 옵션에서 이름을 지정하여 information_schema, mysql, ndbinfo,performance_schema 또는 sys 스키마를 포함할 수 없습니다. 이러한 스키마중 하나 이상을 덤프하려면 스키마 덤프 유틸리티 util.dumpSchemas()를 사용하면 됩니다.
• includeTables: array of strings (인스턴스 덤프 유틸리티 및 스키마 덤프 유틸리티에만 해당)
덤프에서 명명된 테이블을 제외합니다. 테이블 이름은 유효한 스키마 이름으로 한정되어야 하며 필요한 경우 backtick(`) 문자로 인용되어야 합니다. includeTables 옵션으로 명명된 테이블에는 덤프에 DDL 파일이나 데이터 파일이 없습니다. mysql.apply_status, mysql.general_log, mysql.schema 및 mysql.slow_log 테이블의 데이터는 해당 DDL 문이 포함되어 있더라도 항상 스키마 덤프에서 제외되며, 다른 테이블에 테이블 이름을 지정하여 해당 데이터를 포함할 수 없습니다. 옵션 또는 유틸리티.
■ 덤프 방법 - 레벨별 덤프
덤프시 어떤 일련의 작업들을 MySQL이 하는지 알고 싶다면 general_log를 on해줍니다.
로그 내용중 주요 내용을 확인해보면
FLUSH NO_WRITE_TO_BINLOG TABLES
FLUSH TABLES WITH READ LOCK
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
START TRANSACTION WITH CONSISTENT SNAPSHOT
먼저 Flush 명령을 통해 BINLOG를 내려쓰고, Read Lock 모드로 테이블 모드를 변경합니다.
트랜잭션 레벨을 REPEATABLE READ로 만들어 팬텀읽기를 방지함과 동시에 TRANSACTION WITH CONSISTENT SNAPSHOT으로 트랜잭션을 시작해서 일관성을 보장하도록 설정합니다.
이외에도 다양한 로그가 발생됩니다. 확인해보시면 mysqlshell에서 어떻게 덤프를 실행하는지 확인해볼 수 있습니다.
▶︎ util.dumpInstance - 인스턴스 레벨 덤프
인스턴스에 대해 엑스포트를 수행하게 되면 전체 스키마 및 테이블에 대한 정보를 포함한 json파일 및 압축한 데이터 파일과 인덱스 파일을 엑스포트하게 됩니다.
참고로 위의 옵션에서 설명한것처럼 information_schema, mysql, ndbinfo,performance_schema 및 sys 스키마는 제외됩니다.
덤프받을 위치의 디렉토리에는 파일이 존재해서는 안됩니다.
• 옵션 설명
mysql-js > util.dumpInstance("dump directory path",
{option_1,
option_2,
option_2});
dump direcotory path : 덤프할 디렉토리를 지정합니다.
option_x : 선택적 옵션들을 설정합니다.
• 덤프 방법
mysql-js > util.dumpInstance("/root/dumpInstance",
{threads: 8,
showProgress: true,
fieldsOptionallyEnclosed: true,
fieldsTerminatedBy: ",",
linesTerminatedBy: "\n",
fieldsEnclosedBy: '"'});
Acquiring global read lock
Global read lock acquired
Initializing - done
4 out of 8 schemas will be dumped and within them 13 tables, 0 views.
9 out of 12 users will be dumped.
Gathering information - done
All transactions have been started
Locking instance for backup
Global read lock has been released
Writing global DDL files
Writing users DDL
WARNING: User 'orc_tpl'@'%' has a grant statement on an object which is not included in the dump (GRANT SELECT ON `mysql`.`slave_master_info` TO `orc_tpl`@`%`)
WARNING: User 'repl'@'%' has a grant statement on an object which is not included in the dump (GRANT SELECT ON `mysql`.* TO `repl`@`%`)
Running data dump using 8 threads.
NOTE: Progress information uses estimated values and may not be accurate.
Writing schema metadata - done
Writing DDL - done
Writing table metadata - done
Starting data dump
104% (25.00M rows / ~24.03M rows), 171.09K rows/s, 35.98 MB/s uncompressed, 16.27 MB/s compressed
Dump duration: 00:03:40s
Total duration: 00:03:40s
Schemas dumped: 4
Tables dumped: 13
Uncompressed data size: 4.99 GB
Compressed data size: 2.26 GB
Compression ratio: 2.2
Rows written: 25000008
Bytes written: 2.26 GB
Average uncompressed throughput: 22.62 MB/s
Average compressed throughput: 10.23 MB/s
• 덤프중 스레드 확인
8개의 스레드가 덤프를 받는것을 확인할 수 있습니다.
mysql-sql> show processlist;
+-------+-----------------+---------------------+--------+------------------+---------+-----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-------+-----------------+---------------------+--------+------------------+---------+-----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
...
| 25115 | root | localhost | sbtest | Query | 8 | Sending to client | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest3` WHERE (`id` BETWEEN 625001 AND 937500 |
| 25116 | root | localhost | imp | Query | 15 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest6` WHERE (`id` BETWEEN 2187501 AND 25000 |
| 25117 | root | localhost | sbtest | Query | 9 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest3` WHERE (`id` BETWEEN 1 AND 312500) ORD |
| 25118 | root | localhost | sbtest | Query | 6 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest3` WHERE (`id` BETWEEN 937501 AND 125000 |
| 25119 | root | localhost | sbtest | Query | 3 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest3` WHERE (`id` BETWEEN 1562501 AND 18750 |
| 25120 | root | localhost | sbtest | Query | 1 | statistics | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest3` WHERE (`id` BETWEEN 1875001 AND 21875 |
| 25121 | root | localhost | sbtest | Query | 6 | Sending to client | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest3` WHERE (`id` BETWEEN 1250001 AND 15625 |
| 25122 | root | localhost | sbtest | Query | 8 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest3` WHERE (`id` BETWEEN 312501 AND 625000 |
| 25125 | root | localhost | NULL | Query | 0 | init | show processlist |
+-------+-----------------+---------------------+--------+------------------+---------+-----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
• 파일 리스트
스키마 정보, 유저정보, 덤프정보등이 json 파일에 저장됩니다. 그리고 확장자가 zst인 파일이 데이터 파일이 압축된 파일이고 idx파일은 통계정보 및 인덱스에 관련된 파일입니다.
shell > ls -al
total 2203872
drwxr-xr-x 2 root root 12288 Feb 24 22:31 .
drwx------ 10 root root 4096 Feb 24 22:03 ..
-rw-r----- 1 root root 4516 Feb 24 22:31 @.done.json
-rw-r----- 1 root root 1404 Feb 24 22:27 @.json
-rw-r----- 1 root root 9 Feb 24 22:27 meta@cluster@@0.txt.zst
-rw-r----- 1 root root 8 Feb 24 22:27 meta@cluster@@0.txt.zst.idx
-rw-r----- 1 root root 648 Feb 24 22:27 meta@cluster.json
-rw-r----- 1 root root 819 Feb 24 22:27 meta@cluster.sql
-rw-r----- 1 root root 93 Feb 24 22:27 meta@datacenter@0.txt.zst
-rw-r----- 1 root root 8 Feb 24 22:27 meta@datacenter@0.txt.zst.idx
-rw-r----- 1 root root 9 Feb 24 22:27 meta@datacenter@@1.txt.zst
-rw-r----- 1 root root 8 Feb 24 22:27 meta@datacenter@@1.txt.zst.idx
-rw-r----- 1 root root 613 Feb 24 22:27 meta@datacenter.json
-rw-r----- 1 root root 742 Feb 24 22:27 meta@datacenter.sql
-rw-r----- 1 root root 347 Feb 24 22:27 meta.json
-rw-r----- 1 root root 544 Feb 24 22:27 meta.sql
-rw-r----- 1 root root 226 Feb 24 22:27 paulinus.json
-rw-r----- 1 root root 568 Feb 24 22:27 paulinus.sql
-rw-r----- 1 root root 270 Feb 24 22:27 pdb.json
-rw-r----- 1 root root 21 Feb 24 22:27 pdb@ptb@0.txt.zst
-rw-r----- 1 root root 8 Feb 24 22:27 pdb@ptb@0.txt.zst.idx
-rw-r----- 1 root root 9 Feb 24 22:27 pdb@ptb@@1.txt.zst
-rw-r----- 1 root root 8 Feb 24 22:27 pdb@ptb@@1.txt.zst.idx
-rw-r----- 1 root root 577 Feb 24 22:27 pdb@ptb.json
-rw-r----- 1 root root 653 Feb 24 22:27 pdb@ptb.sql
-rw-r----- 1 root root 538 Feb 24 22:27 pdb.sql
-rw-r----- 1 root root 240 Feb 24 22:27 @.post.sql
-rw-r----- 1 root root 795 Feb 24 22:27 sbtest.json
-rw-r----- 1 root root 28295349 Feb 24 22:28 sbtest@sbtest10@0.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:28 sbtest@sbtest10@0.txt.zst.idx
-rw-r----- 1 root root 28204669 Feb 24 22:29 sbtest@sbtest10@1.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:29 sbtest@sbtest10@1.txt.zst.idx
-rw-r----- 1 root root 28206879 Feb 24 22:29 sbtest@sbtest10@2.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:29 sbtest@sbtest10@2.txt.zst.idx
-rw-r----- 1 root root 28183217 Feb 24 22:29 sbtest@sbtest10@3.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:29 sbtest@sbtest10@3.txt.zst.idx
-rw-r----- 1 root root 28174475 Feb 24 22:29 sbtest@sbtest10@4.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:29 sbtest@sbtest10@4.txt.zst.idx
-rw-r----- 1 root root 28180893 Feb 24 22:29 sbtest@sbtest10@5.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:29 sbtest@sbtest10@5.txt.zst.idx
-rw-r----- 1 root root 28179679 Feb 24 22:29 sbtest@sbtest10@6.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:29 sbtest@sbtest10@6.txt.zst.idx
-rw-r----- 1 root root 28181387 Feb 24 22:30 sbtest@sbtest10@@7.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:30 sbtest@sbtest10@@7.txt.zst.idx
-rw-r----- 1 root root 638 Feb 24 22:27 sbtest@sbtest10.json
-rw-r----- 1 root root 843 Feb 24 22:27 sbtest@sbtest10.sql
-rw-r----- 1 root root 28292292 Feb 24 22:30 sbtest@sbtest1@0.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:30 sbtest@sbtest1@0.txt.zst.idx
......
▶︎ util.dumpSchema
특정 스키마에 대해 엑스포트를 수행하게 되면 전체 스키마 및 테이블에 대한 정보를 포함한 json파일 및 압축한 데이터 파일과 인덱스 파일을 엑스포트하게 됩니다.
참고로 위의 옵션에서 설명한것처럼 information_schema, mysql, ndbinfo,performance_schema 및 sys 스키마는 제외됩니다.
덤프받을 위치의 디렉토리에는 파일이 존재해서는 안됩니다.
• 옵션 설명
mysql-js > util.dumpSchemas(["schema_1", "schema_2"],
"dump directory path",
{option_1,
option_2,
option_3});
schema_1, schema_2 : 덤프할 스키마를 지정합니다.
dump directory path : 덤프할 디렉토리를 지정합니다.
option_x : 선택적 옵션들을 설정합니다.
• 덤프 방법
mysql-js > util.dumpSchemas(["sbtest","meta"],
"/root/dumpSchema",
{threads: 8,
showProgress: true,
fieldsOptionallyEnclosed: true,
fieldsTerminatedBy: ",",
linesTerminatedBy: "\n",
fieldsEnclosedBy: '"'});
Acquiring global read lock
Global read lock acquired
Initializing - done
2 schemas will be dumped and within them 12 tables, 0 views.
Gathering information - done
All transactions have been started
Locking instance for backup
Global read lock has been released
Writing global DDL files
Running data dump using 8 threads.
NOTE: Progress information uses estimated values and may not be accurate.
Writing schema metadata - done
Writing DDL - done
Writing table metadata - done
Starting data dump
104% (25.00M rows / ~24.03M rows), 141.47K rows/s, 28.43 MB/s uncompressed, 12.86 MB/s compressed
Dump duration: 00:03:50s
Total duration: 00:03:50s
Schemas dumped: 2
Tables dumped: 12
Uncompressed data size: 4.99 GB
Compressed data size: 2.26 GB
Compression ratio: 2.2
Rows written: 25000003
Bytes written: 2.26 GB
Average uncompressed throughput: 21.69 MB/s
Average compressed throughput: 9.81 MB/s
• 덤프중 스레드 확인
8개의 스레드가 덤프를 받는것을 확인할 수 있습니다.
mysql-sql> show processlist;
+-------+-----------------+---------------------+--------+------------------+---------+-----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-------+-----------------+---------------------+--------+------------------+---------+-----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
...
| 25028 | root | localhost | NULL | Sleep | 19 | | NULL |
| 25334 | root | localhost | NULL | Sleep | 19 | | NULL |
| 25335 | root | localhost | sbtest | Query | 8 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest6` WHERE (`id` BETWEEN 625001 AND 937500 |
| 25336 | root | localhost | sbtest | Query | 17 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest6` WHERE (`id` BETWEEN 1 AND 312500) ORD |
| 25337 | root | localhost | sbtest | Query | 13 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest6` WHERE (`id` BETWEEN 312501 AND 625000 |
| 25338 | root | localhost | sbtest | Query | 19 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest7` WHERE (`id` BETWEEN 1875001 AND 21875 |
| 25339 | root | localhost | sbtest | Query | 5 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest6` WHERE (`id` BETWEEN 937501 AND 125000 |
| 25340 | root | localhost | sbtest | Query | 19 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest7` WHERE (`id` BETWEEN 1250001 AND 15625 |
| 25341 | root | localhost | sbtest | Query | 0 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest6` WHERE (`id` BETWEEN 1250001 AND 15625 |
| 25342 | root | localhost | sbtest | Query | 19 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest7` WHERE (`id` BETWEEN 1562501 AND 18750 |
| 25346 | root | localhost | NULL | Query | 0 | init | show processlist |
+-------+-----------------+---------------------+--------+------------------+---------+-----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
• 덤프 내용 확인
total 2203820
drwxr-xr-x 2 root root 12288 Feb 24 22:38 .
drwx------ 10 root root 4096 Feb 24 22:03 ..
-rw-r----- 1 root root 4400 Feb 24 22:38 @.done.json
-rw-r----- 1 root root 1064 Feb 24 22:34 @.json
-rw-r----- 1 root root 9 Feb 24 22:38 meta@cluster@@0.txt.zst
-rw-r----- 1 root root 8 Feb 24 22:38 meta@cluster@@0.txt.zst.idx
-rw-r----- 1 root root 648 Feb 24 22:34 meta@cluster.json
-rw-r----- 1 root root 819 Feb 24 22:34 meta@cluster.sql
-rw-r----- 1 root root 93 Feb 24 22:34 meta@datacenter@0.txt.zst
-rw-r----- 1 root root 8 Feb 24 22:34 meta@datacenter@0.txt.zst.idx
-rw-r----- 1 root root 9 Feb 24 22:34 meta@datacenter@@1.txt.zst
-rw-r----- 1 root root 8 Feb 24 22:34 meta@datacenter@@1.txt.zst.idx
-rw-r----- 1 root root 613 Feb 24 22:34 meta@datacenter.json
-rw-r----- 1 root root 742 Feb 24 22:34 meta@datacenter.sql
-rw-r----- 1 root root 347 Feb 24 22:34 meta.json
-rw-r----- 1 root root 544 Feb 24 22:34 meta.sql
-rw-r----- 1 root root 240 Feb 24 22:34 @.post.sql
-rw-r----- 1 root root 795 Feb 24 22:34 sbtest.json
-rw-r----- 1 root root 28295349 Feb 24 22:36 sbtest@sbtest10@0.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:36 sbtest@sbtest10@0.txt.zst.idx
-rw-r----- 1 root root 28204669 Feb 24 22:36 sbtest@sbtest10@1.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:36 sbtest@sbtest10@1.txt.zst.idx
-rw-r----- 1 root root 28206879 Feb 24 22:36 sbtest@sbtest10@2.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:36 sbtest@sbtest10@2.txt.zst.idx
-rw-r----- 1 root root 28183217 Feb 24 22:37 sbtest@sbtest10@3.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:37 sbtest@sbtest10@3.txt.zst.idx
-rw-r----- 1 root root 28174475 Feb 24 22:37 sbtest@sbtest10@4.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:37 sbtest@sbtest10@4.txt.zst.idx
-rw-r----- 1 root root 28180893 Feb 24 22:37 sbtest@sbtest10@5.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:37 sbtest@sbtest10@5.txt.zst.idx
-rw-r----- 1 root root 28179679 Feb 24 22:38 sbtest@sbtest10@6.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:38 sbtest@sbtest10@6.txt.zst.idx
-rw-r----- 1 root root 28181387 Feb 24 22:38 sbtest@sbtest10@@7.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:38 sbtest@sbtest10@@7.txt.zst.idx
-rw-r----- 1 root root 638 Feb 24 22:34 sbtest@sbtest10.json
-rw-r----- 1 root root 843 Feb 24 22:34 sbtest@sbtest10.sql
......
▶︎ util.dumpTables - 테이블 레벨 덤프
테이블에 대해 엑스포트를 수행하게 되면 스키마 및 테이블에 대한 정보를 포함한 json파일 및 압축한 데이터 파일과 인덱스 파일을 엑스포트하게 됩니다.
• 옵션 설명
mysql-js > util.dumpTables("schema", [ "table_1", "table_n" ], "export directory")
util.dumpTables("schema", [], {"all": true})
schema : 엑스포트할 테이블이 포함되어 있는 스키마
table_1 : 엑스포트 할 테이블 리스트
export direcotry : 데이터를 덤프할 디렉토리
• 덤프 방법
mysql-js> util.dumpTables("sbtest",
[ "sbtest1", "sbtest4" ],
"/root/dumpTable",
{threads: 8,
showProgress: true,
fieldsOptionallyEnclosed: true,
fieldsTerminatedBy: ",",
linesTerminatedBy: "\n",
fieldsEnclosedBy: '"'});
Acquiring global read lock
Global read lock acquired
Initializing - done
2 tables and 0 views will be dumped.
Gathering information - done
All transactions have been started
Locking instance for backup
Global read lock has been released
Writing global DDL files
Running data dump using 4 threads.
NOTE: Progress information uses estimated values and may not be accurate.
Writing schema metadata - done
Writing DDL - done
Writing table metadata - done
Starting data dump
104% (5.00M rows / ~4.81M rows), 95.22K rows/s, 19.66 MB/s uncompressed, 8.83 MB/s compressed
Dump duration: 00:00:41s
Total duration: 00:00:41s
Schemas dumped: 1
Tables dumped: 2
Uncompressed data size: 977.63 MB
Compressed data size: 441.00 MB
Compression ratio: 2.2
Rows written: 4999999
Bytes written: 441.00 MB
Average uncompressed throughput: 23.64 MB/s
Average compressed throughput: 10.66 MB/s
• 덤프중 스레드 확인
8개의 스레드가 덤프를 받는것을 확인할 수 있습니다.
mysql-sql> show processlist;
+-------+-----------------+---------------------+--------+------------------+---------+-----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-------+-----------------+---------------------+--------+------------------+---------+-----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
...
| 25622 | root | localhost | sbtest | Query | 16 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest4` WHERE (`id` BETWEEN 1875001 AND 21875 |
| 25623 | root | localhost | NULL | Query | 16 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest4` WHERE (`id` BETWEEN 1250001 AND 15625 |
| 25624 | root | localhost | NULL | Query | 16 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest4` WHERE (`id` BETWEEN 1 AND 312500) ORD |
| 25626 | root | localhost | NULL | Query | 16 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest4` WHERE (`id` BETWEEN 937501 AND 125000 |
| 25627 | root | localhost | NULL | Query | 16 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest4` WHERE (`id` BETWEEN 1562501 AND 18750 |
| 25628 | root | localhost | sbtest | Query | 16 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest4` WHERE (`id` BETWEEN 312501 AND 625000 |
| 25629 | root | localhost | NULL | Query | 16 | executing | SELECT SQL_NO_CACHE `id`,`k`,`c`,`pad` FROM `sbtest`.`sbtest4` WHERE (`id` BETWEEN 625001 AND 937500 |
| 25633 | root | localhost | NULL | Query | 0 | init | show processlist |
+-------+-----------------+---------------------+--------+------------------+---------+-----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
• 덤프 내용 확인
shell > cd /root/shsbtest
shell> ls
total 440772
drwxr-xr-x 2 root root 4096 Feb 24 22:41 .
drwx------ 10 root root 4096 Feb 24 22:03 ..
-rw-r----- 1 root root 960 Feb 24 22:41 @.done.json
-rw-r----- 1 root root 1023 Feb 24 22:41 @.json
-rw-r----- 1 root root 240 Feb 24 22:41 @.post.sql
-rw-r----- 1 root root 283 Feb 24 22:41 sbtest.json
-rw-r----- 1 root root 28292292 Feb 24 22:41 sbtest@sbtest1@0.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest1@0.txt.zst.idx
-rw-r----- 1 root root 28206265 Feb 24 22:41 sbtest@sbtest1@1.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest1@1.txt.zst.idx
-rw-r----- 1 root root 28204640 Feb 24 22:41 sbtest@sbtest1@2.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest1@2.txt.zst.idx
-rw-r----- 1 root root 28183927 Feb 24 22:41 sbtest@sbtest1@3.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest1@3.txt.zst.idx
-rw-r----- 1 root root 28179886 Feb 24 22:41 sbtest@sbtest1@4.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest1@4.txt.zst.idx
-rw-r----- 1 root root 28174013 Feb 24 22:41 sbtest@sbtest1@5.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest1@5.txt.zst.idx
-rw-r----- 1 root root 28179058 Feb 24 22:41 sbtest@sbtest1@6.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest1@6.txt.zst.idx
-rw-r----- 1 root root 28185792 Feb 24 22:41 sbtest@sbtest1@@7.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest1@@7.txt.zst.idx
-rw-r----- 1 root root 637 Feb 24 22:41 sbtest@sbtest1.json
-rw-r----- 1 root root 839 Feb 24 22:41 sbtest@sbtest1.sql
-rw-r----- 1 root root 28290915 Feb 24 22:41 sbtest@sbtest4@0.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest4@0.txt.zst.idx
-rw-r----- 1 root root 28205703 Feb 24 22:41 sbtest@sbtest4@1.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest4@1.txt.zst.idx
-rw-r----- 1 root root 28206159 Feb 24 22:41 sbtest@sbtest4@2.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest4@2.txt.zst.idx
-rw-r----- 1 root root 28179957 Feb 24 22:41 sbtest@sbtest4@3.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest4@3.txt.zst.idx
-rw-r----- 1 root root 28179075 Feb 24 22:41 sbtest@sbtest4@4.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest4@4.txt.zst.idx
-rw-r----- 1 root root 28179537 Feb 24 22:41 sbtest@sbtest4@5.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest4@5.txt.zst.idx
-rw-r----- 1 root root 28174226 Feb 24 22:41 sbtest@sbtest4@6.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest4@6.txt.zst.idx
-rw-r----- 1 root root 28180919 Feb 24 22:41 sbtest@sbtest4@@7.txt.zst
-rw-r----- 1 root root 480 Feb 24 22:41 sbtest@sbtest4@@7.txt.zst.idx
-rw-r----- 1 root root 637 Feb 24 22:41 sbtest@sbtest4.json
-rw-r----- 1 root root 839 Feb 24 22:41 sbtest@sbtest4.sql
-rw-r----- 1 root root 459 Feb 24 22:41 sbtest.sql
-rw-r----- 1 root root 240 Feb 24 22:41 @.sql
■ 로드 방법 - 레벨별 로드
가져오기의 진행 상태는 성공적으로 완료된 단계와 중단되거나 실패한 단계를 기록하는 진행 상태 파일에 저장됩니다. 기본적으로 진행 상태 파일의 이름은 load-progress.server_uuid.json이고 덤프 디렉터리에 생성되지만 다른 이름과 위치를 선택할 수 있습니다. 덤프 로드 유틸리티는 덤프 가져오기를 재개하거나 재시도할 때 진행 상태 파일을 참조하고 완료된 단계를 건너뜁니다. 부분적으로 로드된 테이블에 대해서는 중복 제거가 자동으로 관리됩니다. Ctrl + C를 사용하여 진행 중인 덤프를 중단하면, 처음 사용할 때 유틸리티에서 새 작업이 시작되지 않지만 기존 작업은 계속됩니다. Ctrl + C를 다시 누르면 기존 작업이 중지되어 오류 메시지가 표시됩니다. 두 경우 모두 유틸리티는 중지된 위치에서 가져오기를 계속 재개할 수 있습니다.
진행 상태를 재설정하고 덤프 가져오기를 처음부터 다시 시작하도록 선택할 수 있지만 이 경우 유틸리티는 이미 생성된 개체를 건너뛰지 않으며 중복 제거를 관리하지 않습니다. 이런 상태에서 올바른 가져오기를 보장하려면 스키마, 테이블, 사용자, 보기, 트리거, 루틴 및 이벤트를 포함하여 해당 덤프에서 이전에 로드된 모든 객체를 대상 MySQL 인스턴스에서 수동으로 제거해야 합니다. 그렇지 않으면 덤프 파일의 객체가 대상 MySQL 인스턴스에 이미 존재하는 경우 오류와 함께 가져오기가 중지됩니다. 주의를 기울여서ignoreExistingObjects 옵션을 사용하여 유틸리티가 중복 개체를 보고하도록 할 수 있지만 이를 건너뛰고 가져오기를 계속할 수 있습니다. 유틸리티는 대상 MySQL 인스턴스와 덤프 파일의 객체 콘텐츠가 다른지 여부를 확인하지 않으므로 결과 가져오기에 올바르지 않거나 유효하지 않은 데이터가 포함될 수 있습니다.
▶︎ 덤프 로드 제어 옵션
• dryRun: [ true | false ]
덤프 내용을 기반으로 특정 옵션 및 덤프 파일과 에러를 포함하여 수행하는 활동에 대해 수행되는 작업에 대한 정보를 표시하지만 실제로 로드를 수행하지는 않습니다. 기본값은 false입니다.
• waitDumpTimeout: number
이 옵션을 0보다 큰 값으로 설정하면 덤프가 생성 중일 때 동시로 로드되도록 활성화됩니다. 이 값은 덤프 위치의 모든 업로드된 데이터 chunk가 처리된 후에 더 많은 데이터가 나타날 때까지 유틸리티가 기다리는 시간 제한(초 단위)입니다. 이를 통해 유틸리티가 덤프가 생성되는 동안 덤프를 가져올 수 있습니다. 데이터가 사용 가능해지면 처리되고, 더 이상 데이터가 나타나지 않을 때 시간 제한이 초과되면 가져오기가 중지됩니다. 기본 설정인 0은 모든 업로드된 데이터 청크가 처리된 후 유틸리티가 덤프를 완료로 표시하고 더 이상 데이터를 기다리지 않음을 의미합니다. 기본 설정으로는 동시 로드가 비활성화됩니다.
• schema: "string"
MySQL Shell의 덤프 유틸리티에서 생성된 덤프를 로드해야 하는 대상 스키마입니다.
MySQL Shell 8.0.31부터 스키마가 존재하지 않으면 스키마가 생성되고 해당 새 스키마에 덤프가 로드됩니다. 새 스키마 이름이 덤프의 스키마 이름과 다른 경우 덤프는 새 스키마에 로드되지만 로드된 데이터는 변경되지 않습니다. 즉, 이전 스키마 이름에 대한 모든 참조는 데이터에 남아 있습니다. 모든 저장 프로시저, 뷰 등은 새 스키마가 아닌 원래 스키마를 참조합니다.
이 로드 옵션은 단일 스키마 덤프 또는 단일 스키마를 생성하는 필터링 옵션에 대해 지원됩니다.
MySQL Shell 8.0.23부터는 테이블 덤프 유틸리티의 덤프 파일에 원래 테이블이 포함된 스키마를 설정하는 데 필요한 정보가 포함되어 있으므로 이 옵션이 필요하지 않습니다. 기본적으로 해당 릴리스에서는 스키마가 아직 존재하지 않는 경우 대상 MySQL 인스턴스에 다시 생성됩니다. 또는 스키마 옵션을 지정하여 대상 MySQL 인스턴스에 존재해야 하는 대체 스키마에 테이블을 로드할 수 있습니다.
MySQL Shell 8.0.22에서는 테이블 덤프 유틸리티의 덤프 파일에 스키마 정보가 포함되어 있지 않으므로 대상 MySQL 인스턴스에 대상 스키마가 있어야 합니다. 해당 릴리스에서는 기본적으로 전역 셸 세션의 현재 스키마가 대상 스키마로 사용되거나 스키마 옵션을 사용하여 대상 스키마의 이름을 지정할 수 있습니다.
• threads: number
대상 MySQL 인스턴스에 데이터 chunk를 업로드하는 데 사용할 병렬 스레드 수입니다. 각 스레드에는 MySQL 인스턴스에 대한 자체 연결이 있습니다. 기본값은 4입니다. 청크가 활성화된 상태(기본값)로 덤프가 생성된 경우 유틸리티는 여러 스레드를 사용하여 테이블의 데이터를 로드할 수 있습니다. 그렇지 않으면 스레드는 하나의 테이블에만 사용됩니다.
• backgroundThreads: number
파일 내용을 가져오는 데 사용되는 백그라운드 스레드 풀의 스레드 수입니다. 이 옵션과 스레드 풀은 MySQL Shell 8.0.27에서 사용할 수 있습니다. 기본값은 로컬 서버에서 로드된 덤프의 경우 스레드 옵션 값이거나, 로컬 서버가 아닌 서버에서 로드된 덤프의 경우 스레드 옵션 값의 4배입니다.
• progressFile: "string"
로드 진행 상황을 추적하기 위한 로컬 진행 상태 파일의 경로를 지정합니다. 로드 작업 유형에 따라 다른 값이 허용됩니다.
로컬 저장소에서 덤프를 로드하는 경우:
1. ProgressFile 옵션은 생략될 수 있습니다. 이 경우 load-progress-server-uuid.json이라는 진행 상태 파일이 덤프 디렉터리에 자동으로 생성됩니다.
2. ProgressFile 옵션을 빈 문자열로 설정하여 진행 상태 추적을 비활성화할 수 있습니다. 이는 덤프 로딩 유틸리티가 부분적으로 완료된 가져오기를 재개할 수 없음을 의미합니다.
• showProgress: [ true | false ]
가져오기 진행률 정보를 표시(true)하거나 숨깁니다(false). MySQL Shell이 대화형 모드일 때와 같이 stdout이 터미널(tty)인 경우 기본값은 true이고, 그렇지 않은 경우 false입니다. 진행 정보에는 활성 스레드 수와 해당 작업, 지금까지 로드된 데이터 양, 완료율 및 처리량 속도가 포함됩니다. 진행 정보가 표시되지 않는 경우 진행 상태는 덤프 로딩 유틸리티의 진행 상태 파일에 계속 기록됩니다.
• ResetProgress: [ true | false ]
이 옵션을 true로 설정하면 진행 상태가 재설정되고 가져오기가 처음부터 다시 시작됩니다. 기본값은 false입니다. 이 옵션을 사용하면 덤프 로딩 유틸리티가 이미 생성된 개체를 건너뛰지 않고 중복 제거를 관리하지 않습니다. 이 옵션을 사용하려면 올바른 가져오기를 보장하기 위해 먼저 해당 덤프에서 스키마, 테이블, 사용자, 보기, 트리거, 루틴 및 이벤트를 포함하여 이전에 로드된 모든 객체를 대상 MySQL 인스턴스에서 수동으로 제거해야 합니다. 그렇지 않으면 덤프 파일의 객체가 대상 MySQL 인스턴스에 이미 존재하는 경우 오류와 함께 가져오기가 중지됩니다. 적절한 주의를 기울여서ignoreExistingObjects 옵션을 사용하여 유틸리티가 중복 개체를 보고하도록 할 수 있지만 이를 건너뛰고 가져오기를 계속할 수 있습니다.
• SkipBinlog: [ true | false ]
SET sql_log_bin=0 문을 실행하여 가져오기 과정에서 유틸리티가 사용하는 세션에 대해 대상 MySQL 인스턴스에서 바이너리 로깅을 건너뜁니다. 기본값은 false이므로 기본적으로 바이너리 로깅이 활성화됩니다. MySQL DB 시스템의 경우 이 옵션이 사용되지 않으며, true로 설정하려고 하면 오류와 함께 가져오기가 중지됩니다. 다른 MySQL 인스턴스의 경우, updateGtidSet 옵션을 사용하거나 수동으로 대상 MySQL 인스턴스의 소스 MySQL 인스턴스에서 설정된 gtid_executed GTID를 적용하는 경우 항상 SkipBinlog를 true로 설정하세요. 대상 MySQL 인스턴스에서 GTID가 사용 중인 경우(gtid_mode=ON) 이 옵션을 true로 설정하면 가져오기가 수행될 때 새 GTID가 생성 및 할당되는 것을 방지하여 소스 서버에서 설정된 원래 GTID를 사용할 수 있습니다. . 사용자 계정에는 sql_log_bin 시스템 변수를 설정하는 데 필요한 권한이 있어야 합니다.
• ignoreVersion: [ true | false ]
데이터가 덤프된 MySQL 인스턴스의 메이저 버전 번호가 데이터가 업로드될 MySQL 인스턴스의 메이저 버전 번호와 다른 경우에도 덤프를 가져옵니다. 기본값은 false입니다. 즉, 주 버전 번호가 다르면 오류가 발생하고 가져오기가 진행되지 않습니다. 이 옵션을 true로 설정하면 경고가 발생하고 가져오기가 진행됩니다. 덤프 파일의 스키마에 새 주요 버전과의 호환성 문제가 없는 경우에만 가져오기가 성공합니다.
ignoreVersion 옵션을 사용하여 가져오기를 시도하기 전에 MySQL Shell의 업그레이드 검사기 유틸리티 checkForServerUpgrade()를 사용하여 원본 MySQL 인스턴스의 스키마를 확인해야 합니다. 스키마를 덤프하고 대상 MySQL 인스턴스로 가져오기 전에 유틸리티에서 식별된 호환성 문제를 수정해야 합니다.
• ignoreExistingObjects: [ true | false ]
MySQL 인스턴스의 대상 스키마에 이미 존재하는 객체가 포함된 경우에도 덤프를 가져옵니다. 기본값은 false입니다. 즉, 진행 상태 파일을 사용하여 이전 시도에서 가져오기를 재개하는 경우(이 경우 검사를 건너뛰는 경우) 중복된 개체가 발견되면 오류가 발생하고 가져오기가 중지됩니다. 이 옵션을 true로 설정하면 중복된 개체가 보고되지만 오류가 생성되지 않고 가져오기가 진행됩니다. 이 옵션은 주의해서 사용해야 합니다. 유틸리티는 대상 MySQL 인스턴스와 덤프 파일의 객체 콘텐츠가 다른지 여부를 확인하지 않으므로 가져오기 결과에 올바르지 않거나 유효하지 않은 데이터가 포함될 수 있기 때문입니다. 또 다른 전략은 extractTables 옵션을 사용하여 덤프 파일의 객체가 대상 MySQL 인스턴스의 가져온 객체와 동일하다는 것을 확인한 이미 로드한 테이블을 제외하는 것입니다. 가장 안전한 선택은 덤프를 다시 시작하기 전에 대상 MySQL 인스턴스에서 중복 개체를 제거하는 것입니다.
• handlerGrantErrors: [ abort | drop_account | ignore ]
GRANT 또는 REVOKE 오류와 관련된 오류가 발생한 경우 취하는 조치입니다.
1. abort: (기본값) 로드 프로세스를 중지하고 오류를 표시합니다.
2. drop_account: 계정을 삭제하고 로드 프로세스를 계속합니다.
3. 무시: 오류를 무시하고 로드 프로세스를 계속합니다.
• characterSet: "string"
예를 들어 LOAD DATA 문의 CHARACTER SET 옵션에서 대상 MySQL 인스턴스로 가져오는 데 사용되는 문자 집합입니다. 기본값은 MySQL Shell의 인스턴스 덤프 유틸리티, 스키마 덤프 유틸리티 또는 테이블 덤프 유틸리티에 의해 덤프가 생성될 때 사용된 덤프 메타데이터에 제공된 문자 세트이며, 기본적으로 utf8mb4를 사용합니다. 문자 세트는 Character_set_client 시스템 변수에서 허용되고 MySQL 인스턴스에서 지원되어야 합니다.
• maxBytesPerTransaction: number
- 단일 LOAD DATA 문으로 데이터 파일에서 로드할 수 있는 최대 바이트 수입니다. 데이터 파일이 maxBytesPerTransaction 값을 초과하는 경우 여러 LOAD DATA 문이 파일에서 maxBytesPerTransaction 값보다 작거나 같은 청크로 데이터를 로드합니다. 이 옵션은 MySQL Shell 8.0.27에서 사용할 수 있습니다.
- 단위 접미사 k는 킬로바이트, M은 메가바이트, G는 기가바이트를 의미합니다. 최소값은 4069바이트입니다. 더 작은 값이 지정되면 최소값 4096바이트가 암시적으로 사용됩니다. maxBytesPerTransaction 옵션이 설정되지 않은 경우 데이터를 덤프하는 데 사용된 bytesPerChunk 값은 1.5 * bytesPerChunk 값보다 큰 파일의 기본 설정으로 사용됩니다. maxBytesPerTransaction 옵션이 설정되지 않고 데이터 파일이 1.5 * bytesPerChunk 값보다 작은 경우 단일 LOAD DATA 문에서 데이터가 요청됩니다.
- 데이터 파일에 maxBytesPerTransaction 설정보다 큰 행이 포함된 경우 해당 행의 데이터는 단일 LOAD DATA 문에서 요청됩니다. maxBytesPerTransaction 설정을 초과하는 첫 번째 행에 대해 경고가 발생합니다.
- maxBytesPerTransaction 설정이 구성된 로드 작업이 중단되고 실행이 다시 시작되면 이미 로드된 청크를 건너뜁니다. 재개된 로드 작업은 현재 maxBytesPerTransaction 설정을 사용합니다. 작업이 중단되기 전에 사용된 설정은 진행 상태 파일에 저장되지 않습니다.
- 이 옵션의 용도는 데이터 파일이 서버의 group_replication_transaction_size_limit 또는 max_binlog_cache_size 설정에 의해 정의된 제한과 같은 대상 서버의 제한에 비해 너무 큰 경우 데이터를 더 작은 청크로 로드하는 것입니다. 예를 들어, 데이터를 로드할 때 "MySQL 오류 1197(HY000): 다중 문 트랜잭션에 'max_binlog_cache_size' 바이트 이상의 스토리지가 필요합니다."라는 오류가 표시되면 maxBytesPerTransaction을 서버 인스턴스의 max_binlog_cache_size 설정보다 작거나 같은 값으로 설정합니다.
• sessionInitSql: 문자열 목록
대상 MySQL 인스턴스에 데이터를 로드하는 데 사용되는 각 클라이언트 세션 시작 시 실행할 SQL 문의 목록입니다. 이 옵션을 사용하여 세션 변수를 변경할 수 있습니다. 이 옵션은 MySQL Shell 8.0.30에서 사용할 수 있습니다. 예를 들어, 다음 문은 가져오기 과정에서 유틸리티가 사용하는 세션에 대해 대상 MySQL 인스턴스의 바이너리 로깅을 건너뛰고 인덱스 생성에 사용할 수 있는 스레드 수를 늘립니다.
• sessionInitSQL: ["SET SESSION sql_log_bin=0;", "SET SESSION innodb_ddl_threads=8,"]
SQL 문을 실행하는 동안 오류가 발생하면 가져오기가 중지되고 오류 메시지가 반환됩니다.
▶︎ 덤프 로드 옵션
• loadIndexes: [ true | false ]
테이블에 대한 세컨더리 인덱스를 생성(true)하거나 생성하지 않습니다(false). 기본값은 true입니다. 이 옵션을 false로 설정하면 가져오는 동안 세컨더리 인덱스가 생성되지 않으며 나중에 생성해야 합니다. 이는 DDL 파일과 데이터 파일을 별도로 로드하는 경우 및 DDL 파일을 로드한 후 테이블 구조를 변경하려는 경우에 유용할 수 있습니다. 그런 다음 loadIndexes를 true로 설정하고 deferTableIndexes를 all로 설정하여 덤프 로딩 유틸리티를 다시 실행하여 보조 인덱스를 생성할 수 있습니다.
8.0.31부터 MySQL Shell은 MySQL Server의 병렬 인덱스 생성을 활용합니다. 이전에는 덤프 로딩 유틸리티가 인덱스를 한 번에 하나씩 순차적으로 추가했습니다. 이번 릴리스부터는 테이블의 모든 인덱스가 동시에 추가됩니다.
제한 사항 및 구성은 온라인 DDL 작업을 위한 병렬 스레드 구성을 참조하세요.
• deferTableIndexes: [ off | fulltext | all ]
테이블 데이터가 로드될 때까지 보조 인덱스 생성을 연기합니다. 이렇게 하면 로딩 시간을 줄일 수 있습니다. off는 테이블 로드 중에 모든 인덱스가 생성됨을 의미합니다. 기본 설정 전체 텍스트는 전체 텍스트 인덱스만 연기합니다. all은 모든 세컨더리 인덱스를 연기하고 테이블 로드 중에 프라이머리 인덱스만 생성하며, 또한 (MySQL Shell 8.0.22부터) 자동 증가 값을 포함하는 열에 정의된 인덱스도 생성합니다. MySQL Shell 8.0.21에서는 auto-increment 값을 포함하는 unique ley 열이 있는 경우 all을 설정하면 안됩니다.
• analyzeTables: [off | on | histogram ]
테이블이 로드되면 해당 테이블에 대해 ANALYZE TABLE을 실행합니다. on은 모든 테이블을 분석하고, histogram은 덤프에 히스토그램 정보가 저장된 테이블만 분석합니다. 기본값은 off 있습니다. 데이터가 이미 로드된 경우에도 이 옵션을 사용하여 덤프 로딩 유틸리티를 실행하여 테이블을 분석할 수 있습니다.
• showMetadata: [ true | false ]
MySQL Shell의 인스턴스 덤프 유틸리티, 스키마 덤프 유틸리티 또는 테이블 덤프 유틸리티에서 생성된 덤프에 포함된 덤프 메타데이터에서 가져온 gtid_executed GTID 세트와 소스 인스턴스의 바이너리 로그 파일 이름 및 위치를 인쇄합니다. 메타데이터는 YAML 형식으로 인쇄됩니다. 이 옵션은 MySQL Shell 8.0.24에서 사용할 수 있습니다.
gtid_executed GTID 세트는 항상 @.json 덤프 파일의 gtidExecuted 필드로 덤프에 포함됩니다. 덤프 로딩 유틸리티는 소스 MySQL 인스턴스의 gtid_executed GTID 세트를 대상 MySQL 인스턴스에 자동으로 적용하지 않습니다. 복제에 사용하기 위해 대상 MySQL 인스턴스에 이러한 GTID를 적용하려면 대상 MySQL 인스턴스의 릴리스에 따라 updateGtidSet 옵션을 사용하거나 수동으로 가져옵니다. MySQL Shell 8.0.23부터 이는 MySQL DB 시스템 인스턴스에서 지원됩니다. 자세한 내용은 updateGtidSet 옵션 설명을 참조합니다.
덤프 유틸리티를 실행하는 데 사용된 사용자 계정에 REPLICATION CLIENT 권한이 있는 경우 바이너리 로그 파일 이름과 위치가 포함됩니다. 바이너리 로그 파일 이름과 위치는 CHANGE REPLICATION SOURCE TO 명령문의 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 옵션을 사용하여 GTID가 활성화되지 않고 GTID 기반 복제를 사용하지 않는 소스 서버에서 GTID가 활성화된 복제본으로 복제를 설정하는 데 사용할 수 있습니다. (MySQL Server 8.0.23에서 사용 가능)
• updateGtidSet: [ off | append | replace ]
덤프 메타데이터에 기록된 대로 소스 MySQL 인스턴스의 gtid_executed GTID 세트를 대상 MySQL 인스턴스의 gtid_purged GTID 세트에 적용합니다. gtid_purged GTID 세트는 서버에 적용되었지만 서버의 바이너리 로그 파일에는 존재하지 않는 모든 트랜잭션의 GTID를 보유합니다. 이 옵션은 MySQL Shell 8.0.22에서 사용할 수 있지만 해당 릴리스에서는 권한 제한으로 인해 MySQL DB 시스템에서 지원되지 않습니다. MySQL 8.0.23부터는 MySQL DB 시스템 인스턴스에도 이 옵션을 사용할 수 있습니다. 기본값은 off입니다. 이는 설정된 GTID가 적용되지 않음을 의미합니다.
MySQL Shell의 테이블 덤프 유틸리티에서 생성된 덤프에는 이 옵션을 사용하면 안됩니다. MySQL Shell의 인스턴스 덤프 유틸리티 또는 스키마 덤프 유틸리티에서 생성된 덤프에만 사용해야 합니다. 또한 대상 MySQL 인스턴스에서 그룹 복제가 실행 중인 경우에는 이 옵션을 사용하면 안됩니다.
MySQL DB 시스템 인스턴스가 아닌 MySQL 인스턴스의 경우 GTID 세트를 업데이트하기 위해 추가 또는 교체를 설정할 때 SkipBinlog 옵션도 true로 설정합니다. 이렇게 하면 소스 서버의 GTID가 대상 서버의 GTID와 일치하는지 확인됩니다. MySQL DB 시스템 인스턴스의 경우 이 옵션이 사용되지 않습니다.
MySQL 8.0의 대상 MySQL 인스턴스의 경우 소스 MySQL 인스턴스의 gtid_executed GTID 세트를 대상 MySQL 인스턴스의 gtid_purged GTID 세트에 추가하는 추가 옵션을 설정할 수 있습니다. @.json 덤프 파일의 gtidExecuted 필드에 표시되는 적용할 gtid_executed GTID 세트는 대상 MySQL 인스턴스에 이미 있는 gtid_executed 세트와 교차해서는 안 됩니다. 예를 들어, 다른 소스 MySQL 인스턴스의 스키마를 이미 다른 소스 서버의 스키마가 있는 대상 MySQL 인스턴스로 가져올 때 이 옵션을 사용할 수 있습니다.
타겟 MySQL 인스턴스의 gtid_purged GTID 세트를 소스 MySQL 인스턴스의 gtid_executed GTID 세트로 대체하는 데 MySQL 8.0부터 replace를 사용할 수도 있습니다. 이를 위해서는 소스 MySQL 인스턴스의 gtid_executed GTID 세트가 타겟 MySQL 인스턴스의 gtid_purged GTID 집합의 상위 세트여야 하며, 타겟의 gtid_executed GTID 세트에서 gtid_purged GTID 세트에 없는 트랜잭션 집합과 교차해서는 안 됩니다.
MySQL 5.7의 대상 MySQL 인스턴스의 경우 대상 MySQL 인스턴스에 설정된 gtid_purged GTID를 소스 MySQL 인스턴스의 gtid_executed GTID 세트로 바꾸는 교체 옵션을 설정합니다. MySQL 5.7에서 이를 수행하려면 대상 MySQL 인스턴스의 gtid_executed 및 gtid_purged GTID 세트가 비어 있어야 하므로 이전에 가져온 GTID 세트 없이 인스턴스를 사용하지 않아야 합니다.
이 옵션을 사용할 수 없는 MySQL Shell 8.0.21에서는 MySQL Server 인스턴스에 수동으로 설정된 GTID를 적용할 수 있습니다(그룹 복제가 사용 중인 경우 제외). MySQL DB 시스템의 경우 이 방법이 지원되지 않습니다. GTID 세트를 적용하려면 암포트 후 MySQL Shell의 \sql 명령을 사용하여(또는 SQL 모드로 전환) 연결된 MySQL 인스턴스에서 다음 문을 실행하고 @.json 덤프 파일의 gtidExecuted 필드에서 gtid_executed GTID 세트를 복사합니다. 덤프 메타데이터:
mysql-js> \sql SET @@GLOBAL.gtid_purged= "+gtidExecuted_set";
MySQL 8.0에서 작동하는 이 문은 소스 MySQL Server 인스턴스의 gtid_executed GTID 세트를 대상 MySQL 인스턴스의 gtid_purged GTID 세트에 추가합니다. MySQL 5.7의 경우 더하기 기호(+)를 생략해야 하며 대상 MySQL 인스턴스의 gtid_executed 및 gtid_purged GTID 세트는 비어 있어야 합니다.
• createInvisiblePKs: [ true | false ]
프라이머리 키가 포함되지 않은 덤프의 각 테이블에 대해 보이지 않는 열에 프랑리머리 키를 추가합니다. MySQL Shell의 인스턴스 덤프 유틸리티 util.dumpInstance(), 스키마 덤프 유틸리티 util.dumpSchemas() 또는 테이블 덤프 유틸리티 util.dumpTables()에 의해 create_invisible_pks 옵션을 사용하여 덤프가 생성된 경우 true 설정이 자동으로 적용됩니다. 프라이머리 키는 덤프용 DDL이 로드된 경우에만 추가됩니다(loadDdl: true). 보이지 않는 열("my_row_id"라는 이름)은 업로드된 테이블을 사용하는 애플리케이션에 영향을 주지 않습니다.
createInvisiblePKs는 MySQL Shell 8.0.24에 있으며 true 설정이 적용되는 경우 대상 MySQL 인스턴스는 MySQL Server 8.0.24 이상이어야 합니다. 그렇지 않으면 로드가 실패합니다. 보이지 않는 열은 MySQL Server 8.0.23에서 사용할 수 있지만 해당 릴리스에서는 이에 대한 제한으로 인해 이 기능을 사용할 수 없습니다. MySQL Shell 8.0.24 이전 버전의 MySQL Shell에 있는 덤프 로딩 유틸리티는 덤프 메타데이터 플래그를 자동으로 무시하고 프라이머리 키를 추가하지 않으므로 최신 버전의 유틸리티를 사용해야 합니다.
▶︎ 필터링 옵션
• loadDdl: [ true | false ]
이 옵션을 false로 설정하면 덤프의 DDL 파일이 로드에서 제외됩니다. 기본값은 true입니다. 이는 DDL 파일이 로드됨을 의미합니다.
• loadData: [ true | false ]
이 옵션을 false로 설정하면 덤프의 데이터 파일이 로드에서 제외됩니다. 기본값은 true이며, 이는 데이터 파일이 로드됨을 의미합니다.
• loadUsers: [ true | false ]
사용자와 해당 역할 및 권한을 대상 MySQL 인스턴스로 가져오거나(true) 가져오지 않거나(false) 가져오지 않습니다. 기본값은 false이므로 기본적으로 사용자를 가져오지 않습니다. 현재 사용자에 대한 설명은 건너뜁니다. MySQL Shell 8.0.22부터 사용자가 대상 MySQL 인스턴스에 이미 존재하는 경우 오류가 반환되고 덤프 파일의 사용자 부여가 적용되지 않습니다. MySQL Shell 8.0.22부터 덤프 로딩 유틸리티의excludeUsers 또는 includeUsers 옵션을 사용하여 가져오기에 제외하거나 포함할 사용자 계정을 지정할 수 있습니다.
MySQL Shell의 스키마 덤프 유틸리티 및 테이블 덤프 유틸리티는 사용자, 역할 및 권한 부여를 덤프에 포함하지 않지만 인스턴스 덤프 유틸리티는 기본적으로 포함할 수 있고 포함합니다. MySQL Shell 8.0.22부터, 인스턴스 덤프 유틸리티에서excludeUsers 및 includeUsers 옵션을 사용하여 덤프 파일에서 명명된 사용자 계정을 제외하거나 포함할 수도 있습니다.
true를 지정했지만 제공된 덤프 파일에 사용자 계정이 포함되어 있지 않으면 MySQL Shell 8.0.23 이전에는 유틸리티가 오류를 반환하고 가져오기를 중지합니다. MySQL Shell 8.0.23부터 유틸리티는 대신 경고를 반환하고 계속 진행됩니다.
• excludeUsers: array of strings
가져오기에서 명명된 사용자 계정을 제외합니다. 이 옵션은 MySQL Shell 8.0.22에서 사용할 수 있으며, 이를 사용하여 MySQL DB 시스템으로 가져오기가 허용되지 않거나 대상 MySQL 인스턴스에 이미 존재하거나 원하지 않는 사용자 계정을 제외할 수 있습니다. 사용자 이름과 호스트 이름으로 정의된 계정의 경우 "'user_name'@'host_name'" 형식으로, 사용자 이름만으로 정의된 계정의 경우 "'user_name'" 형식으로 각 사용자 계정 문자열을 지정합니다. 호스트 이름을 제공하지 않으면 해당 사용자 이름을 가진 모든 계정이 제외됩니다.
• includeUsers: array of strings
가져오기에는 명명된 사용자 계정만 포함됩니다. 제외사용자 옵션과 마찬가지로 각 사용자 계정 문자열을 지정합니다. 이 옵션은 MySQL Shell 8.0.22에서 사용할 수 있으며, 대상 MySQL 인스턴스에 소수의 사용자 계정만 필요한 경우 제외 사용자 대신 이 옵션을 사용할 수 있습니다. 일부 계정을 포함하고 다른 계정을 제외하도록 두 옵션을 모두 지정할 수도 있습니다.
• excludeSchemas: array of strings
가져오기에서 명명된 스키마를 제외합니다. information_schema, mysql, ndbinfo,performance_schema 및 sys 스키마는 MySQL Shell의 인스턴스 덤프 유틸리티로 생성된 덤프에서 항상 제외됩니다.
예제) excludeSchemas: ["schema_1","schema_2"]
• includeSchemas: array of strings
덤프 파일에서 명명된 스키마만 로드합니다. 일부 스키마를 포함하고 다른 스키마를 제외하도록 두 옵션을 모두 지정할 수 있습니다.
예제) includeSchemas: ["schema_1","schema_2"]
• excludeTables: array of strings
명명된 테이블을 가져오기에서 제외하여 대상 MySQL 인스턴스에 업로드되지 않도록 합니다. 테이블 이름은 유효한 스키마 이름으로 한정되어야 하며 필요한 경우 백틱 문자로 인용되어야 합니다. mysql.apply_status, mysql.general_log, mysql.schema 및 mysql.slow_log 테이블의 데이터는 해당 DDL 문이 포함되어 있더라도 MySQL Shell의 스키마 덤프 유틸리티로 생성된 덤프에서 항상 제외됩니다.
예제) excludeTables: ["schema.table_1","schema.table_2"]
• includeTables: array of strings
덤프 파일에서 명명된 테이블만 로드합니다. 테이블 이름은 유효한 스키마 이름으로 한정되어야 하며 필요한 경우 백틱 문자로 인용되어야 합니다. 일부 테이블을 포함하고 다른 테이블을 제외하도록 두 옵션을 모두 지정할 수 있습니다.
예제) includeTables: ["schema.table_1","schema.table_2"]
• excludeEvents: array of strings
가져오기에서 명명된 이벤트를 제외합니다. 이 옵션은 MySQL Shell 8.0.28에서 사용할 수 있습니다. 이벤트 이름은 유효한 스키마 이름으로 한정되어야 하며 필요한 경우 백틱 문자(`)로 인용되어야 합니다.
• includeEvents: array of strings
덤프 파일에서 명명된 이벤트만 로드합니다. 이 옵션은 MySQL Shell 8.0.28에서 사용할 수 있습니다. 이벤트 이름은 유효한 스키마 이름으로 한정되어야 하며 필요한 경우 백틱 문자(`)로 인용되어야 합니다.
• excludeRoutines: array of strings
가져오기에서 명명된 함수 및 저장 프로시저를 제외합니다. 이 옵션은 MySQL Shell 8.0.28에서 사용할 수 있습니다. 루틴 이름은 유효한 스키마 이름으로 규정되어야 하며 필요한 경우 백틱 문자(`)로 인용되어야 합니다.
• includeRoutines: array of strings
덤프 파일에서 명명된 함수와 저장 프로시저만 로드합니다. 이 옵션은 MySQL Shell 8.0.28에서 사용할 수 있습니다. 루틴 이름은 유효한 스키마 이름으로 규정되어야 하며 필요한 경우 백틱 문자(`)로 인용되어야 합니다.
• excludeTriggers: array of strings
가져오기에서 명명된 트리거를 제외합니다. 이 옵션은 MySQL Shell 8.0.28에서 사용할 수 있습니다. 트리거 이름은 유효한 스키마 이름과 테이블 이름(schema.table.trigger)으로 정규화되어야 하며 필요한 경우 백틱 문자(`)로 인용되어야 합니다. 이 옵션(schema.table)으로 스키마 이름과 테이블 이름을 지정하면 특정 테이블에 대한 모든 트리거를 제외할 수 있습니다.
• includeTriggers: array of strings
덤프 파일에서 명명된 트리거만 로드합니다. 이 옵션은 MySQL Shell 8.0.28에서 사용할 수 있습니다. 트리거 이름은 유효한 스키마 이름과 테이블 이름(schema.table.trigger)으로 정규화되어야 하며 필요한 경우 백틱 문자(`)로 인용되어야 합니다. 이 옵션(schema.table)으로 스키마 이름과 테이블 이름을 지정하면 특정 테이블에 대한 모든 트리거를 포함할 수 있습니다.
■ 덤프 로드 방법 - 옵션 조합을 통한 레벨별 로드
기존 인스턴스에 있던 모든 데이터베이스, 혹은 선택적으로 엑스포트된 데이터베이스들을 로드합니다. 위의 로드 옵션과 필터링 옵션등을 조합하여 원하는 방식으로 로드를 합니다.
로드하기전 dryRun 옵션으로 해당 덤프가 제대로 만들어졌는지 검증 테스트를 해봅니다. 시작하기 전 반드시 local_infile을 설정하고 시작합니다.
mysql-sql > set global local_infile = on;
덤프 로드시 어떤 일련의 작업들을 MySQL이 하는지 알고 싶다면 general_log를 on해줍니다.
mysql-sql > set global general_log = on;
덤프를 로드 할때 tail로 general log를 확인해보면 로드 과정들이 나타나게 됩니다.
처음에는 set을 통해 로드를 위한 최적의 환경(foreign_key_checks = 0, unique_checks = 0)과 캐릭터 셋 설정, SQL모드, 타임존등을 셋팅합니다.
그리고 데이터베이스를 만들고 테이블을 만들고 비로소 로드를 하게 됩니다.
덤프된 디렉토리를 확인해보면 스키마명@테이블명.json 파일이 있습니다. 데이터 덤프시 lineTerminatingBy, fieldsTerminatingBy, fieldsOptionallyEnclosedBy등의 옵션을 사용해서 덤프를 했다면 로드를 할때도 관련 옵션들을 똑같이 적용해줘야 하는데 스키마명@테이블명.json 파일안에 해당 옵션들이 작성되어 있습니다. 그래서 로드시 별도로 입력하지 않아도 로드가 되는 것입니다.
덤프 로드는 덤프와는 다르게 레벨별로 따로 명령이 존재하지 않습니다. 그러나 레벨별로 덤프된 로드에 레벨에 맞게 덤프된 모든 정보가 있기 때문에 불러오기만 하면 됩니다.
전체 인스턴스에 대해 덤프를 받았다면 원하는 스키마와 테이블을 필터링해서 로드가 가능하기 때문에 따로 레벨별로 명령어가 따로 제공되지 않습니다.
• dryRun 테스트
mysql-sql > \js
mysql-js> util.loadDump("/root/dumpInstance", {dryRun: true})
Loading DDL and Data from '/root/dumpInstance' using 4 threads.
Opening dump...
dryRun enabled, no changes will be made.
Target is MySQL 8.0.34. Dump was produced from MySQL 8.0.34
Scanning metadata - done
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL - done
Executing view DDL - done
Starting data load
Executing common postamble SQL
0% (0 bytes / 4.99 GB), 0.00 B/s, 13 / 13 tables done
Recreating indexes - done
No data loaded.
0 warnings were reported during the load.
• 덤프 로드 및 모니터링
기본적으로 옵션을 지정하지 않더라도 모든 옵션이 들어간다고 생각하시면 됩니다. 그리고 위의 옵션 설명들 중 true, false의 기본값이 들어가게 됩니다.
아래 설명은 옵션을 어떻게 사용하는지 안내하기 위해 일부러 작성한 옵션입니다.
1. 덤프 로드
util.loadDump("/root/dumpInstance",
-> {threads: 8});
->
Loading DDL and Data from '/root/dumpInstance' using 8 threads.
Opening dump...
Target is MySQL 8.0.34. Dump was produced from MySQL 8.0.34
Scanning metadata - done
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL - done
Executing view DDL - done
Starting data load
3 thds loading | 100% (4.99 GB / 4.99 GB), 5.45 MB/s, 13 / 13 tables done
Recreating indexes - done
Executing common postamble SQL
85 chunks (25.00M rows, 4.99 GB) for 13 tables in 4 schemas were loaded in 12 min 7 sec (avg throughput 6.88 MB/s)
0 warnings were reported during the load.
2. 프로세스 확인
프로세스 갯수가 8개인것을 확인해볼 수 있습니다.
mysql-sql > show processlist;
+------+-----------------+---------------------+--------+------------------+-------+-----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+------+-----------------+---------------------+--------+------------------+-------+-----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
......
| 1620 | root | localhost | sbtest | Query | 21 | executing | /* mysqlsh loadDump(), thread 0, table `sbtest`.`sbtest2`, chunk ID: 1 */ LOAD DATA LOCAL INFILE '/r |
| 1621 | root | localhost | NULL | Sleep | 58 | | NULL |
| 1622 | root | localhost | sbtest | Query | 21 | executing | /* mysqlsh loadDump(), thread 7, table `sbtest`.`sbtest5`, chunk ID: 1 */ LOAD DATA LOCAL INFILE '/r |
| 1623 | root | localhost | sbtest | Query | 7 | executing | /* mysqlsh loadDump(), thread 6, table `sbtest`.`sbtest7`, chunk ID: 2 */ LOAD DATA LOCAL INFILE '/r |
| 1624 | root | localhost | sbtest | Query | 21 | executing | /* mysqlsh loadDump(), thread 5, table `sbtest`.`sbtest1`, chunk ID: 1 */ LOAD DATA LOCAL INFILE '/r |
| 1625 | root | localhost | sbtest | Query | 21 | executing | /* mysqlsh loadDump(), thread 4, table `sbtest`.`sbtest9`, chunk ID: 1 */ LOAD DATA LOCAL INFILE '/r |
| 1626 | root | localhost | sbtest | Query | 19 | executing | /* mysqlsh loadDump(), thread 1, table `sbtest`.`sbtest6`, chunk ID: 1 */ LOAD DATA LOCAL INFILE '/r |
| 1627 | root | localhost | sbtest | Query | 21 | executing | /* mysqlsh loadDump(), thread 2, table `sbtest`.`sbtest10`, chunk ID: 1 */ LOAD DATA LOCAL INFILE '/ |
| 1628 | root | localhost | sbtest | Query | 19 | executing | /* mysqlsh loadDump(), thread 3, table `sbtest`.`sbtest3`, chunk ID: 1 */ LOAD DATA LOCAL INFILE '/r |
+------+-----------------+---------------------+--------+------------------+-------+-----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
25 rows in set (0.0030 sec)
3. 다른 진행율 확인.
덤프가 있는 디렉토리가 들어가보면 아래와 같은 파일이 있습니다. 이 파일을 tail로 확인해보면 로드되는 진행율을 확인해볼 수 있습니다.
혹시 같은 디렉토리를 재로드 해야 한다면 아래의 파일을 반드시 삭제해야 합니다. 그렇지 않으면 로드가 진행되지 않습니다.
예 : load-progress.UUID
실 파일형식 : load-progress.0a152a7e-958b-11ee-8e1f-fa163efb65ab.json
• 로드 예제
0. 사전 설정
mysql-sql > set global general_log = on;
mysql-sql > set global local_infile = on;
1. 전체 인스턴스 로드
1-1. 전체 인스턴스 로드
덤프된 파일들이 인스턴스 레벨이라면 자동으로 모든 데이터베이스, 테이블 및 트리거, 이벤트등을 생성합니다.
mysql-sql > \js
mysql-js> util.loadDump("/root/dumpInstance",
{threads: 8});
Loading DDL and Data from '/root/dumpInstance' using 8 threads.
Opening dump...
Target is MySQL 8.0.34. Dump was produced from MySQL 8.0.34
Scanning metadata - done
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL - done
Executing view DDL - done
Starting data load
2 thds loading / 100% (4.99 GB / 4.99 GB), 5.09 MB/s, 13 / 13 tables done
Recreating indexes - done
Executing common postamble SQL
85 chunks (25.00M rows, 4.99 GB) for 13 tables in 4 schemas were loaded in 12 min 6 sec (avg throughput 6.89 MB/s)
0 warnings were reported during the load.
1-2. 전체 인스턴스 안에서 특정 스키마와 테이블만 로드
util.loadDump("/root/dumpInstance",
{threads: 8,
loadDdl: true,
loadData: true,
loadIndexes: true,
showProgress: true,
includeSchemas: ["sbtest"],
includeTables: ["sbtest.sbtest1","sbtest.sbtest5"]});
Loading DDL and Data from '/root/dumpInstance' using 8 threads.
Opening dump...
Target is MySQL 8.0.34. Dump was produced from MySQL 8.0.34
Scanning metadata - done
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL - done
Executing view DDL - done
Starting data load
5 thds loading / 100% (997.63 MB / 997.63 MB), 6.16 MB/s, 2 / 2 tables done
Recreating indexes - done
Executing common postamble SQL
16 chunks (5.00M rows, 997.63 MB) for 2 tables in 1 schemas were loaded in 1 min 20 sec (avg throughput 12.86 MB/s)
0 warnings were reported during the load.
2. 전체 스키마 로드
덤프가 특정 스키마만 덤프된 것이라면 스키마만 생성하고 그 스키마 안에 포함된 테이블 및 트리거, 이벤트등을 생성합니다.
mysql-sql > create database sbtest;
mysql-sql > \js
mysql-js> util.loadDump("/root/dumpSchema",
{threads: 8,
loadDdl: true,
loadData: true,
loadIndexes: true,
showProgress: true});
Loading DDL and Data from '/root/dumpSchema' using 8 threads.
Opening dump...
Target is MySQL 8.0.34. Dump was produced from MySQL 8.0.34
Scanning metadata - done
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL - done
Executing view DDL - done
Starting data load
3 thds loading - 100% (4.99 GB / 4.99 GB), 4.55 MB/s, 12 / 12 tables done
Recreating indexes - done
Executing common postamble SQL
83 chunks (25.00M rows, 4.99 GB) for 12 tables in 2 schemas were loaded in 12 min 9 sec (avg throughput 6.87 MB/s)
0 warnings were reported during the load.
3. 테이블들만 입포트
기존 데이터베이스를 자동으로 만들어주고 덤프된 테이블을 로드합니다.
mysql-sql > \js
mysql-js> util.loadDump("/root/dumpTable",
{threads: 8,
loadDdl: true,
loadData: true,
loadIndexes: true,
showProgress: true});
Loading DDL and Data from '/root/dumpTable' using 8 threads.
Opening dump...
Target is MySQL 8.0.34. Dump was produced from MySQL 8.0.34
Scanning metadata - done
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL - done
Executing view DDL - done
Starting data load
5 thds loading \ 100% (997.63 MB / 997.63 MB), 6.40 MB/s, 2 / 2 tables done
Recreating indexes - done
Executing common postamble SQL
16 chunks (5.00M rows, 997.63 MB) for 2 tables in 1 schemas were loaded in 1 min 22 sec (avg throughput 12.73 MB/s)
0 warnings were reported during the load.'Databases > MySQL' 카테고리의 다른 글
| [MySQL] mysqlsh의 util.exportTable, util.importTable를 이용하여 덤프 및 임포트하기 (0) | 2024.02.19 |
|---|---|
| [MySQL] PERSIST, RESET PERSIST를 통한 서버 파라미터 관리 (0) | 2024.01.01 |
| [MySQL] Logrotate - 로그 분할 (0) | 2023.07.02 |
| [MySQL] 서버 자동 환경 설정(MySQL 8.0) (0) | 2023.03.19 |
| [MySQL] 리눅스의 파일 열기 갯수 변경 및 자원 제한 확인 (0) | 2023.03.19 |