책너두 (Real MySQL 8.0 1권) 2일차 (~35p)

요약

서버를 시작하고 종료하기 위해 필요한 데이터 파일과 로그파일의 존재를 알게 됨.

클린 셧다운을 이용하면 MySQL 서버 기동 시 트랜잭션 복구 과정이 없이 빠르게 재기동 가능.

MySQL 서버 접속(소켓, TCP/IP) 방식을 알게 됨.

2가지 MySQL 서버 업그레이드 방식과 그 장단점을 알게 됨.

특히 8.0 버전에 대한 추가 변경 사항들을 알게됨.

발췌

패스..

메모

설정파일 & 데이터 파일 준비

MySQL 서버를 시작하기 위해서는 트랜잭션 로그 파일과 시스템 테이블이 준비되어야 함.

MySQL 서버 설치시, /etc/my.cnf 설정 파일이 준비되고, MySQL 서버를 실행하는데 꼭 필요한 3~4개의 기본적인 설정만 기록돼 있음.

MySQL 서버를 실행하기 위해서

• 초기데이터 파일 (시스템 테이블이 저장되는 데이터 파일)
• 트랜잭션 로그 (리두 로그) 파일

을 생성 해야 한다.

mysqld --defaults-file=/etc/my.cnf --initialize-insecure

• --initialize-insecure 옵션을 사용하면 필요한 초기 데이터 파일과 로그 파일을 생성하고, 비밀번호가 없는 관리자 계정인 root 유저를 생성한다.
• --initialize 옵션을 사용하면 생성된 관리자 계정의 비밀번호를 에러로그 파일(/var/log/mysqld.log) 로 기록한다.
• 파일의 제일 마지막에 root@localhost 관리자 계정이 생기고, 비밀번호는 DqguE(h5o>1S 라고 기록됨.

시작과 종료

• 유닉스 계열 운영체제에서 RPM 패키지로 MySQL 을 설치했다면 자동으로 /usr/lib/systemd/system/mysqld.service 파일이 생성됨. → systemctl 유틸리티를 이용해 MySQL 을 기동하거나 종료하는것이 가능

# mysql 서버 실행
systemctl start mysqld

# mysql 서버 상태 확인
systemctl status mysqld

# mysql 서버 종료
systemctl stop mysqld

# 원격 mysql 서버 셧다운 (SHUTDOWN 권한을 가지고 있어야 함)
SHUTDOWN

MySQL 배포판과 함께 제공되는 mysqld_safe 스크립트를 사용하여 MySQL 서버를 시작하고 종료할 수 있음. → my.cnf 의 “[mysqld_safe]” 섹션의 설정을 참고하여 서버를 실행한다. 해당 섹션에서만 설정 가능한 “malloc-lib” 같은 시스템 설정을 적용하려면 mysqld_safe 스크립트를 이용해서 MySQL 서버를 시작해야 함.

• MySQL 서버에서 실제 트랜잭션이 정상 커밋돼도 데이터 파일에 변경된 내용이 기록되지 않고 로그 파일(리두 로그) 에만 기록돼 있을 수 있다. 서버를 종료하고 나중에 다시 서버를 켜도 이런 현상이 생길 수 있음. → 이런 현상은 꽤 일반적임.
• 아예 MySQL 서버가 종료될 때 모든 커밋된 내용을 데이터 파일에 기록하고 종료하게 할 수 있음. → MySQL 서버의 옵션을 변경하고 MySQL 서버를 종료하면 됨.

mysql> SET GLOBAL innodb_fast_shutdown=0;
linux> systemctl stop mysqld.service

# 원격으로 mysql 서버 종료 시
mysql> SET GLOBAL innodb_fast_shutdown=0;
mysql> SHUTDOWN;

• 이렇게 커밋된 데이터를 데이터 파일에 적용하고 종료하는 것을 클린 셧다운 (Clean shutdown) 이라고 표현함.
• 클린 셧다운으로 종료하면 MySQL 서버가 다시 기동할 때 별도의 트랜잭션 복구 과정을 진행하지 않기 때문에 빠르게 시작할 수 있음.

MySQL 서버가 시작되거나 종료될 떄 MySQL 서버 (InnoDB 스토리지 엔진) 의 버퍼 풀 내용을 백업하고 복구하는 과정이 내부적으로 실행됨. → 실제 버퍼 풀을 백업하는 것이 아니고 데이터 파일의 데이터 페이지에 대한 메타 정보를 백업하므로 용량이 크지 않음. 백업 자체도 빠르게 완료됨. 하지만 서버가 새로 시작되면서 디스크에서 데이터 파일을 모두 읽고 적재해야 하므로 상당한 시간이 걸림. → 서버가 버퍼 풀 내용을 복구하고 있는지 확인해 보는게 좋다.

서버 연결 테스트

MySQL 서버에 직접 접속한다.

서버 프로그램 (mysqld) 과 함께 설치된 클라이언트 프로그램(mysql) 을 실행하면 된다.

1).. linux> mysql -uroot -p --host=localhost --socket=/tmp/mysql.sock
2).. linux> mysql -uroot -p --host=127.0.0.1 --port=3306
3).. linux> mysql -uroot -p

1) MySQL 소켓 파일을 이용해 접속

2) TCP/IP 를 통해 127.0.0.1 (localhost) 에 접속 → port 를 명시하는게 일반적임

• 원격 호스트에 있는 MySQL 서버에 접속하려면 반드시 2) 방식을 사용해야함.
• host 를 localhost 로명시한다면 MySQL 클라이언트 프로그램은 항상 소켓 파일을 통해 MySQL 서버에 접속한다.
  • Unix Domain Socket 을 이용하는 방식임. TCP/IP를 통한 통신이 아니라 유닉스의 프로세스간 통신 (IPC : Inter Process Communication)
