Replicate the database
Database replication is used on many database management systems (DBMS), usually with a master/slave relationship between the original and the copies. The master logs the updates, which then propagate to the slaves. The slave outputs a message that states that it received the update successfully, thus allowing the sending (and potentially resending until successfully applied) of subsequent updates.
Multi-master replication, where updates can be submitted to any database node and then propagate to other servers, often is wanted. It introduces substantially increased costs and complexity, which might make it impractical in some situations. The most common challenge in multi-master replication is transactional conflict prevention or resolution. Most synchronous or eager replication solutions prevent conflicts, while asynchronous solutions resolve conflicts.
For instance, if a record is changed on two nodes simultaneously, an eager replication system would detect the conflict before it confirms the commit and cancels one of the transactions. A lazy replication system would allow both transactions to commit and run a conflict resolution during resynchronization. The resolution of such a conflict can be based on a timestamp of the transaction, on the hierarchy of the origin nodes, or on much more complex logic, which decides consistently on all nodes.
- Horizontal scaling has more data replicas. A multi-layer multi-view access protocol can alleviate horizontal scaling issues.
- Vertical scaling has data replicas that are located further away in distance. The steady and continuous improvements in internet reliability and performance make vertical scaling less challenging.
