distributed_systems_MIT/lec07

lec07

dz / distributed_systems_MIT / lec07

Summary

RAFT part 2

Node Tree

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