<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Data Replication on Brave New Geek</title><link>https://bravenewgeek.com/tag/data-replication/</link><description>Recent content in Data Replication on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 27 Jul 2018 17:43:26 -0600</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/data-replication/index.xml" rel="self" type="application/rss+xml"/><item><title>Building a Distributed Log from Scratch, Part 5: Sketching a New System</title><link>https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-5-sketching-a-new-system/</link><pubDate>Tue, 23 Jan 2018 12:08:53 -0600</pubDate><guid>https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-5-sketching-a-new-system/</guid><description>&lt;p&gt;In &lt;a href="https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-4-trade-offs-and-lessons-learned/"&gt;part four&lt;/a&gt; of this series we looked at some key trade-offs involved with a distributed log implementation and discussed a few lessons learned while building NATS Streaming. In this fifth and final installment, we’ll conclude by outlining the design for a new log-based system that draws from the previous entries in the series.&lt;/p&gt;
&lt;h3 id="the-context"&gt;The Context&lt;/h3&gt;
&lt;p&gt;For context, &lt;a href="https://nats.io/"&gt;NATS&lt;/a&gt; and &lt;a href="https://nats.io/documentation/streaming/nats-streaming-intro/"&gt;NATS Streaming&lt;/a&gt; are two different things. NATS Streaming is a log-based streaming system built on top of NATS, and NATS is a lightweight pub/sub messaging system. NATS was originally built (and then open sourced) as the control plane for Cloud Foundry. NATS Streaming was built in response to the community’s ask for higher-level guarantees—durability, at-least-once delivery, and so forth—beyond what NATS provided. It was built as a separate layer on top of NATS. I tend to describe NATS as a dial tone—ubiquitous and always on—perfect for “online” communications. NATS Streaming is the voicemail—leave a message after the beep and someone will get to it later. There are, of course, more nuances than this, but that’s the gist.&lt;/p&gt;</description></item><item><title>Building a Distributed Log from Scratch, Part 2: Data Replication</title><link>https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-2-data-replication/</link><pubDate>Wed, 27 Dec 2017 12:26:55 -0600</pubDate><guid>https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-2-data-replication/</guid><description>&lt;p&gt;In &lt;a href="https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-1-storage-mechanics/"&gt;part one&lt;/a&gt; of this series we introduced the idea of a message log, touched on why it’s useful, and discussed the storage mechanics behind it. In part two, we discuss data replication.&lt;/p&gt;
&lt;p&gt;We have our log. We know how to write data to it and read it back as well as how data is persisted. The caveat to this is, although we have a durable log, it’s a single point of failure (SPOF). If the machine where the log data is stored dies, we’re SOL. Recall that one of our three priorities with this system is high availability, so the question is how do we achieve high availability and fault tolerance?&lt;/p&gt;</description></item></channel></rss>