--- title: "Replication objectives; primary-backup" subject: "Distributed System" chapter: 7 key: "semester_7/distributed_system:replication-objectives-primary-backup" source: https://www.bctengineer.com/q/semester_7/distributed_system/replication-objectives-primary-backup site: BCT Engineering --- # Replication objectives; primary-backup Distributed System · Chapter 7: Replication - Asked in: 2070 Chaitra, 3+5 marks - Video: [Database Replication Explained (in 5 Minutes)](https://www.youtube.com/watch?v=bI8Ry6GhMSE) — Aced (formerly Exponent) - Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_7/distributed_system/replication-objectives-primary-backup - Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-7 ## Question What are the major objectives for replication in distributed system? Explain primary backup model for fault tolerance. ## Short answer Major objectives of replication are enhancing performance, increasing availability, fault tolerance, scalability, and transparency. In the primary-backup model, one replica manager acts as primary, processing all client requests and sending state updates to backups; after acknowledgements, it replies. If the primary fails, a backup is elected and clients redirected. It tolerates f crash failures with f+1 replicas and provides linearizability. ## Answer #### Major objectives of replication 1. **Enhancing performance**: replicas near clients and sharing the request load reduce response time and server load (caching, mirroring). 2. **Increasing availability**: the service remains available when some servers fail or are unreachable. 3. **Fault tolerance**: correct service despite crash (or Byzantine) failures; data survive failures. 4. **Scalability**: more users and more data can be supported by adding replicas. 5. **Transparency**: replicas appear to the user as a single logical copy of an object (replication transparency), and keep **consistency** between copies. #### Primary-backup (passive) replication model There is one **primary** replica manager (RM) and one or more **backup** (slave) RMs. Front ends communicate only with the primary. ```text Client -> Front End -> Primary RM --updates--> Backup RM 1 | \-> Backup RM 2 <------ reply ----+ (acks from backups) ``` Sequence of events: 1. **Request**: the front end sends the request, with a unique id, to the primary. 2. **Coordination**: the primary checks the id to avoid executing it twice, and orders requests (so it gives a total order). 3. **Execution**: the primary executes the request and stores the response. 4. **Agreement**: if it is an update, the primary sends the new state and the response to all backups, which acknowledge. 5. **Response**: the primary replies to the front end after the acknowledgements. **On primary failure**: backups detect it (heartbeat/timeout), elect or promote one backup as the new primary (e.g. bully election), the front end is redirected, and the new primary continues from the last state. A request in progress is re-sent by the front end, and the id prevents double execution. Properties: tolerates f crash failures with f+1 replicas, cannot tolerate Byzantine faults, gives linearizability if the primary is correct, and has a short failover delay. Examples: replicated databases, Sun NIS (Yellow Pages), ISIS. ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. What does replication transparency mean? A. Replicas are visible to the user as separate objects B. Replicas appear to the user as a single logical copy of an object C. Only the administrator can see replicas D. Replicas never need to be updated Answer: B. The user should see one logical object even though several copies exist, and copies must be kept consistent. (Key point: Replication transparency) 2. In the primary-backup model, when does the primary reply to the front end for an update? A. Before executing the request B. Immediately after receiving it, without telling backups C. After sending the new state to the backups and receiving their acknowledgements D. Only after the backups have elected a new primary Answer: C. The primary executes, sends the new state and response to backups, waits for acknowledgements, and then replies. (Key point: Primary-backup request flow) 3. Why does each request carry a unique identifier in primary-backup replication? A. To encrypt the request B. To choose which backup receives it C. To prevent the same request being executed twice, e.g. when re-sent after a primary failure D. To measure network delay Answer: C. If the primary fails mid-request, the front end re-sends it; the id lets the new primary avoid double execution. (Key point: Duplicate prevention) 4. Which statement about the primary-backup model is correct? A. It tolerates f crash failures with f+1 replicas but not Byzantine faults B. It tolerates Byzantine faults with f+1 replicas C. Front ends send requests to all replicas D. Failover is instantaneous with no delay Answer: A. Backups only copy the primary's state, so crash failures are tolerated with f+1 replicas, while arbitrary faults cannot be masked; failover has a short delay. (Key point: Failure handling and limits) ## Related in Distributed System - [Fault; primary-backup vs active](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Afault-primary-backup-active) — Distributed System, chapter 7 - [Replication, fault tolerance, scalability](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Areplication-scalability-ft) — Distributed System, chapter 7 - [Fault tolerance and types of faults](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Afault-types) — Distributed System, chapter 9 - [Fault tolerance techniques](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Afault-tolerance-techniques) — Distributed System, chapter 9 - [Reasons for replication; fault tolerant services](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Areplication-reasons-ft-services) — Distributed System, chapter 7 - [Fault tolerance; Byzantine failure](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Abyzantine-failure-agreement) — Distributed System, chapter 9 ## Related in other subjects - [Availability and fault tolerance in GFS](https://www.bctengineer.com/question.md?key=semester_8%2Fbig_data_technologies%3Agfs-availability-fault-tolerance) — Big Data Technologies, chapter 2 - [Fault tolerance and redundancy for reliability](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Afault-tolerance-schemes) — Instrumentation II, chapter 7, asked 4× - [Software fault tolerance and recovery](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Asw-fault-tolerance-rollback) — Instrumentation II, chapter 9, asked 2× - [Primary and backup protection](https://www.bctengineer.com/question.md?key=semester_6%2Fswitchgear_and_protection%3Aprimary-and-backup-protection) — Switchgear and Protection, chapter 1, asked 3×