[RealMysql 8.0]04아키텍처 4.2.1 ~ 4.2.6

• 프라이머리 키에 의한 클러스터링
  • InnoDb의 모든 테이블은 기본적으로 프라이머리 키를 기준으로 클러스터링되어 저장된다.
  • 즉 프라이머리 키 값의 순서대로 디스크에 저장된다.
  • 모든 세컨더리 인덱스는 레코드의 주소 대신 프라이머리 키의 값을 논리적인 주소로 사용한다.(디스크 접근도 프라이머리 키로 접근한다.)
  • 프라이머리 키를 통한 범위 검색이 매우 빠르지만, 쓰기 성능은 저하된다.
  • 클러스터링?
    • 테이블을 여러 노드로 분산하는 기술, 이를 통해 데이터베이스의 성능과 확장성을 향상시킬 수 있음. 
    • 두 대 이상의 서버를 하나의 서버처럼 운영하는 기술
    • mysql 은 프라이머리 키를 기준으로 클러스터링하기 때문에 프라이머리 키 값에 대한 인덱싱을 통해 쿼리가 빠르게 수행됩니다.
  • InnoDb 스토리지 엔진과는 달리 MyISAM 스토리지 엔진에서는 클러스터링 키를 지원하지 않음.
• 외래 키 지원
  • InnoDb 스토리지 엔진 레벨에서 지원하는 기능이다. MyISAM 이나 MEMORY 테이블에서는 사용할 수 없다.
• MVCC(Multi Version Concurency Control)
  • Multi Version?
    •  하나의 레코드에 대해 여러 개의 버전이 동시에 관리된다는 의미.
  • 일반적으로 레코드 레벨의 트랜잭션을 지원하는 DBMS가 제공하는 기능
  • MVCC의 가장 큰 목적은 잠금을 사용하지 않는 일관된 읽기를 제공하는 데 있다
  • InnoDb는 undo log 를 이용해 이 기능을 구현한다.
    • 언두로그는 데이터를 변경하기전 백업해 두는 공간이라 생각하면 됨.
  • innoDB 버퍼 풀?
    • innoDB 스토리지 엔진에서 데이터와 인덱스를 캐시하는 메모리 영역
    • mysql 서버가 db를 사용하는동안 자주 참조하는 데이터를 메모리에 저장하여 디스크 I/O 를 최소화하여 성능 향상.
    • mvcc 에서의 버퍼 풀은 읽기용 버전을 저장, 이를 이용하여 트랜잭션마다 데이터 버전을 관리하여 성능을 향상시킴.
    • 변경된 데이터를 디스크에 저장하기전에 담아두는 공간.
  • https://www.youtube.com/watch?v=vQFGBZemJLQ
  • 아직 commit 이나 rollbacsk이 되지않은 상태에서 다른 사용자가 조회시 격리수준에 따라 다르다.
    • read_uncommited 일경우 => InnoDb 버퍼풀이 현재 가지고 있는 변경된 데이터를 읽어서 반환 함.(데이터가 커밋됐든 아니든 변경된 상태 데이터 반환)
    • read_commited 나 그 이상의 격리수준(repeatable_read, serializable) 일경우 => 아직 커밋되지 않았기에 변경되기 이전의 내용을 보관하고 있는 언두 영역의 데이터를 반환한다.
    • 즉 하나의 레코드에 대해 2개의 버전이 유지되고 격리수준에 따라 보여지는 데이터가 다르다.
  • commit 한다면 -> 데이터 저장
  • rollback 한다면 => 언두 로그의 데이터를 innodb 버퍼 풀로 다시 복구, 언두 영역의 데이터는 삭제 한다.
  • 커밋이 된다고 언두영역의 데이터는 바로 삭제가 되지않고, 이 언두 영역을 필요로 하는 트랜잭션이 더는 없을 대 비로소 삭제된다.
  • 앗 궁금하다 =>
    • mysql 에서 트랜잭셔 처리가 길어져 undo log 공간에 데이터가 무수히 많아진다면?
      • 기본적으로 아시다시피 out of memory 에러를 떨군다.
      • 대책으로는 innodb_buffer_pool_size 설정을 하여 언두 로그 공간을 증가시킬 수 있다.
      • 항상 "적절한"...이게 참 어려운거 같다.상황에 따라 매번 달라지는...
• 잠금 없는 일관된 읽기(Non-Locking Consistent Read)
  • InnoDb 스토리지 엔진으 MVCC 기술을 이용해 잠금을 걸지 않고 읽기 작업을 수행한다.
  • 잠금을 걸지 않기 떄문에 InnoDb에서 읽기 작업은 다른 트랜잭션이 가지고 있는 잠금을 기다리지 않고, 읽기 작업이 가능하다.
• 자동 데드락 감지
  • InnoDb 는 교착상태를 체크하기위해 잠금 대기 목록을 그래프 형태로 관리
  • 교착상태가 빠지면 트랜잭션의 언두 로그 양을 체크하여 부담이 덜 한 언두로그 양이 적은 쪽을 롤백한다.
  • 동시처리양이 매우많거나, 트랜잭션의 잠금 개수가 많아지면 cpu 저하를 불러 일으킬 수 있다. 이는 옵션을 이용해 off 할 수 있다. off설정 시 교착상태 발생시 무한정 대기할 수 있으므로 innodb_lock_wait_timeout 설정을 통해 해결할 수 있다.기본 값은 50초다.(50초 보다 훨씬 낮은 설정값으로 변경해서 사용할 것을 권장)
• 자동화된 장애 복구
  • mysql 은 서버가 시작될때 완료되지 못한 트랜잭션이나 디스크에 일부만 기록된 데이터 페이지 등에 대한 일련의 복구 작업이 자동으로 실행된다.
  • 서버가 시작되지 못하는 상황이 생긴다면(서버와 무관하게 하드웨어 이슈 등) 옵션을 통해 변경 후 mysql 을 재 시작해야한다.
  • 옵션 사용과 설명은 추후 필요시 살펴보자.