Mobile Replicated Data

By

Shruti Shivashankaraiah

Shubha Sundara Murthy

CST-594

Contents1. Introduction

2. History

3. System Models

4. Replication Requirements

5. Data Consistency

6. Replicated Data Models

7. Representing Updates

8. Recording Updates

9. Sending Updates

10.Ordering Updates

11.References

Technology is trending towards wireless

Constant Access to Personal DataMillions of users access online

distributed databases

ChallengesConsistency and Availability of DataProviding Users anywhere anytime

AccessComing up with suitable Replication

Protocol.

Introduction

The era of replicated services started 1980’s.

Grapevine developed at Xerox provided a replicated directory and email service.

Many innovations came out of the Coda project at CMU.

Around 1990, researchers articulated a vision, called “Ubiquitous computing”.

History

Portable devices with limited displays, CPU resources, storage, battery life, and security.

Intermittent, low-bandwidth, high-latency network connections.

Changing environmental conditions and contexts.

Key Considerations in Mobile Systems

System Models

1. Remote Data Access

2. Device Master Replication

3. Peer to Peer Replication

4. Publish Subscribe Systems

Remote Data Access

Web access from a cell phone using WAP.

• Data Resides on Central server.

• The server provides methods for querying or accessing the stored information over a network.

• Data consistency is not an issue since all updates are performed directly at the server.

Drawbacks of Remote Data Access

Data is inaccessible if a network connection to the server cannot be established or if the server is temporarily unavailable.

Access time to the data is limited by the round-trip communication latency between device and server.

Communication consumes valuable battery life.

Communication may incur network charges.

Laptop caching files and Web pages.

Data resides on Master Site.

Full or partial data resides on the portable devices (Caching).

Uses weak Consistency model and cache replacement policy

Frequently accessed data or actively-managed user-visible data can be cached.

Any updates are written to master server to make it available for all devices.

Device Master Replication

Drawbacks of Device–Master Replication

Attempts to read a data object fails if the data is not resident on the accessing device.

Weaker consistency guarantees. Concurrent updates on same or different objects lead to conflicts.

Master is responsible for detecting when two devices produce conflicting updates.

If master fails, other devices cannot propagate updates.

PEER-TO-PEER REPLICATION

Peer-to-peer synchronization between mobile devices.

No Master Replica, Pair wise synchronizationComplicated protocols but offers advantagesEasy to add external device by establishing local

synchronization partnerships. Tolerant of failed devices and network outages.

Drawbacks of Peer to Peer Replication

Requires complex protocol to ensure effective utilization of bandwidth during updates.

More prevalent conflicts.

Publish Subscribe System

Publishers broadcast messages to subscribers. Information reaches directly via publisher or

through other subscribers. Example news, weather or sports score. Information created are, by publisher and read-

only, which are usually discarded once read.

Smart watch receiving news, weather reports, and other notices that are broadcast from a central publishing site.

Replication Requirements

Replication requirements for basic data-oriented system models

Data Consistency

Best Effort Consistency Eventual Consistency Casual Consistency Session Consistency Bounded Inconsistency Hybrid Consistency

Best Effort Consistency Guarantees best effort to deliver update to all

replicas. Despite reliable delivery, replicas will not converge

if

*Updates are performed differently at different replicas.

*Updates are applied in different orders at different replicas and are not commutable;

*Replicas have different conflict resolution policies.

*Metadata, such as deletion tombstones, are discarded too early.

*Replicas lose or have corrupt data.

*The system is improperly configured, such as when the synchronization topology is not a well-connected graph.

Eventual Consistency

Guarantees that replicas would eventually converge to a mutually consistent state, to identical contents.

A mobile system provides eventual consistency if :

(1) Each update operation is eventually received by each device

(2) Non-commutative updates are performed in the same order at each replica

(3) The outcome of applying a sequence of updates is the same at each replica.

Casual ConsistencyGuarantees that if update U2 follows U1, then it would

ensure that a replica never performs U2 without performing U1.

Session guarantees have been devised to provide a user with a view of a replicated database that is consistent with respect to the set of read and update operations performed by that user while still allowing temporary divergence among replicas.

read your writes Monotonic readsWrite your readsMonotonic write

Session Consistency

Bounded InconsistencyBounds are placed on the timeliness or inaccuracy of

items that are read from a device’s local replica .

Applications can be presented with a choice of strong or weak read consistency.

For strong consistency, read operations can be directed to the master (or publisher).

If stale information is acceptable then the data can be read from local replica.

Hybrid Consistency

Replicated Data Models

Issues faced by a designer of a replication protocol :ConsistencyUpdate formatChange trackingMetadataSync stateChange enumerationCommunicationOrderingFiltering

Representing UpdatesSchemes:

