본문 바로가기
Database/MYSQL

MySQL 8.0 업그레이드 - MySQL Upgrade

by 반화넬 2025. 2. 27.
반응형

 

 

pgrade Paths

MySQL 8.0 으로 업그레이드는 5.7의 GA 버전에서만 지원되고 있습니다. (5.7.9 or higher) 

그래서 5.7.9 이전 버전이라면 일단 5.7.9까지는 업그레이드나 마이그레이션 후 8.0 버전으로의 업그레이드를 진행해야 합니다.


권장되는 것은 5.7버전의 가장 최근의 버전까지 업그레이드 이후 8.0 버전으로의 업그레이드입니다. 다른 버전 즉 5.6이나 그 이하의 버전에서는 8.0으로 Direct 업그레이드의 지원이 되지 않습니다.

해당 포스팅에서는 MySQL 5.7.31에서 MySQL 8.0.23 버전으로 INPLACE 업그레이드의 내용이 기술되어 있습니다.
               

업그레이드 프로세스

MySQL 서버 가 실행될 때 필요한 정보를 저장하는 테이블이 포함된 mysql 시스템 스키마는 크게 두가지 범주로 나뉘게 됩니다.

  • database object metadata 가 저장된 데이터 딕셔너리 테이블들
  • 다른 운영 목적으로 사용되는 System tables(non-data dictionary tables)


설치 부분과 관련된 업그레이드가 필요한 두 가지 고유 한 버전 번호가 있습니다.

  • 첫번째 data dictionary version 입니다. 이는 data dictionary 테이블에 적용됩니다.
  • 두번째로는 MySQL 버전이라고 하는 서버 버전입니다 다른 스키마의 시스템 테이블 과 오브젝트에 적용됩니다

actual 버전이 current expected 버전보다 낮은 경우 해당 버전과 관련된 설치 부분을 현재 버전으로 업그레이드해야 합니다. 
두 버전 모두 업그레이드가 필요함을 나타내며 데이터 사전 업그레이드가 먼저 발생하게 됩니다.

언급된 두 가지 버전을 반영 관련하여 업그레이드는 다음 두 단계로 이루어집니다.


1 단계 : Data dictionary 업그레이드

이 단계는 다음을 업그레이드합니다.

  • mysql 스키마의 Data dictionary tables

If the actual data dictionary version is lower than the current expected version, the server creates data dictionary tables with updated definitions, copies persisted metadata to the new tables, atomically replaces the old tables with the new ones, and reinitializes the data dictionary.


  • Performance Schema, INFORMATION_SCHEMA, ndbinfo


2 단계 : Server 업그레이드

이 단계는 다른 모든 업그레이드 작업으로 구성됩니다. 버전이 낮다면 모든 버전을 업그레이드해야 합니다.

  • mysql 스키마의 system tables (the remaining non-data dictionary tables)
  • sys 스키마
  • User schemas

Data dictionary 업그레이드 (1 단계)는 MySQL 서버에서 진행을 하며, 이를 방지하는 옵션을 사용하지 않고 시작 시 서버는 필요에 따라 작업을 수행합니다
이 옵션은 MySQL 8.0.16 에서는 '--upgrade=NONE' , MySQL 8.0.16 이전 버전에서는 '--no-dd-upgrade' 이 사용할 수 있습니다.


MySQL 8.0.16 부터 2 단계 진행에 대해서 일부 변경이 있습니다.

MySQL 8.0.16 이전에는 mysql_upgrade 가 Performance Schema, INFORMATION_SCHEMA,objects 를 업그레이드하게 됩니다. DBA는 서버를 시작한 후 mysql_upgrade를 수동으로 호출해야 합니다.

MySQL 8.0.16 부터는 MySQL 서버가 이전에 mysql_upgrade 에서 처리한 모든 작업을 수행하게 됩니다. 업그레이드는 여전히 2단계 작업으로 남아 있지만 MySQL 서버는 두 단계를 모두 수행함으로 프로세스가 더 간단 해졌습니다.


