설치·설계
LTS 버전 선택, 스토리지 엔진·문자셋 표준, 파라미터 표준, 패키지 저장소 관리.
MariaDB
MariaDB 설계 · Galera 클러스터 · 튜닝
MySQL에서 갈라져 독자적으로 발전한 MariaDB. Galera Cluster 기반 동기 복제, MaxScale 라우팅, mariadb-backup 백업, LTS 버전 관리까지 엔진 특성에 맞게 운영합니다.
Architecture
Galera Cluster 아키텍처
Galera는 커밋 시점에 쓰기 집합(write-set)을 인증(certification)하는 가상 동기 복제로, 모든 노드가 같은 데이터를 갖는 다중 프라이머리 클러스터를 만듭니다.
노드 장애 시 남은 노드가 정족수(quorum)를 유지하는 한 서비스가 계속됩니다. MaxScale(또는 ProxySQL)을 앞단에 두어 쓰기는 한 노드로 모으고 읽기는 분산하면, 쓰기 충돌로 인한 롤백을 줄일 수 있습니다.
원격지 DR은 Galera 클러스터 간 비동기 복제로 구성하는 방식이 일반적입니다.
- 최소 3노드(또는 2노드 + Galera Arbitrator)로 정족수 확보
- 모든 테이블은 InnoDB + 기본 키 필수
- 대형 트랜잭션은 분할(흐름 제어·인증 실패 위험)
- 노드 재가입 시 IST/SST 방식과 소요 시간 사전 확인
Application서비스 / 배치
연결
MaxScalereadwritesplit · 장애 감지
라우팅
Galera Node 1쓰기 집중
Galera Node 2동기
Galera Node 3동기
백업·DR
mariadb-backup물리 백업
DR Cluster비동기 복제
wsrep 상태 지표PMM / Grafana알림
Scope
MariaDB 서비스 범위
HA·복제
Galera Cluster, GTID 비동기·반동기 복제, MaxScale 장애 감지·자동 전환.
백업·PITR
mariadb-backup 전체·증분 백업, mariadb-dump 논리 백업, binlog 시점 복구.
튜닝
InnoDB 버퍼 풀·로그, 스레드 풀, 옵티마이저 설정, 슬로 쿼리·인덱스 개선.
모니터링
wsrep_* 상태(흐름 제어·큐), 복제 지연, PMM·Grafana 대시보드.
업그레이드
LTS 간 업그레이드(예: 10.6 → 10.11/11.4/11.8), mariadb-upgrade, 롤링 업그레이드.
보안
계정·역할 정리, TLS, server_audit 플러그인 감사 로그, 데이터 at-rest 암호화.
MySQL ↔ MariaDB
버전 간 호환성 차이(GTID 형식, 시스템 테이블, 인증 플러그인) 검토 후 전환.
Replication
이중화 방식 비교
| 방식 | 특징 | 적합한 용도 | 유의 사항 |
|---|---|---|---|
| Galera Cluster | 인증 기반 가상 동기 복제, 다중 프라이머리 | RPO 최소화, 노드 장애 내성 | 쓰기 확장 수단은 아님, WAN 지연에 민감 |
| 비동기·반동기 복제 | MariaDB 고유 GTID(domain-server-seq) 기반 | 읽기 분산, DR | MySQL GTID와 형식이 달라 혼합 구성 시 주의 |
| MaxScale | readwritesplit 라우팅, 모니터·자동 장애조치 | Galera·복제 앞단 프록시 | 라이선스(BSL) 조건을 사용 전 확인 |
| ProxySQL | 쿼리 규칙 기반 라우팅 | 오픈소스 프록시 선호 시 | Galera 노드 상태 헬스체크 구성 필요 |
Backup & PITR
백업·시점 복구
# 백업
mariadb-backup --backup --target-dir=/backup/full_20261020 \
--user=bkuser --password='***'
# 준비(prepare) 후 복원
mariadb-backup --prepare --target-dir=/backup/full_20261020
systemctl stop mariadb # 데이터 디렉터리는 비어 있어야 함
mariadb-backup --copy-back --target-dir=/backup/full_20261020
chown -R mysql:mysql /var/lib/mysql && systemctl start mariadbSHOW GLOBAL STATUS WHERE Variable_name IN (
'wsrep_cluster_size', -- 클러스터 노드 수
'wsrep_cluster_status', -- Primary 여야 정상
'wsrep_local_state_comment', -- Synced 여야 정상
'wsrep_flow_control_paused', -- 흐름 제어로 멈춘 시간 비율
'wsrep_local_recv_queue_avg' -- 수신 큐 평균
);이전 버전에서는 같은 도구가
mariabackup 이름으로 제공됩니다. 사용 중인 버전의 문서를 기준으로 명령을 확정합니다.Tuning
성능 튜닝 포인트
서버·Galera
- innodb_buffer_pool_size, 로그 파일 크기, flush 설정
- thread_handling=pool-of-threads(스레드 풀) 검토
- wsrep_slave_threads(적용 병렬도), gcache 크기
- 흐름 제어(flow control) 발생 원인 노드 식별
- SST 방식(mariadb-backup) 및 donor 부하 관리
쿼리·스키마
- 슬로 쿼리 로그·ANALYZE FORMAT=JSON 분석
- 기본 키 없는 테이블 정비(Galera 필수 조건)
- 인덱스·조인 순서·옵티마이저 스위치 점검
- 대량 DML 배치 분할
- 파티셔닝·보관 정책
Lifecycle
LTS 수명주기 체크 (2026년 10월 기준)
- 커뮤니티 LTS 시리즈: 10.11 · 11.4 · 11.8 · 12.3 (각 시리즈별 유지보수 종료 시점 상이)
- MariaDB 10.6은 2026년 7월 커뮤니티 유지보수 종료 — 상위 LTS로 업그레이드 계획 필요
- 단기(rolling) 릴리스는 지원 기간이 짧아 운영 환경에는 LTS 사용을 권장
출처: mariadb.org 릴리스 공지(2026년 3분기). 적용 전 공식 일정을 다시 확인하세요.
FAQ
자주 묻는 질문
Galera로 쓰기 성능을 늘릴 수 있나요?
아니요. 모든 노드가 모든 쓰기를 적용하므로 쓰기 처리량 확장 수단이 아니라 가용성·데이터 보호 수단입니다. 쓰기 확장이 필요하면 샤딩 등 다른 설계가 필요합니다.
MySQL에서 MariaDB로(또는 반대로) 바꾸기 쉬운가요?
초기에는 호환성이 높았지만 버전이 갈라지면서 GTID 형식, 시스템 테이블, JSON 처리, 인증 방식 등 차이가 커졌습니다. 덤프·복제 방식의 전환 계획과 호환성 테스트가 필요합니다.
2노드 Galera도 가능한가요?
두 노드만으로는 한 노드 장애 시 정족수를 잃습니다. Galera Arbitrator(garbd)를 세 번째 투표자로 추가하는 방식을 권장합니다.
MaxScale 대신 무엇을 쓸 수 있나요?
ProxySQL, HAProxy(+헬스체크 스크립트) 등이 대안입니다. MaxScale은 BSL 라이선스이므로 사용 조건을 먼저 확인합니다.
클라우드와 데이터베이스, 지금 상태부터 함께 점검해 보시겠어요?
사용 중인 클라우드·DB 버전·구성과 고민을 알려주시면 진단 범위와 진행 방식을 제안드립니다.