Distributed Architectures. Distributed Databases. Distributed Databases. Distributed Databases

Transcription

1 Distributed Architectures Distributed Databases Simplest: client-server Distributed databases: two or more database servers connected to a network that can perform transactions independently and together Parallel databases: use of parallel machines as database servers 2 Distributed Databases Decentralized management of data Evolution of the centralized strategy used up to the 80 Advantages: Reflects the distributed nature of organizations Easier expandability Higher reliability (degradation of performances in case of a failure rather than service interruption) Distributed Databases Classes wrt DBMS software: Homogeneous: same DBMS software on all servers Heterogeneous: different DBMS software on the servers Classes wrt network: LAN WAN 3 4

2 Distributed Databases Applications Where is the Data? Homogeneous Heterogeneous LAN Finance and administration applications Administrative applications across functions WAN Booking systems and finance applications Integrated booking systems, interbank systems Data is split in fragments and distributed across the servers Given a table T Horizontal fragmentation: the fragments are subsets of tuples of T obtained from a selection on T Vertical fragmentation: the fragments are vertical portions of T obtained from a projection on T. They usually share the primary key 5 6 Horizontal Fragmentation Relation Employee(ENum,Name,DepNum,Sal) Horizontal fragmentation Employee1=σ ENum<=3 Employee Employee2=σ ENum>3 Employee Reconstruction Employee= Employee1 Employee2 Vertical Fragmentation Relation Employee(ENum,Name,DepNum,Sal) Horizontal fragmentation Employee1=π ENum,Name Employee Employee2=π ENum,DepNum,Sal Employee Reconstruction Employee= Employee1 Employee2 7 8

3 Allocation Schemes Fragments are distributed across servers according to an allocation scheme Types of allocation schemes: Non redundant: every fragment is allocated to only one server Redundant: a fragment can be replicated in more than one server Transparency Levels Levels of the transparency of query languages with respect to the fragmentation/allocation of data Fragmentation transparency: the user does not have to know that the DB is distributed and fragmented. The query she writes are the same as those she would write for a centralized server, e.g. SELECT * FROM Employee WHERE Sal> Allocation Transparency The user knows the structure of fragments but he does not know where they are allocated E.g. (horizontal fragmentation) SELECT * FROM Employee1 WHERE Sal>1000 UNION SELECT * FROM Employee2 WHERE Sal>1000 Language Transparency The user knows the structure of fragments and the server where they are allocated E.g. (horizontal fragmentation) SELECT * FROM Employee1@Server1 WHERE Sal>1000 UNION SELECT * FROM Employee2@Server2 WHERE Sal>

4 No Transparency The DB is heterogeneous and the user has to use a different SQL dialect for every server Distributed Query Optimization Cost-based approach; consider all plans, pick cheapest; similar to centralized optimization. Difference 1: Communication costs must be considered. Difference 2: Local site autonomy must be respected. Difference 3: New distributed join methods. Query site constructs global plan, with suggested local plans describing processing at each site. If a site can improve suggested local plan, free to do so Distributed Locking How do we manage locks for objects across many sites? Centralized: One site does all locking. Vulnerable to single site failure. Primary Copy: All locking for an object done at the primary copy site for this object. Reading requires access to locking site as well as site where the object is stored. Fully Distributed: Locking for a copy done at site where the copy is stored. Locks at all sites while writing an object. Distributed Deadlock Detection Each site maintains a local waits-for graph. A global deadlock might exist even if the local graphs contain no cycles: T1 T2 T1 T2 T1 T2 SITE A SITE B GLOBAL Three solutions: Centralized (send all local graphs to one site); Hierarchical (organize sites into a hierarchy and send local graphs to parent in the hierarchy); Timeout (abort transaction if it waits too long). 15

5 Distributed Recovery Two new issues: New kinds of failure, e.g., links and remote sites. If sub-transactions of a transaction execute at different sites, all or none must commit. Need a commit protocol to achieve this. A log is maintained at each site, as in a centralized DBMS, and commit protocol actions are additionally logged. Two-Phase Commit (2PC) Site at which the transaction originates is coordinator; other sites at which it executes are subordinates. When a transaction wants to commit: 1. Coordinator force-write prepare log record 2. Coordinator sends prepare msg to each subordinate. 3. Subordinate force-writes an abort or prepare log record and then sends a no or yes msg to coordinator. Two-Phase Commit (2PC) Two-Phase Commit (2PC) 4. If coordinator gets unanimous yes votes, force-writes a commit log record and sends commit msg to all subs. Else, force-writes abort log rec, and sends abort msg. 5. Subordinates force-write abort/commit log rec based on msg they get and then send ack msg to coordinator 6. Coordinator writes end log rec after getting all acks. coord prepare prepare yes/no global decision (abort/commit) abort/ commit ack end sub prepare local decision (abort/commit) 20