• 일반 업그레이드 진행 시 2단계로 수행
   - MySQL 8.0.16 이전 : mysqld 이후 mysql_upgrade 를 별도로 수행
   - MySQL 8.0.16 이후 : mysqld 수행으로 1,2 단계 모두 수행이 됨


2 단계에서 발생하는 대부분의 측면은 MySQL 8.0.16 이전과 동일하지만 특정 기능이 필요하면 명령 옵션을 사용할 수 있습니다.


MySQL 8.0.16부터 --upgrade 옵션이 시작 시 서버가 자동 업그레이드를 수행하는지 여부와 방법을 제어하게 됩니다.

  • 옵션이 없거나 --upgrade=AUTO 를 사용하면 모든 항목을 업그레이드하게 됩니다. (1 단계 및 2 단계)

  • --upgrade=NONE 사용하면 서버는 아무것도 업그레이드하지 않지만 (1 단계와 2 단계 건너 뛰기), Data dictionary의 업그레이드가 필요한 경우 오류와 함께 종료됩니다 즉 이전의 Data dictionary 로는 시작이 불가능 합니다.

  • --upgrade=MINIMAL 하면 서버가 Data dictionary, Performance Schema, INFORMATION_SCHEMA 만 업그레이드하게 됩니다(1 단계) 이 옵션을 사용하면 업그레이드 2단계 Server 업그레이드는 하지 않기 때문에, 복제 관련 에러나 권한 관련된 테이블, 그 외 show .. 등의 명령어 등이 수행이 불가능하여 정상적으로 사용은 어려운 형태가 됩니다

  • --upgrade=FORCE 하면 서버가 필요한 경우 data dictionary, Performance Schema, INFORMATION_SCHEMA 를 업그레이드 후에 2단계의 항목을 모두 강제로 업그레이드하게 됩니다. 서버가 모든 스키마의 모든 오브젝트를 확인하므로 이 옵션을 사용하면 더 많은 시간이 소요될 수 있습니다. 서버는 누락된 경우 help tables 이나 time zone 테이블과 같은 시스템 테이블을 재생성 하게 됩니다.

결론적으로 MySQL 8.0.16 이상 사용시 mysqld 나 mysqld_safe 를 통해서 기동하게 되면 일반 업그레이드가 수행되면서 1,2 단계 업그레이드가 수행되게 되고 정상적으로 사용하기 위해서는 이 방법을 사용해서 업그레이드를 진행해야 합니다.
                   

Pre-check

업그레이드를 하기 위해서는 위에서 설명한 진행 프로세스 등도 고려를 해야 하지만 또 다른 한편으로 업그레이드시에 체크해야 할 사항이 있을 수 있습니다.

그래서 업그레이드시에 여러가지 다각도로 사전에 체크 및 미리 준비를 해야 할 필요성이 있습니다.

업그레이드를 하기전에 확인하고 준비를 할 부분에 대해서 일부 확인해보도록 하겠습니다.
(여기에서 언급된 부분은 여러 종류 중에서 일부이며, 추가적으로 체크하고 검토해야 할 부분은 많이 있습니다.)


파라미터

파라미터의 경우 온프레미스의 설치형 MySQL 의 경우 업그레이드 하기전에 필수로 체크를 해야 하는 부분입니다.

새로운 버전으로 업그레이드하기 위해서 지금 사용중인 파라미터 중에서 이름이 변경된 파라미터, 사라진(obsolete 또는 Removed) 파라미터를 파악해야 하며, 이전과 파라미터의 기능이 달라진 부분도 체크해야 할 부분입니다.

그래서 새로운 버전으로 MySQL을 구동하게 되었을 때 파라미터에서 문제가 발생되면 데이터베이스가 시작이 되지 않을 수도 있습니다.

사전에 체크해봐야 하는 파라미터로는 대표적으로 아래와 같은 파라미터가 있습니다.

  • show_compatibility_56
  • innodb_undo_tablespaces
  • expire_logs_days
  • lower_case_table_names
  • query_cache_size, query_cache_type 또는 query_cache 관련 파라미터

(* 일부만 나열 되어있으므로 그 외 체크해야 할 파라미터는 다수가 존재함)

