• Real MariaDB
  • MariaDB 10.0과 MySQL 5.6을 함께 배우는

  • 이성욱 지음

  • 위키북스 오픈소스 & 웹 시리즈_58, 데이터 & 데이터베이스 시리즈 _ 007
  • ISBN: 9788998139537
  • 35,000원 | 2014년 04월 18일 발행 | 628쪽



▣ 구글과 카카오에서 선택한 MariaDB의 모든 것을 분석해드립니다!

▣ MariaDB 10.0과 MySQL의 5.6 최신 버전을 함께 배울 수 있습니다!

MySQL이 오픈 코어 방식의 상용화를 도입하면서 일부 기능들이 오픈 소스에서 누락되기 시작했는데, 다행히 MariaDB 서버가 그 자리를 조금씩 메워주고 있다. MySQL 엔터프라이즈 버전에만 사용 가능한 상용 기능들을 MariaDB를 통해서 무료로 사용할 수 있게 된 것이다. 또한 MariaDB 사용자도 많이 늘어나면서, 이제 MariaDB는 더는 미완성의 MySQL 변종이 아니라 MySQL 엔터프라이즈 버전과 경쟁하는 안정적인 오픈소스 DBMS가 된 것이다.

『Real MariaDB』는 MariaDB와 MySQL에 관심을 가지고 있는 독자들을 위해서, MariaDB 10.0과 MySQL 5.6의 각 고유 기능과 공통 기능들을 비교 설명하는 방식으로 구성했다.

여러분은 이 책을 통해서 MariaDB와 MySQL의 특성과 기능 차이를 이해하고, 서비스의 특성에 맞게 (MariaDB와 MySQL중에서) 적절한 솔루션을 선택하는 안목을 키울 수 있을 것이라 확신한다.

★ 이 책에서 다루는 내용 ★

  • MariaDB와 MySQL과의 호환성
  • MariaDB의 설치 및 마이그레이션
  • 온라인 스키마 변경
  • 실행 계획 분석
  • MariaDB 10.0과 MySQL 5.6의 최적화
  • MariaDB의 스토리지 엔진
  • MariaDB의 부가 기능(스레드 풀 및 관리 진단 도구)
  • XtraBackup 백업 도구
  • MariaDB 10과 MySQL 5.6의 복제 (GTID와 멀티 소스 복제 그리고 멀티 스레드 슬레이브)

★ 이 책에 관련된 내용이나 MariaDB, MySQL에 대한 기술 문의는 아래 Real MySQL 카페를 이용해 주세요.

이성욱

컴퓨터 과학을 전공하고 금융권의 CRM/DW 프로젝트의 리더로 참여했으며, 2년여간 DW를 위한 ETL 솔루션 개발도 추진했다. NHN의 DBA로 근무하면서 표준화와 데이터 모델링 그리고 DB운영 및 기술 벤치마킹을 수행했으며, 카카오의 전사 MariaDB 업그레이드 및 카카오를 위한 MariaDB 빌드를 위한 코드 보완 및 벤치마킹을 진행하고 있다.