6 Comments on 2PC Two rounds of communication: first, voting; then, termination. Both initiated by coordinator. Any site can decide to abort an transaction. Every msg reflects a decision by the sender; to ensure that this decision survives failures, it is first recorded in the local log. All commit protocol log recs for a transaction contain Transactionid and Coordinatorid. The coordinator s abort/commit record also includes ids of all subordinates. Restart After a Failure of a Sub If we have a commit or abort log rec for transaction T after the last checkpoint, must redo/undo T. If we have a prepare log rec for transaction T, but not commit/abort, Repeatedly contact the coordinator to find status of T, then write commit/abort log rec; redo/undo T; and write end log rec. If we don t have even a prepare log rec for T, unilaterally abort and undo T. Restart After a Failure at the Coordinator If we have a commit or abort log rec for transaction T, but not an end rec, must redo/undo T. keep sending commit/abort msgs to subs until acks received. If we have a prepare log rec for transaction T, but not commit/abort, Write abort on the log and repeat the second phase or Repeat the first phase hoping that the subs are still in the prepare state and a commit can be reached Restart After a Failure at the Coordinator If we don t have even a prepare log rec for T, unilaterally abort and undo T.

7 Blocking If coordinator for transaction T fails, subordinates who have voted yes cannot decide whether to commit or abort T until coordinator recovers. T is blocked. Even if all subordinates know each other (extra overhead in prepare msg) they are blocked unless one of them voted no. Link and Remote Site Failures If a remote site does not respond during the commit protocol for transaction T, either because the site failed or the link failed: If the current site is the coordinator for T, should abort T. If the current site is a subordinate, and has not yet voted yes, it should abort T. If the current site is a subordinate and has voted yes, it is blocked until the coordinator responds. Observations on 2PC Ack msgs used to let coordinator know when it can forget a transaction; until it receives all acks, it must keep T in the transaction Table. If coordinator fails after sending prepare msgs but before writing commit/abort log recs, when it comes back up it aborts the transaction. If a subtransaction does no updates, its commit or abort status is irrelevant. Data Replication Data (entire tables or fragments) can be replicated on different servers The consistency among the different copies is ensured by a data replicator 28

8 Updating Distributed Data Synchronous Replication Synchronous Replication: All copies of a modified relation (fragment) must be updated before the modifying transaction commits. Data distribution is made transparent to users. Asynchronous Replication: Copies of a modified relation are only periodically updated; different copies may get out of synch in the meantime. Users must be aware of data distribution. Current products follow this approach. Voting: the transaction must write a majority of copies to modify an object; must read enough copies to be sure of seeing at least one most recent copy. E.g., 10 copies; 7 written for update; 4 copies read. Each copy has version number. Not attractive usually because reads are common. Read-any Write-all: Writes are slower and reads are faster, relative to Voting. Most common approach to synchronous replication. Choice of technique determines which locks to set. Cost of Synchronous Replication Before an update transaction can commit, it must obtain locks on all modified copies. Sends lock requests to remote sites, and while waiting for the response, holds on to other locks! If sites or links fail, transaction cannot commit until they are back up. Even if there is no failure, committing must follow an expensive commit protocol with many msgs. So the alternative of asynchronous replication is becoming widely used. Asynchronous Replication Allows the modifying transaction to commit before all copies have been changed (and readers nonetheless look at just one copy). Users must be aware of which copy they are reading, and that copies may be out-of-sync for short periods of time. Two approaches: Primary Site and Peer-to-Peer replication. Difference lies in how many copies are ``updatable or ``master copies.

9 Primary Site Replication Implementing the Capture Step Exactly one copy of a relation is designated the primary or master copy. Replicas at other sites cannot be directly updated. The primary copy is published. Other sites subscribe to (fragments of) this relation; these are secondary copies. Main issue: How are changes to the primary copy propagated to the secondary copies? Done in two steps. First, capture changes made by committed transactions; then apply these changes. Log-Based Capture: The log (kept for recovery) is used to generate a Change Data Table (CDT). If this is done when the log tail is written to disk, must somehow remove changes due to subsequently aborted transaction. Procedural Capture: A trigger does the capture; Log-Based Capture is better (cheaper, faster) but relies on proprietary log details. Peer-to to-peer Replication More than one of the copies of an object can be a master in this approach. Changes to a master copy must be propagated to other copies somehow. If two master copies are changed in a conflicting manner, this must be resolved. (e.g., Site 1: Joe s age changed to 35; Site 2: to 36) Best used when conflicts do not arise: E.g., Updating rights owned by one master at a time.