설치형 MySQL 에서는 새로운 버전용 my.cnf 를 준비하는 과정에서 제거 및 변경해야 할 파라미터를 직접 수정 해야함으로 버전 차이간 파라미터를 확인해야 합니다.

특히 lower_case_table_names 파라미터 정책은 MySQL 8.0 버전부터는 인스턴스 생성 이후 변경이 안되기 때문에 8.0 버전으로 업그레이드 하기전에 정책을 명확히 정해야 합니다. 
lower_case_table_names 파라미터는 테이블명의 대소문자 구분 여부에 대한 파라미터로 리눅스 OS 기준으로 기본값 0(false)으로 대소문자를 구분합니다. 리눅스 OS 기준으로 테이블의 대소문자 구문 하지 않고(소문자로 사용) 사용하기 위해서는 1로 설정이 필요합니다.

default_authentication_plugin의 기본값이 MySQL8.0 버전부터 mysql_native_password 에서 caching_sha2_password 으로 변경되었습니다. 기존과 동일한 방식의 인증 플러그인을 기본값으로 사용하려는 경우 my.cnf 설정파일에 명시적으로 다음과 같이 설정 내용 추가가 필요 합니다.
default_authentication_plugin = mysql_native_password

mysql_native_password 과 caching_sha2_password 인증 플러그인에 대해서는 다음 포스팅에서 자세하게 설명하고 있습니다.

 
 

Query Cache 기능도 MySQL 8.0 버전에 없어진 기능으로 기능과 관련된 파라미터 query_cache_size, query_cache_type 는 파라미터 설정파일인 my.cnf 에서 제거를 해야 합니다.


SQL_MODE

버전이 변경되면서 바뀌는 부분 중에는 SQL_MODE 가 있습니다.

MySQL5.7.5 버전부터 추가된 NO_AUTO_CREATE_USER 이 8.0 에서는 기본적으로 활성화되면서 목록에서 제거되었습니다. 그래서 설치형 MySQL 에서는 8.0 업그레이드시 NO_AUTO_CREATE_USER 이 지정되어 있다면 제거하시면 됩니다.

NO_AUTO_CREATE_USER 과 관련되어 프로시저나 트리거에 sql_mode "NO_AUTO_CREATE_USER" 선언되어 있다면 Upgrade Precheck 단계에서 warning 이 발생될 수 있습니다. Precheck 과정에서 검출된다면 해당 내용 제거하여 다시 재생성 하시면 됩니다.

그 외 사용되는 SQL 과 테이블에 입력된 데이터에 따라서 기존에 별도의 값으로 설정하여 SQL_MODE 를 사용하였다면 변경 없이 그대로 사용하시는 것이 SQL 에러 발생 소지를 줄일 수 있는 방법입니다. SQL_MODE 에 따른 Side effect 확인이 어렵다면 기존의 값을 그대로 사용하시는 편이 좋습니다.


Character Set, Collation

MySQL 5.7에서도 utf8mb4 를 사용할 수 있었으며 8.0 버전부터는 기본 Character Set 으로 됨에 따라서, 업그레이드 따른 Character Set 을 고민해야 하며, 정해진 Character Set 다음에는 사용할 Collation 을 선택해야 합니다.

물론 기존에 사용한 Character Set 과 Collation 이 큰 단점이나 사용상 불편이 없다면 그대로 사용하시면 됩니다.

서버 엔진의 Character Set 과 Collation 이 변경(정해졌다면) 되었다면, 테이블과 컬럼에 지정된 Character Set 과 Collation 의 변경을 할지 한다면 언제 시점에 작업할 지 등을 고민해야 합니다.


예약어(Reserved Words)

MySQL 버전에 업그레이드됨에 따라서 예약어는 추가되거나 변경되게 됩니다. 그래서 버전에 맞는 예약어 정보를 확인해서, 예약어로 생성된 테이블이나 컬럼이 있는지 사전에 체크해볼 필요성이 있습니다.

예약어(Reserved Words) 에 대한 정보는 아래 도큐먼트에서 확인하시면 됩니다.

