Zum Inhalt springen
Deutsch

ShardCoordinatorOptionsType

Dieser Inhalt ist noch nicht in deiner Sprache verfügbar.

ShardCoordinatorOptionsType = object

Defined in: src/cluster/sharding/ShardCoordinatorOptions.ts:24

Plain options-object shape consumed by a ShardCoordinator.

readonly optional acquireRetryIntervalMs?: number

Defined in: src/cluster/sharding/ShardCoordinatorOptions.ts:60

Retry interval for lease.acquire() after a failed attempt. Default: 5 s.


readonly allocationStrategy: AllocationStrategy

Defined in: src/cluster/sharding/ShardCoordinatorOptions.ts:27


readonly cluster: Cluster

Defined in: src/cluster/sharding/ShardCoordinatorOptions.ts:26


readonly optional coordinatorStateStore?: CoordinatorStateStore

Defined in: src/cluster/sharding/ShardCoordinatorOptions.ts:89

Optional persistence backend for the allocation state itself (regions + shardHome). Without it, LeaderChanged triggers a full rebuild from Register gossip — fine for a few hundred shards, painful at thousands. With it, the new leader loads the last-known snapshot from the store (e.g. DistributedData) and skips the reallocation storm.

ClusterSharding does NOT auto-instantiate this — the user must explicitly start a DistributedData extension first and pass new DistributedDataCoordinatorStateStore(...). Without that opt-in, ShardCoordinator keeps the v1 rebuild-from- Register behaviour (backwards-compat).


readonly optional handOffTimeoutMs?: number

Defined in: src/cluster/sharding/ShardCoordinatorOptions.ts:42


readonly optional lease?: Lease

Defined in: src/cluster/sharding/ShardCoordinatorOptions.ts:58

Optional split-brain protection. When set, the elected leader’s coordinator must hold the lease before it processes shard messages. Under a network partition where two nodes converge to “I am the leader” gossip views, only the side that successfully acquires the lease ever issues AllocateShard / HandOff directives — the other side stays passive and drops messages (regions retry naturally on their next cache miss).

Without a lease the coordinator gates only on isLeader() — v1 behaviour, no extra coordination.


readonly localResolver: (path) => ActorRef | null

Defined in: src/cluster/sharding/ShardCoordinatorOptions.ts:45

Resolver for local actor paths — used when coordinator lives on the same node as a region.

string

ActorRef | null


readonly numShards: number

Defined in: src/cluster/sharding/ShardCoordinatorOptions.ts:39

Number of shards for this entity type — the bound the coordinator checks an incoming GetShardHome against.

A shard id is hash(entityId) % numShards, so no honest region can ever ask for one outside 0 .. numShards - 1. Without the bound the coordinator allocated, recorded and persisted whatever id it was asked for, and the allocation map is durable state that is replayed at every coordinator start — so a peer could grow it without limit and the growth survived restarts (#583).


readonly optional rebalanceIntervalMs?: number

Defined in: src/cluster/sharding/ShardCoordinatorOptions.ts:41


readonly optional rememberEntities?: boolean

Defined in: src/cluster/sharding/ShardCoordinatorOptions.ts:43


readonly optional rememberEntitiesStore?: RememberEntitiesStore

Defined in: src/cluster/sharding/ShardCoordinatorOptions.ts:74

Optional persistence backend for the entity registry. Only used when rememberEntities: true. Without it, entitiesPerShard stays in-memory only and a full cluster restart loses the registry — until messages re-arrive and trigger fresh EntityStarted notifications. Set to a JournalRememberEntitiesStore (or any custom impl) to make the registry survive cold-starts.

The ClusterSharding extension auto-instantiates the default JournalRememberEntitiesStore (using the active Journal) when rememberEntities: true and no explicit store is provided — so most users don’t need to touch this field.


readonly optional role?: string

Defined in: src/cluster/sharding/ShardCoordinatorOptions.ts:40


readonly typeName: string

Defined in: src/cluster/sharding/ShardCoordinatorOptions.ts:25