Designing Data-Intensive Applications – Multi-Leader Replication

Coding Blocks

We continue our discussion of Designing Data-Intensive Applications, this time focusing on multi-leader replication, while Joe is seriously tired, and Allen is on to Michael’s shenanigans.

For anyone reading this via their podcast player, this episode’s show notes can be at https://www.codingblocks.net/episode161, where you can join the conversation.

Sponsors

• Educative.io – Learn in-demand tech skills with hands-on courses using live developer environments. Visit educative.io/codingblocks to get an additional 10% off an Educative Unlimited annual subscription.

Survey Says How do you put on your shoes? Take the survey at: https://www.codingblocks.net/episode161. News

• Thank you very much for the new reviews:
  • iTunes: GubleReid, tbednarick, JJHinAsia, katie_crossing
  • Audible: Anonymous User, Anonymous User … hmm

When One Leader Just Won’t Do Talking about Multi-Leader Replication Replication Recap and Latency

• When you’re talking about single or multi-leader replication, remember all writes go through leaders
• If your application is read heavy, then you can add followers to increase your scalability
• That doesn’t work well with sync writes..the more followers, the higher the latency
  • The more nodes the more likely there will be a problem with one or more
  • The upside is that your data is consistent
• The problem is if you allow async writes, then your data can be stale. Potentially very stale (it does dial up the availability and perhaps performance)
• You have to design your app knowing that followers will eventually catch up – “eventual consistency“
  • “Eventual” is purposely vague – could be a few seconds, could be an hour. There is no guarantee.
• Some common use cases make this particularly bad, like a user updating some information…they often expect to see that change afterwards
• There are a couple techniques that can help with this problem

Techniques for mitigation replication lag

• Read You Writes Consistency refers to an attempt to read significant data from leader or in sync replicas by the user that submitted the data
• In general this ensures that the user who wrote the data will get the same data back – other users may get stale version of the data
• But how can you do that?
  • Read important data from a leader if a change has been made OR if the data is known to only be changeable by that particular user (user profile)
  • Read from a leader/In Sync Replica for some period of time after a change
  • Client can keep a timestamp of it’s most recent write, then only allow reads from a replica that has that timestamp (logical clocks keep problems with clock synchronization at bay here)
• But…what if the user is using multiple devices?
  • Centralize MetaData (1 leader to read from for everything)
  • You make sure to route all devices for a user the same way
    • Monotonic Reads: a guarantee of sorts that ensures you won’t see data moving backwards in time. One way to do this – keep a timestamp of the most recent read data, discard any reads older than that…you may get errors, but you won’t see data older than you’ve already seen.
    • Another possibility – ensure that the reads are always coming from the same replica
  • Consistent Prefix Reads: Think about causal data…an order is placed, and then the order is shipped…but what if we had writes going to more than one spot and you query the order is shipped..but nothing was placed? (We didn’t have this problem with a Single Replica)
    • We’ll talk more about this problem in a future episode, but the short answer is to make sure that causal data gets sent to the same “partition”

Replication isn’t as easy as it sounds, is it?

Multi-Leader Rep…lication

Single leader replication had some problems. There was a single point of failure for writes, and it could take time to figure out the new leader. Should the old leader come back then…we have a problem. Multi-Leader replication…

• Allows more than one node to receive writes
• Most things behave just like single-leader replication
• Each leader acts as followers to other leaders

When to use Multi-Leader Replication

• Many database systems that support single-leader replication can be taken a step further to make them mulit-leader. Usually. you don’t want to have multiple leaders within the same datacenter because the complexity outweighs the benefits.
• When you have multiple leaders you would typically have a leader in each datacenter
• An interesting approach is for each datacenter to have a leader and followers…similar to the single leader. However, each leader would be followers to the other datacenter leaders
  • Sort of a chained single-leader replication setup

Comparing Single-Leader vs Multi-Leader Replication

Performance – because writes can occur in each datacenter without having to go through a single datacenter, latency can be greatly reduced in multi-leader