MySQL :: MySQL 8.0 Reference Manual :: 9.3 Keywords and Reserved Words
Keywords are words that have significance in SQL. Certain keywords, such as SELECT, DELETE, or BIGINT, are reserved and require special treatment for use as identifiers such as table and column names. This may also be true for the names of built-in functions.



TLS 버전

MySQL 8.0.28 버전부터 TLSv1.0, TLSv1.1 이 Removed 되었습니다. 그에 따라 SSL/TLS로 접속을 사용하는 환경에서는 개발언어 및 접속 드라이버에서 TLSv1.2 이상을 지원하는지를 사전에 체크해야 합니다.


Xtrabackup 백업 유틸리티

MySQL8 버전에서는 xtrabackup 8 버전을 사용해야 합니다 그러나 MySQL 8.0.20 부터 이전 버전과의 호환이 되지 않는 변경된 Redo log format 이 추가됨에 따라서 MySQL의 새로운 버전이나 마이너 버전 출시 직후에는 해당 버전을 지원하는 Xtrabackup 버전이 아직 출시가 되지 않았을 수도 있습니다.
업그레이드하려는 대상의 버전이 출시된 지 얼마 안 된 마이너 버전이라면, 지원하는 Xtrabackup 버전이 존재하는지도 체크해봐야할 사항입니다.

보통은 새로운 MySQL 버전이나 마이너 버전 출시 후에 길지 않은 시간 뒤에 Xtrabackup도 해당 버전에 대응하는 새로운 버전이 출시되는 것이 보통의 패턴입니다.
              

 
 

Upgrade checker(UC) Utility

MySQL 8.0 으로 업그레이드하는 첫 번째 단계는 기존 MySQL 5.7 서버의 업그레이드 준비 상태를 확인하는 것입니다. 

이러한 과정을 간단하게 진행할 수 있도록 upgrade checker utility 가 MySQL Shell 8.0과 함께 도입이 되었습니다.

upgrade checker(UC) 는 is Shell’s scripting mode 에서 사용 가능 하며 실행 방법은 아래와 같습니다.


MySQL Shell 설치

설치는 각 배포판 별로 아래와 같이 설치를 진행하시면 됩니다.

• 우분투

user# sudo dpkg -i mysql-apt-config_0.8.26-1_all.deb
user# sudo apt update
user# sudo apt -y install mysql-shell


만약 mysql-apt-config 패키지가 다운로드가 안된다면 아래 링크를 통해서 패키지 파일을 다운로드 받으시거나 다운로드 링크 정보를 확인하실 수 있습니다.

MySQL :: Download MySQL APT Repository
The world’s most popular open source database



• RHEL/CentOS 7 기준

user# sudo yum install -y mysql-shell


[참고] 아래와 같이 rpm-gpg 에러가 발생되면서 yum 으로 설치나 패키지 버전이 안될 경우
- 에러 메세지 내역

경고: /var/cache/yum/x86_64/7/mysql-tools-community/packages/mysql-....rpm:
Header V4 RSA/... Signature, key ID ...: NOKEY
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql
 
 
The GPG keys listed for the "MySQL Tools Community"
repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.
 
 
Failing package is: mysql-...
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql


MySQL은 최근에 gpg 키를 업데이트 된 것으로 확인됩니다.

그래서 아래와 같이 새로운 키를 import 후에 다시 yum 으로 설치 또는 패키지 버전 업데이트를 시도 해보시기 바랍니다.



실행 명령어

mysqlsh -u root -p -h localhost -e "util.checkForServerUpgrade();"
 
또는
 
mysqlsh root:@localhost:3306 -e "util.checkForServerUpgrade();"



실행 결과 예시

최초 실행 시 패스워드의 저장 여부도 확인합니다.
아래는 수행 결과이며 내용이 긴 관계로 일부 편집이 되어 있으며 아래는 upgrade checker 로 확인된 내용에서 조치한 내용을 기술하였습니다.

1) utf8 사용

현재 사용중인 블로그와 사이트의 MySQL 의 업그레이드 전에 체크해본 결과이며 예전부터 사용한 테이블과 데이터베이스가 있다 보니 utf8 로 사용하면서 utf8mb4 로 권장하는 Warning 이 많이 발생하였습니다.
이전부터 utf8mb4 로 chracterset 과 collation 을 변경 계획하여서 업그레이드 전에 대부분 변경하였습니다.

