Docsity
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Replicated Server - E-Commerce - Lecture Slides, Slides of Fundamentals of E-Commerce

E-Commerce is taking over the traditional commerce practices. It is of special concern for the IT students. Following are the key points of these Lecture Slides : Replicated Server, Transaction Processing, Replication, M Ulti-M Aster Replication, Products, Copy Replication, Multiple Copies, Server, Data Sharing, Synchronous Replication

Typology: Slides

2012/2013

Uploaded on 07/30/2013

shoki_sho
shoki_sho 🇮🇳

4.9

(7)

121 documents

1 / 7

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
3/8/05 1
10. Replication
Transaction Pro cessing
3/8/05 2
Outline
1. Introduction
2. Primary-Copy Replication
3. Multi-Master Replication
4. Other A ppro aches
5. Products
3/8/05 3
1. Introduction
•Replication -using multiple co pies of a server
(called replicas) for better av ailability and
perform ance.
•If you’re not careful, rep lication can lead to
–worse performance - updates must be applied to all
rep licas and synchronized
–worse availab ility -som e algorithm s require multiple
rep licas to be operational for an y of them to be used
3/8/05 4
Replicated Server
•Can rep licate servers on a com m on resource
–Data sha ring -DB se rvers com m unicate with sha red disk
Resource
Server Replica 1 Server Replica 2
Client
•Helps availability in primary-backup scenario
• R equires rep lica cache coheren ce m echanism …
•Hence, this helps perform ance only if
–little conflict between transactions at different servers or
–loose co herence guaran tees (e.g. read committed )
3/8/05 5
Replicated R esource
•To get more improvem ent in availab ility,
replicate the resources (too)
•Also increa ses poten tial throughput
•This is what’s usually m eant by replication
•It’s the scen ario we’ll focus on
Resource replica
Server Replica 1 Server Replica 2
ClientClient
Resource replica
3/8/05 6
Synchronous Replication
•Replicas function just like non-rep licated servers
•Synchronous replication -tran saction updates all
replicas of ev ery item it updates
Start
Write(x1)
Write(x2)
Write(x3)
Commit
x1
x2
x3
•Issues
–Too exp ensive for most applications, due to heavy
distributed transaction load (2-phase commit)
–Can’t co ntrol when updates are applied to replicas
Docsity.com
pf3
pf4
pf5

Partial preview of the text

Download Replicated Server - E-Commerce - Lecture Slides and more Slides Fundamentals of E-Commerce in PDF only on Docsity!

3/8/ 05 1

10.Replication

Transaction Processing

3/8/ 05 2

O utline

1.Introduction

2.Prim ary-Copy Replication

3.M ulti-M asterReplication

4.O therA pproaches

5.Products

3/8/ 05 3

1.Introduction

  • Replication -using m ultiple copies ofa server

(called replicas)forbetteravailability and

perform ance.

  • Ifyou’re notcareful,replication can lead to
    • w orse perform ance -updates m ustbe applied to all

replicas and synchronized

  • w orse availability -som e algorithm s require m ultiple

replicas to be operationalforany ofthem to be used

3/8/ 05 4

Replicated Server

  • Can replicate servers on a com m on resource
    • D ata sharing -D B servers com m unicate w ith shared disk

Resource

Server Replica 1 Server Replica 2

Client

  • H elps availability in prim ary-backup scenario
  • Requires replica cache coherence m echanism …
  • H ence,this helps perform ance only if
    • little conflictbetw een transactions atdifferentservers or
    • loose coherence guarantees (e.g.read com m itted)

3/8/ 05 5

Replicated Resource

  • To getm ore im provem entin availability,

replicate the resources (too)

  • A lso increases potentialthroughput
  • This is w hat’s usually m eantby replication
  • It’s the scenario w e’llfocus on

Resource replica

Server Replica 1 Server Replica 2

Client Client

Resource replica

3/8/ 05 6

Synchronous Replication

  • Replicas function justlike non-replicated servers
  • Synchronous replication -transaction updates all

replicas ofevery item itupdates

Start Write(x1) Write(x2) Write(x3) Commit

x

x

x

  • Issues
    • Too expensive form ostapplications,due to heavy

distributed transaction load (2-phase com m it)

  • Can’tcontrolw hen updates are applied to replicas

2

3/8/ 05 7

Synchronous Replication -Issues

r 1 [xA ]

r 2 [yD ] w 2 [xB ]

yD fails w 1 [yC ]

xA fails

N otequivalentto a one-copy execution, even ifxA and yD neverrecover!

  • D BM S products supportitonly in specialsituations
  • Ifyou justuse transactions,availability suffers.
  • Forhigh-availability,the algorithm s are com plex and

expensive,because they require heavy-duty

synchronization offailures.

  • … offailures? H ow do you synchronize failures?

3/8/ 05 8

