MySQL 5.7에서 MySQL 8.0 업그레이드 고려사항 및 차이점, MySQL 서버 설정

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

---

MySQL 8.0에서는 상당히 많은 기능들이 개선되거나 변경 됐다. 그 중에서도 MySQL 5.7 버전과 8.0 버전의 기본적인 부분의 차이점과 MySQL 8.0버전의 기본적인 부분의 차이점과 MySQL 8.0에서는 사용할 수 없는 기능들이 몇 가지 있다. 그래서 반드시 MySQL 8.0으로 업그레이드하기 전에 아래 내용이 영향을 미치지 않는지 검토해 봐야 한다.

 

• 사용자 인증 방식 변경 : MySQL 8.0 버전부터는 Caching SHA-2 Authentication 인증 방식이 기본 인증 방식으로 바뀌었다. MySQL 5.7에 존재했던 사용자 계정은 여전히 Native Authentication 인증 방식을 사용하겠지만 MySQL 8.0 버전에서 별도의 옵션 없이 생성되는 사용자 계정은 Caching SHA-2 Authentication 인증 방식을 사용하게 될 것이다. 만약 Native Authentication을 계속 사용하고자 한다면 MySQL 서버를 시작할 때 --dafault-authentication-plugin=mysql_native_password 파라미터를 활성화 해야한다.
  • Native Authentication : 해당 방식은 MySQL 서버에 기본적으로 내장되어 있으며, 사용자의 계정 정보와 암호를 MySQL의 내부 데이터 딕셔너리에 저장한다. native authentication 방식에서는 사용자 계정과 암호가 MySQL의 'mysql.user' 테이블에 저장된다. 암호는 해시된 형태로 저장되며, 암호를 비교할 때 클라이언트에서 전달된 암호를 해시하여 저장된 암호와 비교한다. 이 방식은 MySQL 서버에 대한 접근 제어 및 인증을 처리하는 데 사용된다.
  • Caching SHA-2 Authentication : 해당 방식은 보안 향상을 위해 사용자 암호를 SHA-256 해시로 저장하고, 통신 과정에서 보안 강화를 위해 SSL/TLS 암호화를 사용한다.
• MySQL 8.0과의 호환성 체크 : MySQL 8.0 업그레이드 전에 MySQL 5.7 버전에서 손상된 FRM 파일이나 호환되지 않는 데이터 타입 또는 함수가 있는지 mysqlcheck 유틸리티를 이용해 학인해봐야 한다.
• 외래키 이름의 길이 : MySQL 8에서는 외래키(Foreign Key)의 이름이 64글자로 제한된다. 그래서 기존의 MySQL 서버에서 외래키 이름이 64글자 이상인 것이 있는지 확인하고 필요하면 변경하여야 한다.
• 인덱스 힌트 : MySQL 5.x에서 사용되던 인덱스 힌트가 있다면 MySQL 8.0에서 먼저 성능 테스트를 수행해야 한다. MySQL 5.x에서는 성능 향상에 도움이 됐지만 MySQL 8.x에서는 오히려 성능 저하를 유발할 수도 있다.
• 파티션을 위한 공용 테이블스페이스 : MySQL 8.x에서는 파티션의 각 테이블스페이스를 공용 테이블스페이스에 저장할 수 없다. 그래서 파티션의 테이블스페이스가 공용 테이블스페이스에 저장된 것이 있는지 먼저 확인하고, 있다면 ALTER TABLE ... REORGANIZE 명령을 실행해 개별 테이블스페이스를 사용하도록 변경해야 한다.

 

 

 

 

 

 

 

 

▶ MySQL 8.0 업그레이드

---

MySQL 5.7에서 MySQL 8.0으로 업그레이드 하는 가정은 이전 버전처럼 단순하지 않다. 사용자의 눈에 보이는 것은 별로 차이가 없지만 MySQL 서버 내부적을 진행하는 업그레이드 과정은 상당히 복잡하다.

 

→ 대표적으로 MySQL 8.0 버전부터는 시스템 테이블의 정보와 데이터 딕셔너리(Data Dictionary) 정보의 포맷이 완전히 바뀌었다.

 

MySQL 5.7에서 MySQL 8.0으로의 업그레이드는 크게 두 가지 단계로 나뉘어서 처리된다.

 

1. 데이터 딕셔너리 업그레이드 : MySQL 5.7 버전까지는 데이터 딕셔너리 정보가 FRM 확장자를 가진 파일로 별도로 보관됐었는데. MySQL 8.0 버전부터는 데이터 딕셔너리 정보가 트랜잭션이 지원되는 InnoDB 테이블로 저장되도록 개선됐다. 데이터 딕셔너리 업그레이드는 기존의 FRM 파일의 내용을 InnoDB 시스템 테이블로 저장한다. MySQL 8.0 버전부터는 딕셔너리 데이터의 버전 간 호환성 관리를 위해 테이블이 생성될 때 사용된 MySQL 서버의 버전 정보도 함께 기록한다.
2. 서버 업그레이드 : MySQL 서버의 시스템 데이터베이스(performance_schema와 information_schema, 그리고 mysql DB)의 테이블 구조를 MySQL 8.0 버전에 맞게 변경한다.

 

