lec07
dz / distributed_systems_MIT / lec07Summary
RAFT part 2
Node Tree
- faster_backup_scheme
- linearization_definition
- raft
Nodes
raft | |
content | RAFT |
children | who_can_be_leader, backup_mechanism, correctness, persistance |
backup_mechanism | |
content | Backup Mechanism |
children | detect_point, forget_client, log_compaction_snapshots, rollback_scheme (AKA), takes_a_while (Backups can take a while to do a full restore) |
parents | raft |
rollback_scheme | |
content | Rollback Scheme |
parents | backup_mechanism |
takes_a_while | |
content | Can take a while |
children | prefers_candidates |
parents | backup_mechanism |
detect_point | |
content | Detect a point at which followers match servers |
parents | backup_mechanism |
forget_client | |
content | Why is it okay to forget about client command |
children | not_majority (answer) |
parents | backup_mechanism |
remarks | I believe this was a hypothetical situation in the lecture |
not_majority | |
content | not in majority, never executed, no reply back to client. Client resends |
parents | forget_client |
prefers_candidates | |
content | Prefers candidates who know about more recent terms |
parents | takes_a_while, election_restriction |
who_can_be_leader | |
content | Who can be a leader? |
children | why_not_longest (why not choose leader based on longest log?), election_restriction |
parents | raft |
why_not_longest | |
content | Why not use longest log as heuristic? |
parents | who_can_be_leader |
remarks | At this point, there was a good example that showed situation where this wouldn't be a good idea. |
election_restriction | |
content | Election Restriction: vote "yes" only if higher term in last entry, or same last term, or the log length greater than or equal to server that received vote request. |
children | prefers_candidates |
parents | who_can_be_leader |
faster_backup_scheme | |
content | A faster backup scheme |
children | log_backup_acceleration |
remarks | The paper is apparently vague here. Prof calls it a "nondescription". |
log_backup_acceleration | |
content | Log Backup Acceleration |
children | xindex, xleng, xterm |
parents | faster_backup_scheme |
xterm | |
content | xterm |
parents | log_backup_acceleration |
xleng | |
content | xleng |
parents | log_backup_acceleration |
xindex | |
content | xindex |
parents | log_backup_acceleration |
persistance | |
content | Persistance |
children | thrown_away (what can be thrown away?), vs_nonvolatile, writes_to_disk, communicating_outside, items, restore_after_crash, save_state, simultaneous_power_failure (What Persistance Can Help With) |
parents | raft |
writes_to_disk | |
content | Writes to Disk |
parents | persistance |
vs_nonvolatile | |
content | VS. Nonvolatile |
children | thrown_away, performance |
parents | persistance |
performance | |
content | Performance |
parents | vs_nonvolatile |
restore_after_crash | |
content | Restore After Crash |
parents | persistance |
simultaneous_power_failure | |
content | Simulataneous Power Failure |
children | save_state |
parents | persistance |
save_state | |
content | Save State When Power Returns |
children | validate_data |
parents | persistance, simultaneous_power_failure |
validate_data | |
content | Way to Validate Datat |
parents | save_state |
items | |
content | Items that are persistant |
children | voted_for, current_term, log |
parents | persistance |
log | |
content | Log |
children | application_state |
parents | items |
current_term | |
content | Current Term |
children | preserve_evidence |
parents | items |
voted_for | |
content | Voted For |
parents | items |
communicating_outside | |
content | Don't need to persist until communicating with outside |
children | disk_writes_limit (This is probably why there's a benefit to waiting to,persist.) |
parents | persistance |
preserve_evidence | |
content | preserves evidence of pre-existing term numbers |
parents | current_term |
application_state | |
content | Only place where application state exists |
parents | log |
disk_writes_limit | |
content | Disk writes are a limiting factor in performance |
children | synchronous_disk_update |
parents | communicating_outside |
synchronous_disk_update | |
content | Synchronous Disk Update |
children | optimization, ssd_flash_dram (These are ways to improve performance) |
parents | disk_writes_limit |
ssd_flash_dram | |
content | SSD, Flash, Batter-Backed DRAM |
parents | optimization, synchronous_disk_update |
optimization | |
content | Optimiation strategies for synchronous disk update |
children | batch, ssd_flash_dram |
parents | synchronous_disk_update |
batch | |
content | Batch operation: do everything in one go |
parents | optimization |
thrown_away | |
content | Why is it okay for some things to be thrown away? (non-volatile) |
children | reconstructed |
parents | persistance, vs_nonvolatile |
reconstructed | |
content | Some things can be reconstructed from logs |
parents | thrown_away |
log_compaction_snapshots | |
content | Log Compaction and Snapshots |
children | snapshots, solves_long_logs |
parents | backup_mechanism |
solves_long_logs | |
content | Problem Solved: long logs from servers that have been up a while |
parents | log_compaction_snapshots |
snapshots | |
content | Snapshots |
children | app_state_smaller, ask_application_state (transcend software layers (RAFT layer vs Application Layer)), log_structure, restart |
parents | log_compaction_snapshots |
ask_application_state | |
content | Ask Application to save state as log entry |
parents | snapshots |
app_state_smaller | |
content | usually app state is smaller than log |
parents | snapshots |
log_structure | |
content | Snapshots are part of logs, works like this: index with snapshot, then logs after the snapshot |
parents | snapshots |
restart | |
content | What happens during restart? |
children | find_latest_snapshot, follower_not_caught_up |
parents | snapshots |
find_latest_snapshot | |
content | Find latest snapshot index that RAFt found |
parents | restart |
follower_not_caught_up | |
content | Problem: if follower isn't fully caught up with logs up to snapshot, it will never be able to catch up. |
children | install_snapshot_rpc (solution to the "follower not caught up" issue), send_snapshot |
parents | restart |
install_snapshot_rpc | |
content | Install Snapshot RPC |
children | adds_significant_complexity |
parents | follower_not_caught_up |
send_snapshot | |
content | Send Snapshot to Follower |
parents | follower_not_caught_up |
correctness | |
content | correctness |
children | linearizability (Synonym) |
parents | raft |
linearizability | |
content | Linearizability |
children | formalization_of_behavior |
parents | correctness |
remarks | Prof will admit later on that linearizability and correctness are used interchangeably here, but linearizability has a more formal definition. |
adds_significant_complexity | |
content | adds significant complexity |
parents | install_snapshot_rpc |
formalization_of_behavior | |
content | Formalization of Behavior |
parents | linearizability |
linearization_definition | |
content | Execution history is linearizable if total order of operations matches realtime for non-concurrent requests, each read sees most recent write in order |