• 명령어 예시

ALTER DATABASE 스키마명 CHARACTER SET utf8mb4;
 
ALTER TABLE 테이블명 CONVERT TO CHARACTER SET utf8mb4;


2) sql_mode - NO_AUTO_CREATE_USER

8.0에서 deprecate 된 sql_mode 의 NO_AUTO_CREATE_USER 과 관련하여 기본값의 sql_mode 사용 중에 생성된 트리거가 NO_AUTO_CREATE_USER flags 를 사용하고 있다고 확인되어 NO_AUTO_CREATE_USER 를 제외한 상태에서 트리거를 재생성 하였습니다.

3) column has zero default value

wordpress CMS 에서는 날짜 컬럼의 default value 가 0000-00-00 00:00:00 으로 되어 있습니다 MySQL 의 버전이 올라가면서 sql_mode 에 NO_ZERO_DATE 와 관련되어 발생되는 warning 입니다.

wordpress 에서 몇 번 나오고 변경에 대한 내용이 건의/요청 그리고 검토가 있었으나 오래된 CMS에 워낙 많은 Plugin과 연관되어 있기 때문에 이전 버전과 다양한 플러그인의 호환성을 위해서 변경이 어렵다 라고 결정이 된 것 같습니다. 그래서 해당 warning 도 많이 나오긴 했지만 zero default value 는 그대로 사용하기로 하였습니다.


파라미터 변경

upgrade checker 에서는 나오지 않은 내용이지만 문서 확인 및 테스트로 확인된 파라미터를 변경 및 제거하였습니다.

show_compatibility_56
innodb_undo_tablespaces
expire_logs_days
  <- binlog_expire_logs_seconds 로 대체함

utf8에서 utf8mb4 로 변경과 트리거 재생성 후 warning 의 수도 많이 줄었고 그 외에 큰 문제가 될 것은 없는 것으로 확인되어 업그레이드를 진행하였습니다.

[root]# mysqlsh root@localhost -e "util.checkForServerUpgrade();"
Please provide the password for 'root@localhost': ************
Save password for 'root@localhost'? [Y]es/[N]o/Ne[v]er (default No): y
The MySQL server at /var%2Flib%2Fmysql%2Fmysql.sock, version 5.7.31 - MySQL
Community Server (GPL), will now be checked for compatibility issues for
upgrade to MySQL 8.0.23...
 
upgrade to MySQL 8.0.23...
 
1) Usage of old temporal type
No issues found
 
2) Usage of db objects with names conflicting with new reserved keywords
Warning: The following objects have names that conflict with new reserved
keywords. Ensure queries sent by your applications use `quotes` when
referring to them or they will result in errors.
More information:
 
xxxxxxxx.user_t.rank - Column name
xxxxxxxx.users.admin - Column name
 
3) Usage of utf8mb3 charset
Warning: The following objects use the utf8mb3 character set. It is
recommended to convert them to use utf8mb4 instead, for improved Unicode
support.
More information:
 
xxxxxxxx - schema's default character set: utf8
xxxxxxxxxxx - schema's default character set: utf8
xxxxxxxxxx - schema's default character set: utf8
mysql - schema's default character set: utf8
xxxxxxx - schema's default character set: utf8
xxxxxxx - schema's default character set: utf8
xxxxxxxx - schema's default character set: utf8
xxxxxxxxxx.xxxxxx.xxxxxxxx - column's default character set: utf8
 
< ... 중략 .... >
 
4) Table names in the mysql schema conflicting with new tables in 8.0
No issues found
 
5) Partitioned tables using engines with non native partitioning
No issues found
 
6) Foreign key constraint names longer than 64 characters
No issues found
 
7) Usage of obsolete MAXDB sql_mode flag
No issues found
 
8) Usage of obsolete sql_mode flags
Notice: The following DB objects have obsolete options persisted for
sql_mode, which will be cleared during upgrade to 8.0.
More information:
 