• host 를 127.0.0.1 로 명시하면 자기 서버를 가리키는 루프백 IP 지만 TCP/IP 통신 방식을 사용하게 된다.

3) 별도의 호스트 주소와 포트를 명시하지 않음. → 기본값은 localhost 이고, 소켓 파일을 사용하게 됨. 소켓 파일 위치는 MySQL 서버의 설정 파일에서 읽어서 사용한다. 이 유닉스 소켓 파일은 서버를 재시작 하지 않으면 다시 만들어 낼 수 없음. 실수로 삭제하지 않도록 주의

• MySQL 서버에 직접 로그인하지 않고 원격 서버의 MySQL 서버 접속 가능 여부만 확인해야 하는 경우도 있음.
  • 커넥션만 가능한지 확인할 것이므로 MySQL 클라이언트 설치하지 않아도 됨. (보안상의 이유로 아예 설치하지 못할 수도 있음.)
  • 네트워크 연결이 정상적인지 확인하는 경우 연결 테스트 를 진행한다.
    • telnet
    • nc(Netcat)
  • MySQL 이 설치된 IP 주소와 포트를 입력하여 MySQL 버전 정보를 보내는지 확인할 수 있다.
  • telnet 혹은 nc 응답이 정상인데도 우리의 어플리케이션이 MySQL 서버에 접속하지 못하면 계정 비밀번호가 틀렸거나 host 의 부분 접속이 제한되어 있을 것이다.

MySQL 서버 업그레이드

2가지 방법이 있음.

• MySQL 서버 데이터 파일을 그대로 두고 업그레이드 한다.
  • 인플레이스 업그레이드 (In-Place Upgrade) 라고 함.
  • 여러 제약사항이 있지만 업그레이드 시간을 크게 단축할 수 있음.
• mysqldump 도구를 이용해 MySQL 서버의 데이터를 SQL 문장 혹은 텍스트 파일로 덤프 후, 새로 업그레이드된 버전의 MySQL 서버에 덤프된 데이터를 적재한다.
  • 논리적 업그레이드 (Logical Upgrade) 라고 함.
  • 버전간 제약 사항이 거의 없지만 업그레이드 시간이 매우 많이 소요될 수 있음.

인플레이스 업그레이드 제약 사항

업그레이드

• 마이너 버전 간 업그레이드
  • 대부분 데이터 파일의 변경 없이 진행됨. 여러 버전을 건너뛰어서 업그레이드 하는 것을 허용
• 메이저 버전 간 업그레이드
  • 데이터 파일의 변경이 필요하므로 반드시 직전 버전에서만 업그레이드를 허용
• 만약 지금 5.1 버전을 쓰고 있는데, 8.0 까지 업그레이드 해야 된다면 5.1 → 5.5 → 5.6 → 5.7 → 8.0 의 업그레이드 과정을 거쳐야 함. → 상당히 번거로움
• 이럴 때는 mysqldump 프로그램을 사용하는 논리적 업그레이드가 더 나은 방법일 수 있음
• 메이저 버전 업그레이드 시, 특정 마이너 버전에서만 가능한 경우도 있음…
  • GA 버전이 아니면 바로 다음 메이저 버전으로 업그레이드 할 수 없음 (ex: 5.7.8 → 8.0 으로 업그레이드 불가능. 5.7.8 이 GA 버전이 아니기 때문)

MySQL 8.0 업그레이드 시 고려 사항

8.0 에서는 많은 기능들이 개선되고 변경됨. 업그레이드 전 영향을 미칠만한 것들을 검토해보는게 좋음.

• 사용자 인증 방식 변경
  • 8.0 부터 Caching SHA-2 Authentication 이 기본 인증 방식으로 바뀜
• MySQL 8.0 과의 호환성 체크
  • 호환 되지 않는 데이터 타입 혹은 함수가 있는지 확인
• 외래키 이름의 길이
  • 8.0 부터 외래키 이름이 64글자로 제한 (64자 넘어가는 것이 있는지 확인 필요)
• 인덱스 힌트
  • 기존의 인덱스 힌트를 8.0 에서 사용할 때 성능 테스트를 먼저 수행하여 성능 저하의 유무를 먼저 봐야 함 → 성능 저하를 유발 할 수 있기 때문
• GROUP BY 에 사용된 정렬 옵션
  • group by 의 asc, desc 를 제거 하자.
• 파티션을 위한 공용 테이블 스페이스
  • 8.0 부터 파티션의 각 테이블 스페이스를 공용 테이블 스페이스에 저장할 수 없음. → 기존의 공용 테이블 스페이스에 저장되어 있는지 확인 필요 → 있으면 개별 테이블 스페이스를 사용하도록 변경 필요

MySQL 8.0 업그레이드

• 5.7 → 8.0 업그레이드, 이전 버전과 같이 단순하지 않음. (내부적으로 상당히 복잡)
• 8.0 부터 시스템 테이블의 정보와 데이터 딕셔너리 정보의 포맷이 완전히 바뀜
• 5.7 → 8.0 업그레이드 시 크게 두가지 단계로 나뉘어 처리함
  • 데이터 딕셔너리 업그레이드
  • 서버 업그레이드
• 8.0.15 까지는 데이터 딕셔너리 업그레이드는 mysqld 프로그램이 실행하고 서버 업그레이드는 mysql_upgrade 프로그램이 실행함.
• 8.0.16 부터는 mysql_upgrade 유틸리티가 없어지고 mysqld 프로그램이 데이터 딕셔너리와 서버를 순서대로 업그레이드 해줌.

8.0.16 이상 버전으로 업그레이드 할때 --upgrade 옵션으로 데이터 딕셔너리 업그레이드 수행 여부를 제어할 수도 있음.