⛓ No Single Read Replica Alone ⛓

# [ $davids.sh ] · message #234

• @ [ $davids.sh ] · # 1370

  The discussion will primarily be about master-slave replication.

  Its main tasks are (1) to be able to recover from a failure, and (2) to offload read operations from the primary database.

  Topology refers to the connections between these master-slave database nodes (imagine a graph/tree, that will be the topology).

  Replication, on average, has 2 levels of reliability: async and sync.

  The problem with sync is that the database will delay transaction confirmation until the replica confirms it. The problem with async is that if the master fails, some transactions will be missing from the replica, but there is no delay in transaction confirmation.

  The "average" topology is when you have 1 master and 2 slaves on async replication in different data centers.

  So, in practice, we can create a topology where the first 1-2 nodes are in sync but are located close to the master database (within at least one data center), and then 1-n nodes are in async.

  On one hand, we have reliable sync replication with minimal latency because the replicas are as close as possible to the master. On the other hand, we have async replicas that can be placed quite far away for reliability, but the data in them will only be needed for non-real-time reads.

  I can't say I recommend this to everyone immediately; rather, it's a possibility to keep in mind.

  Video on the topic

• @ Ivan ITK 🚫 · # 1372

  It's right here that CockroachDB announced an interesting new data replication system, MOLT Live Migration Service.

• @ [ $davids.sh ] · # 1373

  Tool for migrating from old systems to CDB... Wow, the guys really understand what the business needs