본문 바로가기
Database/MYSQL

MySQL 5.6에서 5.7로 업그레이드한 방법

by 반화넬 2024. 1. 8.
반응형

블로그를 보다 유익한 정보가 있어서 스크랩 해봅니다.

정말 도움 되는 글 같아요. 본문 내용입니다.

Mysql

 

 

어제 Synthesio Coffee Team은 Percona 5.6에서 Percona 5.7로 22TB MySQL Cluster 업그레이드를 완료했습니다. 우리는 이미 대부분의 클러스터를 업그레이드 했고 시간이 걸리는 것을 알고 있었지만 9개월이나 걸릴 것으로 생각하지는 않았습니다. 이것은 다운타임 없이 거대한 데이터베이스 클러스터를 마이그레이션하는 것에 관해 우리가 배웠던 것입니다.

 

초기 설정

우리의 데이터베이스 클러스터는 고전적인 고 가용성 3+1 노드 토폴로지로서 HAProxy를 이용합니다. 이것은 Systemd없이 Debian Jessie에서 4.9.1 커널 (처음에는 4.4.36)에서 실행됩니다. 이 서버는 20 core Dual Xeon E5-2260 v3 (256GB RAM) 및 36*4TB 하드 드라이브(RAID10)를 갖추고 있습니다. 처리량은 약 1억건 / 일이며, insert 및 update가 혼합되어 있습니다.

클러스터 디자인 자체에는 특별한 것이 없습니다.

  • 2서버는 마스터/ 마스터로 구성되지만 쓰기는 메인 마스터에서만 수행됩니다.
  • 읽기는 HAProxy를 통해 마스터 및 두 슬레이브에서 수행됩니다. 단 복제가 지연되는 슬레이브는 사용하지 않도록 설정되어 있습니다.
  • 여분의 슬레이브는 Bobby Tables이 우리 서버와 함께 작동 할 경우 MASTER_DELAY를 1시간으로 설정하여 오프 사이트에서 실행됩니다.

 

1단계 : mysql_upgrade의 지옥에서

Percona Debian 패키지를 사용하여 예비 호스트를 MySQL 5.7로 업그레이드 했습니다.

 
 
MySQL 5.6에서 MySQL 5.7로 업그레이드하려면 TIME, DATETIME 및 TIMESTAMP 컬럼이 있는 모든 테이블을 업그레이드해야 분 초의 정밀도를 지원할 수 있습니다. mysql_upgrade는 시스템 테이블 업그레이드 뿐만 아니라 그 부분도 처리합니다.
 
임시 컬럼이 있는 테이블을 업그레이드한다는 것은 업그레이드가 필요한 모든 테이블에서 ALTER TABLE ... FORCE를 실행한다는 것을 의미합니다. 그것은 회전 디스크에 22TB의 데이터를 임시 테이블로 복사한 다음 데이터를 다시 로드하는 것을 의미합니다.
 
5개월 후 우리는 20% 완료되었습니다.
 
우리는 mysql_upgrade를 kill하였고 두 테이블에 대해 ALTER를 병렬로 실행하는 스크립트를 작성했습니다.
 
2개월 후 업그레이드가 50% 완료되었으며 복제가 약 9백만 초 지연됩니다. 대규모 복제 지연은 계획에 없었으며 이로 인해 예상치 못한 주요 지연이 발생했습니다.
 
우리는 하드웨어를 약간 업그레이드하기로 결정했습니다.
 
우리는 RAID0에 12*3.8TB SSD 디스크를 가진 새로운 호스트를 설치했으며 여분의 호스트에서 데이터를 rsynced하고 프로세스를 재개했습니다. 8일 후 업그레이드가 끝났습니다. 복제를 따라 가기까지 3주가 더 걸렸습니다.
 

2단계 : 2개의 새로운 MySQL 5.7 슬레이브 추가하기

이렇게하기 전에 클러스터에 GTID가 활성화되어 있는지 확인하십시오. GTID를 사용하면 복제를 몇 번 재구성 할 때 많은 시간과 골칫거리를 줄일 수 있었습니다. 

 
MySQL 5.7을 실행하는 2개의 슬레이브를 추가했습니다. /var/lib/mysql에 없는 MySQL 데이터가 있는 새로운 서버를 설치할 때 Percona postinst.sh 스크립트에 버그가 있습니다. 따라서 Percona-server-server-5.6을 설치한 다음 percona-server-server-5.7을 설치하면 버그를 무시할 수 있습니다. 
 
 
 
