lec07

dz / distributed_systems_MIT / lec07

Summary

RAFT part 2

Node Tree

• faster_backup_scheme
  • log_backup_acceleration
    • xindex
    • xleng
    • xterm
• linearization_definition
• raft
  • who_can_be_leader
    • why_not_longest
    • election_restriction
      • prefers_candidates
  • backup_mechanism
    • detect_point
    • forget_client
      • not_majority
    • log_compaction_snapshots
      • snapshots
        • app_state_smaller
        • ask_application_state
        • log_structure
        • restart
          • find_latest_snapshot
          • follower_not_caught_up
            • install_snapshot_rpc
              • adds_significant_complexity
            • send_snapshot
      • solves_long_logs
    • rollback_scheme
    • takes_a_while
      • prefers_candidates
  • correctness
    • linearizability
      • formalization_of_behavior
  • persistance
    • thrown_away
      • reconstructed
    • vs_nonvolatile
      • thrown_away
        • reconstructed
      • performance
    • writes_to_disk
    • communicating_outside
      • disk_writes_limit
        • synchronous_disk_update
          • optimization
            • batch
            • ssd_flash_dram
          • ssd_flash_dram
    • items
      • voted_for
      • current_term
        • preserve_evidence
      • log
        • application_state
    • restore_after_crash
    • save_state
      • validate_data
    • simultaneous_power_failure
      • save_state
        • validate_data

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