MySQL 8.0.15 버전까지는 '데이터 딕셔너리 업그레이드' 작업은 MySQL 서버(mysqld) 프로그램이 실행하고 '서버 업그레이드' 작업은 mysql_upgrade 프로그램이 실행했다. 그래서 MySQL 5.7 버전에서 MySQL 8.0.15 이하 버전으로 업그레이드 할 때는 다음 절차에 따라 업그레이드를 진행했다.

 

1. MySQL 셧다운
2. MySQL 5.7 프로그램 삭제
3. MySQL 8.0 프로그램 설치
4. MySQL 8.0 서버(mysqld) 시작(MySQL 서버가 데이터 딕셔너리 업그레이드를 자동 실행)
5. mysql_upgrade 프로그램 실행(mysql_upgrade 프로그램이 시스템 테이블의 구조를 MySQL 8.0에 맞게 변경)

 

하지만 MySQL 8.0.16부터는 mysql_upgrade 유틸리티가 없어지고, MySQL 서버 프로그램(Mysqld)이 시작되면서 모든 업그레이드 작업을 다음과 같이 '데이터 딕셔너리 업그레이드'와 '서버 업그레이드'를 순서대로 실행한다.

 

1. MySQL 셧다운
2. MySQL 5.7 프로그램 삭제
3. MySQL 8.0 프로그램 설치
4. MySQL 8.0 서버(mysqld) 시작(MySQL 서버가 데이터 딕셔너리 업그레이드를 실행 후, 시스템 테이블 구조를 MySQL 8.0에 맞게 변환)

지금까지는 MySQL 서버의 버전을 업그레이드하고도 mysql_upgrade 유틸리티를 실행하지 않아서 이런 저런 이슈가 발생하곤 했다.

하지만 이제부터는 MySQL 서버가 업그레이드됐다면 MySQL 서버 프로그(mysqld)이 시작되면서 자동으로 필요한 작업을 수행하기 때문에 사용자 실수를 더 줄일 수 있게 됐다.

 

 

 

※ 참고 : MySQL 8.0.16 이상 버전으로 업그레이드 할 때도 --upgrade 옵션을 이용해 데이터 딕셔너리 업그레이드를 수행할지 여부를 제어할 수 있다. --upgrade 파라미터로 다음 4가지 값을 선택할 수 있다.

파라미터 값	데이터 딕셔너리 업그레이드	서버 업그레이드
AUTO	필요한 경우 실행	필요한 경우 실행
NONE	X	X
MINIMAL	필요한 경우 실행	X
FORCE	필요한 경우 실행	항상 실행

 

 

 

 

 

 

 

▶ 서버 설정

---

일반적으로 MySQL 서버는 단 하나의 설정 파일을 사용하는데, 리눅스를 포함한 유닉스 계열에서는 my.cnf라는 이름을 사용하고, 윈도우 계열에서는 my.ini라는 이름을 사용한다. MySQL 서버는 시작될 때만 이 설정 파일을 참조하는데, 이 설정 파일의 경로가 고정돼 있는 것은 아니다. MySQL 서버는 지정된 여러 개의 디렉터리를 순차적으로 탐색하면서 처음 발견된 my.cnf 파일을 사용하게 된다.

 

실제 MySQL 서버는 단 하나의 설정 파일(my.cnf)만 사용하지만 설정 파일이 위치한 디렉터리는 여러 곳일 수 있다는 것이다. 이러한 특성은 MySQL 사용자를 상당히 혼란스럽게 하는 부분이기도 하다.

 

1. /etc/my.cnf File
2. /etc/mysql/my.cnf File
3. /usr/etc/my.cnf File
4. ~/.my.cnf File

 

만약 실수로 1번과 2번 디렉터리에 각각 my.cnf 파일을 만든 경우, MySQL 서버가 어느 디렉터리의 my.cnf 파일을 참조해서 기동했는지 알아내기가 쉽지 않다. 이러한 경우에는 위 예제의 명령으로 MySQL 서버가 어느 디렉터리의 my.cnf 파일을 먼저 읽는지(우선 순위가 높은지)를 확인할 수 있다.

 

MySQL 서버용 설정 파일은 주로 1번이나 2번을 사용하는데, 하나의 장비(서버 머신)에 2개 이상의 MySQL 서버(인스턴스)를 실행하는 경우에는 1번과 2번은 충돌이 발생할 수 있으므로 공유된 디렉터리가 아닌 별도 디렉터리에 설정 파일을 준비하고 MySQL 시작 스크립트의 내용을 변경하는 방법을 사용한다. 그러나 하나의 서버에 2개 이상의 MySQL 서버(인스턴스)를 실행하는 형태로 서비스하는 곳은 별로 없으며 흔하지도 않다.

 

내가 발생했던 에러도 위의 문제로 발생했던 에러이고 이에 대해 작성했던 글도 존재한다.

https://wonsjung.tistory.com/580

MacOS M1 간단 MySQL 설치 및 Homebrew로 설치하기, Can't connect to local MySQL server through socket '/tmp/mysql.sock'