toDBA

MongoDB 3-Node Replica Set 설치 가이드 (Failover 테스트 환경)

핵심 설계 포인트: Docker Compose로 그대로 따라 설치할 수 있는 가이드로 작성했습니다.컨테이너별로 다른 포트(27017/27018/27019)를 쓰는 이유를 명시했습니다 — 셋 다 27017로 통일하면 호스트에서 접속할 때 엉뚱한 컨테이너로 연결되는 흔한 실수가 생깁니다.keyFile 권한(400 + 999:999 소유자)까지 정확히 맞춰야 기동에 실패하지 않는다는 점을 짚었습니다./etc/hosts 등록이 반드시 필요한 이유(컨테이너 간 DNS는 자동이지만 호스트는 별도)를 설명했습니다. 1. 로컬 pc에서 key file 생성 2. docker-compose.yml 파일 생성services: # 이 파일로 띄울 컨테이너들을..

매일 gpt를 이용한 개인신문을 받고있다. 내가 관심있어 하는 주제영역에 대해서 아래 섹션으로 구성해놓고 아래 절차대로 구성한 신문을 매일 보고 있는데 도움이 많이 되는 것 같다. 개인적으로는 DB에 관한 내용을 더 deep하게 달라고 요청했기 때문에 이 부분에 대한 영역이 70% 차지한다. ① 최신 24~72시간 자료 검색DB / AI / 경제 / 부동산 / 커리어 후보를 넓게 수집한다.↓② 공식 출처 우선 검증DB release 같은 기술 정보는 vendor 공식 문서를 우선 확인한다. 어떤 형식으로 받고 있는지에 대해서 간단히 아래는 첫지면에 대한 캡처. 아래는 주제에 대해서 기사 원문.. 진짜로 맞는지는 한번 더 검토해봐야한다.

