06_Recovery
// Log type for BEGIN(0), COMMIT(2), ROLLBACK(3)
typedef struct logG_t {
int32_t log_size;
int64_t lsn;
int64_t prev_lsn;
int32_t trx_id;
int32_t type;
} logG_t;// Log type for UPDATE(1)
typedef struct logU_t {
int32_t log_size;
int64_t lsn;
int64_t prev_lsn;
int32_t trx_id;
int32_t type;
int32_t table_id;
int64_t pagenum;
int32_t offset;
int32_t data_length;
char old_img[120];
char new_img[120];
} logU_t;// Log type for COMPENSATE(4)
typedef struct logC_t {
int32_t log_size;
int64_t lsn;
int64_t prev_lsn;
int32_t trx_id;
int32_t type;
int32_t table_id;
int64_t pagenum;
int32_t offset;
int32_t data_length;
char old_img[120];
char new_img[120];
int64_t next_undo_LSN;
} logC_t;
- Functions which issue a log according to type and return its LSN
issue_begin_log(trx_id)
issue_commit_log(trx_id)
issue_rollback_log(trx_id)
issue_update_log(trx_id, table_id, pagenum, offset, old_img, new_img)
issue_compensate_log(trx_id, table_id, pagenum, offset, old_img, new_img, next_undo_LSN)
- Function which issues a LSN for new log record
issue_LSN(log_size)
- Funtion which gets the trx_id transactions's last LSN for prev_lsn in new log record
get_and_update_last_LSN(trx_id, lsn)
// Simple Example of upper funtions
int64_t issue_begin_log (int trx_id) {
logG_t log;
log.log_size = LOG_G_SIZE;
// Get a lsn for this log record (== new log record)
log.lsn = issue_LSN(LOG_G_SIZE);
// Get a prev_lsn for this log record (== new log record)
log.prev_lsn = get_and_update_last_LSN(trx_id, log.lsn);
log.trx_id = trx_id;
log.type = 0;
write_to_log_buffer(&log, 0);
return log.lsn;
}- Funtions for recovery phase, function details are available below section
DB_recovery(flag, log_num, log_path)
analysis_pass(read_size, start_offset)
redo_pass(flag, log_num, read_size, start_offset, loser)
undo_pass(flag, log_num, start_offset)
There is 2 log buffers, Log_Buffer and Temp_Log_Buffer
Temp_Log_Buffer is used only in recovery phase
Log_Buffer is used to keep a logs issued during transaction's operation
Log_Buffer is used to read a log file for recovery
Temp_Log_Buffer is used to keep a logs issued during recovery phase
Example of logs issued during recovery phase
- Compensate log is issued when undo loser transaction's operation
Use LSN as start offset
Find all (BEGIN, COMMIT) pair or (BEGIN, ROLLBACK) pair of transaction in log file.
If transaction's (BEGIN, COMMIT) pair or (BEGIN, ROLLBACK) pair does not have COMMIT or ROLLBACK log, it is not committed transaction, LOSER.
WAL protocol guarantees that if COMMIT or ROLLBACK log exists then BEGIN log exists. So we don't care about (BEGIN, COMMIT) pair or (BEGIN, ROLLBACK) pair which does not have BEGIN log.
Redo all logs to meet DURABILITY
The results of the committed transactions are reflected by redo pass
The contents of the log are more up-to-date than page's one.
Apply up-to-date information to page by redo operation.
The contents of the page are more up-to-date than log's one.
Do not apply log's information to page by consider-redo operation.
When redo compensate log, record the 'next undo LSN'.
If crash continues in undo pass without the 'next undo LSN', log file continues to grow. To prevent growing log file, 'next undo LSN' is used.
By pointing the 'next undo LSN', undo pass can avoid below case.
Undo loser logs to meet ATOMICITY
The update operations of the not committed transactions are canceled by undo pass
Undo loser transaction's logs according to 'next undo LSN'
Since 'redo pass' redo compensate log, the 'redo pass' result includes undo operation.
Therefore, 'undo pass' can undo according to 'next undo LSN'
Issue a compensate log to record undo operation, when undo loser transactions
Issue a rollback log to record that rollback is done, when last undo operation is done
LSN is maintained on "LSN_FILE"
-
10 Transactions do db_update operation 5 times
→ COMMIT Transaction : 1, 3, 5, 7
→ ROLLBACK Treanstion : 2, 4, 6, 10
→ Do not both of them : 8, 9
-
Flush data buffer to disk after Transaction 4 to see "CONSIDER-REDO"
-
Winner
→ Transaction 1, 3, 5, 7은 COMMIT, Transaction 2, 4, 6, 10은 ROLLBACK 로그를 발급하였기 때문에 LOG_MSG.txt 파일 결과에서 UNDO 되지 않았습니다.
-
Loser
→ Transaction 8, 9는 db_update 수행 후 COMMIT, ROLLBACK 중 아무런 로그도 발급하지 않았기 때문에 analysis pass에서 loser로 분석되어, UNDO 된 것을 확인할 수 있습니다.
-
Consider-Undo
→ Transaction 1 ~ 4 실행 후 data buffer를 flush 하였기 때문에, LOG_MSG.txt에서 Transaction 1 ~ 4의 작업은 consider-redo 처리된 것을 확인할 수 있습니다.
-
CLR
→ ROLLBACK을 수행한 Transaction 2, 4, 6, 10 중 disk에 결과가 반영되지 않은 6, 10의 로그 메세지를 살펴보면, abort 작업 중 발급된 CLR을 redo한 것을 확인할 수 있습니다. 이때 CLR은 다음 undo 로그의 LSN을 가리키고 있으며, 더이상 undo할 것이 없는 경우 -1을 가리키고 있습니다.