AntidoteDB
  • Overview
  • Quickstart
  • Examples & Applications
    • Timeseries Load Generator
    • Antidote Web Shell
    • Calendar App
    • Todo List App
  • Tutorials
    • Java Tutorial
  • Related Projects
  • Architecture
    • Overview
    • Ring
    • Log
    • Materializer
    • Transaction Manager
    • Inter-DC Communication
    • Failure Modes
    • Datatypes in Antidote
    • Commit Hooks
    • Features Configuration
  • Deployment
    • Natively (Linux)
    • Local Docker Setup
    • Docker Compose Setups
    • Docker Swarm
    • Kubernetes
  • Monitoring
    • Prometheus and Grafana
  • API
    • Native (Erlang)
    • Protocol Buffer API
    • Erlang
    • Java
    • JavaScript
    • Go
    • Python
  • Benchmarking
    • Setup
    • Basho Bench
  • Tools
    • Logs and Cache Dump
  • Development
    • Setup & Environment
    • Building a Release
    • Testing
    • Contributing
    • Archived Works
  • Release Notes
    • 0.2.1
    • 0.1.1
    • 0.0.1
Powered by GitBook
On this page
  1. Architecture

Inter-DC Communication

Antidote currently uses ZeroMQ for efficient communication between data centers.

There are two mechanisms once a DC is registered to listen to another DC.

First, the DC creates a new SUB socket and connects it to the PUB socket on the remote DC. Second, it also creates a REQ socket and connects it to the REP socket on the remote DC. This REQ/REP socket pair is for fetching all transactions lost in case of a pub/sub failure.

If a (node inside a) DC crashes, it needs to reconnect to the exact same PUB sockets and same REP sockets. The internals will take care of the lost messages as soon as the newly recovered node receives a ping. It will then figure out which transactions were lost, re-download them via the REQ/REP and resume the normal communication via PUB/SUB.

PreviousTransaction ManagerNextFailure Modes

Last updated 5 years ago