Multi-source replication 개요: 사용 시나리오와 충돌 위험
MySQL 다중 소스 복제의 채널 구조, 데이터 소유권과 충돌 위험을 설명하고 실제 채널 장애 진단 및 Aurora 적용 기준을 정리한다.
전체 문서 29개 · 1 / 2 페이지
MySQL 다중 소스 복제의 채널 구조, 데이터 소유권과 충돌 위험을 설명하고 실제 채널 장애 진단 및 Aurora 적용 기준을 정리한다.
MySQL 비동기 복제의 binlog·relay log 전달 경로와 수신·적용 스레드를 구분하고, 복제 지연과 장애를 단계별로 진단한다.
MySQL 8.0 오류 로그의 component pipeline, 규칙 기반 필터링, JSON 출력과 수집·복구 절차를 운영 관점에서 정리한다.
MySQL Performance Schema의 instrument, consumer, event table 연결 구조와 운영 시 관측·비용 제어 원칙을 정리한다.
MySQL Unique index에서 NULL이 중복으로 허용되는 원리와 복합 키·조건부 유일성·정규화 키 설계 패턴을 운영 관점에서 정리한다.
InnoDB Primary Key의 단조 증가성, 폭, 변경 불가성, 분산 ID 생성이 쓰기와 보조 인덱스에 미치는 영향을 설명한다.
MySQL이 subquery를 semi-join 또는 materialization으로 변환하는 원리와 dependent subquery의 반복 실행을 진단하는 방법을 정리한다.
MySQL이 derived table과 CTE를 merge하거나 materialize하는 조건, 실행 비용, 진단 방법을 운영 관점에서 정리한다.
MySQL이 SQL을 parser, resolver, optimizer, executor 단계로 처리하는 흐름과 실행 계획 해석의 핵심 포인트를 운영 관점에서 정리한다.
ProxySQL가 MySQL 앞단에서 hostgroup, query rule, connection multiplexing으로 어떤 운영 문제를 풀고, read/write split과 failover 보조를 어디까지 맡길 수 있는지 정리한다.
MySQL connection pool 크기, 대기열, timeout, backpressure를 어떻게 설계해야 데이터베이스 과부하와 애플리케이션 장애 전파를 막을 수 있는지 운영 관점에서 정리한다.
MySQL client/server protocol에서 handshake, packet framing, text result set, prepared statement binary protocol이 어떻게 동작하는지 운영 관점에서 정리한다.
MySQL prepared statement와 드라이버 statement cache가 연결 풀과 결합될 때 어떤 메모리·세션·장애 특성이 생기는지 운영 관점에서 정리한다.
MySQL에서 sort_buffer_size, join_buffer_size, tmp_table_size를 세션 메모리 관점에서 어떻게 해석해야 하는지와 과대 설정이 만드는 메모리·디스크·장애 리스크를 운영 관점에서 정리한다.
MySQL에서 wait_timeout, interactive_timeout, net_read_timeout, net_write_timeout가 각각 무엇을 보호하며 어떤 장애 양상으로 나타나는지 운영 관점에서 정리한다.
MySQL에서 max_connections와 thread_cache_size를 어떻게 함께 설계해야 연결 폭주, 메모리 고갈, thread 생성 비용을 줄일 수 있는지 운영 관점에서 정리한다.
MySQL 클라이언트 연결이 생성될 때 handshake, 인증, 세션 스레드 할당이 어떤 순서로 진행되는지 운영 관점에서 정리한다.
MySQL 8.0 InnoDB data dictionary와 metadata lock이 DDL, DML, 장애 대응, 온라인 변경 작업에 미치는 영향을 운영 관점에서 정리한다.
InnoDB 레코드에 포함되는 hidden column이 clustered index, MVCC, undo log, Primary Key 설계에 어떤 의미를 갖는지 운영 관점에서 정리한다.
InnoDB secondary index가 leaf record에 Primary Key를 함께 저장하는 이유와, covering read·clustered lookup·인덱스 크기 증가 비용을 운영 관점에서 정리한다.