Sample questions
Replication ScalingDifficulty 1
In a database context, what does replication mean?
- aSplitting one large table into smaller pieces stored on separate servers
- bKeeping copies of the same data on more than one database server✓
- cCompressing old data so the database uses less disk space over time
- dCaching frequently read rows in application memory to speed up reads
Explanation:Replication means maintaining synchronized copies of the same data across multiple servers; it enables high availability (HA), read scaling, and backup/DR. Option (a) describes sharding, (c) describes archiving/compression, and (d) describes application caching.
Replication ScalingDifficulty 1
Which of the following is a common reason to set up database replication?
- aTo enforce foreign key constraints between two unrelated tables
- bTo automatically normalize the schema into higher normal forms
- cTo reduce the number of indexes the database has to maintain
- dTo keep a standby copy that can take over if the primary server fails✓
Explanation:Replication is typically set up for high availability (a standby that can be promoted), read scaling, and backup/DR. Option (d) is the HA reason. The others are unrelated concerns that replication does not address.
Replication ScalingDifficulty 1
In a classic primary–replica (also called master–slave) setup, where are write operations (INSERT/UPDATE/DELETE) normally sent?
- aTo the primary; the changes are then propagated out to the replicas✓
- bTo any replica, whichever one currently has the lowest load
- cTo all of the servers at the same time, directly by the application
- dTo a replica first, which then forwards the change to the primary
Explanation:Writes go to the single primary, which replicates the changes out to its replicas. Replicas are read-only copies and do not accept writes from the application.
Replication ScalingDifficulty 2
A service is configured to send its read queries to a read replica. A developer accidentally points an UPDATE statement at that same read-replica connection. What happens?
- aThe update succeeds on the replica and is later copied back to the primary
- bThe update succeeds on the replica but is silently ignored by the primary
- cThe write is rejected, because a read replica is read-only✓
- dThe update runs, then the replica automatically becomes the new primary
Explanation:A read replica is read-only; write attempts against it are rejected. Writes must go to the primary, and replication flows in one direction only (primary → replica), never back the other way.
Replication ScalingDifficulty 2
What is the main trade-off between synchronous and asynchronous replication?
- aSynchronous is faster for writes but can lose recent data, whereas asynchronous is slower yet is guaranteed to never lose any committed data
- bSynchronous confirms a write only after a replica has it, adding latency; asynchronous confirms immediately but can lose recent writes✓
- cSynchronous replicates only read queries, while asynchronous replicates only the write queries
- dSynchronous requires exactly one replica, while asynchronous always requires at least three replicas
Explanation:Synchronous replication waits for a replica to acknowledge the write: stronger durability, but higher latency. Asynchronous acknowledges locally first: lower latency, but writes not yet shipped can be lost on failover. Option (a) reverses the relationship.
Replication ScalingDifficulty 3
A system uses asynchronous replication. The primary crashes hard, and a replica is promoted to primary. Users report that a few transactions committed just before the crash are now missing. Why is this possible?
- aThe primary acknowledges commits before the replica receives them, so the newest transactions may never have reached the promoted replica✓
- bPromoting a replica always discards the most recent minute of transactions on purpose, by design
- cAsynchronous replication copies only schema (DDL) changes and never copies the actual row data
- dThe application cached those writes locally and never actually sent them to the database, so they were dropped before ever reaching the primary at all
Explanation:With async replication the primary commits and acknowledges locally before the replica has received the change. On a hard failover, any writes not yet shipped to the promoted replica are lost. Synchronous replication would prevent this, at the cost of write latency.