애플리케이션 개발에서는 '오류처리' 를 바드시 고려하지 않으면 안된다. 즉, 갱신하는 동안 오류가 발생했을 때 어떤 상황이 발생하며 거기에서 어떻게 복구할 수 있는지를 생각할 필요가 있다.

데이터베이스가 일관성 있는 상태로 자동 복구해 주면 그러한 편이 좋은 것은 당연하다. 이것을 실현해 주는 구조가 '트랜잭션' 이다.

어디선가 실패하면 어중간한 상태로 갱신이 확정되는 것이 아니라 전부 없었던 것으로 해준다. (ACID 특성 중에 Atomicity 원자성 에 해당하는 기능)

마지막까지 처리를 마치고 결과를 확정시키니느 것을 COMMIT, 커밋하지 않고 모든 작업을 원래대로 되돌리는 것을 ROLLBACK 이라고 한다.

무정지성 확보하기

OS 장애 등의 서버 장애가 발생하여 그로부터 데이터베이스를 재기동한 때에 '장애 직전까지의 커밋 결과를 손실하지 않고 마치는 것' 이 가능하다. Oracle이나 InnoDB 같은 트랜잭션 대응의 데이터베이스에서는 REDO 로그(데이터베이스에서 수행한 작업을 다시 실행하는 로그) 를 이용한 아키텍처로 무정지성을 보장하고 있다.

REDO 로그

InnoDB에서는 트랜잭션 커밋 시 LSN(Log Sequence Number)이라는 시퀀스 번호가 증가하고, 그 번호와 갱신 대상의 블록의 정보 (갱산할 곳의 블록 ID 및 갱산할 곳의 위치 및 값)을 REDO 로그 파일에 쓴다.

한편, 열 값과 인덱스를 갖는 데이터 파일에는 커밋을 할 때마다 기록을 하는 것이 아니라 캐시 영역에 보관해 두고 정기적으로 디스크에 기록하는 동작을 한다. (체크 포인트)

서버 장애 등의 이유로 재기동을 하게 되는 경우, 캐시 영역의 데이터는 없어졌기 때문에 데이터 파일과 REDO 로그에 기록되어 있는 데이터가 올바르다. 그러나 데이터 파일은 이전 데이터밖에 남지 않았기 때문에 최신 데이터를 읽지 못하고 모순된 결과가 되어 버린다.

그래서 이러한 상황에서는 REDO 로그의 내용을 데이터 파일에 적용시켜 나감으로써 데이터 파일과 REDO 로그의 LSN과 일치시키는 작업을 수행한다. 이 과정을 '충돌 복구(Clash Recovery)' 라고 한다. 복구 시에는 적용을 시작할 가장 오래된 LSN을 특정 한 뒤 그 위치로부터 REDO로그의 내용을 순서대로 대응해 나가면 된다.

※ NoSQL의 대부분은 트랜잭션 기능을 갖고 있지 않으므로 비정상계의 처리에 대응하기 위해서는 그에 상응하는 애플리케이션 로직을 만들어 내지 않으면 안 된다.

복제 및 트랜잭션

MySQL에서는 MySQL5.6 과 InnoDB의 경우 처음으로 원자성 있는 갱신이 가능하게 되었다. 

복제 구성에서 슬레이브에서는 마스터에서 전송되어 온 업데이트성 쿼리를 실행하는 역할과 쿼리 중에서 어디까지를 실행했는지 라는 정보도 관리할 필요가 있다. 

마스터는 트랜잭션이 커밋될 때마다 그 갱신 SQL 문을 바이너리 로그에 기록한다. 슬레이브에서는 바이너리 로그의 내용을 실행하여 나가지만 '현재 어디까지 실행했는지'를 관리하기 위해 '실행을 마친 바이너리 로그의 위치 정보'를 관리하는  InnoDB 테이블을 제공한다.

"데이터 손실 방지"는 장애 대책 중에서도 특지 중요하다. 데이터를 읽어 버리면 비록 서버가 복구되었다 해도 필요한 데이터가 없기 때문에 서비스를 계속할 수 없기 때문이다.

RAID

현재 데이터베이스의 데이터는 HDD에 저정돠는 것이 보통인데 HDD는 하드웨어 중에서 가장 고장률이 높은 부품이다. 그래서 하나의 서버에 여러 개의 HDD를 탑재하고 동일한 데이터를 두 개 이상의 HDD에 분산시키는 기술이 사용되고 있는데 이 기술을 RAID 라고 한다.

기준은 용량에 여유가 있으면 RAID1, 없는 경우는 RAID5를 사용하는 것이 일반적이다.

대규모 어플리케이션에서는 특정 테이블로의 트래픽이 매우 커서 한개의 서버에서 처리를 충분히 끝낼 수 없기 때문에 테이블 단위로 (또는 하나의 테이블을) 여러 서버에 분산하는 경우가 있다. 이러한 분할을 특히 '샤딩(sharding)' 이라고 한다.

샤딩을 하고 있으면 조인을 사용하기 어려운데 결합 대상 테이블 혹은 레코드가 반드시 같은 서버에 있다고 할 수 없기 때문이다. 당연히 동일한 데이터베이스 공간에 있는 테이블끼리밖에 조인할 수 없기 때문에 이러한 용도로는 사용할 수 없다.

대규모가 될 것으로 예상되는 애플리케이션은 샤딩의 필요성을 처음부터 염두에 두고 거대하게 될 것 같은 테이블과 조인을 하지 않도록 애플리케이션을 작성한는 방법이 자주 사용되고 있다.

한편으로는 원격 서버에 있는 테이블을 로컬베이스에 있는 것처럼 보여주는 '데이터베이스 링크' 기능을 가진 제품도 존재 한다.