What replicates where

Two declarations decide where data lives, and they are written by two different people at two different times.

The namespace says how many copies the cluster keeps. That is a property of the data and is written where the namespace is declared. A peer's subscription says which namespaces that peer receives. That is a property of the machine and is written on its membership row. Neither implies the other: a namespace asking for three copies on a cluster where no peer subscribes to it has one.

A namespace declares its replication

DEFINE NAMESPACE archive REPLICATION FACTOR 3;
DEFINE NAMESPACE scratch REPLICATION NONE;

It is declared where the namespace is declared rather than inherited from a store-wide setting — a default nobody chose is indistinguishable, afterwards, from a choice somebody made.

REPLICATION NONE declines replication and REPLICATION FACTOR 3 asks for three copies. FACTOR 1 is accepted and describes the same number of copies as NONE, kept apart because one is a count and the other is a refusal.

A namespace that never said is not a namespace that said NONE. The clause is optional, so DEFINE NAMESPACE prod; states nothing, and INFO FOR NAMESPACE reports replication: NONE — the empty value, not the policy — for such a namespace. The two are kept as different stored facts because the difference cannot be recovered later: on a cluster, a namespace that declined is honoured and a namespace nobody asked about is refused rather than quietly given one copy.

Turning it on after there is already data

ALTER NAMESPACE scratch REPLICATION FACTOR 2;
ALTER NAMESPACE scratch REPLICATION NONE;

It moves in both directions, so a namespace can start unreplicated and be switched on afterwards, and switched off again.

Nothing is redistributed by the statement and no repair step follows it. The log already holds every write the namespace ever took, so a node that begins replicating it replays that history from origin. There is no window during which the new copy is partial-and-believed-complete, because it is not serving that namespace until it has caught up — and there is no synchronisation tool to run, because catching up is the ordinary replication path doing the ordinary thing.

Reading it back

INFO FOR NAMESPACE;

reports replication beside class. class is the other question — how many nodes may write the namespace, not how many copies of it exist — and it is the subject of Two writers on one range.

A peer receives what its subscription names

DEFINE REPLICA db_2 AT 'db-2.internal:9000'
    NODE '3f9a1c04b7e2489db5610af3d82c7e46'
    REPLICATES NAMESPACE archive;

A selective follower — one whose subscription names a namespace rather than the store — receives every sequence of the log with the mutations outside its reach removed. Its own schema and data arrive, and nothing else does.

That includes the catalog. A follower subscribed to archive receives archive's tables and cannot name another tenancy's: asking it to describe a table it does not replicate is not answered with an empty list, it is answered as the absence it is. The check that matters here is the one run as the follower's own reader rather than as an administrator, because an administrator can see everything on every node by construction and would find nothing.

Users travel with the data, inside the subscription's reach

The log is a stream of mutations and the identity class is in it. A subscription therefore carries users, their credential hashes and their grants — for the addresses it names.

Two halves of this are worth separating, because they sound like one rule:

• Store-level users replicate everywhere, always. A user declared at the store signs in on a selective follower. Identity is not something a node can be partially given: a follower that had some of the users would authenticate some of the people and silently refuse the rest.
• A tenancy's credentials stay inside the tenancy. A namespace owner on a selective follower cannot read another tenancy's users, for the same reason they cannot read its records.

REPLICATES STORE hands over every tenancy's identity along with every tenancy's data, which is why it is written deliberately and is never a default.

The quietest failure a cluster has

INFO FOR NODE reports each peer's subscription beside its roles, in the spelling the clause takes, so what the report prints can be pasted into the statement that would correct it.

null means subscribed to nothing. It is the quietest failure a cluster has, because every node is up, every greeting lands, and one copy simply never changes. Nothing is in an error state; there is only a number that stops moving, and the place to see it is the follower rows.