개요 이전 실습에서 MariaDB Replication 구성과 LazyConnectionDatasourceProxy를 활용하여 읽기 / 쓰기 트랜잭션의 Connection을 분리하고 반동기 복제 적용까지 진행하였다. 이를 통해 데이터 복제를 통한 백업, 읽기/쓰기 작업 부하 분산을 통한 성능 개선 등의 이점을 가져갈 수 있었다. Replication 구성 방법이 궁금하다면 다음의 포스팅을 참고하자. 2024.01.05 - [Database] - [MariaDB] Replication 적용기 - 1 (DB Setting) 하지만 Replication 구성만으로는 SPOF 문제가 발생할 수 있다. 앞서 진행했던 Replication 구성은 한대의 Master 서버를 통해 쓰기 작업을 수행하고 Replica..
개요 이전 실습을 통해 Replication을 적용해 보았다. 이를 통해 읽기 작업과 쓰기 작업의 부하를 분산할 수 있었고 추가적으로 데이터 분산, 분석 및 백업에 이점이 있다는 사실을 알 수 있었다. 하지만 Replication을 통해 읽기/쓰기 부하를 분산하는 방식에는 치명적인 단점이 있다. 바로 데이터의 정합성 문제가 발생할 수 있다는 점이다. Master 서버의 변경 사항이 Replica 서버 스토리지 엔진을 통해 동기화되기 전에 Replica 서버에 읽기 작업이 발생한다면, 복제되기 이전의 데이터 셋을 참조하여 정합성 문제가 발생할 수 있다. MariaDB의 경우 기본적으로 비동기 복제 방식을 사용하는데 이 방식은 Replica 서버에 이벤트가 전달되었음을 전혀 신경쓰지 않는 방식이기 때문에 이..
본 포스팅을 시작으로 Replication을 적용하는 여정에 대해 남겨보려고 한다. Replication 을 처음 접해보았거나 개념이 잘 기억나지 않는다면 이전 포스팅을 참고하자. 2024.01.03 - [Database] - [MySQL] 가용성과 확장성을 위한 Database Replication [MySQL] 가용성과 확장성을 위한 Database Replication DB Replication이 왜 필요할까? 다음과 같이 데이터베이스를 한 대만 운영하는 아키텍처가 있다고 가정해보자. 모든 데이터에 대한 읽기와 쓰기 작업은 하나의 MySQL 데이터베이스에서 수행된다. 만 rachel0115.tistory.com 다음과 같이 Master 서버에서의 데이터 변경 사항이 자동으로 Replica 서버에 반..
DB Replication이 왜 필요할까? 다음과 같이 데이터베이스를 한 대만 운영하는 아키텍처가 있다고 가정해보자. 모든 데이터에 대한 읽기와 쓰기 작업은 하나의 MySQL 데이터베이스에서 수행된다. 만약, 갑자기 서비스 홍보가 너무 잘 되어서 트래픽이 폭주했다고 가정해보자. (본 포스팅에서는 주제와 벗어나는 서버 부하는 신경쓰지 않는다.) DB 관점에서 보면 다음과 같이 크게 2가지 문제가 발생할 수 있다. [1. SPOF] 데이터베이스를 한 대만 운영하는 환경에서는 데이터베이스가 다운될 경우 전체 시스템 장애로 이어질 수 밖에 없다. 백업으로 사용할 데이터베이스도 없고 HA 구성도 되어있지 않으니 당연하다. 이처럼 하나의 요소에 생긴 장애가 시스템 전체 장애로 이어지는 것을 SPOF (Single ..
6월부터 본격적으로 본 과정에 들어가게 되면서, 프로젝트 개발을 위해 필요한 여러 설계를 진행하였다. 그 중에서도 데이터베이스 물리적 설계도 진행하였는데, 담당 멘토님께서 PK를 int 로 잡은 이유에 대해서 여쭤보셨다. 그 이유에 대해 PK 생성 방법을 MySQL의 AUTO_INCREMENT를 사용할 예정이기 때문이라고 답했고 멘토님께서 다시 AUTO_INCREMENT로 PK를 생성하는 이유에 대해 여쭤보셨는데 여기에 제대로 답을 하지 못했다. 단순히, AUTO_INCREMENT 전략을 주로 사용하여 PK를 생성한다는 것은 알고 있었지만 왜 쓰는지에 대해서 깊게 생각해본적이 없었다는 생각이 들었다. 따라서 이번 포스팅에서 PK 생성 전략을 살펴보려 한다. 식별자 (PK) 선택 전략 데이터베이스 기본 키..
인덱스란? 인덱스는 데이터베이스에서 데이터를 조회할 때 결과를 빠르게 추출하도록 도와주는 하나의 '데이터베이스 개체'입니다. 마치 사전의 '찾아보기'와 같은 역할을 한다고 생각하시면 됩니다. 결국, 인덱스에 따른 결과 값에 차이는 없고 단지 조회 성능을 개선하는 용도로 사용됩니다. 실무에서는 현실적으로 인덱스 없이 DB 운영이 불가능합니다. 하지만 인덱스가 무조건 있다고 해서 좋은 것은 아니며, 추가적인 DB 공간이 필요하고 데이터 변경 작업시 오히려 성능 저하를 불러일으킬 수 있기 때문에 꼭 필요한 컬럼에 인덱스를 생성해야합니다. 인덱스 특징 장점 적절한 인덱스를 생성하고 사용하면 조회 성능을 획기적으로 개선할 수 있음 [검색 속도 향상 & 시스템 성능 향상] 단점 인덱스는 대략 테이블 크기의 10% ..