A tom icity & Isolation G oal

  • O ne-copy serializability (abbr.1SR)
    • An execution oftransactions on the replicated database has the sam e effectasan execution on a one-copy database.
    • Intuition:the execution is SR and in an equivalentserial execution,each transaction reads from the m ostrecent transaction thatw rote into any copy ofitsw riteset.
    • To check for1SR,firstcheck forSR (using SG),then see if there’s equivalentserialhistory w ith the above property
  • Previous exam ple w as not1SR.Itis equivalentto
    • r 1 [xA ]w 1 [yC ]r 2 [yD ]w 1 [xB ]and
    • r 2 [yD ]w 1 [xB ]r 1 [xA ]w 1 [yC ]
    • butin both cases,the second transaction does notread its inputfrom the previous transaction thatw rote thatinput.

3/8/ 05 9

A tom icity & Isolation (cont’d)

  • A lthough this is not1SR
    • r 1 [xA ]w 1 [yC ]r 2 [yD ]w 1 [xB ]

These are 1SR

  • r 1 [xA ]w 1 [yD ]r 2 [yD ]w 1 [xB ]
  • r 1 [xA ]w 1 [yC ]w 1 [yD ]r 2 [yD ]w 1 [xA ]w 1 [xB ]
  • The previous history is the one you w ould expect
  • Each transaction reads one copy ofits readsetand w rites into allcopies ofits w riteset
  • readset(resp.writeset)isthe setofdata item s (notcopies) thata transaction reads (resp.w rites).
  • Butitm ay notalw ays be feasible,because som e copies

m ay be unavailable.

3/8/ 05 10

A synchronous Replication

  • A synchronous replication
    • Each transaction updates one replica.
    • U pdates are propagated laterto otherreplicas.
  • Prim ary copy:A lltransactions update the sam e copy
  • M ulti-m aster:Transactions update differentcopies
    • U sefulfordisconnected operation,partitioned netw ork
  • Both approaches ensure that
    • U pdates propagate to allreplicas
    • Ifnew updates stop,replicas converge to the sam e state
  • Prim ary copy ensures serializability,and often 1SR
    • M ulti-m asterdoes not.… M ore later.

3/8/ 05 11

2.Prim ary-Copy Replication

  • D esignate one replica as the prim ary copy (publisher)
  • Transactions m ay update only the prim ary copy
  • U pdates to the prim ary are sentlaterto secondary replicas

(subscribers)in the orderthey w ere applied to the prim ary

T1: Start

… Write(x1) ...

Commit

T2 x

Tn

... Primary

Copy

x

xm

Secondaries

3/8/ 05 12

U pdate Propagation

  • Collectupdates atthe prim ary using triggers or

by post-processing the log

  • Triggers
    • O n every update atthe prim ary,a triggerfiresto store the update in the update propagation table.
  • Post-process (“sniff”)the log to generate update

propagations

  • Saves triggerand triggered update overhead during on-line txn.
  • ButR/W log synchronization has a (sm all)cost
  • Requiresadm in (w hatifthe log snifferfails?)
  • O ptionally identify updated fields to com press log
  • M ostD B system s supportthis today.

4

3/8/ 05 19

M ajority Consensus

  • W henevera setofcom m unicating replicas detects a

replica failure orrecovery,they testif they have a

m ajority (m ore than half)ofthe replicas.

  • Ifso,they can electa prim ary
  • O nly one setofreplicas can have a m ajority.
  • D oesn’tw ork w ith an even num berofcopies.
    • U seless w ith 2 copies
  • Q uorum consensus
    • Give a w eightto each replica
    • The replica setthathasa m ajority ofthe weightw ins
    • E.g.2 replicas,one has w eight1,the otherw eight

3/8/ 05 20

3.M ulti-M asterReplication

  • Som e system s m ustoperate w hen partitioned.
    • Requiresm any updatable copies,notjustone prim ary
    • Conflicting updates on differentcopiesare detected late
  • Classic exam ple -salesperson’s disconnected laptop Custom ertable (rarely updated) Orders table (insertm ostly) Custom erlog table (append only)
    • So conflicting updates from differentsalespeople are rare
  • U se prim ary-copy algorithm ,w ith m ultiple m asters
    • Each m asterexchanges updates (“gossips”)w ith otherreplicas w hen itreconnectsto the netw ork
    • Conflicting updates require reconciliation (i.e.m erging)
  • In Lotus N otes,A ccess,SQ L Server,O racle,…

3/8/ 05 21

Exam ple ofConflicting U pdates

A Classic Race Condition

Replica 1

Initially x=

T 1 : X=

Primary

Initially x=

Send (X=1)

Replica 2

Initially x=

T 2 : X=

Send (X=1)

X=

X=

X=

Send (X=2)

X=

Send (X=2)

  • Replicas end up in differentstates 3/8/ 05 22

Thom as’W rite Rule

  • To ensure replicas end up in the sam e state
    • Tag each data item w ith a tim estam p
    • A transaction updates the value and tim estam p ofdata item s (tim estam psm onotonically increase)
    • An update to a replica isapplied only ifthe update’s tim estam p is greaterthan the data item ’stim estam p
    • Y ou only need tim estam ps ofdata item sthatwere recently updated (w here an olderupdate could stillbe floating around the system )
  • A llm ulti-m asterproducts use som e variation ofthis
  • RobertThom as,ACM TO D S,June ’ 79
    • Sam e article thatinvented m ajority consensus

