+

Chapter 5 --- Replication.ipynb

@@ -129,7 +129,7 @@
  "name": "python",
  "nbconvert_exporter": "python",
  "pygments_lexer": "ipython3",
- "version": "3.6.5"
+ "version": "3.6.4"
  }
  },
  "nbformat": 4,

Chapter 7 --- Transactions.ipynb

@@ -133,7 +133,7 @@
  "name": "python",
  "nbconvert_exporter": "python",
  "pygments_lexer": "ipython3",
- "version": "3.6.5"
+ "version": "3.6.4"
  }
  },
  "nbformat": 4,

Chapter 7.1 --- Jepsen.ipynb

@@ -0,0 +1,86 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# Jepsen\n",
+ "Notes on [this sequence of blog posts](https://aphyr.com/tags/jepsen) exploring data properties of various databases.\n",
+ "\n",
+ "## Postgres\n",
+ "* Postgres has various options for consistency, up to and including 2PL serialized isolation.\n",
+ "* However the article focuses on the communication between the client and the server.\n",
+ "* Postgres uses a **two-phase commit** (Byzantine generals problems).\n",
+ "* In order for a commit to succeed on the client side, the (1) transaction must go through and (2) the database must respond to the client with a success.\n",
+ "* If a network partition between the client and the service occurs in between the write and the ack, the client will respond with a failure timeout.\n",
+ "* The data will still be modified, however.\n",
+ "* So if a network partition occurs, and a failure bubbles up, technically services relying on Postgres cannot know if the transaction succeeded or not.\n",
+ "* Is it hard to create a partition between the database and the client? Maybe.\n",
+ "\n",
+ "## Redis\n",
+ "* Redis by default runs on a single server. It offers serialized isolation (e.g. the highest possible guarantee level) via actual serialization (everything runs on one thread, and transactions are sequenced on that thread).\n",
+ "* In this configuration Redis is CP.\n",
+ "\n",
+ "\n",
+ "* Redis can be made highly available.\n",
+ "* It offers asynchronous single-leader replication (see Chapter 6 notes).\n",
+ "* A separate service, called Sentry, is used to detect serious network partitions.\n",
+ "* If a network partition occurs, a quorom of nodes (at least $N / 2 + 1$, so that only one quorom may exist) assembles and elects a new leader.\n",
+ "* The quorom then instructs any client connections to abandon the old configuration and use the new configuration. Nodes are added back as the partition heals and the offline nodes come back online.\n",
+ "* Redis does not gaurantee durability. Replication and disc writes are performed asynchronously, so data that was updated on \"lost\" nodes may not exist in the new quorom (having a quorom protects against this, but as always it's an availability-consistency tradeoff).\n",
+ "\n",
+ "\n",
+ "* By default, during a network partition the old primary will continue to accept and deal with requests.\n",
+ "* This will continue until the partition heals and the new quorom-elected leader can reach the primary again. The old primary will be told to step down.\n",
+ "* The data that was accepted by the old primary and acked will be lost!\n",
+ "\n",
+ "\n",
+ "* Any service built on Redis must be ready to deal with failovers that demolish consistency.\n",
+ "* So in the single-leader replicated configuration, Redis is not consistent.\n",
+ "* Redis is not available, either. If there is a failover there's no node that will accept operations.\n",
+ "* The tradeoff is that it's very fast.\n",
+ "* Caches don't care about consistency loss, which is why Redis is so good for this purpose (the difficulty of cache invalidation notwithstanding).\n",
+ "\n",
+ "\n",
+ "* You can optionally configure how long until the old primary stops accepting requests. \n",
+ "* This essentially requires an occassional quorom ack on the primary, which slows the system down. I don't recommend it.\n",
+ "* Really, if you want to not lose data and not deal with acknowledged consistency problems don't use Redis! It wasn't designed for this!\n",
+ "\n",
+ "\n",
+ "## MongoDB\n",
+ "\n",
+ "* MongoDB also uses a single-leader replication with quorom recovery.\n",
+ "* By default MongoDB also uses a two-phase commit against the leader (apparently it used to not even check if a write succeeded on the leader!).\n",
+ "* If a network partition occurs, similarly to Redis the majority quorom will elect a new leader.\n",
+ "* In the meanwhile, the old leader will continue to accept and ack operations.\n",
+ "* Once the partition heals, and the old leader rejoins the pack, the intervening data written to the old leader and not to the new leader is rolled back (specifically, to a rollback file that a system administrator can look at).\n",
+ "* The article claims it's not possible to get split-brain, but it seems extremely possible to get split-brain...\n",
+ "* So by default MongoDB is not consistent.\n",
+ "\n",
+ "\n",
+ "* As with Redis you can tell MongoDB to use majority acknowledgement. This makes it properly CP, but increases latency by a lot."
+ ]
+ }
+ ],
+ "metadata": {
+ "kernelspec": {
+ "display_name": "Python 3",
+ "language": "python",
+ "name": "python3"
+ },
+ "language_info": {
+ "codemirror_mode": {
+ "name": "ipython",
+ "version": 3
+ },
+ "file_extension": ".py",
+ "mimetype": "text/x-python",
+ "name": "python",
+ "nbconvert_exporter": "python",
+ "pygments_lexer": "ipython3",
+ "version": "3.6.4"
+ }
+ },
+ "nbformat": 4,
+ "nbformat_minor": 2
+}