Skip to content

Clarify leader and follow shard handling in OneShard deployments #361

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
nerpaula merged 1 commit into from
Nov 30, 2023
Merged

Clarify leader and follow shard handling in OneShard deployments #361

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions site/content/3.10/deploy/oneshard.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,14 +10,20 @@ archetype: default
{{< tag "ArangoDB Enterprise Edition" "ArangoGraph" >}}

The OneShard option for ArangoDB clusters restricts all collections of a
database to a single shard and places them on one DB-Server node. This way,
whole queries can be pushed to and executed on that server, massively reducing
cluster-internal communication. The Coordinator only gets back the final result.
database to a single shard so that every collection has `numberOfShards` set to `1`,
and all leader shards are placed on one DB-Server node. This way, whole queries
can be pushed to and executed on that server, massively reducing cluster-internal
communication. The Coordinator only gets back the final result.

Queries are always limited to a single database, and with the data of a whole
database on a single node, the OneShard option allows running transactions with
ACID guarantees on shard leaders.

Collections can have replicas by setting a `replicationFactor` greater than `1`
as usual. For each replica, the follower shards are all placed on one DB-Server
node when using the OneShard option. This allows for a quick failover in case
the DB-Server with the leader shards fails.

A OneShard setup is highly recommended for most graph use cases and join-heavy
queries.

Expand Down
12 changes: 9 additions & 3 deletions site/content/3.11/deploy/oneshard.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,14 +10,20 @@ archetype: default
{{< tag "ArangoDB Enterprise Edition" "ArangoGraph" >}}

The OneShard option for ArangoDB clusters restricts all collections of a
database to a single shard and places them on one DB-Server node. This way,
whole queries can be pushed to and executed on that server, massively reducing
cluster-internal communication. The Coordinator only gets back the final result.
database to a single shard so that every collection has `numberOfShards` set to `1`,
and all leader shards are placed on one DB-Server node. This way, whole queries
can be pushed to and executed on that server, massively reducing cluster-internal
communication. The Coordinator only gets back the final result.

Queries are always limited to a single database, and with the data of a whole
database on a single node, the OneShard option allows running transactions with
ACID guarantees on shard leaders.

Collections can have replicas by setting a `replicationFactor` greater than `1`
as usual. For each replica, the follower shards are all placed on one DB-Server
node when using the OneShard option. This allows for a quick failover in case
the DB-Server with the leader shards fails.

A OneShard setup is highly recommended for most graph use cases and join-heavy
queries.

Expand Down
12 changes: 9 additions & 3 deletions site/content/3.12/deploy/oneshard.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,14 +10,20 @@ archetype: default
{{< tag "ArangoDB Enterprise Edition" "ArangoGraph" >}}

The OneShard option for ArangoDB clusters restricts all collections of a
database to a single shard and places them on one DB-Server node. This way,
whole queries can be pushed to and executed on that server, massively reducing
cluster-internal communication. The Coordinator only gets back the final result.
database to a single shard so that every collection has `numberOfShards` set to `1`,
and all leader shards are placed on one DB-Server node. This way, whole queries
can be pushed to and executed on that server, massively reducing cluster-internal
communication. The Coordinator only gets back the final result.

Queries are always limited to a single database, and with the data of a whole
database on a single node, the OneShard option allows running transactions with
ACID guarantees on shard leaders.

Collections can have replicas by setting a `replicationFactor` greater than `1`
as usual. For each replica, the follower shards are all placed on one DB-Server
node when using the OneShard option. This allows for a quick failover in case
the DB-Server with the leader shards fails.

A OneShard setup is highly recommended for most graph use cases and join-heavy
queries.

Expand Down