distributed_systems_MIT/lec09

lec09

dz / distributed_systems_MIT / lec09

Summary

More Replication, CRAQ

Node Tree

Nodes

zookeeper
content zookeeper
children problems_to_solve, reads_stale_writes_ordered, API, based_on_raft

based_on_raft
content based on raft
parents zookeeper

reads_stale_writes_ordered
content Reads can be stale, writes are ordered
parents zookeeper

problems_to_solve
content Problems to solve
children config_info, elect_master
parents zookeeper
remarks problems it solves, perhaps?

config_info
content Config info
parents problems_to_solve

test_and_set
content VMWare test and set service that is fault-tolerant and does right thing under partitions

elect_master
content Elect Master
children zookeeper_primitives (I think this was a phrase used while talking about,electing a master as a usecase)
parents problems_to_solve

zookeeper_primitives
content "zookeeper primitives"
parents elect_master

API
content API
children exists, filesystem_like, get_data, list, set_data, z_nodes, create, delete, ex_count, ex_locks
parents zookeeper

filesystem_like
content Filesystem-like
children naming_system
parents API

naming_system
content naming system
parents filesystem_like

z_nodes
content Z-Nodes
children regular, sequential, ephemeral
parents API

regular
content Regular
children flags
parents z_nodes

ephemeral
content Ephemeral
children flags
parents z_nodes

sequential
content Sequential
children flags
parents z_nodes

flags
content flags
children create (flags argument)
parents ephemeral, regular, sequential

create
content create(path, data, flags)
parents API, flags

delete
content delete
children version
parents API

version
content version
parents delete

exists
content exists(path, watch)
children check_and_insert
parents API

check_and_insert
content exists check and insert if watch is atomic
parents exists
remarks "if watch is atomic?" I think I meant to say it was an atomic operation?

get_data
content get data
parents API

set_data
content set data
parents API

ex_count
content Example: count (using zookeeper)
children count_pseudocode
parents API

count_pseudocode
content While true x,v = getdata("f") if setdata("f", x-> 1, w) break
children mini_transaction, no_finish_guarantee, pulled_off_atomic
parents ex_count

mini_transaction
content Mini-transaction
children pulled_off_atomic (Atomicity is why this is referred to as a "mini,transaction")
parents count_pseudocode

pulled_off_atomic
content Once pulled off, is atomic
parents count_pseudocode, mini_transaction

no_finish_guarantee
content Not guaranteed to finish
children okay_in_practice
parents count_pseudocode

okay_in_practice
content this is usually okay in practice and doesn't happen
parents no_finish_guarantee

ex_locks
content Example: Locks
children herd_effect, lock_without_herd, non_scalable_lock
parents API
remarks Prof: "in paper, not necessarily helpful"

herd_effect
content Herd effect
children lock_without_herd, too_many_clients
parents ex_locks

too_many_clients
content Problem caused by too many clients
parents herd_effect

non_scalable_lock
content non-scalable lock
parents ex_locks

list
content list operation
parents API

lock_without_herd
content Lock without herd effect
children scalable_lock
parents ex_locks, herd_effect

scalable_lock
content Scalable lock
parents lock_without_herd
remarks Prof impressed that zookeeper can express it but not sure why it is helpful to have in zookeeper

CRAQ
content CRAQ
children optimizes_reads, why_reading, chain_repl

why_reading
content Why read about this?
parents CRAQ

different_ft_properties
content The fault-tolerant properties are different from from RAFT

chain_repl
content Chain replication
children failure_recovery, incomplete_repl_story, old_version, optimizes_reads, raft_load_higher_than_chain_head, chain_of_servers
parents CRAQ

old_version
content old version
parents chain_repl

optimizes_reads
content Optimizes reads
parents chain_repl, CRAQ

chain_of_servers
content Chain of servers
children head, tail
parents chain_repl

head
content Head
children writes_start_proliferate
parents chain_of_servers

tail
content tail
children reads_from_tail, sends_reply_client
parents chain_of_servers

reads_from_tail
content Reads from tail
parents tail

sends_reply_client
content sends reply to client
parents writes_start_proliferate, tail

writes_start_proliferate
content writes start here, proliferate
children sends_reply_client
parents head

failure_recovery
content Failure Recovery
children head_fails_next, intermediate_more_compliex, tail_fails_prev, constrainted_set_of_states
parents chain_repl

constrainted_set_of_states
content Set of strates after failure relatively constrained
parents failure_recovery

head_fails_next
content If head fails, next one in chain becomes head
children intermediate_more_compliex (more complex than head)
parents failure_recovery

tail_fails_prev
content If tail fails, previous node takes over
children intermediate_more_compliex (more complex than tail)
parents failure_recovery

intermediate_more_compliex
content Intermediate failed node, more complex than head/tail
parents tail_fails_prev, failure_recovery, head_fails_next

raft_load_higher_than_chain_head
content load on raft leader higher than chain replication head
parents chain_repl

incomplete_repl_story
content Not a complete replication story
children config_manager (config manager completes I think?)
parents chain_repl

config_manager
content Configuration manager
children if_dead_new_config, monitors_liveness, built_on
parents incomplete_repl_story

monitors_liveness
content Monitors Liveness
parents config_manager

if_dead_new_config
content If it thinks a server is dead, it sends a new config
parents config_manager

built_on
content built on RAFT, Pasx, or zookeeper
parents config_manager