Skip to content
AxonOps Documentation

AxonOps — AI-Native Control Plane for Open Source Data Platforms

Cassandra Time Synchronization

Apache Cassandra resolves conflicting writes by comparing timestamps, so the correctness of stored data depends on the clocks of the machines that generate those timestamps. Cassandra and the Cassandra drivers read the system clock of the host they run on and trust what it returns, which places both the cluster nodes and the application hosts inside that dependency. Installing and operating a time synchronization service is outside the scope of Cassandra and of its drivers, which makes it an environmental prerequisite that has to be designed rather than assumed.

Key points:

  • Cassandra 3.11, 4.x, and 5.0 resolve concurrent writes to the same cell, meaning a single column value within a row, by last-write-wins on a microsecond timestamp. The order in which writes arrive at a replica, a node holding a copy of the data, is not what decides the outcome.
  • The Cassandra drivers generate the write timestamp client-side by default in current versions, taking it from the application host’s clock. Every application host running a driver is therefore inside the cluster’s clock-correctness domain and needs the same synchronization discipline as the nodes. The behaviour is configurable per driver, and a driver can be set to send no timestamp so that the coordinator node receiving the request assigns one instead.
  • Clock skew, the difference between two machines’ clocks at the same instant, fails silently. No error is returned, the write is acknowledged, and the data is wrong when it is read later.
  • Relative synchronization (node-to-node agreement) is what Cassandra depends on, not absolute accuracy against civil time.
  • A small dedicated internal tier running the Network Time Protocol (NTP), or a cloud provider’s time service, gives better relative accuracy than each node synchronizing independently to public NTP pools.

Pages in this section

Section titled “Pages in this section”

The pages are listed in the order they are best read first, from the mechanism to its configuration and operation. Each page also stands alone as a reference for its own topic.

  • How Cassandra uses time covers where a write timestamp comes from, which side generates it in each driver, last-write-wins conflict resolution, and the limits of the coordinator’s monotonicity guarantee.
  • Clock skew failure modes covers what goes wrong under skew: updates that disappear, deletes that do not delete, TTL and writetime() distortion, cross-node timeout accounting, why lightweight transactions do not help, what the Cassandra guardrails do and do not detect, and how much skew a workload can tolerate.
  • NTP fundamentals covers clock drift, how NTP measures and corrects an offset, slewing compared with stepping, and the stratum hierarchy.
  • Deployment architecture covers how to establish what time infrastructure already exists, the internal NTP tier design and its alternatives, the cloud provider time services, Kubernetes, multi-datacenter tiers, and leap-second smearing.
  • Configuring chrony covers the node and tier configuration files, applying them without stepping the clock under a running Cassandra, verification commands, troubleshooting, and the kernel clocksource.
  • Security covers firewall scoping for UDP 123, why clock spoofing is a data-integrity attack against a cluster, symmetric key authentication, and Network Time Security.
  • Monitoring covers which signals to collect, suggested alert thresholds, and the AxonOps agent’s NTP offset metric.
Section titled “Related documentation”