Meta tags:
description=Oxia: Scalable Metadata and Index storage;

Headings (most frequently used words):

become, migrating, from, zookeeper, etcd, to, and, data, operation, mapping, sessions, per, key, or, differences, common, migration, strategies, things, oxia, deliberately, does, not, provide, model, watches, reliable, notifications, ephemerals, sequential, znodes, atomic, sequence, keys, acls, revisions, versions, leases, transactions, collapse, cas, watch, resume,

Text of the page (most frequently used words):
the (68), key (63), and (50), oxia (37), client (27), keys (23), not (21), etcd (21), per (19), are (19), put (19), zookeeper (14), from (14), #session (13), path (13), for (11), data (11), with (11), every (10), multi (10), migrating (10), single (10), delete (10), namespace (9), create (9), only (9), can (9), notifications (9), value (9), sessions (9), prefix (9), shard (8), does (8), become (8), list (8), ephemerals (8), model (7), write (7), created (7), that (7), ephemeral (7), version (7), end (7), sequence (7), use (6), see (6), via (6), each (6), cas (6), across (6), when (6), revision (6), api (6), scoped (6), get (6), operation (6), architecture (6), consistency (5), metadata (5), acls (5), parent (5), hierarchical (5), atomic (5), transactions (5), any (5), provide (5), this (5), one (5), watches (5), sdk (5), watch (5), partition (5), expectedversionid (5), there (5), first (5), but (5), reliable (5), read (4), level (4), semantics (4), time (4), shards (4), has (4), global (4), order (4), all (4), application (4), logical (4), migration (4), resume (4), event (4), txn (4), lease (4), record (4), stream (4), monotonic (4), mapping (4), namespaces (4), sorting (4), operations (4), protocol (4), getting (3), started (3), coordination (3), workloads (3), configuration (3), linearizable (3), deleted (3), state (3), reads (3), revisions (3), workload (3), option (3), source (3), then (3), stores (3), multiple (3), dataset (3), same (3), getnotifications (3), coordinator (3), expectedrecordnotexists (3), set (3), you (3), clients (3), keep (3), configured (3), leases (3), timestamp (3), assigns (3), cluster (3), wide (3), returns (3), znode (3), like (3), security (3), counter (3), znodes (3), events (3), getchildren (3), creating (3), what (3), node (3), page (3), documentation (3), 2026 (2), policies (2), last (2), overwhelming (2), majority (2), leader (2), offset (2), these (2), limits (2), needed (2), sync (2), isolation (2), authentication (2), oidc (2), flat (2), auto (2), serves (2), current (2), point (2), range (2), deletes (2), ordering (2), total (2), things (2), deliberately (2), stop (2), snapshot (2), over (2), cutover (2), verify (2), replica (2), writes (2), dual (2), system (2), depends (2), strategies (2), call (2), where (2), left (2), off (2), update (2), through (2), related (2), lock (2), architect (2), around (2), ctx (2), since (2), equivalent (2), modrevision (2), byte (2), supports (2), number (2), transaction (2), compare (2), collapse (2), attach (2), revoke (2), lifetime (2), close (2), alive (2), heartbeats (2), ttl (2), withsessiontimeout (2), named (2), supported (2), past (2), resumable (2), covers (2), replay (2), versionid (2), which (2), reading (2), maintains (2), modified (2), modification (2), versions (2), lsm (2), withlease (2), commit (2), filter (2), withrange (2), values (2), rangescan (2), notes (2), its (2), own (2), counters (2), partitionkey (2), create_sequential (2), sequential (2), difference (2), tied (2), connection (2), reattached (2), back (2), owns (2), timeout (2), keydeleted (2), transparently (2), they (2), child (2), atomicity (2), unconditional (2), found (2), exists (2), scan (2), setdata (2), store (2), default (2), children (2), without (2), style (2), offers (2), linearizability (2), different (2), many (2), sharded (2), differences (2), common (2), light (2), storage (2), replication (2), consensus (2), maelstrom (2), tla (2), safety (2), correctness (2), physical (2), design (2), goals (2), metrics (2), grpc (2), schema (2), cli (2), reference (2), admin (2), bare (2), metal (2), resources (2), helm (2), kubernetes (2), deployment (2), python (2), java (2), sdks (2), versioning (2), secondary (2), indexes (2), features (2), blog (2), ctrl (2), copyright, 2023, series, projects, llc, website, terms, trademark, policy, other, project, please, https, lfprojects, org, updated, july, fencing, election, service, discovery, tracking, assignment, distribution, none, applies, trade, substantial, gain, throughput, capacity, available, explicit, quorum, paths, historical, local, before, committing, check, depend, drain, convert, restart, simplest, test, non, critical, environments, big, bang, replace, take, consistent, load, into, offline, cut, during, maintenance, window, appropriate, short, outage, acceptable, teach, both, systems, reaches, parity, flip, pattern, used, apache, pulsar, pip, 454, framework, production, datasets, migrate, them, independently, smaller, reversible, change, staged, right, strategy, downtime, budget, how, much, roughly, lowest, highest, risk, known, asks, server, send, acknowledged, managed, processes, tracks, progress, subsequent, picks, previous, accept, rollback, fails, partway, locate, serialise, updates, held, encode, protected, options, preference, currentversion, newconfig, config, unchanged, owner, absent, createrevision, comparing, depending, outcome, performing, puts, gets, atomically, unrelated, later, need, independent, lifetimes, run, expiry, records, written, transparent, your, behalf, construction, class, objects, attached, behave, similarly, instance, whole, changes, analogous, along, fields, equivalents, globally, doubles, applications, snapshots, bounded, staleness, compaction, internal, automatic, compact, rev, handled, automatically, keepalive, construct, handle, implicit, grant, side, withprefix, within, deleterange, streams, below, schemes, currently, offered, coarser, granularity, space, done, tokens, sasl, digest, world, dimensional, increment, several, once, producing, composite, suffix, 00000000005, 00000000001, deltas, positive, integer, just, useful, allocating, ranges, round, trip, pinned, appends, digit, padded, name, always, incrementing, generalise, main, lifecycle, tcp, presenting, password, new, designed, process, restarts, crashes, comes, opens, fresh, still, identified, setting, stable, identity, withidentity, expires, clean, crash, emitted, handles, reconnects, concepts, map, directly, replaces, persistent, calls, receives, continuous, feed, disconnected, pick, silently, dropped, distinction, mutation, care, about, subset, keyrangerangedeleted, keymodified, keycreated, shot, fires, consumed, register, occur, between, firing, registration, lost, native, catch, everything, cross, ops, returning, timestamps, getdata, optimistic, concurrency, sequencekeysdeltas, create_ephemeral, size, carry, stored, pebble, limited, practical, constraints, deep, requirement, either, aware, wise, lexicographic, makes, return, direct, visiting, deeper, entries, closest, match, natural, becomes, typically, marker, separate, misses, error, concrete, consequences, tree, requires, already, exist, shaped, continue, work, recommended, track, relationships, instead, expected, located, required, zxid, guarantees, individual, two, may, land, therefore, have, real, replicate, full, coordinated, paxos, raft, group, partitions, given, routed, library, routing, substrate, programming, swap, nodes, feasible, drop, replacement, scope, handful, differ, enumerates, developer, facing, plan, transition, scroll, top, edit, github, question, give, feedback, skip, content,