3/8/ 05 23

Thom as W rite Rule ⇒ Serializability

Replica 1

T 1 : read x=0 (TS=0)

T 1 : X=1, TS=

Primary

Initially x=0,TS=

Send (X=1, TS=1)

Replica 2

T 1 : read x=0 (TS=0)

T 2 : X=2, TS=

Send (X=1, TS=1)

X=1, TS=

X=2, TS=2 X=1,TS=

Send (X=2, TS=2)

  • Replicas end in the sam e state,butneitherT 1 norT 2 reads

the other’s output,so the execution isn’tserializable.

X=2, TS=

Send (X=2, TS=2)

3/8/ 05 24

M ulti-M asterPerform ance

  • The longera replica is disconnected and

perform ing updates,the m ore likely itw ill

need reconciliation

  • The am ountofpropagation activity increases

w ith m ore replicas

  • Ifeach replica is perform ing updates, the effectis quadratic

5

3/8/ 05 25

M icrosoftA ccess and SQ L Server

  • M ulti-m asterreplication w ithouta prim ary
  • Each row R ofa table has 4 additionalcolum ns
    • globally unique id (GU ID )
    • generation num ber,to determ ine w hich updates from other replicas have been applied
    • version num ber= the num berofupdates to R
    • array of[replica,version num ber]pairs,identifying the largest version num beritgotforR from every otherreplica
  • U ses Thom as’w rite rule,based on version num bers
    • Access uses replica id to break ties.SQ L Server7 uses subscriberpriority orcustom conflictresolution.

3/8/ 05 26

G eneration N um bers (A ccess/SQ L cont’d)

  • Each replica hasa currentgeneration num ber
  • A replica updates a row ’s generation num ber

w heneveritupdates the row

  • A replica know s the generation num berithad w hen it

lastexchanged updates w ith R´,forevery replica R´.

  • A replica increm ents its generation num berevery tim e

itexchanges updates w ith anotherreplica.

  • So,w hen exchanging updates w ith R¢,itshould send

allrow s w ith a generation num berlargerthan w hatit

had w hen itlastexchanged updates w ith R¢.

3/8/ 05 27

D uplicate U pdates (A ccess/SQ L cont’d)

  • Som e rejected updates are saved forlateranalysis
  • To identify duplicate updates to discard them
    • W hen applying an update to x,replace x’sarray of [replica,version#]pairs by the update’sarray.
    • To avoid processing the sam e update via m any paths, check version num berofarriving update againstthe array
  • Considera rejected update to x atR from R´,w here
    • [R´,V ]describes R´in x’sarray,and
    • V ´is the version num bersentby R´.
    • IfV ‡ V ´,then R saw R´’s updates
    • IfV < V ´,then R didn’tsee R´’s updates,so store itin the conflicttable forlaterreconciliation

3/8/ 05 28

4.O therA pproaches

  • N on-transactionalreplication using tim estam ped

updates and variations ofThom as’w rite rule

  • directory services are m anaged this w ay
  • Q uorum consensus per-transaction
  • Read and w rite a quorum ofcopies
  • Each data item hasa version num berand tim estam p
  • Each read chooses a replica w ith largestversion num ber
  • Each w rite increm ents version num berone greaterthan any one ithas seen
  • N o specialw ork needed during a failure orrecovery

3/8/ 05 29

O therA pproaches (cont’d)

  • Read-one replica,w rite-all-available replicas
    • Requirescarefulm anagem entoffailures and recoveries
  • E.g.,V irtualpartition algorithm
    • Each nodeknow s the nodes itcan com m unicate w ith, called its view
    • Transaction T can execute ifits hom e node hasa view including a quorum ofT’s readsetand w riteset
    • Ifa node fails orrecovers,run a view form ation protocol (m uch like an election protocol)
    • Foreach data item with a read quorum ,read the latest version and update the others w ith sm allerversion #.

3/8/ 05 30

Sum m ary

  • State-of-the-artproducts have rich functionality.
    • It’s a com plicated w orld forapp designers
    • Lots ofoptionsto choose from
  • M ostfailoverstories are w eak
    • Fine fordata w arehousing
    • For24·7 TP,need betterintegration w ith cluster node failover

7

3/8/ 05 37

IBM D B

  • V ery sim ilarfeature setto SQ L Serverand O racle
  • Filtered subscriber
    • Create snapshot,then update increm entally (push orpull)
  • M any table type options:
    • Read-only snapshotcopy,optionally w ith tim estam p
    • A ggregates,w ith cum ulative orincrem entalvalues
    • Consistentchange data,optionally w ith row versions
    • “Replica” tables,form ulti-m asterupdating
  • Interoperates w ith m any third party D BM S’s
  • Captures D B2 updates from the D B2 log
    • Forothersystem s,captures updates using triggers