By Herman Lee, Pradeep Nayak

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/3b2723ee-26c5-4f95-93ba-4d1574171a53/Untitled.png

페이스북 팀이 수 년에 걸쳐 진행한 MySQL 8.0 마이그레이션 작업을 공유했습니다.

<aside> 👉🏻 역자 주

이번 글의 대부분은 구글 번역을 사용했습니다. 글을 읽다가 어색한 부분이 있으면 원본 글을 바로 참조하시는 것을 추천해드립니다. - 역자 방신우

</aside>

Oracle 오픈 소스 데이터베이스 MySQL은 Facebook의 중요한 워크로드를 담당합니다. 요구 사항이 늘 변화무쌍하기 때문에, 대응 차원에서 MySQL의 새로운 기능을 적극적으로 개발하고 있습니다. 클라이언트 커넥터, 스토리지 엔진, 옵티마이저 및 복제를 포함하여 MySQL의 다양한 영역을 건드리고 있습니다. 각각의 새로운 주요 MySQL 버전은 워크로드를 마이그레이션하는 데 상당한 시간과 노력이 필요합니다.

주요 도전 과제

MySQL 5.6 마이그레이션은 1년 이상이 걸렸습니다. 버전 5.7이 출시되었을 때 저희는 버전 5.6 LSM-Tree 스토리지 엔진인 MyRocks를 개발 중이었습니다. 5.7로 업그레이드하는 동시에 새 스토리지 엔진을 구축하면 MyRocks 진행 속도가 크게 느려지므로 MyRocks가 완료될 때까지 5.6을 유지하기로 결정했습니다. MyRocks 사용자 데이터베이스(UDB) 서비스 계층 개발을 마쳤을 때, MySQL 8.0도 출시됐습니다.

8.0에는 쓰기 writeset-based 병렬 복제 및 원자적 DDL 지원을 제공하는 트랜잭션 데이터 사전과 같은 강력한 기능이 포함되어 있습니다. 5.7에서 나왔지만 일정상 써보지 못했던 Document Store도 있었습니다. 5.6 버전 수명이 거의 다 되었고, 특히 MyRocks 지원과 MySQL Community. Instant DDL과 같은 8.0의 개선 사항은 MyRocks 스키마 변경 속도를 높일 수 있지만 이를 사용하려면 8.0 코드가 필요했습니다. 코드 업데이트의 이점을 고려하여 8.0으로 마이그레이션하기로 결정했습니다. 8.0 마이그레이션 프로젝트를 처리한 방법과 그 과정에서 발견한 몇 가지 놀라움을 공유하겠습니다. 8.0 마이그레이션이 5.6 및 MyRocks로의 마이그레이션 때보다 훨씬 어려운 작업이라는 건 분명했습니다.