데이터베이스를 지탱하는 기술1(1장~6장)

데이터베이스가 없으면 무엇이 곤란한가

대량의 데이터 중에서 필요한 것을 빨리 반환할 수 없다.

대량의 데이터를 메모리 내에서만으로는 취급할 수 없다.

장애가 발생했을 때 빠른 복구가 어렵다.

병렬성 제어가 어렵다.

데이터 무결성을 보장하는 것은 어렵다.

 

인덱스로 고속 액세스 실현하기

B+Tree 인덱스 O(log(m)N)

B+Tree 인덱스는 Tree 구조로 된 인덱스다. 정상이 root 블록, 최하층이 leaf 블록이며, 그 사이에 branch 블록이 있다.

루트 블록과 브랜치 블록은 검색의 키인 사용자 ID에 대해 해당 블록이 어디에 있는지에 대한 정보를 가지고 있다. 그리고 최하층의 리프 블록은 실제 저장 위치의 정보를 가지고 있다. 루트 -> 브랜치 -> 리프 순으로 도달하여 데이터 얻음

 

테이블 설계와 릴레이션

정규형

제1정규형 : 테이블 구성에서 중복 또는 반복, 복합값 등을 포함하지 않는 경우.

제2정규형 : 기본키가 여러 열로 구성되어 있지 않는 경우.

제3정규형 : 테이블의 모든 열은 기본 키 값에 따라 다 하나로 결정되는 경우.

 

INSERT, SELECT, UPDATE, DELETE

MYSQL은 INSERT 여러개 가능

존재하지 않으면 INSERT 존재하면 UPDATE 가능(REPLACE 문장과 INSERT ... ON DUPLICATE KEY UPDATE)

 

SQL 문의 특징과 이를 잘 다루는 법

SQL문의 실행 효율 의식하기

적절한 인덱스가 사용되고 있는지 확인

  EXPLAIN 사용 

  쿼리 분석 도구 사용

관리계 명령

 

가용성과 데이터의 복제

데이터베이스는 어떤때에 크래쉬 되는가?

소프트웨어 장애

OS 장애

하드웨어 장애

조작 실수

 

장애가 발생해도 서비스를 제공할 수있도록 설계

 

데이터 손실 방지하는 방법

디스크 이중화

RAID : 데이터베이스의 데이터는 HDD에 저장. 동일한 데이터를 두 개 이상의 HDD에 분산시키는 기술

서버 이중화에 의한 다운 타임 줄이기

 

복제

단방향 복제

단방향/비동기

마스터에서 갱신한 결과가 슬레이브에 비동기로 전파하는 유형의 복제(MYSQL 표준 복제 기능)

마스터에서 실행한 갱신계의 SQL문이 바이너리 로그라는 전용 로그 파일로 기록 => 로그 파일의 내용이 슬레이브로 전송되어 저장 => 슬레이브는 저장된 로그 파일을 순차적으로 실행 => 마스터와 슬레이브 상태가 일치

슬레이브에는 바이너리 로그 수신과 바이너리 로그 실행 2단계

전자는 I/O 스레드, 후자는 SQL 스레드가 실행

단방향 준동기화

새로운 버전의 MYSQL에서는 슬레이브가 바이너리 로그를 수신하는 부분을 동기화 방식으로 할 수 있다.(준동기식 복제)

=> 업데이트가 슬레이브에 도착하는 것이 보장, 마스터 손실에 의한 데이터 손실의 위험을 억제

=> BUT 응답 시간이 나빠진다. 데이터 손실의 위험과 응답시ㅣ간의 악화에 대해 균형을 취한 방식

단방향 동기

슬레이브에 대해 업데이트 결과의 반영까지 마친 상태에서 처음으로 클라이언트에 응답을 반환하는 방식(MYSQL X)

 

양방향 복제

양방향 복제는 기술적으로 어렵다. 특히 어려운 것이 업데이트의 충돌 => 분산형 배타 제어의 구조가 필요

(MYSQL CLUSTER)

 

장애로부터의 복구 방법

