Group:
security
Topic:
a single system image
Topic:
backup processor
Topic:
broadcasting information
Topic:
data caching
Topic:
database consistency and reliability
Topic:
database implementation
Topic:
database security
Topic:
file cache
Topic:
file system reliability
Topic:
immutable files and data
Topic:
information as a hint
Topic:
key distribution
Topic:
managing shared memory
Topic:
read-only and write-once file systems
Topic:
reliability of distributed systems
Topic:
shared objects
Topic:
shared information for collaborative work
Topic:
timestamps
Topic:
updating information in a distributed system
Topic:
updating information with rumor mongering and random updates
Topic:
version control
| |
Summary
Replicated data is data copied to multiple locations. Replication moves data closer to its use. Access is faster and network bandwidth is reduced. If one copy is destroyed, other copies may take its place. Data caching moves data to a faster media or stores results for reuse.
If data is immutable or version controlled, a copy in one location is the same as a copy in another.
If the data changes, then copies must be updated or invalidated. For cached data, this property is called cache coherency. The cache may "snoop" the memory bus for updates. Optimisitic replication copies the data and invalidates the data on change.
Update propagation may lead to consistency errors. Replicated data can have the same problems as shared data (e.g. data races). Database and transactional data may require sequential consistency. (cbb 8/06)
Subtopic: advantages of replication 
| Quote: propagation good for information dissemination
| | Quote: use caching, replication, and prediction to improve latency [»pattDA10_2004]
| | Quote: with timestamped data, queries can be concurrent with updates by using previous copy [»copeG3_1980]
| | Quote: stale data is OK; most data is updated infrequently or not at all; allows lazy replication and scalability [»boswA10_2005]
|
Subtopic: optimistic replication
| Quote: survey of optimistic replication algorithms; background propagation of change; supports concurrent work and allows for unreliable communications [»saitY3_2005]
| | Quote: under an optimistic approach, invalidating remote copies was more robust than propagating changes [»franMJ9_1997]
| | Quote: eager update everywhere replication serializes conflicting transactions via total order multicast of batched updates at commit; reduce conflicts with snapshot isolation and short message delays [»kemmB9_2000]
| | Quote: survey of eager replication; primary copy or update everywhere, change propagation, voting or non-voting [»wiesM10_2000]
| | Quote: for eager replication, consider update everywhere with a few messages per transaction
|
Subtopic: sequential consistency
| Quote: define sequential consistency of replicated data by a serialization condition; i.e., behavior indistinguishable from a shared-memory system [»afekY1_1993]
| | Quote: sequential consistency for replicated data from Lamport; but he required a FIFO request queue per memory [»afekY1_1993]
| | Quote: lazy cache algorithm buffers read and write requests; sequential consistency by atomic write to In queues, and flush on write..read by a processor [»afekY1_1993]
| | Quote: one-copy serialization on a replicated database is equivalent to some serial execution on a nonreplicated database [»franMJ9_1997]
|
Subtopic: cache coherence
| Quote: cache coherence if a read always returns the value of the last write; stronger than sequential consistency [»afekY1_1993]
|
Subtopic: replicated database
| Quote: provide redundant data servers for requests to unchanged data that don't access differential file [»maryF_1982, OK]
| | Quote: a predicate database is easily relocated, replicated, and independently implemented [»giffDK12_1985]
| | Quote: reliable broadcast is useful for replicated databases and other applications
| | Quote: use 0-safe database replication where no copy is consistent and up-to-date; use subtransactions to update remote copies; e.g., Den Danske Bank [»franL12_1999]
|
Subtopic: replicated directories
| Quote: Vesta subtrees may be replicated; the agreement invariant says that no name is bound to different values in different repositories
| | Quote: every Vesta object has at most one master copy; only a master directory can append new names; non-master directories use replication [»heydA_2006]
| | Quote: a non-master stub is a placehoder for data in another repository; master appendable directories use non-master stubs for named objects held elsewhere [»heydA_2006]
| | Quote: most operations on a Vesta repository affect only one repository; the rest use two repositories; all operations maintain the agreement invariant [»heydA_2006]
| | Quote: the Vesta repository operations are create, append, replace a master stub, make a ghost, copy between appendable directories, create a non-master stub, and transfer mastership [»heydA_2006]
| | Quote: Vesta does not require multi-site atomic transactions to maintain the agreement invariant
| | Quote: Hypertext indices can be replicated, non-replicated, or multiple-attributed [»clifC2_1989]
| | Quote: Clearinghouse is decentralized and replicated [»oppeDC7_1983]
| | Quote: Clearinghouse's update algorithm only requires eventual delivery of repeated messages [»demeA8_1987]
| | Quote: Clearinghouse domain servers can keep direct pointers or replicas of other domain clearinghouses [»oppeDC7_1983]
|
Subtopic: replicated files
| Quote: data consistency becomes a problem when multiple copies exist; traditionally, all copies are kept identical [»afekY1_1993]
| | Quote: optimal distributed algorithm for identifying corrupted files by exchanging page signatures [»abdeKA1_1994]
| | Quote: few update conflicts across network partitions caused by optimistic server replication; over nearly a year [»kistJJ2_1992]
| | Quote: Amoeba files are replicated on two disks; the create-file operation can return when 0, 1 or 2 copies written to disk [»vanrR10_1988]
| | Quote: UNIX file system described by a replicated, immutable superblock [»mckuMK8_1984]
|
Subtopic: replicated file chunks
| Quote: replicate GFS file chunks on multiple chunkservers and racks; usually three replicas
| | Quote: use leases to maintain order across replicas; master grants a chunk lease to the primary replica, and the primary orders the mutations [»gherS10_2003]
| | Quote: chunkservers forward data immediately to the next replica over a precomputed path [»gherS10_2003]
|
Subtopic: replicated objects
| Quote: Amoeba handles replicated objects by storing and retrieving the capabilities for multiple copies; a client can try each one [»taneAS12_1990]
| | Quote: Amoeba's directory server provides lazy, automatic replication of immutable files; copies can be regenerated if needed [»taneAS12_1990]
| | Quote: in Ocra, shared objects are replicated on all machines; writes by reliable broadcast, reads locally [»taneAS8_1992]
| | Quote: Vice removes worries about replication of data; just store it in Vice [»boreN2_1988]
| | Quote: ZOG provides for read-only, automatically updated, secondaries stored on remote machines [»akscRM5_1984]
| | Quote: two phase gossip best for systems that use distributed and replicated event histories for large data objects [»heddA10_1989]
| | Quote: two phase gossip--replicated data objects with checkpoint and event history; roll-forward an object when all sites have complete histories [»heddA10_1989]
|
Subtopic: read and write quorums
| Quote: use read and write quorums to manage replicated data [»giffDK_1979]
| | Quote: resilient extend true-copy token scheme for replicated data that can handle total site crashes and network partition [»minoT5_1982]
| | Quote: two phase gossip uses quorum consensus; a query uses a quorum to gather a complete history for an object; an update writes a quorum [»heddA10_1989]
|
Subtopic: replicated data
| Quote: use read and write quorums to manage replicated data [»giffDK_1979]
| | Quote: resilient extend true-copy token scheme for replicated data that can handle total site crashes and network partition [»minoT5_1982]
| | Quote: authentication server replicated in every Andrew server; all but one are read-only; propagate changes over secure lines [»satyM8_1989]
|
Subtopic: naming
| Quote: naming should support replicated objects [»watsRW_1981]
|
Subtopic: shared references
| Quote: Cedar reference variables can be freely replicated and discarded due to garbage collection [»swinDC7_1985]
|
Related Topics
Group: security (23 topics, 874 quotes)
Topic: a single system image (30 items)
Topic: backup processor (3 items)
Topic: broadcasting information (18 items)
Topic: data caching (35 items)
Topic: database consistency and reliability (15 items)
Topic: database implementation (18 items)
Topic: database security (12 items)
Topic: file cache (23 items)
Topic: file system reliability (26 items)
Topic: immutable files and data (59 items)
Topic: information as a hint (18 items)
Topic: key distribution (35 items)
Topic: managing shared memory (74 items)
Topic: read-only and write-once file systems (8 items)
Topic: reliability of distributed systems (35 items)
Topic: shared objects (13 items)
Topic: shared information for collaborative work (36 items)
Topic: timestamps (19 items)
Topic: updating information in a distributed system (50 items)
Topic: updating information with rumor mongering and random updates (13 items)
Topic: version control
(34 items)
|
