# Intro AWS RDS 에서도 MySQL 8.4.3 버전이 릴리즈 되었습니다.내년에는 Aurora MySQL 4 버전이 나오지 않을까 예상됩니다.지난 몇년간 MySQL 5.7 에서 MySQL 8.0으로의 업그레이드 & 마이그레이션이 이루어졌던 것 처럼, 이제는 8.4 버전에 대해 미리 학습하고 대비해두는 것이 좋을 것으로 보입니다.하여튼, 이 글에서는 MySQL 8.4 버전을 활용해서 InnoDB Cluster를 구성하는 내용을 기록하겠습니다.   # 환경Docker에 편하게 구성하려 했으나... 성능 간섭이 생길 것 같아, 비용은 들지만 AWS EC2 에 인스턴스를 구성합니다.Ubuntu Server 24.04 LTSt2.microgp2 8GB 스토리지인스턴스 수량 총 4대 필요 인스턴스를 4개 ..

인트로MySQL을 운영하면서 주의깊게 보는 메트릭이 여러가지 있습니다. CPU 사용율이나 Memory 사용량 등 하드웨어 수치도 중요하지만, 그 중 서버 내부 메트릭 중 Handler 메트릭이 있습니다. 이 수치들을 모니터링하면 실제 피크타임에 문제가 발생하고 나서 알아차리는 것 보다 빠르게 미리 문제를 식별하고 조치할 수 있습니다.이 글에서는 간단하게 해당 메트릭들을 PMM을 통해 모니터링하고, 조치하고, 자동화하는 방법을 작성해보겠습니다.   실험 환경AWS RDS MySQL 8.0.39버전, db.t4g.micro 클래스의 DB 인스턴스슬로우 쿼리, slow_extra 파라미터 활성화로컬에서 docker를 통해 Percona Monitorng Management를 실행 (PMM)AWS IAM 사용자..

목적DB 버전을 업그레이드하는 작업은 단순 버전 업그레이드 이상의 주의를 기울여야 할 필요가 있습니다.특히, 서비스 중단 없이 실시간 세션을 유지한 채로 어플리케이션 추가 배포 없이 업그레이드를 진행하려면 사전에 세심한 설계와 준비가 필수입니다. 이 글은 AWS RDS MySQL 5.7에서 MySQL 8.0으로 무중단 마이그레이션을 위한 ProxySQL과 Route53 활용 사례를 소개하기 위해 작성되었습니다. 단순 DB 한 대만 있는 시나리오가 아닌, 난이도를 높이기 위해 실무 아키텍처를 살짝 가져와봤습니다.  기술 요구사항(제약사항)업그레이드- 현재 운영 중인 DB(MySQL 5.7)를 MySQL 8.0으로 업그레이드하되, 어플리케이션 재배포 없이 중단 없는 무중단 세션 전환.데이터 일치- 마이그레이..

이 글은 '관계형 데이터 모델링 프리미엄 가이드 (이론과 실무를 겸비한 최고의 전략서)'를 보고 학습한 내용을 정리한 글입니다. 데이터 모델링이 어려운 이유?모델링 이론 외에 알아야 하는 분야의 폭이 넓기 때문데이터의 본질(추상적인 개념), DBMS의 구체적인 특징과 기능까지 모두 알아야 함데이터 관점과 성능 관점 모두 지식을 습득해야 함사실상 정답이 없음좋은 모델은?단순하고 명확한 모델데이터 무결성이 보장되는 모델성능과 대척점에 있는 경우도 있음본질적으로 중복을 줄이는 것  2장. 데이터 모델링 기본 개념관계형 데이터 모델함수 종속에 의해 정규화된 모델이 관계형 모델이다.무결성(Integrity)흠이 없이 온전함데이터 값이 정확한 상태정합성데이터가 서로 모순이 없이 일관되게 일치해야 한다는 의미무결성과..

최근 프로젝트에서 기존의 utf8 문자 집합을 가진 테이블을 utf8mb4로 변환하는 작업을 진행했습니다.다들 아시다시피 utf8 3바이트 문자체계로는 이모지 등의 특정 문자를 삽입할 수 없습니다. (utf8mb3)이번 작업도 레거시 아키텍처인 utf8(mb3) 기반의 테이블에 이모지 등의 문자가 삽입되어야하는 요구사항이 생겨서 캐릭터셋 컨버팅(확장)이 필요한 상황이었습니다. 문자 집합 확장 작업은 비손실 작업이기 때문에 데이터 손실에 대한 부담없이 작업할 수 있었습니다. 그래서 개발 DB 환경에서 먼저 성공적으로 작업 후 퇴근했는데, 개발팀에서 컬럼을 바꿨냐는 문의 메세지가 왔습니다.당연히 바꾸지 않았다고 말씀드렸고, 다음 날 출근해서 문제를 파악하기 시작했습니다. 컬럼 타입 묵시적 변경 이슈는 데이터..