xxxxxxxxxxx.trigger_name123 - TRIGGER uses obsolete
NO_AUTO_CREATE_USER sql_mode
xxxxxxxxxxx.trigger_name123 - TRIGGER uses obsolete
NO_AUTO_CREATE_USER sql_mode
xxxxxxxxxxx.trigger_name123 - TRIGGER uses obsolete
NO_AUTO_CREATE_USER sql_mode
global system variable sql_mode - defined using obsolete NO_AUTO_CREATE_USER
option
 
9) ENUM/SET column definitions containing elements longer than 255 characters
No issues found
 
10) Usage of partitioned tables in shared tablespaces
No issues found
 
11) Circular directory references in tablespace data file paths
No issues found
 
12) Usage of removed functions
No issues found
 
13) Usage of removed GROUP BY ASC/DESC syntax
No issues found
 
14) Removed system variables for error logging to the system log configuration
To run this check requires full path to MySQL server configuration file to be specified at 'configPath' key of options dictionary
More information:
 
15) Removed system variables
To run this check requires full path to MySQL server configuration file to be specified at 'configPath' key of options dictionary
More information:
 
16) System variables with new default values
To run this check requires full path to MySQL server configuration file to be specified at 'configPath' key of options dictionary
More information:
 
17) Zero Date, Datetime, and Timestamp values
Warning: By default zero date/datetime/timestamp values are no longer allowed
in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in
SQL_MODE by default. These modes should be used with strict mode as they will
be merged with strict mode in a future release. If you do not include these
modes in your SQL_MODE setting, you are able to insert
date/datetime/timestamp values that contain zeros. It is strongly advised to
replace zero values with valid ones, as they may not work correctly in the
future.
More information:
MySQL 8.0 and wrong dates
 
xxxxxxxxxx.xxxxxxxxxxxxx.Register_dt - column has zero default value:
0000-00-00 00:00:00
 
< ... 중략 .... >
 
18) Schema inconsistencies resulting from file removal or corruption
No issues found
 
19) Tables recognized by InnoDB that belong to a different engine
No issues found
 
20) Issues reported by 'check table x for upgrade' command
No issues found
 
21) New default authentication plugin considerations
Warning: The new default authentication plugin 'caching_sha2_password' offers
more secure password hashing than previously used 'mysql_native_password'
(and consequent improved client connection authentication). However, it also
has compatibility implications that may affect existing MySQL installations.
If your MySQL installation must serve pre-8.0 clients and you encounter
compatibility issues after upgrading, the simplest way to address those
issues is to reconfigure the server to revert to the previous default
authentication plugin (mysql_native_password). For example, use these lines
in the server option file:
 
[mysqld]
default_authentication_plugin=mysql_native_password
 
However, the setting should be viewed as temporary, not as a long term or
permanent solution, because it causes new accounts created with the setting
in effect to forego the improved authentication security.
If you are using replication please take time to understand how the
authentication plugin changes may impact you.
More information:
 
Errors: 0
Warnings: 703
Notices: 4

                

진행한 업그레이드 절차

MySQL 5.7 버전에서는 Cmake 컴파일 하여 사용하였고 이번에 8.0 버전에는 빌드가 된 바이너리 파일을 사용하였습니다


파일 다운로드 및 압축 해제

 
[root]# tar Jxvf mysql-8.0.23-linux-glibc2.12-x86_64.tar.xz



디렉토리 이동 및 소유권 변경

[root]# mv mysql-8.0.23-linux-glibc2.12-x86_64 /usr/local/
[root]# chown -R mysql:mysql /usr/local/mysql-8.0.23-linux-glibc2.12-x86_64



MySQL 5.7 버전 종료 및 심볼릭 링크 변경

[root]# systemctl stop mysqld
 
[root]# cd /usr/local/
[root]# unlink mysql
 
[root]# ln -s mysql-8.0.23-linux-glibc2.12-x86_64 mysql



데이터 파일 및 기타 디렉토리 이동

[root]# cd /usr/local/mysql-5.7.31
 
[root]# mv data /usr/local/mysql
[root]# mv logs /usr/local/mysql
[root]# mv tmp /usr/local/mysql



