이 문서는 percona 측에서 제공하는 pt-online-schema-change에 대해 올린 document를 제가 번역 한 것입니다.
틀린부분이 있을 수 있는데 그럴경우 댓글로 달아주시면 감사하겠습니다 ㅎ
OUTPUT¶
Tool이 STDOUT로 활동한 것에 대해 정보를 출력합니다. 그래서 데이터 카피를 하는 도중에 무엇을 하고 있는지 볼 수 있습니다. STDERR를 통해--progress옵션으로 출력됩니다. --print.를 명시하면 추가 정보를 얻을 수 있습니다.
만약 --statistics를 명시하면 내부적으로 다양한 것에 대한 카운트가 출력됩니다.
# Event Count
# ====== =====
# INSERT 1
OPTIONS¶
--dry-run and --execute are mutually exclusive.
This tool accepts additional command-line arguments. Refer to the “SYNOPSIS” and usage information for details.
--alter¶
type: string
alter table 키워드 없이 스키마 수정. 콤마로 여러 개의 테이블을 동시에 수정 할 수 있습니다. alter table mysql syntax에서 제공해준다.
제약사항들이 아래에 명시되어 있습니다..
· 첫 번째, 가장 많이 나타나는 현상으로 primary key 또는 unique index가 현재 테이블에 필요하다는 것입니다. 왜냐하면 새로운 테이블에 실시간으로 업데이트 되는 것을 유지하기 위해 delete trigger를 생성하기 때문입니다.
이미 존재하는 column 중에 alter명령어로 primary key나 unique index가 생성이 되는 경우 예외적으로 delete trigger를 사용할 것입니다.
· rename절은 table을 rename하는데 사용될 수 없습니다.
· column들은 삭제나 재 추가를 통해 새로운 이름으로 rename 될 수 없습니다. 이 툴은 원본 컬럼들의 데이터를 새로운 컬럼으로 복사하지 않을 것입니다.
· default value를 반드시 지정해주어야 합니다. 만약 default value와 not null 없이 column을 추가한다면 에러가 발생합니다.
· drop forgien key constraint_name은 실제 constraint_name이 아닌 _constraint_name을 요청합니다. MySQL 제한 때문인데, pt-online-schema-change 는 새로운 테이블을 만들 때 foreign key제약사항이름을 이끌기 위해서 강조를 추가합니다. 예를 들어, 이 제약조건을 삭제하고자 한다면
· CONSTRAINT `fk_foo` FOREIGN KEY (`foo_id`) REFERENCES `bar` (`foo_id`)
--alter "DROP FOREIGN KEY _fk_foo"를 명시해야 합니다.
· 이 툴은 MySQL 5.0에서 slave error를 야기할 수 있기 때문에LOCK IN SHARE MODE를 사용하지 않습니다.
· 쿼리가 master와 slave에서 다른 에러를 만들어내는데, master에러는 아래와 같습니다:
· 'Deadlock found when trying to get lock; try restarting transaction' (1213),
· slave에러로는: 'no error' (0). Default database: 'pt_osc'.
· Query: 'INSERT INTO pt_osc.t (id, c) VALUES ('730', 'new row')'
이 에러는 MyISAM테이블에서 InnoDB테이블로 변환될 때 발생됩니다.
왜냐하면 MyISAM은 트랜잭션화되어 있지 않지만 InnoDB는 트랙잭션화 되어 있기 때문입니다. MySQL 5.1과 그 이후는 이러한 문제를 정확히 다루고 있습니다. 하지만 5.0에서는 5%정도의 에러가 발생합니다.
MySQL 버그는 http://bugs.mysql.com/bug.php?id=45694와 유사합니다.
하지만 이것은 MySQL 5.0에서 고쳐지지 않았습니다.
--alter-foreign-keys-method¶
type: string
외래키 새로운 테이블을 참조하게 수정을 어떻게 할까요? 변경할 테이블을 참조하는 외부 키는 제대로 된 데이터를 보장하기 위해서 특별히 신경을 써야 합니다. 원본 테이블자리에 신규테이블을 rename시킬 때, 외래키는 이름이 변경된 테이블을 따라옵니다. 그리고 반드시 신규테이블을 참조하도록 변경되어야 합니다. 툴은 기술적으로 두 가지를 지원합니다. 자동적으로 자식 테이블을 찾아서 참조 제약조건을 변경시킵니다.
auto
자동으로 가장 좋은 방법을 결정합니다. 툴이 rebuild_constraints을 사용하는데 만약 사용하지 않을 경우 drop_swap을 사용합니다.
rebuild_constraints
이 방법은 삭제하기 위해 alter table을 사용하고 신규테이블에 foreign key constraint를 다시 추가시킵니다. 이것은 하나 또는 여러 자식테이블이 너무 커서 alter가 오래 걸리는 경우를 제외하고 선호되는 기술입니다. 이 툴은 자식테이블의 줄 수를 원본테이블에서 신규테이블로 복사 가능한 비율로 비교함으로써 결정한다. --chunk-time보다 자식테이블이 alter 되는 시간이 더 적다고 어림잡으면 이 기술을 사용할 것입니다.
자식테이블의 변경시간을 추정하기 위해 --chunk-size-limit의 줄 수 복사 비율을 증가시킵니다. 그 이유는 MySQL의 Alter Table이 줄 복사의 외부 프로세스보다 많이 빠르기 때문입니다.
MySQL 제한 때문에, 외래키는 ALTER한 후에는 이전과 같은 이름을 가질 수 없을 것입니다. 이 도구는 재정의되었을 때 이름에 _를 붙이는 방식으로 외래키 이름변경을 가집니다. 이런 경우, MySQL은 또한 자동적으로 foreign key를 위해 index 이름변경이 요청 됩니다.
drop_swap
외래키 체크를 비활성화(FOREIGN_KEY_CHECKS=0) 하고 신규 테이블을 rename 시키기 전에 원본 테이블을 지웁니다. 클라이언트가 찾아내지 못하게끔 rename을 사용하는 것이 원본과 신규 테이블 전환의 일반적인 방법과 다릅니다. 이 방법은 더 빠르고 block이 없습니다. 하지만 두 가지 이유로 더 위험성이 존재합니다. 첫 번째로, 원본테이블을 지우고 임시테이블을 이름 변경하는 짧은 동안에 alert 된 테이블이 존재하지 않는다면, 쿼리는 에러결과가 나올 것입니다. 두 번째로 에러와 신규테이블이 원본테이블 자리에 이름 변경이 되지 않는다면 영구적으로 원본테이블이 사라지기 때문에 중단하긴 늦은 것입니다.
이 방법은 강제로 --no-swap-tables와 --no-drop-old-table을 강제로 사용해야 합니다.
none
이 방법은 swap 없는 drop_swap과 같습니다. 원본테이블로부터 참조되는 외래키들은 존재하지 않는 테이블로 참조할 것이다. 이것은 전형적으로 SHOW ENGINE INNODB STATUS에 아래와 같이 외래키 방해에 대한 메시지를 보여주게 될 것 입니다.
Trying to add to index `idx_fk_staff_id` tuple:
DATA TUPLE: 2 fields;
0: len 1; hex 05; asc ;;
1: len 4; hex 80000001; asc ;;
But the parent table `sakila`.`staff_old`
or its .ibd file does not currently exist!
왜냐하면 원본테이블은 sakila.staff_old로 이름변경되었고 삭제되었습니다. 이 외래키 참조조건을 다루는 방법은 데이터베이스 관리자가 비활성화할 수 있도록 되어 있습니다.
--[no]analyze-before-swap¶
default: yes
원본 테이블과 전환시키기 전에 새로운 테이블에 analyze table을 실행시키는 옵션입니다. innodb_stats_persistent가 5.6이상에서 enable일 때 default로 해야 합니다. 이 옵션은 MySQL 버전이나 innodb_stats_persistent 값을 무시하고 enable, disable로 명확하게 명시합니다. 이것을 무시하는 것은 innodb 옵티마이저 상태에 대해 잠재적으로 중요한 문제가 있습니다. 만약 테이블 변경된 것이 느리고 툴이 빠르게 완료되었다면 새로운 테이블은 뒤바뀐 후에 옵티마이저 분석을 가지고 있지 않은 것입니다. 옵티마이저 통계가 업데이트될 때까지 인덱스를 사용하는 쿼리로 풀 테이블 스캔을 하면 빨리 끝낼 수 있습니다. (보통 10초 내외). 만약 테이블이 크고 서버가 매우 바쁘면 이것은 서버가 죽을 수 있습니다.
--ask-pass¶
MySQL 접속할 때 패스워드를 묻습니다.
--charset¶
short form: -A; type: string
기본적인 언어셋 을 설정한합니다. 만약 값이 utf8이면, perl의 binmode STDOUT을 통해 utf8로 설정하고, DBD::mysql의 옵션을 mysql_enable_utf8로 설정이 되고, MySQL을 연결한 후에 name을 utf8로 설정하도록 합니다. utf8없이 또 다른 값이 설정되고 MySQL에 연결된 수에 set name이 됩니다.
--[no]check-alter¶
default: yes
--alter에서 명시된 구문을 분석하고 의도하지 않은 가능성을 경고합니다.
Column renames
툴의 이전버전에선, change column와 같은 컬럼 이름변경은 column 데이터가 없어졌습니다. 현재 버전에선, alter 문을 분석하고 이러한 문제를 잡기 위해서 원본 컬럼 값을 남깁니다. 하지만 SQL 분석하는 것이 완벽 하지 않기 때문에 반드시 먼저 툴에서 --dry-run를 하고 --print를 통해 정확하게 Column 명을 적은걸 다시 한번 확인해야 합니다.
DROP PRIMARY KEY
--alter에서 DROP PRIMARY KEY를 한다면 (case- and space-insensitive), 경고가 출력되고 --dry-run를 명시하지 않으면 tool이 종료됩니다. primary key를 바꾸는 것은 위험합니다. 하지만 이 툴은 그것을 다룰 수 있습니다. 이 툴은 특히 Delete Trigger가 primary key alter를 하는데 있어서 가장 적용이 잘되는데 그 이유는 Trigger의 primary key를 사용하는 걸 선호하기 때문입니다. 반드시 먼저 툴에서 --dry-run를 하고 --print를 통해 정확하게 Trigger를 다시 한번 확인해야 합니다.
--check-interval¶
type: time; default: 1
--max-lag 검사하는 동안의 sleep time
--[no]check-plan¶
default: yes
안전하게 하기 위해서 query실행계획을 체크합니다. 기본적으로, 이 옵션은 적은 양의 쿼리가 돌아가기 전에 EXPLAIN을 하게 합니다. 하지만 많은 양을 실행하게 하면 나쁜 실행조건이 MySQL에서 나오게 합니다. 이러한 청크 경계를 결정하는 쿼리가 포함되어 있고 청크 자체를 조회한다. 만약 MySQL이 나쁜 결과를 나타낸다면, 이 툴은 그 실행 계획을 무시할 것입니다. The tool 실행계획이 좋은지 나쁜지 결정하기 위해 몇 가지를 사용합니다. 첫 번째로 explain report인데, MySQL은 사용하는 row에 대해 설계된 인덱스를 사용하기 위해서 작동합니다. 만약 MySQL이 다른 인덱스를 선택하면 tool은 쿼리가 안전하지 않다고 고려합니다.
툴은 또한 MySQL report에서 쿼리를 사용하기 위한 index가 얼마나 많은지 체크합니다. explain은 Column 키 길이에 대해 보여줍니다. 툴은 가장 큰 키 길이를 기억하고. 인덱스의 접두사가 더 작은 것을 사용 해서 MySQL report에서 청크를 생략 할 것입니다. 이 과정을 통해 더 나쁜 실행계획을 가진 청크를 생략하는데 이용됩니다.
그 툴은 각각의 테이블에서 나쁜 실행계획 때문에 생략이 된 청크는 첫 번째에 경고가 뜹니다. 그 뒤에 일어나는 청크들은 지나치게 됩니다. 툴의 출력에서 생략된 Column과 생략된 청크의 수를 볼 수 있고, 생략된 청크는 조용히 생략됩니다.
옵션은 각각 테이블과 청크에 대해 몇 가지 설정이 추가됩니다. 이 작업은 MySQL에 위협이 되지 않지만, 시간을 소비하고 서버에 여러 번 왕복합니다. 너무 작은 청크들을 만드는 건 비교적으로 크게 되어 오버헤드를 야기할 것입니다. 그러므로 청크를 너무 작게 만들지 않는 것을 추천합니다. 작게 만든다면 동작하는 것이 너무 오래 걸릴 것이기 때문입니다.
--[no]check-replication-filters¶
default: yes
어느 서버든 어느 replication에 필터가 걸려있으면 중단됩니다. 이 툴은 서버에서 replication filter 옵션인 binlog_ignore_db와 replicate_do_db같은 것을 봅니다. 만약 어떤 필터라도 걸린 것을 찾는 다면 tool은 종료 될 것입니다. 만약 filtering 옵션이 걸린 채로 구성이 된 replication이 있다면 replication 실패를 야기시킬 수 있기 때문에 마스터에 존재하고 replication이 아닌 데이터베이스나 테이블을 수정하지 않도록 조심해야 합니다. replication에 대한 자세한 룰은 http://dev.mysql.com/doc/en/replication-rules.html를 보아야 합니다.
--check-slave-lag¶
type: string
replication의 lag가 --max-lag보다 더 작아지지 않는 한 데이터 복사를 일시 중지합니다. connection 옵션으로부터 상속받은 설정 값이 DSN입니다. (--port, --user, etc.) 이 옵션은 연결된 모든 replication에서 replication 지연을 지속적으로 모니터링하고 찾는 일반적인 행동을 덮어 씌운다. 만약 모든 replication에 대해 모니터링을 원하지 않고 하나의 replication에 대해 모니터링 하는 것을 더 원한다면 DSN option에 --recursion-method 옵션을 포함해서 사용하면 됩니다.
--chunk-index¶
type: string
테이블을 작게 쪼개기 위해 index를 선호합니다. 기본적으로 작게 쪼개기 위해 가장 적합한 index를 선택합니다. 이 옵션은 선호하는 index를 지정합니다. 만약 인덱스가 존재하지 않는다면 인덱스 선택에 실패해서 되돌아올 것입니다. 이 툴은 sql문에 force index절을 index로 추가합니다. 이 옵션을 사용할 때는 조심해야 합니다. 잘못된 인덱스 선택이 나쁜 성능을 야기할 수 있습니다.
--chunk-index-columns¶
type: int
--chunk-index의 가장 왼쪽에 column을 사용합니다.
이것은 복합 인덱스에 대해서만 작동하고 이 경우 사용하면 MySQL query 옵티마이저가 인덱스의 정확한 시작, 종료 포인트 위치를 사용하는 것 대신에 넓은 범위의 줄을 보는 것을 야기하는 버그가 있습니다. 이 문제는 때때로 4개 또는 그 이상의 많은 column을 가진 인덱스에서 발생합니다. 만약 발생하면 툴은 --[no]check-plan옵션과 관계된 경고를 보여줄 것입니다.
--chunk-size¶
type: size; default: 1000
각각의 청크를 위해 선택한 줄 수만큼 복사됩니다. k, M, G와 같은 단위가 허용됩니다.
이 옵션은 --chunk-time 정확한 시간에 동작하도록 동적으로 chunk size를 정의한 행동을 덮어 쓸 수 있습니다. 이 옵션이 정확하게 설정되지 않았을 때, 기본값이 시작 값으로 사용되지만 나중에 툴이 이 옵션 값을 무시합니다. 만약 이 옵션이 정확하게 설정 되었다면 동적으로 설정된 것을 비활성화 하고 명시된 줄의 수만큼 정확하게 모든 청크를 만들도록 노력합니다.
만약 청크 인덱스가 유니크 하지 않다면, 설계된 것보다 청크가 더 커질 수도 있지만 이것은 희박합니다. 예를 들어 테이블에 인덱스로부터 청크된 수가 10,000인데 where절에서 나온 값이 1,000건이라면 chunk의 제일 작은 값은 10,000이 되어야 합니다. 이러한 청크는 --chunk-size-limit. 옵션 때문에 생략될 수 있습니다.
--chunk-size-limit¶
type: float; default: 4.0
설계된 청크 사이즈보다 청크를 더 크게 복사하지 않습니다.(chunk_size의 오차범위)
테이블이 유니크 한 인덱스를 가지지 않을 때, 청크사이즈는 부정확할 수 있습니다. 이 옵션은 부정확하게 최대로 견딜 수 있는 값을 명시한다. 이 툴은 explain을 사용해서 청크 안에서 가장 많은 줄을 어림잡습니다. 만약 어림잡은 값이 설계된 청크사이즈보다 2배를 넘는다면, 이 툴은 청크를 생략합니다.
이 옵션에서 1이 가장 작은 값입니다. 이것은 --chunk-size 보다 더 크지 않다는 것을 의미합니다. 아마도. 왜냐하면 explain이 어림잡아 보고된 것과 실제 청크의 줄 수가 다를 수 있기 때문에 1로 명시된 값을 원하지 않을 것입니다. 값을 0으로 함으로써 chunk check를 덮어 씌워서 비활성화 할 수 있습니다.
이 툴은 또한 --alter-foreign-keys-method 옵션을 통해 foreign key를 어떻게 다룰지를 결정하는데 사용됩니다.
--chunk-time¶
type: float; default: 0.5
각각 data 복사 쿼리에 맞는 동적으로 청크 사이즈를 맞추면서 실행하는 것이 오래 걸립니다. 이 툴은 복사비율(rows per second)과 각각 데이터 카피 쿼리 후에 청크사이즈를 맞춥니다. 그래서 다음 쿼리 실행시간이 정해집니다. 시간당 쿼리 평균이 더욱 기하급수적으로 저하되는 것을 유지합니다. 그래서 만약 서버부하 변경 때문에 서버의 성능이 변경이 된다면 이 툴을 빠르게 적응합니다.
이 옵션을 0으로 설정한다면, 청크사이즈는 자동으로 적절하게 되지 않을 것이고 쿼리 시간이 변경될 것입니다. 하지만 쿼리 청크 사이즈는 변하지 않을 것입니다. default 값은 두고 --chunk-size 값을 정확히 명시하는 게 또 다른 방법입니다.
--config¶
type: Array
config file을 comma(,)로 분할해서 읽어옵니다.
만약 명시된다면 이것은 반드시 커맨드 라인의 첫 번째에 써야 합니다.
--critical-load¶
type: Array; default: Threads_running=50
모든 청크 후에 show global status를 조사합니다. 그리고 만약 너무 부하가 높다면 꺼버립니다. 이 옵션은 MySQL 상태 값 및 한계점 목록을 comma로 구분되어 적용합니다. 각각의 값은 optional =MAX_VALUE 형태로 적어야 합니다. 만약 지정하지 않는다면, 이 툴이 현재 시작점의 값을 검수함으로써 현재 값의 두 배를 한계점으로 결정합니다.
더 자세한 건 --max-load에서 볼 수 있습니다. 이러한 옵션들은 유사하게 작동하는데, 옵션이 일시 중지하는 것 대신 툴 동작이 중단되는 것을 제외하고, 한계점을 명시하지 않는다면 기본값이 다르게 선출됩니다. 이 옵션을 설정하는 이유는 원본 테이블에 trigger 추가하는 경우를 안전체크 하는 것입니다. 아마도 모든 서버의 Threads_running은 같은 값이 아닐 것입니다. 하지만 default 50은 대부분의 서버에서는 높은 값이어서 받아들이는 도중에 작동이 멈출 것입니다.
--database¶
short form: -D; type: string
접속할 database 명
--default-engine¶
신규테이블의 engine 설정
기본적으로 원본테이블과 동일하게 새로운 테이블이 생성이 됩니다. 그래서 만약 원본 테이블이 InnoDB를 사용한다면 새로운 테이블도 InnoDB를 사용해야 합니다. 틀림없이 replication에도 연관이 있습니다. 이것은 같은 테이블에 다른 엔진을 사용하게 될 경우 replication에 적용되지 않게 됩니다. 이 옵션에서 명시하는 시스템의 기본 엔진이 신규테이블에 생성됩니다.
--defaults-file¶
short form: -F; type: string
주어진 파일로부터 mysql 옵션을 읽습니다. 반드시 절대경로로 써야 합니다.
--[no]drop-new-table¶
default: yes
원본 테이블 복사에 실패한 경우 신규테이블을 지워야 합니다.
--no-drop-new-table과 --no-swap-tables 명시하면 alert 명령어가 적용되어 있고 원본테이블로부터 데이터가 복사된 새로운 테이블을 남깁니다. 자세한 것은 --new-table-name을 보면 됩니다.
–no-drop-new-tables은 alter-foreign-keys-method drop_swap과 함께 동작하지 않습니다.
--[no]drop-old-table¶
default: yes
rename한 이후에 원본 테이블을 삭제하지 않습니다. 원본 테이블 rename이 성공적으로 된 후에는 신규 테이블이 그 자리를 차지합니다. 그리고 만약 에러가 없다면 툴이 원본 테이블을 삭제하는 것이 기본값입니다. 만약 어떠한 에러가 발생한다면 툴은 원본테이블을 남깁니다.
만약 –no-swap-tables를 명시하면 원본 테이블은 삭제되지 않습니다.
--[no]drop-triggers¶
default: yes
원본테이블에서 Trigger를 지웁니다. --no-drop-triggers는 --no-drop-old-table도 강제로 적용시킵니다.
--dry-run¶
새로운 테이블을 생성하고 alter합니다. 하지만 trigger를 생성하지 않고, copy date 또는 원본 테이블을 replace하지 않습니다.
--execute¶
이 문서를 읽고 alter table하기를 원할 것입니다. alter table을하기 위해서 반드시 이 옵션을 명시해야 합니다. 만약 하지 않는다면 이 툴은 오직 몇 가지 안전체크를 동작하고 끝날 것입니다. 이 도움이 문서를 읽고 이 툴 사용을 어떻게 해야 할지 이해하게끔 할 것입니다. 만약 이 문서를 읽지 않는다면 이 옵션을 명시하지 않을 것입니다.
--force¶
이 옵션은 alter-foreign-keys-method=none 사용하는 경우를 확인하고 우회합니다. 외래키 참조를 깨버립니다.
--help¶
tool에 대한 도움을 보여주고 끝마칩니다.
--host¶
short form: -h; type: string
접속한 호스트를 나타냅니다.
--max-flow-ctl¶
type: float
Somewhat similar to –max-lag but for PXC clusters. Check average time cluster spent pausing for Flow Control and make tool pause if it goes over the percentage indicated in the option. A value of 0 would make the tool pause when any Flow Control activity is detected. Default is no Flow Control checking. This option is available for PXC versions 5.6 or higher.
--max-lag¶
type: time; default: 1s
모든 replication 지연이 이 값보다 작아질 때까지 데이터 복사를 일시 중지시킵니다. 각 데이터 복사 쿼리 후에(각각의 청크), 이 툴은 연결된 모든 서버에 대해 Seconds_behind_master를 통해 replication 지연이 있는지 확인합니다. 만약 어떠한 replication이라도 현재 설정한 값보다 크게 지연이 된다면 이 툴은 모든 replication에 대해 체크를 하면서 --check-interval초 만큼 sleep(대기) 시킬 것입니다. 만약 --check-slave-lag를 명시한다면 이 툴은 모든 서버가 아니라 지연되고 있는 서버만 검사할 것입니다. 만약 정확하게 서버를 툴이 모니터링 하길 원한다면 DSN값에 --recursion-method를 사용해야 합니다.
이 툴은 replication 지연이 중단 될 때 동안 계속 기다립니다. 만약 하나의 replication이 중지되면, 이 툴은 replication이 시작 될 때까지 계속 기다립니다. 모든 replication이 정상 동작하고 지연이 없으면 데이터 복사가 계속됩니다.
툴은 기다리는 동안 진행상황을 기록합니다. 만약 replication이 중지되었다면 즉각적으로 진행상황을 기록하고 출력합니다. 그리고 지속적으로 진행상황을 기록합니다.
--max-load¶
type: Array; default: Threads_running=25
모든 청크를 한 후에 show global status를 검토하고 상태 값이 한계점보다 크다면 일시 중지시킵니다. 이 옵션은 MySQL의 상태 값 리스트를 콤마로 분할되어서 적용이 됩니다. optional =MAX_VALUE 형식으로 각각 적용시킵니다. 만약 값을 넣지 않으면 툴은 현재 값에 20%를 증가시켜서 검토하고 한계점으로 결정합니다.
예를들어서, 만약 Thread_connected가 너무 높은 값을 가질 때 일지정지 되길 원한다면 Threads_connected를 명시할 수 있습니다. 그리고 툴이 시작할 때 현재 값을 체크해서 값을 20%으로 추가할 것입니다. 만약 현재 값이 100이라면, 툴은 120을 넘으면 중지할 것입니다. 그리고 120아래로 줄어들면 다시 시작할 것입니다. 만약 110같이 정확한 한계 값을 명시하길 원한다면 “Threads_connected:110” 또는 “Threads_connected=110”로 사용할 수 있습니다.
이 옵션의 목적은 툴이 서버의 너무 높은 부하를 막는 것입니다. 만약 데이터 복사 쿼리가 강요한다거나 lock wait을 발생시킨다면 서버의 다른 쿼리들이 block되고 기다릴 수 있습니다. 이것은 전형적으로 Thread_running 증가를 야기시킵니다. 그리고 툴은 show global status를 하면서 각 쿼리가 끝난 후에 즉각적으로 발견할 수 있습니다. 만약 이 값에 대해 한계 점을 명시하길 원한다면 툴에게 일반적으로 쿼리가 실행될 때까지 대기하도록 할 수 있습니다. 이것은 대기하는 것을 막을 수 없지만 서버에게 대기열로부터 복구하기 위한 기회를 줄 수 있습니다. 만약 대기하는 것을 알린다면 chunk time을 최고로 줄일 수 있다.
--new-table-name¶
type: string; default: %T_new
변경되기 전에 신규테이블의 이름입니다. %T는 원본테이블이름으로 변경됩니다. 이것이 기본값으로 사용될 때, 툴은 고유한 테이블 이름을 찾기 위해서 10_를 이름에 접두사로 붙입니다. 만약 테이블이름이 명시되면 툴은 _접두사를 붙이지 않습니다. 그리고 명시한 테이블이름은 반드시 존재하지 않아야 합니다.
--password¶
short form: -p; type: string
연결할 때 쓰이는 패스워드입니다. 만약 패스워드에 콤마가 들어갈 경우 “ex,ample”과 같이 쌍 따옴표로 감싸주어야 합니다.
--pid¶
type: string
PID파일을 생성하게 합니다. 만약 PID파일이 이미 존재하고 PID가 포함하는 것이 현재 PID와 다르다면 툴이 시작되지 않습니다. 하지만 만약 PID가 존재하고 포함하고 있는 PID가 오랫동안 작동되지 않았다면 현재 PID를 PID파일에 덮어씌웁니다. PID 파일이 삭제되면 자동으로 툴이 종료됩니다.
--plugin¶
type: string
Perl 모듈 파일은 pt_online_schema_change_plugin 클래스에 정의합니다. pt-online-schema-change의 많은 부분들을 후크 할 수 있도록 Perl 모듈을 쓰기 위해서 plugin이 허용을 합니다. Perl과 이 문서의 범위를 넘어서는 Percona Toolkit에 대해 많은 지식을 요구합니다. 만약 도움을 원하거나 질문이 있다면 Percona쪽에 문의를 해야 합니다. 더 자세한 정보는 PLUGIN에 존재합니다.
--port¶
short form: -P; type: int
커넥션을 할 Port
--print¶
SQL 명령어를 출력합니다. 이 옵션은 툴에서 실행한 명령어의 대부분을 보기 위해 허용합니다. 예를 들면 --dry-run과 함께 쓸 수 있습니다.
--progress¶
type: array; default: time,30
각 줄을 복사하는 동안에 STDERR를 보고서에 작성해서 보여줍니다. 이 값은 두 개의 파트로 구성되어 있고 콤마로 분할됩니다. 첫 번째 파트는 시간, 비율, 반복을 정할 수 있습니다. 두 번째 파트는 비율, 시간(초), 반복의 수에서 얼마나 종종 출력이 될지를 명시합니다.
--quiet¶
short form: -q
STDOUT 메시지를 출력하지 않습니다(--progress 비활성화). 에러와 경고는 여전히 STDERR에서 출력됩니다.
--recurse¶
type: int
replication을 발견했을 때 계층안에서 반복하기 위한 레벨의 수입니다. 기본값은 무한대입니다. 또한 --recursion-method에서 볼 수 있습니다.
--recursion-method¶
type: array; default: processlist,hosts
replication을 찾기 위해 recursion-method를 선호합니다. 가능한 매소드는 아래와 같습니다.
METHOD USES
=========== ==================
processlist SHOW PROCESSLIST
hosts SHOW SLAVE HOSTS
dsn=DSN DSNs from a table
none Do not find slaves
SHOW SLAVE HOSTS은 신뢰할 수 없기 때문에 processlist 메소드가 default입니다. 하지만 hosts 메소드가 일반적인 포트(3306)를 쓰지 않는다면 더 나을 수 있습니다. 툴은 보통 모든 replication을 찾고 정상동작 하지만 값을 줄 경우엔 그 값이 첫 번째로 사용됩니다. hosts 메소드는 report_host, report_port 등과 같은 것을 구성하기 위해서 replication에 요청합니다.
dsn 메소드는 특별합니다. 다른 DSN을 읽어서 TABLE을 명시합니다. 그 명시된 DSN은 반드시 D와 t에 명시되거나 자격이 있는 데이터베이스 테이블이어야 합니다. DSN table은 아래와 같은 구조를 따릅니다.
CREATE TABLE `dsns` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`parent_id` int(11) DEFAULT NULL,
`dsn` varchar(255) NOT NULL,
PRIMARY KEY (`id`)
);
10.10.1.16과 10.10.1.17에 대해서 replication 지연을 모니터링 하게 만들기 위해 테이블에 h=10.10.1.16와 h=10.10.1.17를 insert해야합니다. 현재 DSN들은 id로 정렬되어 있습니다. 하지만 id와 parent_id는 그렇지 않으면 무시됩니다.
--set-vars¶
type: Array
콤마로 분리해서 MySQL 변수들을 설정합니다. variable=value 형식으로 입력해야 합니다.
아래 값은 기본 값입니다.
wait_timeout=10000
innodb_lock_wait_timeout=1
lock_wait_timeout=60
커맨드라인에서 명시된 변수들은 기본값들을 덮어씁니다. 예를 들어 –set-vars로 명시한 wait_timeout=500이 기본 값은 10000을 덮어씁니다.
이 툴은 변수를 설정하지 않으면 계속적으로 경고를 출력합니다.
--sleep¶
type: float; default: 0
각각의 청크를 복사한 후에 얼마나 많이 대기(단위는 초) 할 것인지를 정합니다. 이 옵션은 --max-lag와 --max-load에 의해서 조절이 불가능할 때 유용하게 쓰입니다. 테이블이 작을 경우 0.1과 같이 작은 값으로 사용되지만 아주 큰 테이블일 경우 아주 길게 잡아야 합니다.
--socket¶
short form: -S; type: string
커넥션을 하기 위해 사용하는 socket
--statistics¶
내부 카운터에 대한 통계를 출력합니다. insert의 수와 비교해서 얼마나 많은 경고들이 억제되었는지 보는데 유용합니다.
--[no]swap-tables¶
default: yes
alter table된 원본테이블과 신규테이블을 교체합니다. 이 단계에서 원본테이블자리에 새로운 테이블 스키마가 만들어지면서 online schema change 프로세스가 완료됩니다. 원본테이블은 과거 테이블이 되고 --[no]drop-old-table을 비활성화 하지 않는 한 툴이 테이블을 삭제합니다.
--tries¶
type: array
중요한 작업을 얼마나 많이 시도할지를 결정합니다. non-fatal, recoverable errors때문에 작동실패가 의심된다면 툴이 대기하고 작동을 재시도 할 것입니다. 이러한 작동들이 기본값만큼 재시도 되고 재시도 사이의 시간(seconds)은 대기합니다.
OPERATION TRIES WAIT
=================== ===== ====
create_triggers 10 1
drop_triggers 10 1
copy_rows 10 0.25
swap_tables 10 1
update_foreign_keys 10 1
analyze_table 10 1
기본값을 변경하기 위해서 아래와 같이 신규 값을 명시합니다.
--tries create_triggers:5:0.5,drop_triggers:5:0.5
이 툴은 create_triggers와 drop_triggers에 대해 시도하는 중간의 대기시간을 0.5초로 잡고 5번 재시도하게끔 만든 것입니다.
정확한 포맷은 아래와 같습니다.
operation:tries:wait[,operation:tries:wait]
세가지 값 모두가 반드시 명시되어야 합니다.
대부분의 작동들이 메타데이터에 대한 락 때문에 MySQL 5.5이상 버전에서 lock_wait_timeout(--set-vars)의 영향을 받습니다. MySQL의 어떤 버전에서는 innodb_lock_wait_timeout에 의해 줄 복사가 영향을 받습니다. create trigger와 dropping 트리거의 경우, 각각 CREATE TRIGGER와 DROP TRIGGER에 시도수가 적용됩니다. 줄 복사의 경우, 전체테이블이 아니라 각 청크에 대해 시도수가 적용됩니다. 테이블 교체의 경우, 일반적으로 한번만 rename table문이 적용되기 때문에 시도수가 하나에 대해 적용됩니다. 외래키 참조조건을 재설정하는 경우, 각각의 alter문에 시도수가 적용됩니다.( --alter-foreign-keys-method로 rebuild_constraints 하거나 drop_swap method인 경우)
이 툴은 에러가 발생했을 경우 아래와 같이 각 동작 별로 재시도합니다:
Lock wait timeout (innodb_lock_wait_timeout and lock_wait_timeout)
Deadlock found
Query is killed (KILL QUERY <thread_id>)
Connection is killed (KILL CONNECTION <thread_id>)
Lost connection to MySQL
손실이 많을 경우 커넥션이 죽고 툴이 자동으로 재 접속 할 것입니다.
실패와 재시도는 --statistics로 인해 기록됩니다.
--user¶
short form: -u; type: string
현재 유저가 아니라면 접속하기 위한 유저입니다.
--version¶
버전을 보여주고 종료한다.
--[no]version-check¶
default: yes
Percona Toolkit, MySQL, 또 다른 프로그램들에 대해 최종 버전을 체크합니다.
이것은 일반적으로 자동적으로 업데이트를 체크한다는 두 가지 특성이 있습니다. 첫 번째로, 이 툴은 로컬 시스템에 있는 자신과 다른 프로그램의 버전을 체크합니다. 예를 들어 모든 MySQL서버와 연결된 Perl, Perl 모듈인 DBD::mysql의 버전을 체크합니다. 두 번째로 이것은 버전에 관하여 알려진 문제들을 알려줍니다. 예를 들어 MySQL 5.5.25와 5.5.25a는 치명적인 버그를 가지고 있습니다.
툴이 일반적으로 출력하기 전에 업데이트나 알려진 문제들에 대해 먼저 출력이 됩니다.
이 특성은 툴의 일반 동작에서 절대적으로 방해할 것입니다. 더 자세한 사항은 https://www.percona.com/version-check를 보면 됩니다.
PLUGIN¶
new() 서브루틴을 함께 쓰는 pt_online_schema_change_plugin 클래스를 호출해서 정의해야만 명시됩니다. 이 툴은 해당 클래스 대신에 생성할 것이고 정의된 훅을 호출합니다. 훅 없이는 플러그인을 제대로 쓸 수 없습니다.
아래와 같이 존재합니다.
init
before_create_new_table
after_create_new_table
before_alter_new_table
after_alter_new_table
before_create_triggers
after_create_triggers
before_copy_rows
after_copy_rows
before_swap_tables
after_swap_tables
before_update_foreign_keys
after_update_foreign_keys
before_drop_old_table
after_drop_old_table
before_drop_triggers
before_exit
get_slave_lag
각각의 훅은 다른 논쟁으로부터 통과됩니다. 훅을 위해 통과된 논쟁을 보기 위해 툴의 소스코드 안에서 훅의 이름을 찾습니다. 아래와 같이.
# --plugin hook
if ( $plugin && $plugin->can('init') ) {
$plugin->init(
orig_tbl => $orig_tbl,
child_tables => $child_tables,
renamed_cols => $renamed_cols,
slaves => $slaves,
slave_lag_cxns => $slave_lag_cxns,
);
}
모든 훅을 콜 할 때 # --plugin hook을 앞에서 선언을 해주어야 합니다.
질문이나 도움이 필요하면 Percona와 접촉해야 합니다.
DSN OPTIONS¶
이러한 DSN 옵션들은 DSN을 생성하는데 사용된다. 각각의 옵션은 option=value같이 주어집니다. 이 옵션들은 P, p는 다른 옵션인 것처럼 세심합니다. =(equal) 앞뒤로 공백이 있으면 안 됩니다. 만약 빈칸을 넣을 경우에는 따옴표를 반드시 붙여야 합니다. DSN들은 콤마로 구분되어있습니다. percona-toolkit 매뉴얼 페이지에서 더 자세하게 나와있습니다.
- A
dsn: charset; copy: yes, 기본 언어 셋
- D
dsn: database; copy: yes, 신규 또는 원본 테이블을 위한 데이터베이스
- F
dsn: mysql_read_default_file; copy: yes, 주어진 파일로부터 기본 옵션을 읽음
- h
dsn: host; copy: yes, 연결할 호스트
- p
dsn: password; copy: yes, 연결할 패스워드이며, 패스워드에 콤마가 들어가면 쌍 따옴표를 써줘야 합니다..
- P
dsn: port; copy: yes, 연결을 위한 사용할 포트
- S
dsn: mysql_socket; copy: yes, 연결을 위해 사용할 소켓 파일
- t
dsn: table; copy: no, alter를 할 테이블이름
- u
dsn: user; copy: yes, 현재 유저가 아니라면, 유저이름
ENVIRONMENT¶
환경변호 PTDEBUG는 STDERR 디버깅 출력이 가능합니다. 디버깅을 활성화 고 파일에 모든 출력을 캡쳐 할 수 있습니다. 아래와 같이 :
PTDEBUG=1 pt-online-schema-change ... > FILE 2>&1
주의 : 디버깅 출력물은 양이 많고 메가바이트로 변환될 수 있습니다.
SYSTEM REQUIREMENTS¶
Perl, DBI, DBD::mysql과 Perl이 신규버전으로 설치되도록 몇 가지 중요한 패키지도 필요합니다.
이 툴은 MySQL 5.0.2이전버전은 Trigger가 지원되지 않기 때문에 이상 버전에서만 작동됩니다.
BUGS¶
알려진 버그의 경우, http://www.percona.com/bugs/pt-online-schema-change를 보면 됩니다.
https://bugs.launchpad.net/percona-toolkit에 버그리포트를 작성할 시엔 아래와 같이 써주면 좋습니다.
- tool를 실행 시키기 위해 사용된 완벽한 command-line
- Tool의 버전(--version)
- 연관된 모든 MySQL 서버 버전
- Tool STDERR을 포함한 출력물
- 입력 파일들(log, dump, config file 등)
가능하면, “ENVIRONMENT”를 보고 PTDEBUG와 함께 돌려서 디버깅을 포함한 출력물을 보내야 합니다.
'MySQL > MySQL Admin' 카테고리의 다른 글
| Mysql prompt 변경하기! (0) | 2015.12.04 |
|---|---|
| Transaction이란? (0) | 2015.12.04 |
| percona toolkit - pt-online-schema-change dry-run and print (0) | 2015.11.26 |
| percona toolkit 설치 (0) | 2015.11.24 |
| percona toolkit - pt-online-schema-change 기본 설명 (0) | 2015.11.24 |