1 Replication Techniques مريم رضويان
2 منابع 1)M. Wiesmann, F. Pedone, A. Schiper B. Kemme, G. Alonso Understanding Replication in Databases and Distributed Systems This paper appeared in the Proceedings of 20th International Conference on Distributed Computing Systems (ICDCS'2000), April IEEE Computer Society Technical Committee on Distributed Processing. 2)Matthias Wiesmann Fernando Pedoney Andr´e Schiper,Bettina Kemmez Gustavo Alonsoz Database Replication Techniques: a Three Parameter Classification 2002 Proceedings of 19th IEEE Symposium on Reliable Distributed SystemsDatabase Replication Techniques: a Three Parameter Classification
3 منابع 3) F. Pedone, R. Guerraoui, and A. Schiper. Exploiting atomic broadcast in replicated databases. In Proceedings of EuroPar (EuroPar ’ 98), Sept 4)B. Kemme and G. Alonso. A suite of database replicationprotocols based on group communication primitives. In Proceedings of the 18th International Conference on Distributed Computing Systems (ICDCS), Amsterdam, The Netherlands, May
4 Replication در دو حوزه مختلف مطرح است Distributed DataBase Distributed System Replication در سيستمهاي توزيع شده هدف اصلي از Replication Fault tolerance Failure بايد از ديد کاربر و application پنهان باشد
5 Group Communication مجموعه اي از قراردادها و ابزارهاي سطح بالا براي برقراري ارتباط و ساخت سرويسهاي Replicate شده ايده اصلي : همه Replica ها بعنوان يک موجوديت تلقي شوند Agreement Properties Ordering Properties اهداف Fault Tolerance Consistency
6 Distributed Databases Distributed Database هدف : performance لزومي به پنهان سازي Failure نيست هنگام crash تراکنش rollback مي شود
7 Report Objective and Approach انگيزه مقايسه تکنيکهاي Replication در دو حوزه استفاده از ايده هاي مطرح در Distributed Sys. ها High Level Abstraction Group Communication هدف Group Communication-based replication in Data Base رويکرد Classification of replication Techniques Distributed Database Distributed System
8 Overall View
9 Distributed System سازگاري در Distributed System ضمانت تحويل پيغامها با ترتيب خاص لايه مجازي Group communication هدف اصلي از Replication Fault tolerance Failure بايد از ديد کاربر و application پنهان باشد
10 Replication protocol in Distributed Sys شامل 5 فاز مي باشد Request Server Coordination Execution Agreement Coordination Client Response
11 Replication protocols in Distributed Sys Request يک client عملياتي بر روي يک يا چند replica را در خواست مي کند دو رويکرد client به تمامي replica ها درخواست مي فرستد client به يک replica درخواست ميفرستد ودر ادامه replica در فاز server coordination عمليات را به ديگر replica ها ارسال ميکند مورد استفاده در Database ها توزيع داده ها بايد از ديد کاربر transparent باشد Active Replication vs. Passive Replication
12 Replication protocol in Distributed Sys Server Coordination Phase سرورها با هم براي ترتيب انجام عمليات همروند هماهنگ سازي ميکنند Execution phase تراکنش اجرا ميشود Agreement Coordination replica ها با هم توافق که همگي آنها يک کار را انجام داده اند Client Response Phase لحظه اي که Client پاسخ را از طرف سيستم دريافت ميکند
13 Replication protocol in Distributed Sys Eager Replication No response until everything has been done Lazy Replication Immediate response
14 Client A Client B Replica 1 Replica 2 Replica 3 Update Client A Phase 1: Request Phase 2: Coordination Phase 3: Execution Phase 4: Agreement Phase 5: Response Client B
15 Abstraction in Replication Group Communication فراهم کننده ارتباط يک به چند پنهان سازي پيچيدگيهاي حفظ سازگاري Atomic Broadcast (ABCAST) View Synchronous Broadcast (VSCAST)
16 Atomic Broadcast ABCAST Provides Atomicity اگر عضوي از گروه پيغام m را دريافت کند بقيه اعضا نيز آنرا دريافت خواهند کرد Total order اگر يکي از اعضاي گروه دو پيغام m و n را به ترتيب خاصي در يافت کند هر عضو ديگر نيز اين دو پيغام را به همين ترتيب دريافت ميکند
17 View Synchronous Broadcast بر اساس مفهوم دنباله اي از view ها است که state گروه را مشخص مي کند V 0,V 1,V 2, …,V n g) ) :Vi اعضاي فعال گروه در يک لحظه خاص هنگامي که فرآيندي بخواهد به گروه اضافه ويا اينکه آن فرآيند crash کند View جديد Vi+1 تعريف و Install مي شود. VSCAST تضمين ميکند اگر فرآيند p ( در Vi ) پيغام m را قبل از Install کردن Vi+1 بفرستد هيچ فرآيند ديگري قبل از دريافت m نمي تواند Vi+1 را Install بکند
18 Active Replication client توسط ABCAST درخواست رابه Server ها مي فرستد. Server Coordination توسط خصوصيت Total Order ، ABCAST اعمال مي شود.
19 Active Replication تمامي replica ها به ترتيبي که در خواستها را دريافت ميکنند آنها را اجرا ميکند. تمامي replica ها پاسخ را به client بر مي گردانند Same input + same order => same output Clients address servers as a group سرورها Input را به ترتيب يکسان دريافت ميکنند
20 Passive Replication يکي از Replica ها به عنوان primary است و بقيه backup هستند client در خواست را به primary مي فرستد. هيچ initial coordination لازم نيست. Primary در خواست را اجرا مي کند Primary از طريق فرستادن پيغامهاي update ، coordinate مي کند. Primary پاسخ را به client مي فرستد.
21 Replication in Database هدف از Replication درپايگاه داده توزيع شده. کارايي کاهش زمان پاسخ به query Replication Model در پايگاه داده ها Client ها از طريق تراکنشها به داده ها دسترسي دارند دو عمليات از دو تراکنش وقتي با هم conflict دارند که به يک داده دسترسي داشته باشند ويکي از آنها write باشد :Isolation از طريق اعمال مکانيزمهاي concurrency control مثل locking protocol
22 Replicated Databases One Logical Database N logical replicas Network connects Replicas Clients connect to the logical Database. Replicas processes transactions (ACID properties)
23 استراتژي هاي Replication رده بندي انواع Replication. زماني که update propagation رخ مي دهد eager vs. Lazy وسايتي که update را انجام مي دهد primary vs. every where eager replication update ها در يک تراکنش اعمال مي شود تمام replica ها به روز رسانيده مي شوند بعد تراکنش commit ميشود سازگاري داده ها حفظ مي شود Overhead تبادل پيغام بالا است زمان پاسخ هم بالا است
24 استراتژي هاي Replication Lazy Replication يک کپي محلي به روز رسانيده مي شود و پس از commit تراکنش update ها پخش مي شود کارايي بالاتر در برخي مواقع ناسازگاري داده داريم Primary copy ابتدا نسخه primay به روز رسانيده مي شود سپس بقيه نسخه ها replication control ساده تر Single point of failure Bottleneck
25 استراتژي هاي Replication update every where هر کپي ممکن است ابتدا به روز رسانيده شود مسئله هماهنگي مشکل تر Eager Primary Copy Lazy Primary Copy Eager Update Everywhere Lazy Update Everywhere Update Propagation Update Location
26 Eager primary copy replication update ابتدا در primary master اتفاق مي افتد پس از آن update در بقيه سايتها اجرا مي شود وقتي primary copy تائيد سايتهاي ديگر را گرفت commit مي کند
27 Eager primary copy replication فاز SC را نداريم Eager Primary Copy Replication مشابه Passive Replication Eager Primary copy 2pc Passive Replication VSCAST
28 Eager Update everywhere replication دو پروتکل متفاوت براي جلوگيري از conflict وجود دارد distributed locking Atomic broadcast Distributed locking approach
29 Distributed locking approach Client درخواست را به يکي از سايتها مي فرستد SC: درخواست lock به بقيه سايتها فرستاده ميشود در صورت اختصاص يافتن lock در همه update انجام مي پذيرد اجراي 2PC
30 Data Replication based on Atomic broadcast ايده اصلي : استفاده از total order با استفاده از ABCAST براي هماهنگي تراکنش ها توسط مدير تراکنش. فاز SC به جاي 2PC توسط total order از ABCAST تامين مي شود دو عمل متداخل به ترتيب ABCAST در تمامي سايتها اجرا مي شوند
31 Data Replication based on Atomic broadcast client در خواست را به server محلي مي فرستد server درخواست را به ديگر server ها از طريق ABCAST مي فرستد server ها تراکنش را اجرا مي کنند فاز 4 در واقع موجود نيست. server محلي در خواست را به client مي فرستد
32 Eager Update everywhere Active Replication
33
34 Lazy Replication Overhead پايين تر SC پس از پاسخ به client رخ مي دهد Reconciliation :update برنده را مشخص مي کند
35 Conclusion تمامي تکنيکهايي که بر سازگاري تاکيد دارند قبل از پايان يک مر حله SC و يا AC primary copy و passive replication SC ندارند Update Everywhere SC دارد
36 Another Classification for eager replication پارامترهای دسته بندی Server Architecture Primary-copy Update everywhere Server Coordination Constant Interaction Linear Interaction Transaction Termination Voting termination Non-voting termination
37 Update Everywhere – Constant Interaction – Non-Voting Techniques The transaction starts on the delegate server. The transaction is processed in a non-deterministic way. The point of determinism is reached. The transaction is sent to all servers using an atomic commitment. Processing continues on all replicas in a deterministic way. Each replica terminates the transaction in the same way.
38 Update Everywhere – Constant Interaction – Voting Techniques 1. The transaction starts on the delegate server. 2. The transaction is processed in a non-deterministic way. 3. The transaction is broadcast to all servers. 4. Processing continues on all replicas. 5. A voting termination phase takes place. 6. Each replica terminates the transaction according to the outcome of the voting protocol.
39 Recovery and Fault-Tolerance Issues 1-safe: when the client receives the notification of t ’ s commit, t has been committed on the delegate or the primary server of t. 2-safe: when the client receives the notification of t ’ s commit, t is guaranteed to eventually commit on all servers. Group-safe :when the client receives the notification of t ’ s commit, t is guaranteed to eventually commit on group of servers.
40 Future Work ارتباطات درون لايه اي تحليل ارتباطات بين Application و لايه Group Communication يکسان سازي (Unification) سرويسهاي پايه اي (Primitives) ارتباطات گروهي تسهيل طراحي سرويس هاي جديد ارائه ديد شفافتر از Interface لايه هاي Application و Group Communication استفاده از سرويسهاي Messaging براي تبادل پيغامها Group-Safe Replication مطرح در حوزه Fault-Tolerance از دست رفتن تراکنش در صورت از کار افتادن (Crash) گروه معمولاً با از کار افتادن f تا از سرورها (0<f<n)
41 تکنيکهاي ترکيبي Replication بسياري از تکنيکهاي ذکر شده پياده سازي نشده اند استفاده از Total Order Broadcast براي جلوگيري از بن بست (Dead Lock) استفاده از فاز Agreement Control يا Voting براي تضمين Atomicity مزاياي تکنيکهاي ترکيبي به حد اقل رساندن ارتباطات شبکه اي و بن بستها ( با Total Broadcast) عدم نياز به Determinism Replica ها ميتوانند بصورت غير Deterministic عمل کرده و تراکنشها را Abort کنند و Atomicity تضمين ميکند تمام آنها در نهايت در يک State خواهند بود طراحي و Specification پروتکلي براساس ترکيبي از اين دو تکنيک Future Work
42 Requirements Develop and apply appropriate techniques in order to avoid current limitations of eager update everywhere approaches Keep flexibility of update everywhere no restrictions on type of transactions and where to execute them Consistency and fault-tolerance of eager replication Good Performance response time + throughput Straightforward, Implementable Solution Easy integration in existing systems
43 Response time and message overhead Goal: Reduce number of messages per transaction reduce response time reduce message overhead Solution local execution of transaction bundle writes and send them in a single message at the end of the transaction (as done in lazy schemes)
44 Group Communication Services Group Communication: Multicast Delivery order (FIFO, causal, total, etc.) Reliable delivery: on all nodes vs. on all available nodes Membership control ISIS, Totem, Transis, Phoenix, Horus, Ensemble,... Goal: Exploit rich semantics of group communication on a low level of the software hierarchy
45 Lock Manager One possible Solution: Given a transaction T Local Phase: T acquires standard local read and write locks Send Phase: Send write set using total order multicast Upon reception of write set of T on local node Commit Phase: multicast commit message Upon reception of write set of T on remote node l Lock Phase: request all write locks in a single step; if there is a local transaction T ’ with conflicting lock and T ’ is still in local phase or send phase, abort T ’. If T ’ in send phase, multicast abort Write Phase: apply updates of T Upon reception of commit/abort message of T on remote node, terminate T accordingly For two transactions of same node: 2 phase locking. For concurrent transactions of different nodes: optimistic scheme with early conflict detection: when write set of one transaction is delivered the conflict is detected. Adjustment to other concurrency control schemes possible
46 Message Delivery Guranatees Uniform-Reliable Delivery If a site delivers a message, all non-faulty sites deliver the message Correctness on all sites (faulty or non-faulty): when a transaction commits at any site then it commits at all non-faulty sites High message delay Reliable Delivery If a non-faulty site (non-faulty for a sufficiently long time) delivers a message it is delivered at all non-faulty sites. Correctness in the failure-free case In case of failures: all non-faulty sites commit the same set of transactions a transaction might be committed at a faulty site (shortly before failure) and it is not committed at the other sites. Low message delay