MySQL Major/Minor Upgrade
목표
- MySQL Minor/Major Upgrade의 방법론에 대해 이해한다.
- 무중단이나 순단으로 서비스연속성이 유지되도록 업그레이드 작업을 진행한다.
- 실 서비스에 사용할 수 있도록 최대한의 특이사항과 유의사항에 대해 정리한다.
- MySQL Upgrade시 수행 되는 내부 로직에 대해 이해하고 업그레이드 시나리오를 작성하도록 한다.
MySQL Upgrade 방법
- In-Place Upgrade
- MySQL 서버의 데이터 파일을 그대로 두고 업그레이드하는 방법
- 여러가지 제약사항이 존재하지만 업그레이드 시간을 단축가능 - Logical Upgrade
- mysqldump 도구 등을 이용해 MySQL 서버의 데이터를 SQL 문장이나 텍스트 파일로 덤프한 후, 새로 업그레이드된 버전의 mysql 서버에서 덤프된 데이터를 적재하는 방법 ( Dump & restore)
- 버전간 제약사항이 In-place에 비해 매우 적지만 시간이 매우 많이 소요
이 포스팅에서는 Logical Upgrade를 제외하고 In-Place Upgrade 방식으로 작업 검토.
In-Place Upgrade도 1대의 인스턴스만 존재 할 시 재기동이 필수적으로 필요한 작업으로 다운타임이 발생하지만, 다양한 복제 토폴로지를 통한 순단수준의 다운타임 확보 가능
MySQL Minor Upgrade
Minor Upgrade 특이사항 및 주의사항
- 대부분의 DBMS 마이너 버전 패치는 엔진 변경 자체의 난이도는 높지 않다.
- 그러나 마이너 버전 릴리즈 노트를 확인하고 필요 시 업데이트를 진행해야 보안 취약점 에 대한 보안성 향상, 일부 기능 개선등의 효과를 볼수 있다.
- 테스트는 N-N 구조지만 Read Instance(1:1) 가 있거나, Standby Master( N:1) 가 구축되어 있을 시) 다운타임 최소화 가능
- 모든 오브젝트에 대해 변동사항이 있는 경우가 많지 않으므로 대부분 Inplace 방식으로 수행
- 다량의 서비스를 업그레이드 한다면, 서비스 영향도가 가장 작은 것부터 업그레이드 진행
한대의 인스턴스 Minor Upgrade 순서
- MySQL 셧다운 → 엔진파일 덮어쓰기(변경) → MySQL 서버(mysqld) 시작 → MySQL upgrade 실행
- 업그레이드 시 mysqld vs mysql_upgrade
mysqld( 1단계 업그레이드) | mysql_upgrade(2단계 업그레이드) |
Database Object 메타데이터가 저장되는 Data dictionary Table 업그레이드 performance_schema, Information_schema 업그레이드 |
mysql 스키마의 system tables 업그레이드 sys 스키마 업그레이드 비호환 기능, 테이블 체크, 문제 확인 |
- 실제 업그레이드는 두가지 단계로 나뉘어서 처리 ( 1단계: mysqld, 2단계 : mysql_upgrade)
작업 시나리오
사전 작업
--다양한 방식의 백업수행 (물리백업 - xtrabackup, 논리백업 - mysqldump 등등) 서비스 고려
mysqldump --all-databases > dump.sql
--패치 대상 설치파일 다운로드
wget https://downloads.mysql.com/archives/get/p/23/file/mysql-5.7.37-linux-glibc2.12-x86_64.tar.gz
tar -xvf mysql-5.7.37-linux-glibc2.12-x86_64.tar.gz -C /mysql/Dwight/
- 작업 시에는 심볼릭 링크를 변경을 통해 설치 파일을 변경하였음
본 작업
-- 업그레이드 대상 서버 파라미터 적용
SET GLOBAL innodb_fast_shutdown=0
Innodb_fast_shutdown?? - InnoDB의 셧다운 모드
- 0 - slow shutdown, 모든 로그와 버퍼를 데이터파일로 동기화함
- 1 (deafult) - 데이터 파일 동기화 안함 ( 기동 시 redo에서 확인)
- 2 - 강제로 로그를 플러시하고 종료하는 옵션
- 0으로 변경 후 수행해야 해야 업그레이드 실패 시 로그와 서버 파일들을 처리할 수 있는 상태로 둠 (데이터 파일을 완전히 준비)
--mysql 계정에서 수행
mysqladmin -u root -p shutdown
cd /mysql/Dwight
rm -rf instance
ln -s mysql-5.7.37-linux-glibc2.12-x86_64 instance
mysqld_safe --defaults-file=/data/Dwight/my.cnf &
mysql_upgrade -u root -p
결과 값 (업그레이드 명령어 수행시 mysql의 system tables를 업그레이드 한 것을 확인 할 수 있음)
Minor Upgrade 체크리스트
- 백업 정상 수행 여부
- Rollback 플랜
- 신규 & 변경 파라미터 확인(엔진 변경사항 체크)
MySQL Major Upgrade
MySQL 5.7 to 8.0 Major Upgrade 특이사항 및 주의사항
- 메이저 버전 업그레이드의 경우 상당히 많은 기능들이 개선되거나 변경되었음
- 메이저 버전 간 업그레이드는 직전 버전에서만 허용됨, 예를 들어 5.6 → 8.0 은 허용되지 않음
- MySQL 5.7 버전의 GA버전인 5.7.9 버전 이후의 버전만 8.0 으로 업그레이드 할 수 있음
- 다운타임을 허용하는 경우, Logical Upgrade를 수행 할 수 있겠지만 대부분의 서비스는 In-place 방법으로 수행해야 하므로 작업 검토 필요
- JDBC 버전 등 Application 단에서 업그레이드가 필요할 수 있는 내용을 확인
- 위와 같은 문제점을 해결하기 위해서, 메이저 업그레이드의 경우 Staging이나 DEV단에서 충분한 성능테스트를 거쳐야함
- percona toolkit에 있는 업그레이드 관련도구 활용(pt-upgrade, pt-query-digest 등) - 대부분 성능테스트 관련 툴
- To be 버전인 MySQL 8.0에서도 8.0.16버전 이전과 이후의 업그레이드 방식이 조금 달라짐
* 8.0.16버전 이전에서는 mysql_upgrade를 통한 1단계, 2단계 업그레이드를 수행 필요
* 8.0.16버전 이후에서는 mysqld에 mysql_upgrade가 포함( 1단계, 2단계)
* 8.0.16버전 이후에서 mysql_upgrade 명령어를 수행 했을 때
주요 변경점
- 인증 플러그인 변경 (5.7 : mysql_native_password , 8:0 chching_sha2_password)
- MySQL 서버에서 파티셔닝을 제공하지 않음, innoDB와 NDB 스토리지 엔진 에서만 파티셔닝 사용 가능
- 기본 캐릭터셋 변경
- character set latin1 → utf8mb4, collation latin1_swedish_ci → utf8mb4_0900_ai_ci - 인덱스 힌트 사용
- 외래키 이름의 길이 제한
- 파티션을 위한 공용 테이블 스페이스
- GROUP BY ASC(DESC) 절 사용 불가
- 참조) https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html
작업 시나리오
--다양한 방식의 백업수행 (물리백업 - xtrabackup, 논리백업 - mysqldump 등등) 서비스 고려
mysqldump --all-databases > dump.sql
--패치 대상 설치파일 다운로드
wget https://downloads.mysql.com/archives/get/p/23/file/mysql-8.0.28-linux-glibc2.12-x86_64.tar.gz
tar -xvf mysql-8.0.28-linux-glibc2.12-x86_64.tar.gz -C /mysql/Dwight/
--mysqlcheck를 통한 변경 필요 내용 확인
mysqlcheck -u root -p --all-databases --check-upgrade
--mysqlsh 실행
sudo yum install -y mysql-shell
mysqlsh -u root -p -e "util.checkForServerUpgrade();" --socket=/tmp/mysql.sock
mysqlsh -- util checkForServerUpgrade --target-version=8.0.28 --config-path=/data/Dwight/my.cnf --socket=/tmp/mysql.sock
mysqlcheck ??
-mysql_upgrade 안에 포함된 upgrade 시 수행되어야하는 내용들을 출력해주는 프로그램
*해당 내용을 참고하여 선 작업을 수행하면 업그레이드 수행에 대한 시간을 줄일 수 있음
mysql shell 이란??
- 업그레이드 체크 외 다양한 자바스크립트 Utilty를 제공하는 코드 편집기(덤프 등)
*업그레이드 체크하는 유틸 사용시 24개의 항목에 대해서 체크 결과 제공
1) Usage of old temporal type
2) MySQL 8.0 syntax check for routine-like objects
3) Usage of db objects with names conflicting with new reserved keywords
4) Usage of utf8mb3 charset
5) Table names in the mysql schema conflicting with new tables in 8.0
6) Partitioned tables using engines with non native partitioning
7) Foreign key constraint names longer than 64 characters
8) Usage of obsolete MAXDB sql_mode flag
9) Usage of obsolete sql_mode flags
10) ENUM/SET column definitions containing elements longer than 255 characters
11) Usage of partitioned tables in shared tablespaces
12) Circular directory references in tablespace data file paths
13) Usage of removed functions
14) Usage of removed GROUP BY ASC/DESC syntax
15) Removed system variables for error logging to the system log configuration
16) Removed system variables
17) System variables with new default values
18) Zero Date, Datetime, and Timestamp values
19) Schema inconsistencies resulting from file removal or corruption
20) Tables recognized by InnoDB that belong to a different engine
21) Issues reported by 'check table x for upgrade' command
22) New default authentication plugin considerations
23) Columns which cannot have default values
24) Check for invalid table names and schema names used in 5.7
본작업 (업그레이드)
SET GLOBAL innodb_fast_shutdown=0
--mysql 계정에서 수행
mysqladmin -u root -p shutdown
cd /mysql/Dwight
rm -rf instance
ln -s mysql-8.0.28-linux-glibc2.12-x86_64 instance
mysql_safe --defaults-file=/data/Dwight/my.cnf &
mysql_upgrade -u root -p
사후작업
--mysqlcheck를 통한 변경 필요 내용 확인
mysqlchechk -u root -p --all-databases --check-upgrade
Major Upgrade 체크리스트
- 백업 정상 수행 여부
- Rollback 플랜
- 신규 & 변경 파라미터 확인(엔진 변경사항 체크)
- mysqlsh 정상 수행 여부
- mysqlcheck 정상 수행 여부
Rollback Plan
- 역방향 리플리케이션
CHANGE MASTER TO MASTER_HOST="10.213.211.8",
MASTER_USER='replication_user',MASTER_PASSWORD='#######',
MASTER_AUTO_POSITION=1;
start slave;
show slave status\G
서비스 DB(마스터)와 모든 데이터 싱크가 일치하는지 확인
show slave status\G
추가 의문점
질문 1. 8.0 → 5.7 역방향 리플리케이션 시 복제가 중지 되는 경우는 어떤 경우가 있을까??
- 5.7에서 지원하지 않은 신규 기능을 사용할때
- cachinh_sha2_password
- role 생성
- invisible indexes
- character set 이슈
기본 캐릭터셋 변경
- character set latin1 → utf8mb4, collation latin1_swedish_ci → utf8mb4_0900_ai_ci
character set 이슈로 정상 리플리케이션이 되지 않을 수 있으니 utf8mb4 collation이 있다면 utf8로 변경하거나 아래의 설정으로 변경 ( utf8mb4_general_ci / utfmb4_bin 으로 생성된 테이블들이 MySQL 8.0 에서는 utf8mb4_0900_ai_ci 로 생성)
--mysql 8.0 my.cnf 변경
character_set_server= utf8mb4
collation-server = utf8mb4_bin
init_connect='SET NAMES utf8mb4 COLLATE utf8mb4_bin'
skip_character_set_client_handshake
질문 2. Minor/ Major Downgrade는 가능 할까?
공식적으로 지원하지 않으며 기존에 쉽게 수행할 수 있는 실행파일을 바꾸는 방법대로 실행하면 아래와 같은 에러 메시지 발생
다운그레이드를 위해서는 데이터 덤프 필요
질문 3. mysql_upgrade 를 수행하지 않으면 어떻게 될까??
서버 접속에는 지장없으나, 시스템 파일들의 변동사항이 적용되지 않아 서비스 불가 가능성 있음
업그레이드가 필요 없을 때 수행하면 발생하는 에러메시지
'MySQL & MariaDB' 카테고리의 다른 글
[Aurora MySQL] 쿼리 수행중 the table tmp is full Error 발생 (0) | 2023.08.15 |
---|---|
MySQL GTID 복제 환경에서 Reset Master 수행 시 발생 장애 케이스 (0) | 2022.12.27 |
MySQL GTID 복제 환경에서 Reset Master/Reset Slave 명령어 (0) | 2022.12.27 |
MySQL Multi Source Replication(MSR) 실습 (0) | 2022.12.26 |
MySQL GTID Replication 실습 (0) | 2022.12.22 |