조그만 사람의 개발 주머니

복제 Failover 복제는 고가용성의 초석이다. 데이터 복사본을 다른 위치에서 지속적으로 업데이트하면 백업으로 이동하는 것보다 재해로부터 복구하는 것이 훨씬 쉽다. 여기에서는 레플리카를 원본 노드로 승격하는 올바른 방법에 대해 설명한다. "레플리카 승격"과 "Failover"가 동의어임에 유의하자. 두 가지 모두 쓰기를 수행하지 못하도록 소스를 강등시키고 레플리카를 소스 역할로 승격시키는 작업을 의미한다. 계획된 승격 일반적으로 승격은 유지 관리 이벤트( 보안 패치, 커널 업데이트, 재시작을 해야하는 몇 가지 구성 옵션으로 인한 재시작 등 )로 인해 수행된다. 이러한 유형의 승격을 계획된 승격이라고 한다. 이 승격을 성공적으로 처리하기 위해 다음 단계를 수행한다. 1. 승격할 레플리카를 결정한다. 대개..

개요 MySQL 의 복제 기능은 소위 "스케일 아웃"이라는 아키텍처를 사용하는 고성능 애플리케이션의 기반이 된다. 복제를 통해 하나 이상의 서버를 다른 서버의 레플리카로 구성하여 데이터를 소스 복사본과 동기화할 수 있다. 이는 고성능 애플리케이션에 유용할 뿐만 아니라 고가용성, 확장성, 재해 복구, 백업, 분석, 데이터 웨어하우징 등 여러 작업을 위한 초석이 되기도 한다. 복제는 대략적인 과정은 다음과 같다. 소스 서버의 로그에 데이터 또는 데이터 구조를 수정하는 이벤트를 기록한다. 그러면 레플리카 서버는 소스의 로그에서 이벤트를 읽고 재생할 수 있다. 당연히 이렇게 되면 실시간과 레플리카에 표시된 시간 사이의 지연 ( 레플리카 지연 )이 발생하고, 이는 쿼리의 규모에 따라 몇 초, 몇 분 또는 몇 시간..

스크립트 바로가기: https://daglo.ai/share/f6L9Z-uv_szFXfbs 토스 데이터베이스의 HA 및 DR 솔루션에 대해 설명해 주세요. MMM은 MySQL Multi-Master Replication Manager의 약자로 토스 Live SQL 데이터베이스 HA 솔루션으로 사용되고 있다. 구글에서 개발한 솔루션이었으나, 현재는 업데이트가 중단되어 필요에 따라 자체 업데이트를 하며 운영하고 있다. 토스 데이터베이스는 마스터-마스터 노드로 구성되며, MMM을 통해 서로 데이터를 복제한다. 모니터링 데몬은 각 데이터베이스 서버에서 실행되며, 서비스 IP는 MMM 데이터베이스 롤 변경에 따라 이동되어, 애플리케이션 서버에 페일오버한다. 모니터링 항목은 4가지이며 이상이 있을 시 MMM이 스텐..

쿼리를 재구성하는 방법 문제가 있는 쿼리를 최적화할 때는, 원하는 결과를 얻을 수 있는 다른 쿼리를 구성하는 것이 좋지만 반드시 원하는 결과와 동일한 데이터를 산출하는 쿼리를 고집할 필요는 없다. 효율성이 향상된다면 쿼리를 다시 작성하여 약간은 다른 결과를 검색하고, 궁극적으로 애플리케이션 코드를 통해 성능을 향상 시킬 수 있다. 이 섹션에서는 광범위한 쿼리를 재구성하는 데 도움이 되는 기법에 대해 설명하고 각 기법을 언제 사용하는지에 대해 설명하고자 한다. 복잡한 쿼리 vs 많은 쿼리 쿼리 설계에 대한 중요한 질문은 "복잡한 쿼리를 여러 개의 단순한 쿼리로 분할하는 것이 더 나은지 여부"이다. 데이터베이스 설계에 대한 전통적인 접근 방식은 가능한 한 적은 쿼리로 최대한 많은 작업을 수행하는 것을 강조했..

쿼리가 느린 이유 빠른 쿼리의 핵심은 당연히도 실행 시간에 있다. 쿼리는 작업이지만, 하위 작업으로 구성되며 이러한 하위 작업은 모두 시간을 소모한다. 결국 쿼리를 최적화하기 위해서는 하위 작업을 (1) 제거하거나, (2) 발생 횟수를 줄이거나 (3) 더 빠르게 수행하여 최적화해야한다. 일반적으로 클라이언트로부터 서버까지의 쿼리의 ( 아주 대략적인 ) 라이프 사이클은 구문 분석, 계획 실행 후 다시 클라이언트로 돌아가는 것으로 이루어진다. 여기서 실행은 쿼리의 수명 중 가장 중요한 단계이며, 이 작업에서 스토리지 엔진에 대한 많은 호출과 그룹화 및 정렬과 같은 검색 후 작업이 이루어진다. 이 모든 작업을 수행하는 동안 쿼리는 네트워크, CPU 및 통계, 계획, 잠금 등의 작업에 시간을 소비하며, 특히 행..