새로운 슬레이브의 MySQL 5.7 구성은 예비 호스트와 innobackupex를 이용해서 동기화 했습니다.
 
수신자 측 :
mysql -e "SET GLOBAL expire_logs_days=7;"
nc -1 -p 9999 | xbstream -x
 
발신자 측 :
innobackupex --stream=xbstream --parallel=8 ./ | nc slave[3,4] 9999
 
30시간 후 :
innobackupex --use-memory=200G --apply-log
 
슬레이브 3 :
CHANGE MASTER TO MASTER_HOST="master", MASTER_USER="user", MASTER_PASSWORD="password", MASTER_AUTO_POSITION=1;
 
슬레이브 4 :
CHANGE MASTER TO MASTER_HOST="slave 3", MASTER_USER="user", MASTER_PASSWORD="password", MASTER_AUTO_POSITION=1;
 

3단계 : 복제 따라 잡기 (다시)

다시 한 번 우리는 복제에 늦었습니다. 필자는 지연된  MySQL 복제를 수정하는 것에 대해 이미 썼습니다. 다음 구성을 적용하기 전에 장단점을 주의 깊게 읽으십시오.

STOP SLAVE;

SET GLOBAL sync_binlog=0;

SET GLOBAL innodb_flush_log_at_trx_commit=2;

SET GLOBAL innodb_flush_log_at_timeout=1800;

SET GLOBAL slave_parallel_workers=40;

START SLAVE;

두 호스트의 복제본을 잡는 데는 보통 2~3주 정도 소요되었기 때문에 우리는 보통보다 훨씬 많은 쓰기 작업을 수행했습니다.

 

4단계 : 작업을 끝내다

마이그레이션이 거의 완료되었습니다. 몇가지 할 일이 남아있었습니다.

 

우리는 HAProxy를 재구성하여 슬레이브 3에 대한 쓰기를 전환시켰는데, 사실상 새로운 마스터가 되고 슬레이브 4에서 읽습니다. 그런 다음 플랫폼에서 모든 쓰기 프로세스를 다시 시작하여 나머지 연결을 종료합니다.

 

5분 후, 슬레이브 3은 마스터에서 모든 것을 따라 잡고 복제를 중단했습니다. 롤백해야하는 경우를 대비하여 마스터에서 마지막 트랜잭션 ID를 저장햇습니다.

 

그런 다음 슬레이브 3를 슬레이브 4의 슬레이브로 재구성하여 마스터 / 마스터 구성에서 다시 실행합니다.

 

우리는 MySQL 5.7에서 마스터를 업그레이드하고 innobackupex를 다시 실행하여 슬레이브 3의 슬레이브로 만들었습니다. 복제가 따라 잡기까지 며칠이 걸렸고 어제 클러스터에 마스터를 다시 추가했습니다.

 

일주일 후 우리는 더이상 쓸모없는 슬레이브 1과 슬레이브 2를 버렸습니다.

 

 
롤백, 누가 "롤백"이라고 했습니까?
 
나의 옛날 중국인 스승은 모든 마이그레이션에 관하여 속담을 가지고 있었습니다.
A good migration goes well but a great migration expects a rollback.
 
뭔가 잘못되었을 경우, 우리는 계획 B를 가졌습니다.
 
스위칭 할 때, 우리는 마지막 트랜잭션을 마스터에서 실행시켰고 마스터는 여전히 슬레이브 1과 슬레이브 2에 연결되어 있었습니다. 문제가 발생하면 모든 것을 중단하고 누락 된 트랜잭션을 내보내고 데이터를 로드한 다음 원래 마스터 + 슬레이브 1 + 슬레이브 2로 다시 전환했습니다. 고맙게도, 이것은 우리가 해야만하는 것이 아닙니다. 다음번에는 6TB Galera cluster를 MySQL 5.5에서 MySQL 5.7로 마이그레이션하는 방법에 대해 설명하겠습니다. 그러나 나중에.
 
 
반응형
저작자표시

관련글

티스토리툴바