• Database replication can be used in many DBMS
  • Usually with a master/slave relationship between the original (Master Database) and the copies (Slave Database)
  • Data-modifying commands like insert, delete, or update must be sent to the master database
  • Most applications require a much higher ratio of reads to writes; thus, the number of slave databases in a system is usually larger than the number of master databases

Master Database

  • Generally only supports write operations

Slave Database

  • Gets copies of the data from the Master Database and only supports read operations


Better Performance

High Fault Tolerance

High Availability

  • Website remains in operation even if a database is offline as you can access data stored in another database server
  • Thus, high Availability (可用性)

Potential Disaster Senario

What if one of the database down

Only one Slave Database is available and it goes offline

  • Read operations will be directed to the Master Database temporarily
  • A new slave database will replace the old one that goes offline

One of the many slave database goes offline

  • Read operations are redirected to other healthy slave databases
  • A new database server will replace the old one that goes offline

Master database goes offline

  • A slave database will be promoted to be the new master. All the database operations will be temporarily executed on the new master database
  • A new slave database will replace the old one for data replication immediately
  • In production systems, promoting a new master is more complicated as the data in a slave database might not be up to date. The missing data needs to be updated by running data recovery scripts. But we use algorithms like Raft Consensus Algorithm to handle the promotion process automatically