[DB] Distributed Database - ③

0. 개요

1. Synchronous Replication

동기식 복제

• Voting

• Read-any Write-all

  1) Voting

  : writes to majority of copies (update) & read enough copies
  e.g. 10개의 copies중 7개에 update를 수행 => 4개 site를 read하여 업데이트 된 data를 read

  2) Read-any Write-all

  : 동일한 데이터가 저장된 모든 site에 update를 수행 => 1개의 site를 read하여 업데이트 된 data를 read
  e.g. 10개의 copies를 모두 즉시 update => 1개의 site를 read하여 업데이트 된 data를 read

• Voting & Read-andy Write-all 방식 모두 여러 site에서의 update(Write)연산을 수행하므로 Xact를 위해서 lock을 걸어야 함.

• 여러가지 이유로 Asynchronous Replication is widely used!

2. Asynchronous Replication

비동기식 복제

• Primary Site : 1개의 master copy

• Peer-to-Peer : 여러 개의 master copy

  1) Primary Site

  : 1개의 master copy만 변경, 변경 후 공개하여 다른 site들에 복제

• secondary copies들은 master(primary) copy를 subscrite하여, master copy의 업데이트 사항을 읽어와(capture) 반영(apply)

• secondary copies의 업데이트는 즉시 일어나지 않을 수 있음

  • capture : 변경 내용을 확인 (log record를 통해)
  • apply : master를 제외한 나머지 site에서 capture를 보고 변경 사항 적용

  2) Peer-to-Peer

  : 여러 개의 master copy 존재

  • master copies에 변화가 생기면 다른 copy들로 propagate
  • 이때 둘 이상의 master copy가 충돌한다면 해결해야한다.
    e.g. 서울site Joe's age value : 35
    부산site Joe's age value : 36

3. Distibuted Locking

• Centralized : 하나의 master site에서만 locking
• primary copy : object가 만들어진 site에서 locking
• Fully Dsitributed : copy가 저장된 site에서 locking

1) Deadlock Detection

: single site에서와 distributed에서 다름

• 각 site 별로 local waits-for graph가 존재
  => 취합하면(global)에서 deadlock 발생 가능
• 즉 하나의 site만으로 판단X,

1. Centralized : 하나로 합쳐
2. Hierarchical :
3. Timeout: 어느정도 기다렸더니 timeout발생하면 deadlock발생했다고 판단

4. Distributed Recovery ★

• new issues?

  • failures (e.g. link network failure)

• commit protocl ★ => recovery 수행

1) 2PC ( 2 Phase Commit)

• coordinator : 트랜잭션이 시작하는 site (1개)
• subordinate : 그 트랜잭션이 수정하는 data를 가지고 있는 site (여럿)

coor->sub : prepare msg
sub->coor : send yes if sub writes prepare log to record else no

① Coordinator sends prepare msg to subordinate
② Subordinate sends no / yes
③ if 'yes' => Coordinator commit log record & send "commit msg" to subs
if 'no' => Coordinator force-writes abort log rec & send "abort msg"
④ Subordinates force-write "commit/abort" log rec (yes/no)
⑤ Subordinates send "ack msg" to coordinator (done!)
⑥ Coordinator writes end log after getting all acks

Sum. 트랜잭션을 주도하는 사이트(C)에서 트랜잭션에 영향을 받는 사이트(S)에 준비 메시지를 보낸다(1)
준비가 되었다면 commit log를 작성하고 commit msg를 S에 보내거나 (2)-1
준비가 안되었다면 abort log를 작성하고 abort msg를 S에 보냄 (2)-2
S는 commit or abort log를 작성 -(3)
모든 S가 트랜잭션의 변경을 적용하였다면 ack msg를 보냄 -(4)
모든 S가 ack msg를 보냈다면, 모든 Subordinates가 트랜잭션의 변경 사항을 적용하였으므로 Coordinator는 "end log"를 작성 =(5)

즉, site별로 commit/abort가 가능