The translation is temporarily closed for contributions due to maintenance, please come back later.
The translation was automatically locked due to following alerts: Could not merge the repository.
Zen

Source string Source string

113/10000 · 113
English Actions
SENT – the bucket was migrated to the destination replica set. The `router` uses the SENT state to calculate the new location of the bucket. A bucket in the SENT state goes to the GARBAGE state automatically after BUCKET_SENT_GARBAGE_DELAY seconds, which by default is :ref:`0.5 seconds <cfg_basic-collect_bucket_garbage_interval>`.
GARBAGE – the bucket was already migrated to the destination replica set during rebalancing; or the bucket was initially in the RECEIVING state, but some error occurred during the migration.
Buckets in the GARBAGE state are deleted by the garbage collector.
Migration is performed as follows:
At the destination replica set, a new bucket is created and assigned the RECEIVING state, the data copying starts, and the bucket rejects all requests.
The source bucket in the source replica set is assigned the SENDING state, and the bucket continues to process read requests.
Once the data is copied, the bucket on the source replica set is assigned the SENT and it starts rejecting all requests.
The bucket on the destination replica set is assigned the ACTIVE state and starts accepting all requests.
There is a specific error ``vshard.error.code.TRANSFER_IS_IN_PROGRESS`` that returns in case a request tries to perform an action not applicable to a bucket which is being relocated. You need to retry the request in this case.
The _bucket system space
The ``_bucket`` system space of each replica set stores the ids of buckets present in the replica set. The space contains the following fields:
``bucket`` – bucket id
``status`` – state of the bucket
``destination`` – UUID of the destination replica set
An example of ``_bucket.select{}``:
---
- - [1, ACTIVE, abfe2ef6-9d11-4756-b668-7f5bc5108e2a]
- [2, SENT, 19f83dcb-9a01-45bc-a0cf-b0c5060ff82c]
...
Once the bucket is migrated, the destination replica set identified by UUID is filled in the table. While the bucket is still located on the source replica set, the value of the destination replica set UUID is equal to ``NULL``.
The routing table
А routing table on the ``router`` stores the map of all bucket ids to replica sets. It ensures the consistency of sharding in case of failover.
The ``router`` keeps a persistent pool of connections to all the storages that are created at startup. This helps prevent configuration errors. Once the connection pool is created, the ``router`` caches the current state of the routing table in order to speed up routing. If a bucket migrated to another ``storage`` after rebalancing, or a failover occurred and caused one of the shards switching to another replica, the ``discovery fiber`` on the ``router`` updates the routing table automatically.
As the bucket id is explicitly indicated both in the data and in the mapping table on the ``router``, the data is consistent regardless of the application logic. It also makes rebalancing transparent for the application.
Processing requests
Requests to the database can be performed by the application or using stored procedures. Either way, the bucket id should be explicitly specified in the request.
All requests are forwarded to the ``router`` first. The only operation supported by the ``router`` is ``call``. The operation is performed via the ``vshard.router.call()`` function:
result = vshard.router.call(<bucket_id>, <mode>, <function_name>, {<argument_list>}, {<opts>})
Requests are processed as follows:
The ``router`` uses the bucket id to search for a replica set with the corresponding bucket in the routing table.
If the map of the bucket id to the replica set is not known to the ``router`` (the discovery fiber hasn’t filled the table yet), the ``router`` makes requests to all ``storages`` to find out where the bucket is located.
Once the bucket is located, the shard checks:
whether the bucket is stored in the ``_bucket`` system space of the replica set;
whether the bucket is ACTIVE or PINNED (for a read request, it can also be SENDING).

Loading…

User avatar None

New source string

testing_project / Documentation: concepts/sharding/vshard_architecture — English

---
- - [1, ACTIVE, abfe2ef6-9d11-4756-b668-7f5bc5108e2a]
- [2, SENT, 19f83dcb-9a01-45bc-a0cf-b0c5060ff82c]
...
a year ago
Browse all string changes

Things to check

Ellipsis

The string uses three dots (...) instead of an ellipsis character (…)

Reset

Glossary

English English
No related strings found in the glossary.

String information

Flags
read-only
String age
a year ago
Last updated
a year ago
Source string age
a year ago
Translation file
string 82