Text of the page (random words):
migrating from zookeeper or etcd oxia skip to content oxia metadata store and coordination system documentation blog ctrl k ctrl k documentation what is oxia getting started migrating from zk etcd features consistency model ephemerals namespaces notifications key sorting partition keys secondary indexes sequence keys versioning client sdks go java node js python deployment kubernetes helm resources bare metal security admin operations reference cli configuration schema grpc api metrics architecture design goals logical architecture physical architecture correctness protocol safety tla maelstrom consensus coordinator oxia replication protocol storage blog light what is oxia getting started migrating from zk etcd features consistency model ephemerals namespaces notifications key sorting partition keys secondary indexes sequence keys versioning client sdks go java node js python deployment kubernetes helm resources bare metal security admin operations reference cli configuration schema grpc api metrics architecture design goals logical architecture physical architecture correctness protocol safety tla maelstrom consensus coordinator oxia replication protocol storage light on this page differences common to zookeeper and etcd migrating from zookeeper data model operation mapping watches become reliable notifications sessions and ephemerals sequential znodes become atomic sequence keys acls migrating from etcd operation mapping revisions become per key versions leases become sessions transactions collapse to per key cas watch resume data migration strategies things oxia deliberately does not provide question give us feedback edit this page on github scroll to top documentation migrating from zk etcd migrating from zookeeper or etcd oxia offers the same programming model as zookeeper and etcd linearizable keys sessions ephemerals notifications compare and swap but sharded across many nodes a migration is feasible for the overwhelming majority of coordination workloads but it is not a drop in replacement the consistency scope and a handful of operation semantics differ this page enumerates every developer facing difference so you can plan the transition differences common to zookeeper and etcd sharded substrate zk and etcd replicate the full dataset on every node coordinated by a single paxos raft group oxia partitions the dataset across many shards each with its own replica set and leader operations for a given key are routed to the shard that owns that key the client library does the routing transparently per key linearizability not cluster wide oxia guarantees linearizability on every individual key see consistency model two operations on different keys may land on different shards and therefore have no global real time ordering no global total order zk assigns a monotonic zxid to every modification and etcd assigns a monotonic revision oxia maintains a version counter per key and does not provide a cluster wide sequence no multi key transactions across shards oxia offers per key cas via an expected version option but no atomic multi key commit related keys can be co located on the same shard with a partition key when multi key atomicity is required migrating from zookeeper data model zookeeper stores data in a hierarchical tree of znodes creating a b requires a to already exist oxia stores flat keys path shaped keys like a b c continue to work and are the recommended style but oxia does not track parent child relationships you can put a b without first creating a and there is no list the children of a operation use a range scan or list with a prefix instead concrete consequences exists is not a separate call a get that misses returns a not found error getchildren path becomes list prefix prefix end marker typically list a a oxia namespaces can be configured for either hierarchical aware default or natural byte wise lexicographic key sorting hierarchical sorting is what makes list a a return only the direct children of a without visiting deeper entries the closest match to zookeeper s getchildren semantics keep the default for zk style workloads creating a deep path is a single put there is no create parent requirement znode data size limits do not carry over keys and values are stored in pebble and limited only by the lsm store s practical constraints operation mapping zookeeper oxia notes create path data put key value create create_ephemeral put key value ephemeral session is created on first ephemeral write create create_sequential put prefix value sequencekeysdeltas 1 partitionkey prefix see sequence keys setdata path data version put key value expectedversionid v optimistic concurrency via per key version setdata path data 1 put key value unconditional write getdata path get key returns value version and created modified timestamps getchildren path list prefix prefix end prefix scan no hierarchical semantics exists path get key returning not found delete path version delete key expectedversionid v delete path 1 delete key unconditional delete multi ops no cross key atomicity use per key cas or re architect around a single key sync path not needed every read is linearizable watches become reliable notifications zookeeper watches are one shot when an event fires the watch is consumed and the client has to re register it events that occur between firing and re registration are lost and there is no native catch me up on everything since timestamp t oxia replaces watches with a persistent notifications stream scoped to a namespace a client calls getnotifications and receives a continuous feed of keycreated keymodified keydeleted and keyrangerangedeleted events the stream is reliable and resumable disconnected clients pick up where they left off and no events are silently dropped there is no child vs data distinction the stream covers every mutation in the namespace and clients filter by key if they only care about a subset sessions and ephemerals the concepts map directly an oxia session is created transparently on the first ephemeral write the client sdk handles heartbeats and reconnects when the session expires clean close crash or partition past the timeout all ephemerals tied to it are deleted and keydeleted notifications are emitted session timeout is configured per client via withsessiontimeout see ephemerals the main lifecycle difference zk sessions are tied to a tcp connection and can be reattached by presenting the session id password on a new connection oxia sessions are not designed to be reattached across process restarts a client that crashes and comes back up opens a fresh session any ephemerals it still owns can be identified by setting a stable client identity with withidentity and reading it back from the record metadata sequential znodes become atomic sequence keys zookeeper s create_sequential appends a 10 digit padded counter to the created znode name always incrementing by 1 and scoped to the parent path oxia s sequence keys generalise this the counter is scoped to the prefix key pinned to a single shard with partitionkey deltas can be any positive integer not just 1 useful when allocating ranges in a single round trip multi dimensional counters are supported one put can increment several counters at once producing composite suffix keys like data 00000000005 00000000001 acls zookeeper supports per znode acls with schemes like world ip digest and sasl oxia does not currently provide per key acls isolation is offered at coarser granularity by namespaces each namespace has its own key space and shard set and per client authentication is done via oidc tokens see security migrating from etcd operation mapping etcd oxia notes put key value put key value put withlease id put ephemeral sessions are client scoped see below get key get key get key withrange end list key end or rangescan key end list returns keys only rangescan streams keys values delete key delete key delete key withrange end deleterange key end atomic within a shard watch key watch key withprefix getnotifications namespace scoped filter client side on key txn if then commit put expectedversionid v put expectedrecordnotexists single key cas only no multi key transaction api lease grant ttl put withlease client session implicit put ephemeral session is a client level construct not a named handle lease keepalive id handled automatically by the client sdk compact rev lsm compaction is internal and automatic no application api revisions become per key versions etcd assigns every modification a globally monotonic revision which doubles as a cluster wide logical timestamp applications use it for reliable event replay snapshots and bounded staleness oxia maintains a monotonic versionid per key along with created and modified timestamp fields in the record metadata it does not provide a global revision equivalents which version am i reading versionid on the record analogous to etcd s modrevision reliable replay of all changes the notifications stream is resumable and covers the whole namespace point in time reads at a past revision not supported oxia serves the current state of each key leases become sessions etcd leases are first class named objects create a lease attach keys to it keep it alive revoke it to delete every attached key oxia s sessions behave similarly but are scoped to the client instance a single session is created per client the first time it writes an ephemeral record session ttl is configured at client construction via withsessiontimeout keep alive is transparent the sdk heartbeats on your behalf on client close or session expiry all ephemeral records written by that client are deleted there is no api for create a lease attach unrelated keys revoke later the session s lifetime is the client s lifetime if you need multiple independent lifetimes run multiple clients transactions collapse to per key cas etcd s txn supports comparing any number of keys and depending on the outcome performing any number of puts gets deletes atomically oxia has no multi key transaction api for single key compare and set use the expectedversionid or expectedrecordnotexists option on put and delete create only if absent etcd equivalent txn with createrevision 0 client put ctx lock byte owner oxia expectedrecordnotexists update only if unchanged since last read etcd equivalent txn with modrevision r client put ctx config newconfig oxia expectedversionid currentversion if an etcd workload depends on multi key transactions options in order of preference are re architect around a single key encode the protected state as one value use a partition key to co locate related keys on a single shard then serialise updates through a lock held on a coordinator key accept application level rollback when a multi key update fails partway through watch resume etcd watches resume from a known revision the client asks the server send me every event with revision r oxia notifications resume from an acknowledged offset managed by the client sdk as the application processes each event the sdk tracks progress and a subsequent getnotifications call from the same client picks up where the previous one left off data migration strategies the right strategy depends on downtime budget and how much of the workload can dual write roughly in order from lowest to highest risk staged namespace by namespace if the source system stores multiple logical datasets create one oxia namespace per dataset and migrate them independently each migration is a smaller reversible change dual write verify cutover teach the application to write to both systems verify the oxia replica reaches parity flip reads then stop writes to the source this is the pattern used by apache pulsar s pip 454 framework for migrating zookeeper metadata to oxia in production snapshot cutover take a consistent snapshot of the source load it into oxia offline cut over during a maintenance window appropriate when a short outage is acceptable big bang replace stop drain convert restart the simplest option for test or non critical environments things oxia deliberately does not provide before committing check that the workload does not depend on any of these global total order across all keys oxia has per shard ordering only multi key transactions across shards only per key cas and shard local range deletes are atomic point in time reads at historical revisions oxia serves the current state of each key hierarchical create parent semantics keys are flat parent paths are not auto created or auto deleted per key acls isolation is at the namespace level authentication is client level via oidc sync explicit quorum read not needed every read is linearizable and not available for the overwhelming majority of coordination workloads fencing leader election service discovery session tracking offset assignment configuration distribution none of these limits applies and the trade is a substantial gain in write throughput and metadata capacity last updated on july 11 2026 getting started consistency model copyright 2023 2026 oxia a series of lf projects llc for website terms of use trademark policy and other project policies please see https lfprojects org policies