장애가 발생해 손실되거나 불일치를 일으킨 슬레이브는 나중에 새로운 것을 다른 서버에서 다시 만들어 전체 복구시키는 방법을 사용 => BUT 시간 너무 많이 걸려 => 앞으로는 장애 시점과 현시점과의 차이만을 복구하는 방법으로 변경

 

인위적 실수에 대한 해결

백업 => 시점복구(마지막 백업 이후의 업데이트 로그를 적용)

업데이트 로그의 어느 위치가 마지막 백업 시점인가를 파악

가장 쉬운 방법은 일시적으로 업데이트를 멈추고 백업을 하여 그 시점에서의 업데이트 로그의 위치를 특정하는 방법

BUT 백업중에 업데이트 불가 => 트랜잭션 이용

 

*Time Delayed Replication도 가능.

마스터에서 수행한 업데이트를 어느 시간이 지난 후에 슬레이브에 반영

잘못된 작업을 했다면 그 지연되고 있는 슬레이브를 마스터로 승격

단, 지연된 상태라 참조 쿼리를 돌리지 못해.

 

트랜잭션과 무결성, 무정지성

데이터베이스가 작업 중간에 에러가 발생하면 복구를 해야한다. ex) 돈을 송수신하는 경우

트랜잭션 : 데이터베이스가 일관성 있는 상태로 자동 복구해 주는 구조

커밋 : 마지막까지 처리를 마치고 결과를 확정시키는 것

롤백 : 커밋하지 않고 모든 작업을 원래대로 되돌리는 것

현대 프로그래밍 언어에서는 예외처리를 하면 알아서 롤백

 

트랜잭션 기능의 대표적인 두 번째 이점 : 무정지성의 향상

OS 등의 서버 장애가 발생하여 그로부터 데이터베이스를 재가동한 때에 장애 직전까지의 커밋 결과를 손실하지 않고 마치는 것이 가능

InnoDB에서는 트랜잭션을 커밋하면 그때마다 LSN(Log Sequence Number)이라는 시퀀스 번호가 증가하고, 그 번호의 갱신 대상의 블록의 정보를 REDO 로그 파일에 쓴다. 한편, 열 값과 인덱스를 갖는 데이터 파일에는 커밋을 할 때마다 기록을 하는 것이 아니라 캐시 영역에 보관해 두고 정기적으로 디스크에 기록하는 동작을 한다.

충돌복구 : REDO 로그의 내용을 데이터 파일에 적용시켜 나감으로써 데이터 파일과 REDO 로그의 LSN과 일치시키는 작업을 수행

시퀀셜 기록은 HDD에서 매우 빠르기 때문에 REDO 로그 파일로의 기록량이 증가하더라도 그 추가비용은 문제 X

단, SSD에 의한 고속화가 진행되어 가게되면 무시할 수 없다.

 

잠금 매커니즘에 의한 배타제어

잠금 매커니즘으로 다른 트랜잭션에서의 동일한 레코드에 대한 갱신을 방지

잠금의 범위 : 테이블(비효율) 또는 레코드

잠금 기간 : 트랜잭션의 종료(커밋 또는 롤백)까지

잠금 매커니즘에 대한 단점은 동일한 레코드에 대한 갱신이 동시에 한 개의 클라이언트밖에 할 수 없다는 점

MYSQL에서는 LOCK(UNLOCK)TABLES 이라는 전용의 SQL문이 있다. 일련의 처리를 시작하기 전에 LOCK TABLES를 하여 모든 것이 끝난 뒤에 UNLOCK TABLES을 하면 된다.

InnoDB처럼 트랜잭션을 지원하는 것은 이러한 수고가 불필요하고 데이터베이스가 전부 대신해 주기 때문에 간단하다.

 

복제 및 트랜잭션

원자성을 갖는 복제의 중요성

슬레이브는 마스터에서 보낸 업데이트성 쿼리 중에서 어디까지를 실행했는지가 중요 => 실행을 마친 바이너리 로그의 위치정보를 관리하는 InnoDB 테이블 제공