Как работает перебалансировка свопов Couchbase?
Я пытаюсь понять, как обеспечивается согласованность данных во время обновления через Интернет с входящими операциями в базу данных с использованием перебалансировки подкачки.
- Когда я говорю перебалансирование свопа (с добавлением и удалением 1 узла), данные с одного узла копируются на вновь добавленный узел. Что происходит в течение этого переходного периода с запросами, поступающими на удаляемый узел?
- Видим ли мы какие-либо проблемы с доступностью данных во время обмена?
2 ответа
Внутренний баланс происходит постепенно, перемещая vBuckets между узлами. Добавляете ли вы или удаляете узлы.
VBucket - это, в основном, "ID раздела" или "осколок". На протяжении всего времени жизни кластера vBucket для данного ключа является постоянным. В принципе:
vbucket = hash(key) % number_of_vbuckets-1
Поскольку общее количество vbucket никогда не изменится в течение всего срока действия кластера, vbucket является постоянным.
Чтобы определить, какому серверному узлу принадлежит данный vBucket, каждый сервер имеет синхронизированную "Карту кластеров", которая в основном обеспечивает отображение, определяющее, какой vBucket принадлежит какому серверу. Эта карта принимается клиентом на начальном этапе подключения и периодически обновляется (различными способами).
Клиенты при отправке запросов данных (получить, сохранить) указывают в пакете запроса фактический vbucket, к которому принадлежит элемент. Если все хорошо, клиент отправит запрос на правильный сервер, и операция продолжится.
Ребаланс - это концепция переназначения vbuckets на другие серверы. В случае добавления узла новый узел становится владельцем некоторых vbuckets, ранее принадлежавших другим узлам; в случае удаления узла каждый из оставшихся серверов получает дополнительные vbuckets, принадлежащие старому узлу.
Перебалансировка выполняется постепенно; это означает, что не все vbuckets передаются одновременно. Во время этого процесса клиент может отправлять запросы на старый узел для vbuckets, которым он больше не владеет. Когда это происходит, узел отвечает сообщением об ошибке "НЕ МОЙ VBUCKET", по сути говоря, сообщая клиенту, что он больше не отвечает за этот vbucket, и что клиент должен перенастроить себя. Затем клиент самостоятельно изменит внутреннюю конфигурацию и отправит операцию на правильный узел.
Если узел полностью удален, клиент также примет это как подсказку для перенастройки и снова отправит операцию на правильный узел.
Если клиент отправляет запрос на vbucket непосредственно перед его передачей, передача просто задерживается до тех пор, пока эта конкретная операция не будет снова распространена на новый узел.
Во всех случаях из-за архитектуры Couchbase всегда существует явное соглашение между клиентом и каждым узлом о том, является ли этот узел правильным для операции.
Во время перебалансировки свопа вы правы, данные копируются из удаленного узла в новый узел. На самом простом это делает это v_bucket за один раз. Во время копирования хэш-карты клиент использует точки на v_bucket на исходящем узле. Как только все данные были скопированы, включая любые изменения, сделанные во время копирования, v_bucket на исходящем узле блокируется для обновления, затем хэш-карта изменяется, чтобы указывать на v_bucket на новом узле. При переключении между v_buckets будет наименьшее прерывание, но все это должно обрабатываться клиентом, и вы не ожидаете появления каких-либо проблем, только небольшое увеличение времени отклика во время переключения. Все данные остаются доступными во время перебалансировки. Затем он переходит к следующему v_bucket.