앞선 고성능을 위한 인덱싱 (1) 에서는 다양한 유형의 인덱스를 소개하고, 유의할 점들을 살펴보았다. 이곳에서는 이런 인덱스들을 실제로 활용하고 최적화하는 방법에 대해 살펴본다. 고성능을 위한 인덱싱 전략 Prefix 인덱스 및 인덱스 선택성 인덱싱도 결국 비용이다. 데이터가 크기가 클수록 인덱스의 크기는 커진다. 이 때, 전체 값 대신 앞의 몇 개의 문자를 인덱싱 하면 공간을 절약하고 성능을 향상시킬 수 있다. "앞의 몇 개"의 기준은 총 데이터의 갯수 (#T)에 대한 고유한 데이터의 갯수(Cardinality)의 비율에 따라 달라진다. Cardinality / #T 의 값은 1 / #T부터 1까지의 스펙트럼을 지니며, 1에 가까울수록 훌륭한 인덱스 선택이 된다. 즉, 데이터의 고유성이 보장되는 범위 ..

개요 인덱스란, 스토리지 엔진이 행을 빠르게 찾기 위해 사용하는 데이터 구조이다. 인덱스는 우수한 성능을 위해 매우 중요하며, 데이터가 커질수록 더더욱 중요하다. 잘못된 인덱싱의 사용은 실제 성능 문제의 주요 원인이 되기도 한다. 인덱스 최적화는 쿼리 성능을 향상시키는 가장 강력한 방법이다. 인덱스는 성능을 수십 배나 향상시킬 수 있으며 최적의 인덱스는 때때로 단순히 양호한 인덱스보다 성능을 2배 정도 향상 시킬 수 있다. 인덱싱 기본 MySQL에서 인덱스가 어떻게 작동하는지 이해하는 가장 쉬운 방법은 책의 색인을 떠올리는 것이다. 책에서 특정 주제에 대해 찾고 싶다면, 색인을 펴서 주제를 논하는 페이지 번호를 찾고, 해당 페이지로 이동하면 된다. MySQL 스토리지 엔진은 비슷한 방식으로 인덱스를 사용..

서론 논리적, 물리적으로 우수한 설계는 고성능 쿼리의 기반이 된다. 스키마 설계는 중요하지만, 때때로 트레이드 오프를 피하기 어렵기도 하다. 가령, 비정규화된 스키마는 일부 쿼리의 속도를 높일 수 있지만, 다른 쿼리의 성능에 영향을 줄 수 있다. 카운터 및 요약 테이블을 추가하는 것이 쿼리 최적화에 도움이 될 수는 있지만, 유지 보수에 비용이 많이 들 수 있다. 따라서, 이번 장에서는 MySQL 에서 스키마 설계 시 어떤 사항들을 유의해야 하는지 살펴보고자 한다. 최적의 데이터 유형 선택 MySQL은 다양한 데이터 유형을 지원하고, 성능 향상과 리소스의 낭비를 줄이기 위해서는 적절한 데이터 유형을 선택해야 한다. 다만, 아래의 간단한 지침들은 데이터 유형과는 무관하게 더 나은 설계를 하는 데에 도움을 준..

개요 본 장에서는 MySQL 서버에서 적합한 설정 파일을 만드는 방법을 다룬다. 가령, 혹자는 "MySQL 설정 파일"에 다음과 같은 질문을 할 수도 있다. "32GB의 RAM과 12개 CPU 코어가 있는 서버에 가장 적합한 설정 파일은 무엇인가요?" 이 질문에 대한 답은 그리 간단하지 않다. 단순히 하드웨어의 스펙에 의존하는 것이 아니라 워크로드, 데이터, 어플리케이션의 특성이나 요구 사항에 맞추어 서버를 설정해야 한다. MySQL은 기본 설정으로 대부분의 시스템에서 훌륭하게 동작한다. 그래서 대부분은 기본 설정으로 MySQL 서버를 구성하고 스키마 최적화나 인덱스 및 쿼리 디자인 등에 더 많은 시간을 할애하는 것이 좋다. 심지어 기본 옵션을 변경하였을 때, 얻을 수 있는 잠재적 이점은 그리 크지 않을..

개요 MySQL에 필요한 4가지 기본 리소스는 CPU, 메모리, 디스크, 네트워크 리소스이다. 네트워크는 심각한 병목 현상을 거의 나타내지 않지만, CPU, 메모리, 디스크는 확실히 자주 나타낸다. CPU, 메모리, 디스크 간의 관계는 복잡하여, 한 영역의 문제가 종종 다른 곳에서 나타난다. 어떤 문제에 자원을 투입하기 전에 다른 문제에 자원을 대신 투입해야하는지 자문하는 과정이 필요하다. 이 장에서는 MySQL의 적절한 성능을 위해 하드웨어와 운영 체제를 어떻게 구성해나가는 것이 필요한지 다룬다. MySQL의 성능을 제한하는 요소 MySQL의 가장 흔한 병목 현상은 "CPU 고갈"이다. MySQL이 병렬로 너무 많은 쿼리를 실행하려고 하거나 수가 적더라도 CPU에서 쿼리가 너무 오랫동안 실행될 때 CP..