LoginSign Up
← Back to all sparks
D

Dragonfly

INFRA · APIS
Velocity5.0

In-memory datastore compatible with Redis and Memcached

www.dragonflydb.io ↗

Dragonfly opens a 2.1 line with metrics that explain why replicas drop.

in-memory datastoreobservabilityreplicationclusteringrelease maintenance
◆Current state
Dragonfly tagged v2.1.0 on November 4, exporting snapshot counters, a save-in-progress gauge and replica disconnects labeled closed, error or timeout. Before, a replica dropped for stalling was indistinguishable from one whose connection simply closed. The 1.40 and 2.0 lines keep getting small cluster-mode fixes, including faster GetSlotInfo and slot migration that no longer drops writes.
◆Where it's heading
Dragonfly is maturing for production operations: the 2.0 line fixed cluster correctness, and 2.1 starts by making replication and persistence observable from Prometheus. The project says it prefers small incremental features, so 2.1 will likely grow the same way.
◆Prediction
More metrics and cluster-mode fixes on 2.1, with 1.40 and 2.0 still getting backports for a while.

◆Recent moves

  1. 9d ago

    Dragonfly 2.1.0 exports snapshot and replica-disconnect metrics

    The first 2.1 release exports persistence and replication state that was only in INFO or logs, including why a replica disconnected. It shifts the focus from 2.0's cluster correctness fixes to making those failures visible to operators.

    View source ↗
  2. 14d ago

    i2.0.6: faster slot info lookups in cluster mode

    A refactor that makes GetSlotInfo faster on the 2.0 line. It continues the cluster-mode tuning after the migration and sharding fixes, with no user-facing behaviour change described.

    View source ↗
  3. 23d ago

    i1.40.13: Sidekiq queues placed on the same shard

    A cherry-picked change maps Sidekiq's private and public queues to the same shard on the 1.40 line. It is a narrow placement tweak for one workload.

    View source ↗
  4. 24d ago

    i2.0.5: Fibonacci hashing evens out slot-based sharding

    With the experimental slot-based sharding flag, keys are now spread across shard threads with Fibonacci hashing instead of slot modulo shard count, which could pile structured key sets onto one thread. It is another step in tuning 2.x cluster mode.

    View source ↗
  5. 24d ago

    i1.40.12: single-shard BLMOVE completes in one hop

    A single-shard BLMOVE now completes in one hop when data is already available. It is a small latency fix on the 1.40 maintenance line.

    View source ↗
  6. 24d ago

    i2.0.4: slot migration no longer drops writes to empty buckets

    Slot migration now visits empty buckets, so writes landing in them during a migration are no longer silently dropped on the target. It is a data-consistency fix for cluster users, ported to the 2.0 line.

    View source ↗