• The synchronization of that data across datacenters can happen asynchronously making the system feel faster overall
• Fault tolerance – in single-leader, everything is on pause while a new leader is elected
• In multi-leader, the other datacenters can continue taking writes and will catch back up when a new leader is selected in the datacenter where the failure occurred Network problems
• Usually a multi-leader replication is more capable of handling network issues as there are multiple data centers handling the writes – therefore a major issue in one datacenter doesn’t cause everything to take a dive

So it’s clear right? Multi-leader all the things? Hint: No!

Problems with Multi-Leader Replication

• Changes to the same data concurrently in multiple datacenters has to be resolved – conflict resolution – to be discussed later
• External tools for popular databases:
  • Tungsten replicator for MySQL
  • BDR for PostgreSQL
  • GoldenGate for Oracle
• Additional problems – multi-leader is typically bolted on after the fact
• Auto-incrementing keys, triggers, constraints can all be problematic
  • Those reasons alone are reasons why it’s usually recommended to avoid multi-leader replication

Clients with offline operation

• Multi-leader makes sense when there are applications that need to continue to work even when they’re not connected to the network
  • Calendars were an example given – you can make changes locally and when your app is online again it syncs back up with the remote databases
  • Each application’s local database acts as a leader
  • CouchDB was designed to handle this type of setup

Collaborative editing

Google Docs, Etherpad, Changes are saved to the “local” version that’s open per user, then changes are synced to a central server and pushed out to other users of the document

Conflict resolution

• One of the problems with multi-leader writes is there will come times when there will be conflicting writes when two leaders write to the same column in a row with different values
• How do you solve this?
  • If you can automate, you should because you don’t want to be putting this together by hand
  • Make one leader more important than the others
  • Make certain writes always go through the same data centers
• It’s not easy – Amazon was brought up as having problems with this as well

Multi-Leader Replication Toplogogies

• A replication topology describes how replicas communicate
• Two leaders is easy
• Some popular topologies:
  • Ring: Each leader reads from “right”, writes to the “left”
  • All to All: Very Chatty, especially as you add more and more nodes
  • Star: 1 special leader that all other leaders read from
• Depending on the topology, a write may need to pass through several nodes before it reaches all replicas
• How do you prevent infinite loops? Tagging is a popular strategy
• If you have a star or circular topology, then a single node failure can break the flow
• All to all is safest, but some networks are faster than others that can cause problems with “overrun” – a dependent change can get recorded before the previous
• You can mitigate this by keeping “version vectors”, kind of logical clock you can use to keep from getting too far ahead

Resources We Like

• Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann (Amazon)
• Past episode discussions on Designing Data-Intensive Applications (Coding Blocks)
• Amazon Yesterday Shipping (YouTube)
• Uber engineering blog (eng.uber.com)

Tip of the Week

• .http files are a convenient way of running web requests. The magic is in the IDE support. IntelliJ has it built in and VSCode has an extension. (IntelliJ Products, VSCode Extension)

• iTerm2 is a macOS Terminal Replacement that adds some really nice features. Some of our Outlaw’s favorite short-cuts: (iTerm2, Features and Screenshots)
  • CMD+D to create a new panel (split vertically)
  • CMD+SHIFT+D to create a new panel (split horizontally)
  • CMD+Option+arrow keys to navigate between panes
  • CMD+Number to navigate between tabs
• Ruler Hack – An architect scale ruler is a great way to prevent heat build up on your laptop by giving the hottest parts of the laptop some air to breathe. (Amazon)
• Fizz Buzz Enterprise Edition is a funny, and sadly reminiscent, way of doing FizzBuzz that incorporates all the buzzwords and most abused design patterns that you see in enterprise Code. (GitHub)
• From our friend Jamie Taylor (of DotNet Core Podcast, Tabs ‘n Spaces, and Waffling Taylors), mkcert is a “zero-config” way to easily generate self-signed certificates that your computer will trust. Great for dev! (GitHub)
  • Find out more about Jamie on these great shows…
    • https://dotnetcore.show/
    • https://tabsandspaces.io/
    • https://wafflingtaylors.rocks/