[10/04] CUBRID 리뷰 이후 정리

10/04 CUBRID : cubridebook (HA/백업/보안)
리뷰 이후 내용을 정리합니다

Ha 구성시 force_remove_log_archives=no 를 권장하는 이유

log_max_archives

• 보존할 보관 로그 파일의 최소 개수를 설정하는 파라미터
• 최소값은 0이며 기본값은 INT_MAX (2147483647)
• CUBRID 설치 시 cubrid.conf에는 0으로 설정되어 있다. 이 파라미터의 동작은 force_remove_log_archives의 영향을 받는다 ➡️ force_remove_log_archives=no이면, 활성화된 트랜잭션이 참조하고 있는 기존 보관 로그 파일 또는 HA 환경에서 슬레이브 노드에 반영되지 않은 마스터 노드의 보관 로그 파일이 삭제되지 않는다.

예제 1 ) cubrid.conf > log_max_archives=3 , force_remove_log_archives=yes
최근 3개의 보관 로그 파일만 유지하고 네 번째 보관 로그가 생성될 때에는 이전에 생성된 보관 로그 파일을 자동으로 삭제한다. 이때 삭제되는 보관 로그 파일의 정보는 *_lginf 파일에 기록된다.

예외 1) 활성화된 트랜잭션이 기존 보관 로그 파일을 여전히 참조하고 있다면, 해당 보관 로그 파일은 삭제되지 않는다. 즉, 어떤 트랜잭션이 첫 번째 보관 로그 파일이 생성되는 시점에서 시작되어 다섯 번째 보관 로그 파일이 생성되는 시점까지도 종료되지 않았다면 첫 번째 보관 로그 파일은 삭제되지 않는다.

예외 2) 보관 로그 파일의 정보가 데이터베이스 볼륨에 아직 반영되어 있지 않은 경우 에도 해당 보관 로그 파일은 삭제되지 않는다. (체크포인트가 발생한 이후의 보관 로그는 데이터 버퍼의 수정된 페이지 정보를 가지고 있으므로 데이터베이스 복구를 위해 필요하다.)

참고 1) DB 운영 중에 log_max_archives의 값을 동적으로 변경하는 경우, 변경된 값은 새로운 보관 로그 파일이 생성될 때 적용된다. 예를 들어, 해당 값을 10에서 5로 변경한 경우, 새로운 보관 로그 파일이 생성되는 시점에 오래된 파일 5개를 삭제한다.

force_remove_log_archives

ha_mode 를 on으로 설정하여 HA 환경을 구축하려면 force_remove_log_archives 를 no로 설정하여 HA 관련 프로세스에 의해 사용할 보관 로그(archive log)를 항상 유지하는 것을 권장

why?

force_remove_log_archives를 yes로 설정하면 HA 관련 프로세스가 사용할 보관 로그 파일까지 삭제될 수 있고, 이로 인해 데이터베이스 복제 노드 간 데이터 불일치가 발생할 수 있다.

환경별 force_remove_log_archives & log_max_archives 사용

1) HA 환경이 아닌 경우(ha_mode=off) = single 모드 일때,

force_remove_log_archives를 yes(기본값)로 설정하면, 최대 log_max_archives 개수만큼만 보관 로그가 유지되고 나머지는 자동으로 삭제된다. 단, 가장 오래된 보관 로그 파일에 액티브한 트랜잭션이 있다면 이 트랜잭션이 종료될 때까지 해당 로그 파일이 삭제되지 않는다.

2) HA 환경인 경우(ha_mode=on)

force_remove_log_archives를 no로 설정하고, log_max_archives 개수를 지정하면 복제 반영 후 자동으로 삭제된다.

ha_mode=on일 때 force_remove_log_archives를 yes로 설정하면 복제 반영이 안된 보관 로그가 삭제될 수 있으므로(❗️🟰 데이터베이스 볼륨 반영), 이를 권장하지는 않는다. 다만, 복제 재구축을 감수하더라도 마스터 노드의 디스크 여유 공간을 확보하는 것이 우선된다면 force_remove_log_archives를 yes로 설정하고, log_max_archives를 적당한 값으로 설정한다.

3) 참고상황
cubrid backupdb -r 옵션을 사용하여 명령을 실행하면 삭제된다. 하지만 HA 환경에서는 -r 옵션을 사용하면 안 된다. 복제 반영이 안된 보관 로그가 삭제된다면 복제 노드 간 데이터 불일치 발생 가능

즉, 데이터베이스 운영 중에 보관 로그 볼륨을 가급적 남기고 싶지 않다면 cubrid.conf의 log_max_archives 값을 작은 값 또는 0으로 설정하되, force_remove_log_archives의 값은 HA 환경이면 가급적 no로 설정한다.

what is WAL?

WAL

• 트랜잭션이 일어나기 전에 로그를 미리 기록하여 트랜잭션 undo, redo 를 할 수 있도록 한다.
• UNDO는 UPDATE 이전의 데이터를 포함하고 REDO는 UPDATE할 새 데이터를 포함
• 시스템 고장 시 복구가 가능하게 하기 위한 정책
• undo 복구 : 트랜잭션이 작업을 진행하기 전 데이터로 되돌리는 것을 말한다.

• 중간에 트랜잭션이 종료되어 A 가 1000원을 잃어버리게 되는 상황이 왔을 때(중간 결과물이 디스크에 쓰여진 상황) A 계좌에 다시 1000원을 증가시켜 원래대로 되돌리는 undo 복구를 진행한다.

• redo 복구 : 트랜잭션이 작업을 진행한 후 상태로 되돌리는 것을 말한다.

• 트랜잭션 작업이 제대로 진행되었고 그 결과가 메모리에만 쓰여지고 디스크에는 쓰여지지 않았을 때
  정전이 되어서 메모리가 날아가는 경우, 트랜잭션 작업 결과도 사라지게 된다. 이 경우, 트랜잭션 결과를 다시 복구하기 위해 (로그를 이용하여) redo 복구를 진행한다.

• A가 1000원을 출금한 상황. 메모리에까지 쓰여졌는데 디스크에 쓰여지기 전에 정전이 되어 메모리/디스크 작업이 모두 사라짐. 그러면, A가 1000원을 출금하기 전의 상황이기 때문에 A 계좌에 다시 1000원을 감소시키도록 (이미 커밋한 트랜잭션의 수정을 재반영하는 복구 작업)인 redo 복구 진행

큐브리드도 WAL 방식입니다.

큐브리드 트랜잭션에서 이어서,,,,공부,,,,
WAL에 대한 내용

Q&A (dooray에 정리)

https://nhnent.dooray.com/project/3241711113770001992/3377009799348180850