Operation-Sending ProtocolsItem-Sending Protocols

Comparisons:Common item layout

run different applications with custom APIs for accessing different replicas of the shared collection

Common operationsMay even have different physical schemas.

Recording Updates

Schemes:Log-Based Systems

Recording UpdatesState-Based Systems

Recording Updates

Comparison

Sending updates

Direct BroadcastSimplest technique.Device that performs a local update operation to

immediately send that update to all other replicas.Expensive and not totally reliable. Avoids the need to log such updates.Needs to know complete set of replicas for a data

collection.Devices that are currently unavailable miss updates.Example: Coda

Sending updates

Full Replica or Log ExchangeSimple and robust.Pairs of devices periodically exchange replicas or logs.Eventual consistency can be achieved.Waste substantial bandwidth, consume CPU resources,

and reduce battery life.Need for more network efficient protocol, may be?

Sending Updates

Gossip ProtocolsA device sends a randomly selected update (or set of

updates) to some other device. One technique: Rumor Mongering, dispersing hot rumors

Replica or logs.

Many failed attempts, off the list.

Alternatively, adopt a fixed expiration period : epidemic algorithm

Simple to implement, no device connectivity constraints, small amount of metadata

But, update may not reach all replicas. Send cold rumors.

Sending updates

Message Queue ProtocolsA reliable messaging system can propagate updates. Example: IBM’s MQ Series or Microsoft’s SQL Service BrokerThe replica that performs an update operation simply places

this update on queues.Delivery queues managed by the messaging system.Each replica need not have a direct connection to each other

replica.The simplest scheme is to have a single tree, all updates are

sent to the root of this multicast tree.A well knit replication topology facilitates eventual

convergence.But, broken /unreliable links and must be handled.

Sending updates

Modified Bit ProtocolScenario: Cell phone and home PC share a copy of a person’s

address book.Each device tracks updates with modified bit for each item.Updating: operation on local replica and change modified bitDuring synchronization, exchange all items with nonzero modified

bit and reset the bit.Widely used for cell phones and PDAs.Provides eventual consistency.Simple, low-overhead synchronization technique for systems

involving lesser number of devices.But, it works less well for rapidly changing replica sets and does

not allow incremental update exchange between devices that do not have an established synchronization partnership

Sending updates

Device–Master Timestamp ProtocolsDevice-Master model allows a simpler replication protocol .Could use the modified-bit protocol, but lots of book

keepingMaster assigns update timestamps to each item on local

update or on receiving an update from client device.Client records the time of its last synchronization with the

master. No client-specific synchronization state to be stored on

master, only per-item update timestamps.Alternatively, master can save the last synchronization of

the replica to initiate synchronization.

Sending updates

Device–Master Log-Based ProtocolClients can hold update logs.Clients stores local updates in log which are exchanged

during synchronization.No extra per-item metadata.Client can discard its complete log after

synchronization, trivial log management.Variations: Master can hold update logs, but added

burden of shared log.

Sending updatesAnti-Entropy/metadata exchange Protocols

In a peer-to-peer replication model in which devices can obtain updated items directly.

More metadata for efficient pairwise synchronization.Each device to record last unique identifier for each

item and version metadata(version vectors).The protocol is robust enough to operate over lossy

wireless networks.But, network congestion while exchanging metadata

and infrequent updates leads to waste of networking and processing resources.

Sending updates

Anti-entropy With ChecksumsDevice to compute checksum over the contents of the

replica.The partner device verifies and then optionally go for

metadata exchange.Variations:

Exchange metadata, checksum later.

Peel-back checksuming Reduces the network traffic but may increase the overall

synchronization latency.

Sending updates

Knowledge-Driven Log-Based ProtocolsEach device maintain knowledge about the set of

versions or operations that have been incorporated into its local replica.

A device’s knowledge is the set of unique identifiers for all operations that are stored in its local log.

Updation: operation and ID added to knowledge.More compact than Anti-Entropy protocol.A knowledge vector is a data structure containing a set

of <replica, accept-stamp> pairs.Efficient, robust, and flexible.

Sending updates

Knowledge-Driven State-Based ProtocolsMobile devices are not equipped to store or manage

any sort of operation log.Each item in a replica is stored with a unique version

number that is updated whenever the item is updated. Each entry in a device’s knowledge vector is a

<replica, version number> pair.Scenario:

Exchange knowledge exceptions along with knowledge vector.

But a knowledge exception indefinitely stay.

Ordering Updates

Schemes: Ordered DeliverySequencersUpdate TimestampsUpdate CountersVersion VectorsOperation Transformation

Other Ordering Issues

References

http://pooh.poly.asu.edu/Mobile/ClassNotes/Papers/ReplicatedData/ReplicatedDataManagementForMobileComputing.pdf

Thank You