MySQL 시니어 프레임워크 기술면접
새 면접Q. InnoDB의 페이지 압축(Page Compression)과 테이블 압축(Table Compression)의 차이점을 설명하고, 각각의 동작 원리와 성능 특성을 비교해주세요. 또한 ROW_FORMAT=COMPRESSED와 COMPRESSION='zlib' 옵션의 차이, 압축을 사용할 때 Buffer Pool과 I/O에 미치는 영향, 그리고 프로덕션 환경에서 압축 사용 여부를 결정하는 기준을 제시해주세요.
테이블 압축(ROW_FORMAT=COMPRESSED)은 InnoDB 페이지 레벨에서 압축하며 압축된 데이터와 압축 해제된 데이터를 모두 Buffer Pool에 유지합니다. 페이지 압축(COMPRESSION 옵션)은 파일 시스템 레벨의 Transparent Page Compression을 사용하며 압축 해제된 데이터만 Buffer Pool에 유지합니다. 테이블 압축은 CPU 오버헤드가 크고 압축 실패 시 페이지 분할이 발생하지만 호환성이 좋고, 페이지 압축은 CPU 효율적이고 Punch Hole 기능으로 디스크 공간을 실제로 절약하지만 파일 시스템 지원이 필요합니다. 읽기 중심 워크로드에서 디스크 I/O가 병목인 경우 압축이 유리하며, 쓰기가 많거나 CPU 바운드인 경우 압축을 피해야 합니다.
- • 테이블 압축은 InnoDB 레벨, 페이지 압축은 파일 시스템 레벨에서 동작
- • Buffer Pool 사용 패턴 차이: 테이블 압축은 압축/비압축 페이지 모두 캐싱, 페이지 압축은 비압축만 캐싱
- • 테이블 압축은 압축 실패 시 페이지 분할로 인한 성능 저하 가능
- • 페이지 압축은 Punch Hole 기능으로 실제 디스크 공간 절약, 파일 시스템 지원 필요
- • 읽기 중심 + I/O 병목 환경에서 압축 효과적, 쓰기 중심 + CPU 병목 환경에서는 부적합
압축률을 높이기 위해 KEY_BLOCK_SIZE를 작게 설정할 때 발생하는 문제점과 최적값을 찾는 방법을 설명해주세요.
Q. MySQL의 GTID(Global Transaction Identifier) 기반 복제와 전통적인 Binary Log Position 기반 복제의 차이를 설명하고, GTID의 내부 구조와 동작 원리를 설명해주세요. 또한 GTID 기반 복제에서 errant transaction이 발생하는 시나리오와 이를 감지하고 복구하는 방법, 그리고 GTID 모드로 전환 시 고려사항과 롤백 전략을 제시해주세요.
GTID는 server_uuid:transaction_id 형식으로 각 트랜잭션에 글로벌하게 유일한 식별자를 부여하여 복제 토폴로지에서 위치 추적을 자동화합니다. Binary Log Position 방식은 파일명과 오프셋으로 위치를 추적하여 마스터 변경 시 수동 계산이 필요하지만, GTID는 자동으로 복제 위치를 찾아 페일오버가 간편합니다. Errant transaction은 슬레이브에서 직접 쓰기가 발생해 마스터에 없는 GTID가 생성되는 것으로, gtid_executed를 비교하여 감지하고 해당 슬레이브를 격리하거나 GTID를 주입하여 복구합니다. GTID 전환 시 모든 노드가 MySQL 5.6 이상이어야 하며, gtid_mode=OFF_PERMISSIVE → ON_PERMISSIVE → ON 순으로 단계적 전환하고, 롤백은 역순으로 진행합니다.
- • GTID는 server_uuid:transaction_id 형식으로 트랜잭션을 글로벌하게 식별
- • 자동 페일오버와 토폴로지 변경이 용이하며 복제 위치 계산 불필요
- • Errant transaction은 슬레이브 직접 쓰기로 발생, gtid_executed 비교로 감지
- • GTID 모드 전환은 OFF_PERMISSIVE → ON_PERMISSIVE → ON 단계적 진행
- • gtid_mode, enforce_gtid_consistency 파라미터 설정 필요
GTID 기반 복제에서 CREATE TABLE ... SELECT 문이나 트랜잭션 내 임시 테이블 사용이 제한되는 이유를 설명해주세요.
Q. MySQL 8.0에서 도입된 Invisible Index의 목적과 사용 사례를 설명하고, 인덱스를 삭제하기 전에 Invisible Index로 전환하여 테스트하는 전략을 설명해주세요. 또한 Descending Index의 동작 원리와 ORDER BY col1 ASC, col2 DESC 같은 혼합 정렬에서 Descending Index가 성능에 미치는 영향을 설명해주세요.
Invisible Index는 인덱스를 물리적으로 유지하되 옵티마이저가 사용하지 않도록 하는 기능으로, 인덱스 삭제 전 영향도를 안전하게 테스트할 수 있습니다. ALTER TABLE ... ALTER INDEX idx INVISIBLE로 설정하면 쿼리 성능 변화를 모니터링하고, 문제 발생 시 VISIBLE로 즉시 복구할 수 있어 대용량 인덱스 재생성 비용을 피할 수 있습니다. Descending Index는 MySQL 8.0부터 실제 역순 정렬된 B-Tree를 생성하며, 이전 버전은 DESCENDING을 무시하고 오름차순으로만 저장했습니다. 혼합 정렬 쿼리에서 (col1 ASC, col2 DESC) 인덱스를 생성하면 Using filesort 없이 인덱스 스캔만으로 정렬을 완료하여 대용량 데이터에서 성능이 크게 향상됩니다.
- • Invisible Index는 인덱스를 유지하되 옵티마이저가 사용하지 않도록 설정
- • 인덱스 삭제 전 안전한 영향도 테스트 가능, 즉시 롤백 가능
- • MySQL 8.0의 Descending Index는 실제 역순 B-Tree 생성
- • 혼합 정렬(ASC/DESC) 쿼리에서 Using filesort 제거 가능
- • use_invisible_indexes 시스템 변수로 테스트 세션에서만 활성화 가능
프로덕션 환경에서 사용되지 않는 인덱스를 자동으로 식별하는 방법과 Performance Schema를 활용한 인덱스 사용률 모니터링 전략을 설명해주세요.
Q. MySQL 8.0에서 도입된 Role 기반 권한 관리의 동작 원리를 설명하고, 전통적인 사용자별 권한 부여 방식과 비교하여 장점을 설명해주세요. 또한 Dynamic Privilege와 Static Privilege의 차이, default_role과 activate_all_roles_on_login의 역할, 그리고 대규모 조직에서 Role 기반 권한 체계를 설계하는 모범 사례를 제시해주세요.
Role은 권한의 논리적 집합으로, CREATE ROLE로 생성하고 GRANT 문으로 권한을 부여한 뒤 사용자에게 할당합니다. 전통적 방식은 각 사용자마다 개별 권한을 부여해야 하지만, Role은 직무별로 권한을 그룹화하여 관리 복잡도를 줄이고 일관성을 유지합니다. Static Privilege는 SELECT, INSERT 등 전통적 권한이고, Dynamic Privilege는 BACKUP_ADMIN, REPLICATION_SLAVE_ADMIN 등 플러그인이나 컴포넌트가 정의하는 권한입니다. default_role은 로그인 시 자동 활성화되는 역할을 지정하고, activate_all_roles_on_login=ON은 모든 부여된 역할을 자동 활성화합니다. 대규모 조직에서는 read_only, read_write, admin 등 계층적 Role을 정의하고, 환경별(dev, staging, prod) Role을 분리하며, 정기적으로 권한 감사를 수행해야 합니다.
- • Role은 권한의 논리적 집합으로 직무별 권한 관리 간소화
- • Static Privilege는 기본 권한, Dynamic Privilege는 확장 가능한 플러그인 권한
- • default_role과 activate_all_roles_on_login으로 자동 활성화 설정
- • 계층적 Role 구조와 환경별 분리로 보안 강화
- • mysql.role_edges 테이블로 Role 상속 관계 관리
Password Validation Plugin과 Password Expiration 정책을 조합하여 엔터프라이즈급 패스워드 보안 정책을 구현하는 방법을 설명해주세요.
Q. MySQL의 Thread Pool과 전통적인 One-Thread-Per-Connection 모델의 차이를 설명하고, Thread Pool이 해결하는 문제와 동작 원리를 설명해주세요. 또한 thread_pool_size, thread_pool_stall_limit 파라미터의 역할과 튜닝 전략, 그리고 Thread Pool 사용 시 주의사항과 Connection Pool(HikariCP, c3p0 등)과의 관계를 설명해주세요.
One-Thread-Per-Connection 모델은 각 클라이언트 연결마다 전용 스레드를 생성하여 수천 개 동시 접속 시 컨텍스트 스위칭 오버헤드와 메모리 부족 문제가 발생합니다. Thread Pool은 제한된 수의 워커 스레드가 여러 연결을 처리하여 스레드 생성 비용을 줄이고 CPU 코어 수에 맞춰 최적화합니다. thread_pool_size는 스레드 그룹 수로 보통 CPU 코어 수로 설정하고, thread_pool_stall_limit은 쿼리가 블록될 때 새 스레드를 생성하는 임계값입니다. 장시간 실행 쿼리가 많으면 Thread Pool이 고갈될 수 있어 타임아웃 설정이 중요하며, 애플리케이션 Connection Pool은 데이터베이스 연결 재사용을 담당하고 Thread Pool은 서버 측 스레드 관리를 담당하여 상호 보완적입니다.
- • Thread Pool은 제한된 워커 스레드로 다수 연결 처리, 컨텍스트 스위칭 감소
- • thread_pool_size는 CPU 코어 수 기준, thread_pool_stall_limit은 블로킹 감지 임계값
- • 고동시성 환경에서 스레드 생성 오버헤드와 메모리 사용량 절감
- • 장시간 쿼리로 인한 Thread Pool 고갈 방지 필요
- • 애플리케이션 Connection Pool과 상호 보완적 역할
MySQL Enterprise Edition의 Thread Pool과 Percona Server의 Thread Pool 구현 차이를 설명하고, 각각의 장단점을 비교해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!