MariaDB 주니어 배포·운영 면접
새 면접Q. MariaDB 운영 환경에서 정기적인 백업을 수행해야 합니다. mysqldump를 이용한 백업 방법과 이 백업 파일을 이용해 데이터를 복구하는 방법을 설명해주세요. 또한 백업 시 서비스에 미치는 영향을 최소화하기 위해 어떤 옵션을 사용할 수 있는지 말씀해주세요.
논리적 백업 도구의 기본 명령어와 트랜잭션 일관성을 보장하는 옵션을 생각해보세요.
mysqldump는 MariaDB의 논리적 백업 도구로, 'mysqldump -u사용자명 -p 데이터베이스명 > 백업파일.sql' 형식으로 사용합니다. 복구는 'mysql -u사용자명 -p 데이터베이스명 < 백업파일.sql' 명령으로 수행합니다. 서비스 영향을 최소화하기 위해 --single-transaction 옵션을 사용하면 테이블 락 없이 일관된 스냅샷을 얻을 수 있습니다. InnoDB 엔진 사용 시 이 옵션은 특히 유용하며, 백업 중에도 서비스가 정상적으로 동작할 수 있습니다. 추가로 --routines, --triggers 옵션을 함께 사용하면 저장 프로시저와 트리거도 백업할 수 있습니다.
- • mysqldump를 이용한 백업과 mysql 명령을 이용한 복구 방법
- • --single-transaction 옵션으로 서비스 중단 없이 백업 가능
- • InnoDB 엔진에서 트랜잭션 일관성 보장
운영 중인 데이터베이스의 야간 정기 백업 스케줄링과 장애 발생 시 특정 시점으로 데이터 복구 작업에 사용됩니다.
물리적 백업 방법인 Mariabackup과 mysqldump의 차이점은 무엇이며, 각각 어떤 상황에서 사용하는 것이 적합한가요?
Q. 운영 중인 MariaDB 서버의 성능이 갑자기 느려졌다는 보고를 받았습니다. 현재 실행 중인 쿼리들을 확인하고, 문제가 되는 슬로우 쿼리를 찾아 종료하는 과정을 설명해주세요. 또한 슬로우 쿼리 로그를 활성화하여 지속적으로 모니터링하는 방법도 함께 설명해주세요.
실행 중인 프로세스 목록을 보는 명령어와 슬로우 쿼리 로깅 설정을 생각해보세요.
먼저 'SHOW PROCESSLIST' 또는 'SHOW FULL PROCESSLIST' 명령으로 현재 실행 중인 쿼리 목록과 실행 시간을 확인합니다. Time 컬럼이 큰 값을 가진 쿼리가 문제의 원인일 가능성이 높습니다. 문제 쿼리를 종료하려면 'KILL 프로세스ID' 명령을 사용합니다. 슬로우 쿼리 로그는 my.cnf 설정 파일에 'slow_query_log=1', 'slow_query_log_file=/var/log/mysql/slow.log', 'long_query_time=2' 등을 설정하여 활성화합니다. 설정 후 MariaDB를 재시작하거나 'SET GLOBAL slow_query_log=1' 명령으로 즉시 적용할 수 있습니다. 이후 mysqldumpslow 도구로 슬로우 쿼리 로그를 분석하여 최적화가 필요한 쿼리를 식별합니다.
- • SHOW PROCESSLIST로 실행 중인 쿼리 확인 및 KILL 명령으로 종료
- • 슬로우 쿼리 로그 설정을 통한 지속적인 모니터링 체계 구축
- • long_query_time 설정으로 기준 시간 이상 쿼리 기록
실시간 서비스에서 갑작스러운 응답 지연 발생 시 원인 쿼리를 신속하게 찾아 조치하고, 재발 방지를 위한 모니터링 체계를 구축하는 데 사용됩니다.
슬로우 쿼리를 발견한 후 EXPLAIN 명령을 사용하여 쿼리 실행 계획을 분석하는 방법과 인덱스 최적화 전략에 대해 설명해주세요.
Q. MariaDB의 Master-Slave 복제 구조에서 Master 서버에 문제가 생겼을 때 Slave를 Master로 승격시키는 Failover 과정을 설명해주세요. 또한 복제 지연(Replication Lag)이 발생하는 원인과 이를 확인하는 방법에 대해서도 말씀해주세요.
복제 상태를 확인하는 명령어와 Slave를 독립적인 Master로 전환하는 절차를 생각해보세요.
Slave에서 'SHOW SLAVE STATUS'로 복제 상태를 확인하고 Seconds_Behind_Master가 0이 될 때까지 대기합니다. 복제가 최신 상태가 되면 'STOP SLAVE' 명령으로 복제를 중지하고, 'RESET SLAVE ALL'로 복제 정보를 제거하여 Slave를 독립적인 Master로 전환합니다. 애플리케이션의 DB 접속 정보를 새로운 Master로 변경합니다. 복제 지연은 Master의 쓰기 부하가 높거나 Slave의 하드웨어 성능이 부족할 때 발생하며, 'SHOW SLAVE STATUS'의 Seconds_Behind_Master 값으로 확인합니다. 복제 지연을 줄이려면 Slave의 하드웨어를 업그레이드하거나 병렬 복제(slave_parallel_threads) 설정을 활용할 수 있습니다.
- • SHOW SLAVE STATUS로 복제 상태 확인 후 STOP SLAVE와 RESET SLAVE ALL로 승격
- • Seconds_Behind_Master 값으로 복제 지연 모니터링
- • 복제 지연 원인은 Master 부하 또는 Slave 성능 부족
서비스 가용성을 보장하기 위해 Master 장애 시 신속하게 Slave로 전환하고, 평소 복제 지연을 모니터링하여 데이터 정합성을 유지하는 데 사용됩니다.
Master-Master 복제 구조와 Master-Slave 구조의 차이점은 무엇이며, 각각 어떤 상황에서 적합한가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!