인트로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 관련 이슈 실제 시나리오로 살펴보겠습니다. 크로스 어카..