MySQL 기동 - 업그레이드 진행

# /etc/ld.so.conf 파일 내 mysql/lib 존재 하는 지 확인
[root]# cat /etc/ld.so.conf | grep mysql
/usr/local/mysql/lib
 
# MySQL 시작
cd /usr/local/mysql/bin
./mysqld_safe --defaults-file=/etc/my.cnf &



업그레이드 로그

[System] [MY-010116] [Server] /usr/local/mysql/bin/mysqld (mysqld 8.0.23) starting as process 13049
[Warning] [MY-010156] [Server] Although a path was specified for the --slow-query-log-file option, log tables are used. To enable logging to files use the --log-output=file option.
[System] [MY-011012] [Server] Starting upgrade of data directory.
[System] [MY-013576] [InnoDB] InnoDB initialization has started.
[System] [MY-013577] [InnoDB] InnoDB initialization has ended.
[System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /tmp/mysqlx.sock
[Warning] [MY-010772] [Server] db.opt file not found for redologs database. Using default Character set.
[Warning] [MY-010772] [Server] db.opt file not found for undologs database. Using default Character set.
[System] [MY-011003] [Server] Finished populating Data Dictionary tables with data.
[System] [MY-013381] [Server] Server upgrade from '50700' to '80023' started.
[System] [MY-013381] [Server] Server upgrade from '50700' to '80023' completed.
[Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
[System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
[System] [MY-010931] [Server] /usr/local/mysql8/bin/mysqld: ready for connections. Version: '8.0.23' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server - GPL.

            

업그레이드 확인 및 추가 모니터링

업그레이드가 완료되었다면 몇 가지를 확인해보도록 하겠습니다

업그레이드 확인

[root]# mysqlcheck -u root -p --all-databases --check-upgrade
Enter password:
schema.table1 Table is already up to date
schema.table2 Table is already up to date
schema.table3 Table is already up to date
schema.table4 Table is already up to date
schema.table5 Table is already up to date
schema.table6 Table is already up to date
schema.table7 Table is already up to date
< .... 중략.... >



MySQL 로그 모니터링

MySQL이 8.0으로 업그레이드가 완료된 다음에는 한동안 집중적인 로그 모니터링이 필요 합니다.
예를 들어 업그레이드한 MySQL 마이너버전에 따라서 현재 설정한 my.cnf 파일에서 Deprecated 된 파라미터가 설정되어서 관련된 로그가 Warning 으로 기록되거나 사전에 체크가 되기 어려운 Warning 내용들이 업그레이드 이후 DB 사용 중에 mysqld 로그에 기록될 수 있습니다. 
업그레이드 이후에는 로그의 집중 모니터링이 필요 합니다.


SlowQuery 모니터링

MySQL이 8.0 마이너 버전에 따라서 여러 기능이 추가되고 있으며, 그 중에서는 SQL 실행에 관한 추가적인 기능도 포함된 경우가 있습니다. 그에 따라서 사용중인 SQL이 MySQL 5.7 버전과 다른 실행계획으로 실행될 수도 있으며 경우에 따라서 수행 시간이 기존보다 더 느려질 수도 있습니다
업그레이드 후에는 기존보다 보다 더 SlowQuery에 대한 모니터링이 필요하며 필요시에는 long_query_time 파라미터를 조금 더 낮게 조정하여 튜닝 검토할 SQL에 대한 모니터링 활동이 필요할 수도 있습니다.
                          

Reference

Reference Link

mysqlserverteam.com/upgrade-is-going-away [link]
mysqlserverteam.com/mysql-5-7-to-mysql-8-0 [link]
mysqlserverteam/mysql-shell-upgrade-checker-utility [link]
dev.mysql.com/upgrading-what-is-upgraded [link]
dev.mysql.com/upgrade-paths [link]
percona.com/percona-xtrabackup/8.0 [link]
percona.com/xtrabackup-8-x-and-mysql-8-0-20 [link]
https://jira.percona.com/browse/PXB-2315 [link]

 

원본 : https://hoing.io/archives/17694

반응형
저작자표시

관련글

티스토리툴바