1. InnoDB buffer pool size 온라인으로 변경하기
MySQL Ver. 5.7.5 부터 추가된 기능으로 시스템 변수에 값을 변경하여 버퍼풀 사이즈의 크기를 변경하는 것이 가능하다. 실제 내부적으로는 모든 실행중인 트랜잭션들이 완료될 때까지 작업을 시작하지는 않는다. 그리고, 변경하는 작업이 시작되면 InnoDB 에서 새로운 트랜잭션을 실행하지 못한다. 즉, 사이즈를 변경하는 작업 중일 때에는 어떤 트랜잭션도 실행 되지 않는다. 이 규칙에도 예외는 있다.
바로 사이즈를 줄이는 작업인데, 이 작업이 조각모음을 통해 페이지가 제거되는 작업으로 처리가 된다고 판단되면 동시 작업이 허용되고, 위에서 설명한 규칙이 적용되지 않는다.
참고 사항으로 Nested Transaction(중첩된 트랜잭션)의 경우에 초기화와 실제 사이즈 수정 작업 사이에 운나쁘게 걸리게 되면 실패할 수도 있다.
이 작업을 위해서 상태 변수로 InnoDB_buffer_pool_resize_status가 추가되었다.
그리고, 에러 로그 파일을 통해서도 확인이 가능하다.
자세한 내용은 다음의 url에서 확인할 수 있다.
2. Online Rename Index 작업
MySQL Ver. 5.7 부터 Index의 이름을 변경하는 Alter 작업은 Online 중에 메타 데이터만 변경하는 것으로 작업이 가능하다.
3. Online Enlarge VARCHAR Size 작업
MySQL Ver. 5.7 부터 VARCHAR 타입의 컬럼에 대해 크기를 키우는 작업에 대해서는 온라인으로 메타 데이터만 수정하여 처리하는 것이 가능하다.
크기를 키우는 것에 대해서만이다.
4. ALTER 작업에 대한 성능 개선
현재 Index를 생성할 때 데이터를 다시 입력하는 작업을 진행한다. 데이터가 적으면 문제가 되지 않지만, 데이터의 볼륨이 큰 경우, 이 작업은 굉장히 느린 작업이 된다. 그래서 다시 데이터를 입력할 때, Bulk load를 통해 작업을 진행하도록 수정하였다. 이렇게 작업하면 좀 더 나은 성능 향샹을 노릴 수 있다.
5. Buffer pool list 스캔과 프로세싱 코드 최적화
플러쉬 리스트 배치 작업이 진행될 때 과도한 양의 페이지를 스캔하는 일이 발생하면 성능이 뚝 떨어지는 현상이 이전 버젼에서는 존재했다. MySQL Ver. 5.7에서는 이 문제를 해결 하기 위해 Hazard Pointer 개념을 도입하였다.
Hazard Pointer는 멀티 스레드를 사용하는 컴퓨팅 환경에서 lock-free data 구조 에서 각 노드들의 dynamic memory management 에 의해 발생하는 문제를 해결하기 위하여 도입된 것이다. 자세한 내용은 다음의 위키에서 확인해 보도록 하자.~
https://en.wikipedia.org/wiki/Hazard_pointer
6. InnoDB 로그에 대한 checksum 활성화 여부 설정 기능 추가
MySQL Ver. 5.7.8 부터 InnoDB Log Checksum에 대한 알고리즘을 선택할 수있는 기능이 추가되었다. MySQL Ver. 5.7.8에서는 innodb_log_checksum_algorithm 이라는 시스템 변수를 사용하여 제공하고 있고, MySQL Ver. 5.7.9 부터는 innodb_log_checksum 이라는 시스템 변수를 통해 제공하고 있다.
이전에는 무조건 innodb 알고리즘만을 내부적으로 사용하였다. 현재는 사용할지 말지를 결정할 수 있는데, 왜냐하면, innodb_log_checksum 시스템 변수는 알고리즘은 CRC-32C로 고정되어있고 사용 여부만 설정할 수 있기 때문이다.
MySQL Ver. 5.7.8 에서 제공된 innodb_log_checksum_algorithm은 어떤 알고리즘을 사용할 것인지 선택도 가능하다. 하지면 현재 GA 최신버젼에서는 삭제되었다.
2. Crash Recovery 시에 TableSpace 찾기 프로세스 성능 개선
MySQL Ver. 5.7.5 부터 InnoDB의 Crash Recovery 진행시에 해당 TableSpace를 찾는 방식이 개선되었다.
이전에는 data directory안의 모든 ibd 파일을 찾아서 space_id를 찾아냈었다. 즉, 모든 TableSpace 파일을 열어서 Space id와 테이블 스페이스 파일의 맵핑 테이블을 만들어서 그것으로 리두로그를 이용한 Crash Recovery 작업을 진행했다. MySQL Ver. 5.6.6 부터는 테이블 생성 시 DATA DIRECTORY 옵션을 사용하여 생성하는 데이터 파일의 위치를 지정할 수 있었다. 그래서 해당 정보를 가지고 있는 isl 이라는 파일을 만들었는데, 여기에 data directory가 아닌 곳에 생성된 데이터 파일의 위치정보를 저장하였다.
MySQL Ver. 5.7.5 부터는 다음의 방식으로 데이터 파일의 space_id를 찾는 방식이 개선되었다.
[Redo log Record Type 추가]
:MLOG_FILE_NAME, MLOG_FILE_DELETE : space_id와 데이터 파일 정보를 가진 레코드 타입
1. MLOG_FILE_NAME : 가장 최근의 체크포인트 작업 이후에 발생한 변경작업에 영향을 받은 데이터 파일의 위치 정보및 space id를 가지고 있다.
2. MLOG_FILE_DELETE : 데이터 파일이 삭제될 경우 작성되는 레코드 타입으로 추정(?)
위의 기능 추가로 다음과 같은 효과를 얻을 수 있다.
1. Crash Recovery를 진행하기 위해 Data Directory 하위의 모든 데이터 파일에 대한 스캔 작업을 하지 않아도 된다.
2. 가장 최근에 진행한 체크 포인트 작업 이후에 변경 작업이 발생한 데이터 파일에 대해서면 작업이 진행된다.
3. 임의로 사라진 데이터 파일로 인해 redo log 작업 내용이 사라지지 않는다. 만약, 작업하고자 하는 데이터 파일이 존재하지 않으면 작업은 중지된다.
4. 만약, 맞지 않는 데이터를 가진 isl 파일로 인해 복구 작업이 실패되면 isl 파일은 삭제된다. 이 파일은 이젠 모든 복구 작업 완료 후, 테이블이 오픈될 때에만 사용되어진다.
MySQL Ver. 5.7.6 부터는 InnoDB General Tablespace 기능 추가로 인해 다음과 같은 작업이 추가되었다.
1. 내부 Data Dictionary에 저장된 SYS_TABLESPACE 를 스캔하여, SYS_DATAFILES 테이블 안의 모든 내용을 찾는다. 그리고 이전에 생성된 모든 General Tablespace를 오픈한다. 테이블 스페이스 내부가 비어있어도 오픈한다.
2. 내부 Data Dictionary에 저장된 SYS_TABLES 를 찾아서 0보다큰 space id를 가진 테이블에 대대 SYS_DATAFILES 에서 정보를 찾아서 해당 데이터 파일을 모두 오픈한다.
자세한 내용은 다음의 url에서 확인할 수 있다.
https://dev.mysql.com/doc/refman/5.7/en/innodb-recovery-tablespace-discovery.html
'MySQL별책부록' 카테고리의 다른 글
| MySQL Ver. 5.7에서 임시테이블에 대한 성능 개선 (0) | 2016.06.02 |
|---|---|
| MySQL Ver. 5.7 DML 작업 성능 개선 (1) | 2016.06.01 |
| 26. MySQL Ver. 5.7 show slave status 기능 개선 (0) | 2016.05.03 |
| 25. MySQL Ver. 5.7 NUMA 성능 지원 기능 추가 (1) | 2016.03.24 |
| 24. DATETIME과 TIMESTAMP 사용법 (0) | 2015.10.06 |