Semester7

Notes of courses done/attended in semester 7 in college

have copy of data at multiple places
advantages
- increase availability = fault tolerance
- distributes load among multiple nodes
- decreases latency, ppl send request to node close to their system
Challenges
- any change in one replica , must be refglected in others else inconsistent states, this s synchronous replication
- this affects latency
Asynchronous replication
- keval ek me kar abhi, baaki ka asynchronously hota rahega
3 kind of replication strategies
- single leader
- multiple leader
- leaderless

there is no ordering of requests
when leader is there , one replica is primary and others are secondary
secondary do not accept request for update, only for reads
- for any update to be done, they send to primary or client sends to primry
- primary applies writes in some order and also tells to secondary ki is order me lagayo, so all of them see same state
here, no leader
client can talk to any replica for r/w

3 replicas and 2 users
user 1234 is updating, updating in all 3 replicas
- 1 replica is offline
- so bas 2 me changes hue
user 2345 asks for image url
- 2 nodes give same info, 3rd node gives diff
- he sees ki 2 node me new version so tells last node to correct it
so, read requests must be sent to all the replicas and update stale values

when u read, read from all and update if needed
it may not give update to db easily, bcz reads may not be frequent
so anti-entropy process
- bg me chalta and checks if some older version remains etc

Does read have to be from everyone?
nah, follow quorum principle
when we write, say there are n replicas
we write to w nodes, and read from r nodes, such that w + r > n
the idea is the nodes in which we write and from where we read must overlap (atleast one node must be part of overlapping region)
so atleast one ndoe will have value of most recent write
r and w can be chosen, n is fixed

for each data item, keep a version vector along all nodes
position in vector correspond to node number
all elems in one vector < second vector then ok,
100 < 200, 100 < 110
but if some value is smaller, some are larger => concurrent writes ho rahe
- 100 and 011

if conflict hua, what is considered as most recent
Last Write Wins
- timestamp for every write, latest timestamp wala le le, baki ko reject
- achieves eventual convergence, but durability ke cost pe

which one comes first, which one comes second etc
server can determine if 2 operns are concurrent by looking at version numbers
maintains version number for each data item
value written to key => increase version number
when client reads a data item, server returns all versions
b4 writing client must read all values
so write is not successful unless we read all values
when client writes a key, it must include version number from previous ones
overwrite all versions less than what client has told. higher waale rakhe rteh as at is

requires application semantics
- union for a shopping cart
  - 2 alag entries aayi, merge kardia unko
- last write wins
what number of minimium and max nodes can fail (how robustly I handle it) depends upon quorum values