알고있다고 생각했던 개념들을 입 밖으로 내보니 제대로 설명 못하거나, 틀린 개념을 알고 있다는 걸 발견했다.스터디의 중요성 같기도 하다. (같은 직군과 평소에 이야기를 할 기회가 없어서 아쉽다ㅠ)  완전관리형 서비스인 AWS RDS Aurora MySQL 만 메인으로 사용하다보니 binlog replication 관련해서는 겉핥기만 알고 있다는 것을 알았다.percona pt-osc, gh-ost, mha, mmm 등 운영에 필요한 메인스트림의 주요 도구들도 사용할 일이 없어서 제대로 파악하지는 못하고 있었다. 그래서 이번에 관련 도구와 기술을 잘 써놓은 서적인 'DBA를 위한 MySQL 운영 기술' 절판된 책을 중고로 구매했다.https://search.shopping.naver.com/book/cat..

여러가지 비즈니스적 결정 사유로 인해 크고 작은 마이그레이션 작업은 DBA로서 피할 수 없는 일상 업무입니다. 이번에도 언제나 그렇듯, 클러스터 마이그레이션이 진행되었습니다.서비스 규모는 조금 있었으나 다행히 중단이 가능한 서비스여서 부담은 크지 않았습니다. 특이점이라고 한다면 AWS 계정이 달라서 CROSS-ACCOUNT 스냅샷 공유를 통해 스냅샷을 공유받아 복원한다는 점이었으나, 몇 번 해보니 KMS 관련 세팅만 잘 하면 별 문제는 없었습니다.  이 종류의 마이그레이션을 진행하면서 MySQL 계정 관련 문제를 일으킨 서로 다른 두 가지 사례를 소개합니다. 귀여운 경험치를 가진 글입니다 호호     1. validate_password_policy 관련 이슈 실제 시나리오로 살펴보겠습니다. 크로스 어카..

안녕하세요? DBA로 일하고 있는 일반인입니다.  [AWS 멀티 어카운트 환경]에서의 RDS 운영 - Aurora MySQL 을 Slack ChatOps로 극한까지 자동화한 개인 프로젝트를 소개합니다.플랫폼 엔지니어링의 관점에서 어떻게 하면 데이터베이스 운영을 최소한의 리스크로 고품질로 유지시킬지에 대해 많은 고민을 담았습니다.이 글에서 설명하는 모든 내용의 코드는 https://github.com/leezzangmin/db_automation 에서 보실 수 있습니다.    프로젝트의 목적과 탄생 배경DBA로서 매일 반복적인 작업을 하다 보면 지치기 마련입니다.모든 개발팀의 요청 작업 및 데이터베이스 배포는 수문장처럼 지키고있는 DBA의 검토를 받습니다.아무리 간단하고 변경내용이 작은 작업이라도 업무 협..

MySQL을 운영하다보면 종종 Rollback History List Length 메트릭에 걸려있는 알람이 울립니다. 트랜잭션이 너무 오래 열려있어서 Length가 길어지는 현상인데요, MySQL에서는 MVCC 를 통해 잠금없는 SELECT를 구현합니다. MVCC 매커니즘은 Undo Log(=Rollback Segment)를 통해 구현되기 때문에 Undo Log를 임계치 이하로 관리하는 것이 매우 중요합니다. 임계치를 벗어나게 되면 read 레이턴시가 전반적으로 매우 하락해서 유저 경험 또한 매우 하락하게 되겠죠 -_-; 제가 경험했던 Undo Log가 길어지는 이유는 크게 세 가지 였습니다. 서비스 Batch가 장시간 실행되는 경우 개발자가 개인 컴퓨터 환경에서 수동으로 트랜잭션을 열고 난 후에, 커밋..

MySQL은 오픈소스 서비스입니다. 그래서 공식 홈페이지에 가면 쉽게 소스를 다운받을 수 있습니다. 다운받는 과정까지가 가장 쉽습니다 다운 받고 압축을 풀면, vscode로 열어서 코드를 확인할 수 있습니다. '소스 설치' 를 할 것이 아니라면 어느 OS 에서든지 그냥 아무거나 받아서 봐도 됩니다. 소스를 다운받는 것에 큰 의미는 없고, 유능한 DBA가 되려면 언젠가 소스를 까볼 일이 생길 것만 같았습니다. 그래서 오늘은! 칼을 뽑은 김에 테이블을 삭제하는 프로세스가 내부적으로 어떻게 일어나는지 살펴보겠습니다. 참고로 이 글은 C/C++을 학부시절에만 만져봐서 뭐가 어떻게 흘러가는지 모를 사람에 의해 쓰여지고 있습니다. 가장 아래에 첨부된 소스코드 가이드가 있긴 한데, 워낙 프로젝트가 방대해서 도움이 잘..