작업 중인 프로시저 강제 종료 시나리오
Delimiter → 구문 문자
Delimiter 명령어는 이러한 구문 문자를 정의하는 기능 → 문법의 끝을 나타내는 역할
함수는 쿼리를 수행한 후 값을 가져오는 것이 중점이지만
프로시저는 여러 쿼리를 한번에 수행하는 것이 중점
프로시저 생성 시 중요한 부분
1.
프로시저명() 안에 있는 파라미터 선언부분
a.
그 값을 받을 파라미터의 이름과 데이터타입
2.
BEGIN ~ END 사이에 수행할 쿼리
위의 프로시저는 insert문을 반복해서 1만행 마다 커밋하면서 50만행 실행
•
오토커밋을 꺼준 후, 아래를 실행
call test_insert_commit(500000)
Shell
복사
•
50만행 관련 프로시저가 수행되다가 mysql 프로세스 중단 시까지 데이터 양 확인 가능
•
이 때, MySQL은 프로세스를 지정하여 강제 종료할 수 있지만 DBMS 중에는 복수의 프로세스가 협력하는 형태로 동작하는 아키텍처로 인해, 전체 프로세스가 종료가 되지 않는 경우도 존재
◦
멀티 프로세스 구성
•
멀티 스레드 구조 = MySQL
지속성과 성능 양립 구조
트랜잭션의 특성 중 Durability(지속성)
⇒ 시스템이 정상일 때뿐만 아니라 비정상적 종료 등의 시스템 장애에 견딜 수 있다는 것을 의미
DBMS 구조
하드디스크에서 지속성을 실현하기 위해 쓰기를 전부 동기화로 처리하는 것은 비효율적(느리고 실용적 x)
지속성과 성능의 양립을 위한 DBMS의 3가지 구조
로그 선행 쓰기 (WAL. Write Ahead Log)
•
데이터베이스의 데이터 파일 변경을 직접 수행하지 않고 우선 로그 변경 내용을 기술한 로그 레코드를 작성하여 동기화하는 구조
•
MySQL에서는 InnoDB log라고 부름
•
이점
◦
디스크에 연속하여 write하므로 무작위로 쓰는 것보다 성능이 높음
◦
디스크에 쓰는 용량과 횟수를 줄일 수 있음
◦
데이터베이스 버퍼를 이용하므로 DB 데이터 파일로 변경 시 효율성이 높음
◦
Commit 시에는 WAL에 변경 내용을 write하므로 트랜잭션 커밋과 동시에 데이터 파일을 동기화할 필요가 없음
•
단점
◦
트랜잭션마다 버퍼를 취해 비동기 write를 수행하면 로그와 데이터 파일 간의 일관성 유지가 어려움
데이터베이스 버퍼
•
데이터 파일의 입력을 데이터베이스 버퍼로 경유하여 단순화
•
효율적으로 데이터 일관성 유지 가능
•
WAL과 버퍼 풀에 갱신이 먼저 반영되고, 이후 check point에서 데이터파일에 수정사항이 반영되는 것이 반복됨
•
MySQL 갱신 흐름 (OS의 페이징과 유사)
1.
갱신 대상의 데이터를 포함한 page가 버퍼 풀에 존재하는지 확인 후 없다면 데이터 파일로부터 읽기
2.
버퍼 풀의 해당 page에서 갱신 수행
3.
2번의 갱신 내용이 commit과 함께 log에 기록됨
•
버퍼 풀에 갱신되었지만, 아직 데이터파일에 써지지 않은 page는 버퍼 풀 내에서 dirty page로 다룸
◦
dirty page : 메모리를 읽어서 갱신된 페이지
4.
데이터 page는 Check Point 때 데이터 파일로 write
5.
Check Point 이전의 로그 파일은 불필요. 갱신과 함께 1번부터 다시 반복
크래시 복구 (Crash Recovery)
WAL, 데이터 베이스 버퍼, 파일이 지속성을 담보하며 연계하면서 현실적으로 동작 수행
MySQL 서버를 재시작하면서 복구할 수 있는 구조
•
Crash 발생 시 상태
◦
WAL : 마지막으로 commit된 트랜잭션의 갱신 정보를 가짐
◦
데이터베이스 버퍼 : 내용이 모두 소실됨
◦
데이터베이스 파일 : 마지막 check point까지의 갱신 정보를 가짐
•
Crash 이후 MySQL 서버 재시작 시 Roll-Forward 수행
◦
Roll-Forward : 데이터베이스 파일과 WAL의 check point 이후 갱신 정보를 사용하여 데이터베이스 파일을 Crash 이전까지 commit된 최신 상태로 수정
◦
Roll-Forward Recovery 전략: 바이너리 로그를 증분 백업으로 보존하고 이를 사용해 풀 백업 시점 이후 임의 시점까지 복원하는 것
•
논리적 파괴(DDL 문에 의한 테이블 파기 등)나 물리적 파손(디스크 장치 고장 등)에는 이와 같은 대응 불가능
◦
주기적 백업 필요. 장애 발생 시 백업으로 복원
PITR (Point-in-time Recovery)
•
백업을 통한 복구는 백업 이후 갱신이 반영되지 않음
•
PITR: 데이터베이스에 실행된 갱신을 기록한 로그를 보존하여(Archive) 로그를 통해 임의의 시점으로 복원하는 것
•
Archive 지정
◦
WAL을 사용
◦
Crash 복구를 위해 check point 이전의 로그(불필요한 로그)도 보존하는 모드
•
바이너리 로그
◦
InnoDB 로그는 InnoDB 전용 crash 복구에만 이용
◦
PITR에는 MySQL에서 이용하는 바이너리 로그 사용
백업
백업 : 현제 이용하는 데이터를 복제 후, 어딘가 다른 장소로 이동
복원 : 백업 데이터로부터 이용할 수 있는 상황까지 복구
백업에는 3가지 관점이 존재
핫 백업과 콜드 백업
•
Hot Backup
◦
온라인 백업
◦
백업 대상의 데이터베이스를 정지하지 않고 가동한채로 백업 데이터를 얻음
◦
MySQL에서의 Hot Backup
▪
주로 OS의 기능으로 백업 데이터를 얻음
▪
트랜잭션 구조 이용, 특수 로그 지정, OS 또는 하드웨어의 스냅샷 등의 방법 존재
▪
mysqldump 커맨드라인 클라이언트 유틸리티 사용 가능
•
Cold Backup
◦
오프라인 백업
◦
백업 대상의 데이터베이스를 정지한 후, 백업 데이터를 얻음
◦
MySQL에서의 Cold Backup
▪
주로 데이터베이스의 기능으로 백업 데이터를 얻음
▪
MySQL 서버를 셧다운하고 데이터 디렉터리 안의 디렉터리와 파일을 OS 명령어로 모두 복사
논리 백업과 물리 백업
•
Logical Backup
◦
SQL 기반의 텍스트 형식으로 백업 데이터 기록
◦
오픈 소스 데이터베이스에서 주로 이용
◦
이식성이 우수한 대신, 물리 백업보다 크기가 크다
•
Physical Backup
◦
데이터 영역을 그대로 dump하여 이미지로 바이너리 형식 기록
◦
클로즈드 소스 데이터베이스에서 주로 이용
▪
소스 코드가 공개되지 않는 데이터베이스 시스템을 의미. 상업적인 라이선스 아래에 판매됨 → 오라클
◦
최소 크기로 데이터를 얻을 수 있는 대신, 복원 단위가 도구에 따라 다르며 일부 데이터 교환 혹은 적용 불가능하다.
풀 백업과 부분(증분/차등) 백업
•
Full Backup
◦
전체 백업
◦
매일 데이터베이스 전체 데이터를 백업
•
Partial Backup
◦
풀 백업 이후, 갱신 된 데이터를 백업
◦
차등(Differential) 백업
▪
풀 백업 이후 갱신된 데이터 백업
◦
증분(Incremental) 백업
▪
어떠한 백업 이후 갱신된 데이터 백업
▪
차등 백업보다 데이터 양이 작지만 복원시 모든 증분 백업을 차례로 적용해야하므로 절차가 복잡함
롤 포워드 리커버리
•
바이너리 로그를 증분 백업으로 보존 → 풀 백업 시점 이후 임의의 시점까지 복원
•
현재의 데이터 베이스 = 풀 백업한 데이터 + 풀 백업 후 얻은 모든 증분 백업
데이터베이스 관리 시 주의점
•
백업 파일들을 물리적으로 떨어진 장치에 각각 보관
•
장치를 지리적으로 떨어진 장소에 보관하면 재해로부터 데이터를 지킬 수 있음
•
장애는 언제든지 일어날 수 있다는 것을 전제로 대책을 세워야 함
•
백업과 복구에 걸리는 시간과 부하를 측정하여 차질 없이 운영 가능해야 함
•
24시간 가동이 필요하다면 핫 백업 필요
•
일정 시간만 운영해도 된다면 콜드 백업을 1일 1회 실행
•
VLDB(Very Large Data Base) 운용 시 논리 백업에는 너무 많은 시간이 소요되므로 물리 백업을 사용