<저서>

  • PHP5 웹 프로그래밍
  • MySQL 성능 최적화
  • Real MySQL
  • ▣ 01장: MariaDB
    • 1.1 MariaDB란?
    • 1.2 MariaDB vs. MySQL
      • 1.2.1 MariaDB와 MySQL 그리고 PerconaServer
      • 1.2.2 공통점
      • 1.2.3 차이점
        • 1.2.3.1 라이선스
        • 1.2.3.2 스토리지 엔진
        • 1.2.3.3 기능
        • 1.2.3.4 옵티마이저
      • 1.2.4 버전별 호환성
      • 1.2.5 성능 비교
      • 1.2.6 MariaDB가 MySQL을 대체하게 될까?
      • 1.2.7 MariaDB와 MySQL 선택
  •  
  • ▣ 02장: 설치
    • 2.1 다운로드
    • 2.2 설치
      • 2.2.1 윈도우 버전 설치
        • 2.2.1.1 설치 프로그램(MSI)을 이용한 설치
        • 2.2.1.2 압축(ZIP)된 MariaDB 설치
      • 2.2.2 리눅스 버전 설치
        • 2.2.2.1 RPM을 이용한 설치
        • 2.2.2.2 압축(tar.gz)된 MariaDB 설치
    • 2.3 업그레이드
      • 2.3.1 MySQL에서 MariaDB로 업그레이드할 때 주의 사항
      • 2.3.2 버전에 관계없이 가장 안전한 방법
      • 2.3.3 MySQL 5.0이나 그 이전 버전에서 MariaDB 5.5로 업그레이드
      • 2.3.4 MySQL 5.1에서 MariaDB 5.5로 업그레이드
      • 2.3.5 MySQL 5.5에서 MariaDB 5.5로 업그레이드
  •  
  • ▣ 03장: MariaDB 기동 및 쿼리 실행
    • 3.1 서버 시작 및 종료
      • 3.1.1 리눅스에서 MariaDB 서버의 시작과 종료
        • 3.1.1.1 서비스로 등록된 경우
        • 3.1.1.2 서비스로 등록되지 않은 경우
      • 3.1.2 윈도우에서 MariaDB 서버의 시작과 종료
        • 3.1.2.1 서비스로 등록된 경우
        • 3.1.2.2 서비스로 등록되지 않은 경우
    • 3.2 서버 로그인
      • 3.2.1 서버 로그인 및 버전 확인
      • 3.2.2 mysql 클라이언트 프로그램 옵션
        • 3.2.2.1 안전 모드로 mysql 클라이언트 실행
        • 3.2.2.2 --execute 옵션으로 mysql 클라이언트 실행
        • 3.2.2.3 --batch 모드와 함께 --execute 옵션으로 mysql 클라이언트 실행
        • 3.2.2.4 --batch 모드로 --skip-column-names와 함께 --execute 옵션으로 mysql 클라이언트 실행
    • 3.3 데이터베이스 및 사용자 생성
      • 3.3.1 MariaDB의 사용자 계정 인식과 권한
        • 3.3.1.1 사용자의 식별
        • 3.3.1.2 권한
        • 3.3.1.3 권한의 부여
        • 3.3.1.4 권한 그룹
      • 3.3.2 MariaDB의 기본 사용자
      • 3.3.3 MariaDB의 기본 데이터베이스
      • 3.3.4 새로운 데이터베이스 생성
      • 3.3.5 사용자 생성
        • 3.3.5.1 사용자 생성 및 권한 부여
        • 3.3.5.2 관리자 계정 준비
    • 3.4 테이블 생성 및 변경
      • 3.4.1 테이블 생성
      • 3.4.2 테이블 변경(온라인 및 오프라인)
        • 3.4.2.1 오프라인 스키마 변경
        • 3.4.2.2 MariaDB의 온라인 스키마 변경
        • 3.4.2.3 MySQL의 온라인 스키마 변경
        • 3.4.2.4 pt-online-schema-change
        • 3.4.2.5 온라인 스키마 변경을 사용해도 될까?
      • 3.4.3 테이블 삭제
    • 3.5 데이터 조작
      • 3.5.1 INSERT
      • 3.5.2 SELECT
      • 3.5.3 UPDATE
      • 3.5.4 REPLACE
      • 3.5.5 DELETE
  •  
  • ▣ 04장: 실행 계획 분석
    • 4.1 개요
      • 4.1.1 쿼리 실행 절차
      • 4.1.2 옵티마이저의 종류
      • 4.1.3 통계 정보
        • 4.1.3.1 MySQL 5.6의 통계 정보
        • 4.1.3.2 MariaDB 10.0의 통계 정보
      • 4.1.4 히스토그램 통계 정보
        • 4.1.4.1 히스토그램이란?
        • 4.1.4.2 MariaDB에서 히스토그램 사용
      • 4.1.5 조인 옵티마이저 옵션
    • 4.2 예제 데이터 준비
      • 4.2.1 예제 데이터 적재
      • 4.2.2 통계 정보 수집
    • 4.3 실행 계획 분석
      • 4.3.1 id 칼럼
      • 4.3.2 select_type 칼럼
        • 4.3.2.1 SIMPLE
        • 4.3.2.2 PRIMARY
        • 4.3.2.3 UNION
        • 4.3.2.4 DEPENDENT UNION
        • 4.3.2.5 UNION RESULT
        • 4.3.2.6 SUBQUERY
        • 4.3.2.7 DEPENDENT SUBQUERY
        • 4.3.2.8 DERIVED
        • 4.3.2.9 UNCACHEABLE SUBQUERY
        • 4.3.2.10 UNCACHEABLE UNION
        • 4.3.2.11 MATERIALIZED
        • 4.3.2.12 INSERT
      • 4.3.3 table 칼럼
      • 4.3.4 type 칼럼
        • 4.3.4.1 system
        • 4.3.4.2 const
        • 4.3.4.3 eq_ref
        • 4.3.4.4 ref
        • 4.3.4.5 fulltext
        • 4.3.4.6 ref_or_null
        • 4.3.4.7 unique_subquery
        • 4.3.4.8 index_subquery
        • 4.3.4.9 range
        • 4.3.4.10 index_merge
        • 4.3.4.11 index
        • 4.3.4.12 ALL
      • 4.3.5 possible_keys 칼럼
      • 4.3.6 key 칼럼
      • 4.3.7 key_len 칼럼
      • 4.3.8 ref 칼럼
      • 4.3.9 rows 칼럼
      • 4.3.10 Extra 칼럼
        • 4.3.10.1 const row not found
        • 4.3.10.2 Distinct
        • 4.3.10.3 Full scan on NULL key
        • 4.3.10.4 Impossible HAVING
        • 4.3.10.6 Impossible WHERE noticed after reading const tables
        • 4.3.10.7 No matching min/max row
        • 4.3.10.8 no matching row in const table
        • 4.3.10.9 No tables used
        • 4.3.10.10 Not exists
        • 4.3.10.11 Range checked for each record(index map: N)
        • 4.3.10.12 Scanned N databases
        • 4.3.10.13 Select tables optimized away
        • 4.3.10.14 Skip_open_table, Open_frm_only, Open_trigger_only, Open_full_table
        • 4.3.10.15 unique row not found
        • 4.3.10.16 Using filesort
        • 4.3.10.17 Using index(커버링 인덱스)
        • 4.3.10.18 Using index for group-by
        • 4.3.10.19 Using join buffer(Block Nested Loop), Using join buffer(Batched Key Access)
        • 4.3.10.20 Using sort_union, Using union, Using intersect, Using sort_intersection
        • 4.3.10.21 Using temporary
        • 4.3.10.22 Using where
        • 4.3.10.23 Using where with pushed condition
        • 4.3.10.24 Deleting all rows
        • 4.3.10.25 FirstMatch(tbl_name)
        • 4.3.10.26 LooseScan(m n)
        • 4.3.10.27 Materialize, Scan
        • 4.3.10.28 Start materialize, End materialize, Scan
        • 4.3.10.29 Start temporary, End temporary
        • 4.3.10.30 Using index condition
        • 4.3.10.31 Rowid-ordered scan, Key-ordered scan
        • 4.3.10.32 No matching rows after partition pruning
      • 4.3.11 EXPLAIN EXTENDED(Filtered 칼럼)
      • 4.3.12 EXPLAIN EXTENDED(추가 옵티마이저 정보)
      • 4.3.13 EXPLAIN PARTITIONS(Partitions 칼럼)
    • 4.4 옵티마이저 힌트
      • 4.4.1 힌트의 사용법
      • 4.4.2 STRAIGHT_JOIN
      • 4.4.3 USE INDEX / FORCE INDEX / IGNORE INDEX
      • 4.4.4 SQL_CACHE / SQL_NO_CACHE
      • 4.4.5 SQL_CALC_FOUND_ROWS
      • 4.4.6 기타 힌트
    • 4.5 실행 계획 분석 시 주의사항
      • 4.5.1 Select_type 칼럼의 주의 대상
      • 4.5.2 Type 칼럼의 주의 대상
      • 4.5.3 Key 칼럼의 주의 대상
      • 4.5.4 Rows 칼럼의 주의 대상
      • 4.5.5 Extra 칼럼의 주의 대상
        • 4.5.5.1 쿼리가 요건을 제대로 반영하고 있는지 확인해야 하는 경우
        • 4.5.5.2 쿼리의 실행 계획이 좋지 않은 경우
        • 4.5.5.3 쿼리의 실행 계획이 좋은 경우
  •  
  • ▣ 05장: 최적화
    • 5.1 풀 테이블 스캔
    • 5.2 ORDER BY 처리(Using filesort)
      • 5.2.1 소트 버퍼(Sort buffer)
      • 5.2.2 정렬 알고리즘
      • 5.2.3 정렬의 처리 방식
        • 5.2.3.1 인덱스를 사용한 정렬
        • 5.2.3.2 드라이빙 테이블만 정렬
        • 5.2.3.3 임시 테이블을 이용한 정렬
        • 5.2.3.4 정렬 방식의 성능 비교
      • 5.2.4 ORDER BY....LIMIT n 최적화
      • 5.2.5 정렬 관련 상태 변수
    • 5.3 GROUP BY 처리
      • 5.3.1 인덱스 스캔을 이용하는 GROUP BY(타이트 인덱스 스캔)
      • 5.3.2 루스(loose) 인덱스 스캔을 이용하는 GROUP BY
      • 5.3.3 임시 테이블을 사용하는 GROUP BY
    • 5.4 DISTINCT 처리
      • 5.4.1 SELECT DISTINCT
      • 5.4.2 집함 함수와 함께 사용된 DISTINCT
    • 5.5 임시 테이블(Using temporary)
      • 5.5.1 임시 테이블이 필요한 쿼리
      • 5.5.2 임시 테이블이 디스크에 생성되는 경우(Aria 스토리지 엔진을 사용)
      • 5.5.3 임시 테이블 관련 상태 변수
      • 5.5.4 인덱스를 가지는 내부 임시 테이블
      • 5.5.5 내부 임시 테이블(Internal Temporary Table)의 주의사항
    • 5.6 인덱스 컨디션 푸시다운(Index Condition Pushdown, ICP)
    • 5.7 멀티 레인지 리드(Multi Range Read)
      • 5.7.1 RowId 기준 정렬(Rowid-ordered scan)
      • 5.7.2 Key 기준 정렬(Key-ordered scan)
      • 5.7.3 Key와 RowId 모두 정렬(Key-ordered, Rowid-ordered scan)
      • 5.7.4 멀티 레인지 리드 최적화와 정렬
      • 5.7.5 멀티 레인지 리드 최적화 주의 사항
    • 5.8 인덱스 머지(Index merge)
      • 5.8.1 Using union
      • 5.8.2 Using sort_union
      • 5.8.3 Using intersect
      • 5.8.4 Using sort_intersect
    • 5.9 테이블 조인
      • 5.9.1 조인의 종류
        • 5.9.1.1 JOIN (INNER JOIN)
        • 5.9.1.2 OUTER JOIN
        • 5.9.1.3 카테시안 조인
        • 5.9.1.4 NATURAL JOIN
      • 5.9.2 조인 알고리즘
        • 5.9.2.1 조인 캐시 레벨(join_cache_level)
        • 5.9.2.2 조인 버퍼 설정
        • 5.9.2.3 단순 네스티드 루프(Simple Nested Loop, NL)
        • 5.9.2.4 블록 네스티드 루프(Block Nested Loop, BNL)
        • 5.9.2.5 블록 네스티드 루프 해시(Block Nested Loop Hash, BNLH)
        • 5.9.2.6 블록 인덱스 조인(Block Index Join, Batched Key Access, BKA)
        • 5.9.2.7 블록 인덱스 해시 조인(Block Index Hash Join, Batched Key Access Hash)
      • 5.9.3 조인의 주의사항
        • 5.9.3.1 조인 실행 결과의 정렬 순서
        • 5.9.3.2 INNER JOIN과 OUTER JOIN의 선택
    • 5.10 서브 쿼리
      • 5.10.1 세미 조인 서브쿼리 최적화
        • 5.10.1.1 Table pullout 최적화
        • 5.10.1.2 FirstMatch 최적화
        • 5.10.1.3 Semi-join Materialization 최적화
        • 5.10.1.4 LooseScan 최적화
        • 5.10.1.5 Duplicate Weedout 최적화
      • 5.10.2 세미 조인이 아닌 서브쿼리 최적화
        • 5.10.2.1 Materialization
        • 5.10.2.2 IN-to-EXISTS
      • 5.10.3 서브 쿼리 캐시
  •  
  • ▣ 06장: 스토리지 엔진
    • 6.1 Aria 스토리지 엔진
      • 6.1.1 트랜잭션
      • 6.1.2 페이지 캐시
      • 6.1.3 시스템 설정 변수
    • 6.2 XtraDB 스토리지 엔진
      • 6.2.1 InnoDB와 XtraDB 스토리지 엔진 교체
    • 6.3 InnoDB 스토리지 엔진
      • 6.3.1 MySQL 5.6 InnoDB
        • 6.3.1.1 영구적인 통계 정보
        • 6.3.1.2 데이터 읽기 최적화
        • 6.3.1.3 커널 뮤텍스(Kernel mutex)
        • 6.3.1.4 멀티 스레드 기반의 언두 퍼지(Multi threaded purge)
        • 6.3.1.5 독립된 플러시 스레드
        • 6.3.1.6 가변 페이지 사이즈
        • 6.3.1.7 테이블 스페이스 복사(Transportable tablespace)
        • 6.3.1.8 독립된 언두 스페이스
        • 6.3.1.9 읽기 전용 트랜잭션(Read-only transaction) 최적화
        • 6.3.1.10 버퍼 풀 덤프 & 로드
        • 6.3.1.11 리두 로그 사이즈
        • 6.3.1.12 리두 로그 크기 변경
        • 6.3.1.13 데드락 이력
      • 6.3.2 더티 페이지 플러시
        • 6.3.2.1 플러시 리스트 플러시
        • 6.3.2.2 LRU 리스트 플러시
        • 6.3.2.3 InnoDB와 XtraDB의 더티 플러시
        • 6.3.2.4 MySQL 5.5 InnoDB의 더티 플러시
        • 6.3.2.5 MariaDB 5.5 XtraDB의 더티 플러시
        • 6.3.2.6 MySQL 5.6 InnoDB의 더티 플러시
        • 6.3.2.7 MariaDB 10.0의 XtraDB
      • 6.3.3 버퍼 풀 성능 개선
        • 6.3.3.1 NUMA
        • 6.3.3.2 버퍼 풀 메모리 초기 할당
        • 6.3.3.3 InnoDB 잠금 세분화
        • 6.3.3.4 I/O 기반의 워크로드 성능 향상
        • 6.3.3.5 어댑티브 해시 파티션
      • 6.3.4 원자 단위의 쓰기(FusionIO SSD를 위한 Atomic write)
      • 6.3.5 확장된 InnoDB 엔진 상태 출력
        • 6.3.5.1 백그라운드 스레드 관련 상태 변수
        • 6.3.5.2 세마포어 관련 상태 변수
        • 6.3.5.3 인서트 버퍼와 어댑티브 해시 인덱스 관련 상태 변수
        • 6.3.5.4 로그 관련 상태 변수
        • 6.3.5.5 버퍼 풀 관련 상태 변수
        • 6.3.5.6 트랜잭션 관련 상태 변수
      • 6.3.6 XtraDB 리두 로그 아카이빙
      • 6.3.7 변경된 페이지 트랙킹
    • 6.4 전문 검색 엔진
      • 6.4.1 전문 검색 인덱스 추가
      • 6.4.2 전문 검색 인덱스를 위한 테이블 스페이스
      • 6.4.3 전문 검색 인덱스 관련 INFORMATION_SCHEMA 정보
        • 6.4.3.1 InnoDB의 모든 전문 검색 인덱스에 적용되는 내용
        • 6.4.3.2 전문 검색 인덱스를 가진 테이블 단위로 적용되는 내용
      • 6.4.4 전문 검색 인덱스 사용
      • 6.4.5 주의 사항
    • 6.5 Memcached 플러그인
      • 6.5.1 아키텍처
      • 6.5.2 설치 및 테스트
      • 6.5.3 캐시 정책
      • 6.5.4 사용자 테이블 등록
      • 6.5.5 관련 시스템 변수
    • 6.6 카산드라 스토리지 엔진
      • 6.6.1 카산드라
      • 6.6.2 카산드라 스토리지 엔진
    • 6.7 CONNECT 스토리지 엔진
      • 6.7.1 CONNECT 스토리지 엔진 설치
      • 6.7.2 오라클 RDBMS 테이블 연결
      • 6.7.3 my.cnf 설정 파일 연결
      • 6.7.4 운영체제의 디렉터리 연결
    • 6.8 시퀀스 스토리지 엔진
      • 6.8.1 시퀀스 스토리지 엔진 기본 사용법
      • 6.8.2 누락된 번호 찾기
      • 6.8.3 순차적으로 조합된 번호 쌍 생성
      • 6.8.4 배수 또는 공배수 찾기
      • 6.8.5 순차적인 알파벳 생성
      • 6.8.6 순차적인 날짜 생성
      • 6.8.7 데이터 복제 가공
    • 6.9 Mroonga 전문 검색 스토리지 엔진
      • 6.9.1 인덱스 알고리즘
        • 6.9.1.1 구분자(Stopword) 방식
        • 6.9.1.2 n-Gram 방식
        • 6.9.1.3 구분자와 n-Gram의 차이
      • 6.9.2 Mroonga 전문 검색 엔진 설치
      • 6.9.3 Mroonga 전문 검색 엔진 사용
  •  
  • ▣ 07장: 기타 기능
    • 7.1 성능 향상
      • 7.1.1 스레드 풀(Thread Pool)
        • 7.1.1.1 MySQL 서버의 전통적인 연결 및 처리 방식
        • 7.1.1.2 MariaDB의 스레드 풀
        • 7.1.1.3 MariaDB 스레드 풀의 사용과 튜닝
        • 7.1.1.4 주의 사항
    • 7.2 관리 및 진단
      • 7.2.1 SHOW EXPLAIN FOR <THREAD-ID>
      • 7.2.2 슬로우 쿼리 로그에 실행 계획 출력
      • 7.2.3 구조화된 실행 계획 출력
      • 7.2.4 스레드 단위의 메모리 사용량
      • 7.2.5 SHUTDOWN 명령
      • 7.2.6 사용자나 쿼리 실행 강제 종료(KILL)
      • 7.2.7 GET DIAGNOSTICS
    • 7.3 개발 생산성
      • 7.3.1 LIMIT ROWS EXAMINED
      • 7.3.2 DELETE...RETURNING
      • 7.3.3 마이크로 초 단위의 시간 저장
      • 7.3.4 DATETIME 타입의 기본값 설정
      • 7.3.5 정규 표현식 기능 확장
      • 7.3.6 가상(Virtual) 칼럼
      • 7.3.7 동적(Dynamic) 칼럼
    • 7.4 파티션
      • 7.4.1 명시적 파티션 지정
        • 7.4.1.1 명시적 파티션 지정 사용법
        • 7.4.1.2 명시적 파티션 지정 기능의 용도
      • 7.4.2 파티션 테이블 스페이스 교체(Exchange)
    • 7.5 백업
      • 7.5.1 바이너리 로그 원격 백업
      • 7.5.2 XtraBackup 소개
        • 7.5.2.1 XtraBackup 패키지 구성
        • 7.5.2.2 XtraBackup의 원리
        • 7.5.2.3 XtraBackup의 기본 사용법
      • 7.5.3 XtraBackup의 기능
        • 7.5.3.1 스트리밍 백업
        • 7.5.3.2 압축
        • 7.5.3.3 암호화
        • 7.5.3.4 슬레이브 백업
        • 7.5.3.5 병렬(Parallel) 백업
        • 7.5.3.6 백업 속도 조절
        • 7.5.3.7 개별 테이블 복구
        • 7.5.3.8 FLUSH TABLES WITH READ LOCK 개선
      • 7.5.4 XtraBackup의 고급 사용법
        • 7.5.4.1 PIT(Point In Time) 복구
        • 7.5.4.2 증분(Incremental) 백업
        • 7.5.4.3 부분(Partial) 백업
        • 7.5.4.4 컴팩트(Compact) 백업
        • 7.5.4.5 스트리밍(Streaming) 백업
        • 7.5.4.6 암호화(Encrypt) 백업
  •  
  • ▣ 08장: 레플리케이션
    • 8.1 글로벌 트랜잭션 아이디(Global Transaction ID)
      • 8.1.1 글로벌 트랜잭션 아이디(GTID)란?
      • 8.1.2 글로벌 트랜잭션 아이디의 필요성
      • 8.1.3 MariaDB 10.0 글로벌 트랜잭션 아이디
        • 8.1.3.1 GTID를 이용한 복제 구축
        • 8.1.3.2 GTID를 사용한 복제 관리
        • 8.1.3.3 GTID를 이용한 슬레이브에서 트랜잭션 건너뛰기
      • 8.1.4 MySQL 5.6 글로벌 트랜잭션 아이디
        • 8.1.4.1 GTID를 이용한 복제 구축
        • 8.1.4.2 GTID 관련 함수
        • 8.1.4.3 GTID 이벤트 건너뛰기
    • 8.2 멀티 소스 복제(Multi-source replication)
      • 8.2.1 멀티 소스 복제 관련 명령
      • 8.2.2 멀티 소스 복제 구축
      • 8.2.3 멀티 소스 복제와 글로벌 트랜잭션
    • 8.3 멀티 스레드 복제
      • 8.3.1 MySQL 5.6의 멀티 스레드 복제
      • 8.3.2 MariaDB 10.0의 멀티 스레드 복제
    • 8.4 크래시 세이프(Crash safe) 슬레이브
      • 8.4.1 MariaDB 10.0의 크래시 세이프 복제
      • 8.4.2 MySQL 5.6의 크래시 세이프 복제
    • 8.5 ROW 기반의 복제 기능 개선
      • 8.5.1 ROW 포맷의 용량 최적화
      • 8.5.2 ROW 포맷 바이너리 로그를 위한 정보성 로그 이벤트
        • 8.5.2.1 MariaDB 주석 이벤트
        • 8.5.2.2 MySQL 5.6의 정보성 로그 이벤트
    • 8.6 지연된 복제
    • 8.7 MariaDB와 MySQL 서버간의 복제
    • 8.8 그 외의 기타 기능 개선
      • 8.8.1 바이너리 로그 체크섬
      • 8.8.2 바이너리 로그 API
      • 8.8.3 바이너리 로그 그룹 커밋
  • 30쪽, 밑에서 두 번째 줄

    조정되진 않고, MaiaDB 옵션으로만 조정된다.

    ==>

    조정되진 않고, MariaDB 옵션으로만 조정된다.

  • 59쪽, 6번째 문단

    실행된 서버나 mysql_upgrade를 가진

    ==>

    실행된 서버나 mysql_upgrade_info를 가진

  • 74쪽, 첫 번째 문단 마지막 줄

    MariaDB이 마스터 MySQL에 접속하지

    ==>

    MariaDB가 마스터 MariaDB에 접속하지

  • 94쪽, 숫자 목록의 첫 번째 항목

    INPLACE 스티마 변경이

    ==>

    INPLACE 스키마 변경이

  • 122쪽, 밑에서 9번째 줄

    엔진 레벨에서 관리되었는다.

    ==>

    엔진 레벨에서 관리되었다.

  • 129쪽, 첫 번째 줄

    MariaDB 10.0에서 히스트그램을 관리하는

    ==>

    MariaDB 10.0에서 히스토그램을 관리하는

  • 132쪽, 세 번째 문단

    column_stats 테이블의 조회해 보면

    ==>

    column_stats 테이블을 조회해 보면

  • 137쪽, 마지막 문단

    컬럼 2개와 ... (중략) ... fd1 컬럼과 fd2 컬럼

    ==>

    칼럼 2개와 ... (중략) ... fd1 칼럼과 fd2 칼럼

  • 141쪽, 밑에서 8번째 줄

    특정 컨넥션 단위로

    ==>

    특정 커넥션 단위로

  • 148쪽, 세 번째 줄

    그리고 UPDATE나 INSERT, DELETE 문장에 대해서는 실행 계획을 확인할 방법이 없다. UPDATE나 INSERT, DELETE 문장의 실행 계획을 확인하려면 WHERE 조건절만 같은 SELECT 문장을 만들어서 대략적으로 계획을 확인해 볼 수 있다.

    ==>

    (삭제)

  • 159쪽, 두 번째 문단

    사용된 MATERIAILZED 키워드는

    ==>

    사용된 MATERIALIZED 키워드는

  • 159쪽, 4.3.2.12 INSERT 제목 바로 아래

    MariaDB 10.0부터는

    ==>

    MariaDB 10.0.5부터는

  • 163쪽, 참고란

    MariaDB 다른

    ==>

    MariaDB 다른

  • 183쪽, 두 번째 문단

    스캔이 아니라 ranage로 인덱스 레인지

    ==>

    스캔이 아니라 range로 인덱스 레인지

  • 197쪽, 그림 4-10은 아래 그림으로 대체

    그림 4-10

  • 199쪽, 밑에서 5번째 줄

    “Using filesort”는 중요한 부분이므로 6.3.2절 “ORDER BY 처리(USING FILESORT)”와 7.4.8절 “ORDER BY”에서 다시 자세히 다루겠다.

    ==>

    “Using filesort”는 중요한 부분이므로 5.2절 “ORDER BY 처리(USING FILESORT)”에서 다시 자세히 다루겠다.

  • 206쪽, 밑에서 3번째 줄

    인덱스를 조사해고, 인덱스가

    ==>

    인덱스를 조사해서 인덱스가

  • 211쪽, 3번째 줄

    5.3.7.1절 “비교 조건의 종류와 효율성”에서 작업 범위 제한 조건과 체크 조건의 구분을 언급한 바 있는데, 실제로 작업 범위 제한 조건은 각 스토리지 엔진 레벨에서 처리되지만 체크 조건은 MariaDB 엔진 레이어에서 처리된다.

    ==>

    실제로 작업 범위 제한 조건은 각 스토리지 엔진 레벨에서 처리되지만 체크 조건은 MariaDB 엔진 레이어에서 처리된다.

  • 214쪽, 6번째 줄

    테이블인 경우 EXtra 필드에

    ==>

    테이블인 경우 Extra 필드에

  • 216쪽, 3번째 줄

    최적화(IN-TO-EXIST 변환)되어서

    ==>

    최적화(IN-to-EXISTS 변환)되어서

  • 236쪽, 밑에서 8번째 줄

    비교하거나 성능을 분석하는 자주 사용된다.

    ==>

    비교하거나 성능을 분석하는 것이다.

  • 245쪽, 첫 번째 줄

    많은 사람은 MariaDB이 풀 테이블 스캔을

    ==>

    많은 사람들이 MariaDB가 풀 테이블 스캔을

  • 246쪽, 5.2.1 소트 버퍼(Sort buffer) 바로 아래

    MariaDB

    ==>

    MariaDB

  • 246쪽, 밑에서 2번째 줄

    테이블을 위한 소드 버퍼도

    ==>

    테이블을 위한 소트 버퍼도

  • 248쪽, 본문 밑에서 3번째 줄

    그런데 OOK-Killer는

    ==>

    그런데 OOM-Killer는

  • 265쪽, 5.3.1 항목 아래 2번째 줄

    생성되어 있아면 그 인덱스를

    ==>

    생성되어 있다면 그 인덱스를

  • 274쪽, 밑에서 3번째 줄

    임시 테이블이 1개(3-2=1)가

    ==>

    임시 테이블이 1개(1-0=1)가

  • 307쪽, 하단 SQL 문

    SELECT * FROM departments WHERE dept_no='d001';
    SELECT * FROM employees WHERE emp_no=1000001;
    SELECT d.*, e.*
    
    FROM departments d, employees e
    WHERE dept_no = 'd001' AND emp_no=1000001;
    

    ==>

    SELECT * FROM departments WHERE dept_no='d001';
    SELECT * FROM employees WHERE emp_no=1000001;
    
    SELECT d.*, e.*
    FROM departments d, employees e
    WHERE dept_no = 'd001' AND emp_no=1000001;
    
  • 315쪽, 3번째 문단 2번째 줄

    from_date>'2000-01-01'인

    ==>

    from_date>'1995-01-01'인

  • 315쪽, 가운데 SQL 문

    WHERE de.from_date>'2000-01-01' AND e.emp_no<109004;

    ==>

    WHERE de.from_date>'1995-01-01' AND e.emp_no<109004;

  • 316쪽, 첫 번째 줄

    조건(from_date>'2000-01-01')을 만족하는

    ==>

    조건(from_date>'1995-01-01')을 만족하는

  • 317쪽, 3번째 줄

    이용해 (from_date>’2000-01-01’) 조건을

    ==>

    이용해 (from_date>’1995-01-01’) 조건을

  • 319쪽, 밑에서 5번째 줄

    조인 버퍼 사용할 수

    ==>

    조인 버퍼를 사용할 수

  • 320쪽, 본문 두 번째 문단

    departments 테이블이 먼저 읽고

    ==>

    departments 테이블을 먼저 읽고

  • 323쪽, 8번째 줄

    배치 키 액세스가 수행되어야 때도 있는데,

    ==>

    배치 키 액세스가 수행되어야 할 때도 있는데,

  • 325쪽, 8번째 줄

    명시됐다고 해서 옵타마이저는 항상

    ==>

    명시됐다고 해서 옵타마이저가 항상

  • 336쪽, 3번째 문단 2번째 줄

    드라이빙 테이블로 선택된 것을

    ==>

    드라이빙 테이블로 선택되었는지

  • 341쪽, 가운데 숫자 목록 1번째 항목

    150000보다 큰 사원 검색하여

    ==>

    150000보다 큰 사원을 검색하여

  • 342쪽, 밑에서 2번째 줄

    “End temporar” 문구가 표시된다.

    ==>

    “End temporary” 문구가 표시된다.

  • 363쪽, 두 번째 문단 첫 번째 줄

    어렵지 않게 테이스 스페이스

    ==>

    어렵지 않게 테이블 스페이스

  • 365쪽, 첫 번째 줄

    익스포트해서 임포트하는 할

    ==>

    익스포트해서 임포트할

  • 369쪽, 본문 3번째 문단 2번째 줄

    식별하는 값다.

    ==>

    식별하는 값이다.

  • 379쪽, 밑에서 2번째 줄

    <그림 6-2>의 상태에서

    ==>

    <그림 6-3>의 상태에서

  • 420쪽, 밑에서 9번째 줄

    로코드가 추가되거나

    ==>

    레코드가 추가되거나

  • 429쪽, 목록 3번째 항목

    55개 호환성 테스트 통화

    ==>

    55개 호환성 테스트 통과

  • 431쪽, 밑에서 6번째 줄

    플러그인이 사용한 메타

    ==>

    플러그인이 사용할 메타

  • 441쪽, 그림 6-23

    컬럼 패밀리 ==> 칼럼 패밀리

  • 448쪽, 밑에서 첫 번째 줄

    확장자는 좀 틀리긴 하지만

    ==>

    확장자는 좀 다르긴 하지만

  • 449쪽, 5번째 줄

    srclen 옵션은

    ==>

    seclen 옵션은

  • 465쪽, 2번째 줄

    Mroonga 전문 검색 엔진에서 별도로 토크나이징7을 기준으로 잘라서 토큰을 생성하는 작업을 토크나이징이라고 표현한다. 토큰은 특수 문자나 공백 등을 제거하고 검색에서 의미가 있을 만한 단어들을 지칭한다. 예를 들어서 “전문 검색이 뭔가요?”라는 문자열이 있다면 많은 사용자들이 공백이나 물음표와 같은 문장 기호에는 별로 관심이 없을 것이다. 그래서 “전문”과 “검색이” 그리고 “뭔가요”라는 단어(토큰)를 잘라 내어서 검색할 수 있도록 인덱싱하는 것이다.)을 수행하지 않기 때문에 저장된 내용이 그대로 변형없이 유지되며 검색 또한 전방 일치만 허용된다.

    ==>

    Mroonga 전문 검색 엔진에서 별도로 토크나이징7을 수행하지 않기 때문에 저장된 내용이 그대로 변형없이 유지되며 검색 또한 전방 일치만 허용된다.

  • 465쪽, 하단 각주

    입력된 문자열을 지정된 구분자(구분자는 특수 문자 또는 공백이나 문장 기호 등이 될 수 있음)

    ==>

    입력된 문자열을 지정된 구분자(구분자는 특수 문자 또는 공백이나 문장 기호 등이 될 수 있음)을 기준으로 잘라서 토큰을 생성하는 작업을 토크나이징이라고 표현한다. 토큰은 특수 문자나 공백 등을 제거하고 검색에서 의미가 있을 만한 단어들을 지칭한다. 예를 들어서 “전문 검색이 뭔가요?”라는 문자열이 있다면 많은 사용자들이 공백이나 물음표와 같은 문장 기호에는 별로 관심이 없을 것이다. 그래서 “전문”과 “검색이” 그리고 “뭔가요”라는 단어(토큰)를 잘라 내어서 검색할 수 있도록 인덱싱하는 것이다.

  • 472쪽, 그림 7-3

    컨넥션 ==> 커넥션

    쓰레드 ==> 스레드

  • 472쪽, 밑에서 8번째 줄

    아주 빨리 실행되되는 CPU

    ==>

    아주 빨리 실행되는 CPU

  • 508쪽, 7번째 줄

    네 번째와 다섯 번째 예제 쿼리의 UPDATE 문장에서도

    ==>

    네 번째 쿼리의 UPDATE 문장에서도

  • 522쪽, 2번째 줄

    때에는 innobackup 스크립트를

    ==>

    때에는 innobackupex 스크립트를

  • 525쪽, 2번째 줄

    log of lsn (742879760) to (742879760) was copied.” 메시지는 이번 백업이 실행되면서 시작 LSN은 742879760이며 LSN 742879760 시점까지

    ==>

    log of lsn (742923074) to (742923074) was copied.” 메시지는 이번 백업이 실행되면서 시작 LSN은 742923074이며 LSN 742923074 시점까지

  • 531쪽, 첫 번째 줄

    shell> innobackup

    ==>

    shell> innobackupex

  • 535쪽, 두 번째 문단 5번째 줄

    이렇게 백업을 스트리밍으로 백업을 전송하면

    ==>

    이렇게 스트리밍으로 백업을 전송하면

  • 542쪽, 가운데 코드 영역

    장애 발생 시점 : 2013년 1월 4일 10시 정각

    ==>

    장애 발생 시점 : 2013년 4월 1일 10시 정각

  • 542쪽, 가운데 코드 영역

    mysql-bin.000002 : 마지막 변경 일시(2013년 1월 4일 02시 20분)
    mysql-bin.000003 : 마지막 변경 일시(2013년 1월 4일 04시 20분)
    mysql-bin.000004 : 마지막 변경 일시(2013년 1월 4일 07시 30분)
    mysql-bin.000005 : 마지막 변경 일시(2013년 1월 4일 10시 정각)
    

    ==>

    mysql-bin.000002 : 마지막 변경 일시(2013년 4월 1일 02시 20분)
    mysql-bin.000003 : 마지막 변경 일시(2013년 4월 1일 04시 20분)
    mysql-bin.000004 : 마지막 변경 일시(2013년 4월 1일 07시 30분)
    mysql-bin.000005 : 마지막 변경 일시(2013년 4월 1일 10시 정각)
    
  • 551쪽, 본문 3번째 문단 마지막 줄

    스크립트를 --export 옵션과 함께

    ==>

    스크립트를 --compact 옵션과 함께

  • 552쪽, 2번째 줄

    참조해서 인덱스 새로 빌드할지를

    ==>

    참조해서 인덱스를 새로 빌드할지를

  • 580쪽, 숫자 목록의 4번 항목

    시스템 변수를 4번에서 확인된

    ==>

    시스템 변수를 3번에서 확인된

  • 585쪽, 본문 밑에서 2번째 줄

    GTID 셋은 “1-6”(“1번부터 6번까지)라는

    ==>

    GTID 셋은 “1-6”(“1번부터 6번까지)라는

  • 587쪽, 주의란

    1번부터 6번까지이다.

    ==>

    1번부터 7번까지다.

  • 604쪽, 본문 2번째 줄

    먼저 컬럼 3개를

    ==>

    먼저 칼럼 3개를

  • 617쪽, 밑에서 4번째 줄

    릴레이 로드 파일로

    ==>

    릴레이 로그 파일로

  • 618쪽, 가운데 표는 아래 그림으로 대체

    618쪽 그림

관련 글


엮인 글

엮인 글 주소: http://wikibook.co.kr/real-mariadb/trackback/