16-08-2012, 04:28 PM
Replication and Consistency
1Replication.ppt (Size: 617 KB / Downloads: 27)
Replication: A key to providing good performance, high availability and fault tolerance in distributed systems (passive and active).
The important issue is keeping replicas consistent.
Consistency models and protocols
The Gossip architecture: an approach to propagate updates.
Enhancing Services by replicating data
Performance
When a distributed system needs to scale in numbers and geographical area, performance can be improved by replicating servers.
Fault Tolerance
Under the fail-stop model, if up to N of N +1 servers crash, at least one remains to supply the service.
Increased Availability
Service may not be available when servers fail or when the network is partitioned.
Replication Management (1)
Front End: Request Communication
Requests can be made to a single RM or to multiple RMs
Coordination: The RMs decide
whether the request is to be applied
the order of requests
FIFO ordering: If a FE issues r then r’, then any correct RM handles r and then r’.
Causal ordering: If the issue of r “happened before” the issue of r’, then any correct RM handles r and then r’.
Total ordering: If a correct RM handles r and then r’, then any correct RM handles r and then r’.
Execution: The RMs execute the request tentatively.
Replication Management (2)
Agreement: The RMs attempt to reach consensus on the effect of the request.
E.g., Two phase commit through a coordinator
Response
One or more RMs responds to the front end.
In the case of fail-stop model, the FE returns the first response to arrive.
Weak consistency
Weak consistency
Accesses to synchronization variables associated with a data store are sequentially consistent
No operation on a synchronization variable is allowed to be performed until all previous writes have been completed everywhere
No read or write operation on data items are allowed to be performed until all previous operations to synchronization variables have been performed.
Release consistency
Before a read or write operation on shared data is performed, all previous acquires done by the process must have completed successfully.
Before a release is allowed to be performed, all previous reads and writes by the process must have completed
Accesses to synchronization variables are FIFO consistent (sequential consistency is not required).
Client-Centric Consistency models
Many systems: one or few processes perform updates
How frequently should these updates be made available to other read-only processes?
Examples:
DNS: single naming authority per domain
Only naming authority allowed updates (no write-write conflicts)
How should read-write conflicts (consistency) be addressed?
NIS: user information database in Unix systems
Only sys-admins update database, users only read data
Only user updates are changes to password