앞선 글에서 Replica Set을 구축하며 "Primary에 쓰면 Secondary로 비동기 복제된다"고 설명했는데, 그 복제를 실제로 가능하게 하는 것이 **Oplog(Operations Log)**입니다.MySQL의 바이너리 로그(binlog)와 목적은 같지만 구조와 동작 방식은 다른 부분이 많습니다.이 글에서는 Oplog의 구조, 저장 방식, 그리고 복제/멱등성과 어떻게 연결되는지 살펴봅니다.1. Oplog란 무엇인가Oplog는 Primary에 가해진 모든 쓰기 연산(insert/update/delete/일부 명령어)을 순서대로 기록해두는 특수한 컬렉션입니다.local 데이터베이스의 oplog.rs 컬렉션(local.oplog.rs)에 저장되며, Secondary들은 이 컬렉션을 계속 읽어(tai..

단일 mongod 인스턴스는 프로세스가 죽거나 서버 장애가 나면 그대로 서비스 중단입니다.MongoDB의 Replica Set은 동일한 데이터를 여러 노드에 복제해두고, Primary 장애 시 남은 노드 중 하나를 자동으로 승격시켜 서비스를 지속시키는 구성입니다.MySQL의 복제(Replication)+MHA(또는 Orchestrator) 조합과 목적은 같지만, MongoDB는 자동 Failover가 DB 자체 기능으로 내장되어 있다는 점이 다릅니다. 이 글에서는 가장 기본이 되는 3-Node 구성을 처음부터 끝까지 구축합니다.1. 왜 3개(홀수) 노드인가Replica Set은 투표(vote)를 통한 과반수(majority) 합의로 Primary를 선출합니다.노드가 짝수면 네트워크 분할(split-bra..

쿼리가 느려질 때 MySQL이었다면 EXPLAIN부터 찍어봤을 겁니다.MongoDB에도 동일한 역할을 하는 explain()이 있고, 인덱스 설계 원리 역시 B-Tree 기반이라 개념적으로 닮은 부분이 많습니다. 이 글에서는 MongoDB의 인덱스 종류, explain() 읽는 법, 그리고 실전에서 자주 마주치는 튜닝 포인트를 예시로 정리합니다.1. 인덱스가 없으면 생기는 일: COLLSCAN인덱스가 없는 컬렉션에서 조건 조회를 하면, MongoDB는 문서를 처음부터 끝까지 훑는 COLLSCAN을 수행합니다. MySQL의 Full Table Scan과 동일한 개념입니다.db.users.find({ name: "이테스" });인덱스가 없다면 실행계획은 대략 이렇습니다.db.users.find({ name:..

MongoDB에서 스키마 설계를 시작하면 가장 먼저 마주치는 질문이 "이 데이터를 한 문서 안에 다 넣을까(임베딩), 아니면 별도 컬렉션으로 나누고 참조할까?"입니다. RDB에서는 정규화가 기본값이라 이런 고민 자체가 없었지만, MongoDB에서는 이 선택이 곧 조회 성능, 쓰기 원자성, 데이터 정합성을 좌우합니다. 이 글에서는 Embedding과 Referencing 두 패턴을 예시로 비교하고, 실무에서 어떤 기준으로 선택하는지 정리합니다.1. 두 패턴 한눈에 비교jj 구분 Embedding (임베딩)Referencing (참조)저장 방식연관 데이터를 한 문서 안에 중첩별도 문서/컬렉션에 저장하고 ID로 연결조회find() 한 번으로 완료$lookup 또는 애플리케이션에서 여러 번 조회쓰기 원자성단일..

MongoDB를 처음 접하면 "JSON 저장하는 DB"라고 단순하게 이해하기 쉽습니다.하지만 MongoDB가 실제로 디스크에 저장하는 형식은 JSON이 아니라 **BSON(Binary JSON)**입니다.이 글에서는 BSON이 무엇이고 JSON과 어떻게 다른지, 그리고 그 위에서 Document가 어떤 구조로 이루어지는지 예시로 살펴봅니다.1. BSON이란?BSON은 Binary JSON의 줄임말로, MongoDB가 문서를 저장·전송할 때 실제로 사용하는 바이너리 인코딩 포맷입니다. mongosh나 드라이버에서 우리가 보는 { name: "Kim", age: 34 } 같은 JSON 형태는 사람이 보기 편하게 표현된 것이고, 서버 내부와 디스크(WiredTiger 스토리지 엔진)에는 BSON으로 인코딩되어..

MySQL/MariaDB를 운영하다 MongoDB를 처음 접하면 가장 먼저 헷갈리는 것이 "테이블이 왜 없지?", "JOIN은 어떻게 하지?" 같은 질문입니다.MongoDB는 MySQL과 단순히 문법만 다른 데이터베이스가 아닙니다.데이터를 저장하고 설계하는 방식 자체가 다릅니다.이 글에서는 RDB(관계형 데이터베이스)의 대표주자인 MySQL과 문서지향(Document-Oriented) NoSQL인 MongoDB의 구조적 차이를 실제 예시로 비교해보겠습니다.특히 MySQL/MariaDB를 운영해본 DBA라면 익숙한 Table, Row, Column, PK, FK, JOIN, 정규화 등의 개념을 MongoDB에서는 어떻게 바라보는지 중심으로 설명합니다.0. MongoDB란?MongoDB는 대표적인 Docum..

DBA가 반드시 확인해야 할 변경사항최근 MySQL 운영 환경에서 MySQL 8.0 → 8.4 업그레이드를 검토하는 경우가 많아졌다. 특히 AWS RDS 환경에서는 MySQL 8.0의 Standard Support 종료 시점이 다가오면서 8.4 업그레이드를 더 이상 단순한 "버전 업그레이드"로 보기 어렵다.2026년 현재 운영 DBA 입장에서는 다음과 같은 선택지를 검토해야 한다.MySQL 8.0 유지 + RDS Extended SupportMySQL 8.4로 Major Version UpgradeAurora MySQL로 전환장기적으로 MySQL 8.4 LTS 기반으로 운영Amazon RDS 기준으로 MySQL 8.0의 Standard Support는 2026년 7월 31일 종료되며, 이후에는 Exten..

MySQL vs MariaDB GTID 복제 내부 동작 정리Global Transaction Identifier(GTID) 기반 복제의 개념부터 실무에서 마주치는 트러블슈팅 포인트까지 정리했습니다.1. GTID란모든 커밋된 트랜잭션에 전역적으로 유일한 식별자를 부여하는 방식입니다.구분 포맷 예시MariaDBDomainID-ServerID-Sequence0-1-1523MySQLServer_UUID:Transaction_ID9a511b7b-7059-11e2-9a24-08002762b8af:14왜 MariaDB만 Domain ID가 있을까MariaDB의 GTID에만 Domain ID가 붙는 이유는 Multi-Source Replication(MSR) 때문입니다. 하나의 복제본이 여러 마스터로부터 동시에 데이터..