Skip to main content

Database Replications

Sync vs Async replication

  • sync ensures strong consistency, but slower writes
  • async ensures fastest writes, but result in eventual consistency or even data lost in case of failure

Single Leader Replication

  • problems with failover

    • some writes from previous leader have not been propagated to replicas, data are lost
    • accidental failovers due to network, puts more burden on the network
    • if old leader comes back up, need to ensure it doesn't think it's still the leader

  • Eventual Consistency - Reading your own writes

    • after write, read from another partition, no data there, how to solve it? Read from the same partition (for some short period of time)

  • Eventual Consistency - Monotonic Rreads

    • read the same query but have different results. fix? Partition the user by id to make sure each user don't read from different replicas

  • Eventual Consistency - Prefix Reads

    • prefix context didn't not sync, doesn't see the question, only see the response
    • fix: put relavant data together, each user read relavant data from the same shard (like all user in a chat group all read from shard a because chat group a is sharded to it)

  • Replication Log Implementation Options

    • Use logical log

  • Pros:

    • single write point

  • Cons:

    • limited write throughput, can use shard

Multi-Leader Replication

  • Circular topology, star topology are both weak

  • all-to-all topology may have prefix reads problem

  • Solutions to write conflicts

    • Conflict Avoidance
      • partition data
    • Last write wins (Cassandra)
      • but timestamp can be different..
      • Clock Skewer
    • On read
      • If multiple writes, ask reader which one to pick
    • On write
      • The application merges the writes
    • Detecting concurrent writes
      • Version Vectors (git)

  • Pros:

    • multiple leader in multiple different regions
    • higher write throughput

  • Cons:

    • write conflits between leaders

Leaderless Replication

  • Read from many replica and write to many replica

  • How to keep the data up to date?

    • Anti-Entropy
      • Background process looks at multiple nodes and their store values, use version numbers to decide the latest value
    • Read Repair
      • Read from multiple replicas and pick the newest data (use versioning), and sync outdated versions
    • Quorum:
      • Read successful if at least r nodes are read from
      • Write successful if at least w nodes are written to
      • if r + w > n, then at least one node will have the most updated data
    • Quorums are not perfect
      • Write Conflict: different write data with the same version, use conflict resolution mechanism
      • Sloppy Quorums:

  • Pros:

    • can work quite well in practice with a cross datacenter solution by having the quorum write parameter be small enough that all writes can go to one datacenter

  • Cons:

    • slower reads as a result of multiple queires to nodes
    • still have to reason about write conflicts
    • Quorums are not perfect, provide illusion of strong consistency when in reality this is often not true

123

Back to top