Понимание кворума/Vnode (R vs PR)

Question

Я делал несколько экспериментов, чтобы понять Riak. Вот кое-что межжала я нашел:

У меня есть кластер из 2 узлов и тип ковша, который имеет n_val из

[root@co-riak002 ~]# riak-admin ring-status 
================================== Claimant =================================== 
Claimant: 'riak@10.172.48.68' 
Status:  up 
Ring Ready: true 

============================== Ownership Handoff ============================== 
No pending changes. 

============================== Unreachable Nodes ============================== 
All nodes are up and reachable 

[root@co-riak002 ~]# riak-admin bucket-type create testBucket '{"props":{"n_val":2}}' 
testBucket created 
[root@co-riak002 ~]# riak-admin bucket-type activate testBucket       
testBucket has been activated 

И тогда я написал что-то в нем:

[root@co-riak002 ~]# curl -XPUT -d '{"bar":"foo"}' -H "Content-Type: application/json" http://localhost:8098/types/testBucket/buckets/stuff/keys/hello?w=2&returnbody=true 
[1] 10890 
[root@co-riak002 ~]# 
[1]+ Done     curl -XPUT -d '{"bar":"foo"}' -H "Content-Type: application/json" http://localhost:8098/types/testBucket/buckets/stuff/keys/hello?w=2 

Теперь я могу прочитать это как с r=2, так и с pr=2:

[root@co-riak002 ~]# curl http://localhost:8098/types/testBucket/buckets/stuff/keys/hello?r=2 
{"bar":"foo"} 
[root@co-riak002 ~]# curl http://localhost:8098/types/testBucket/buckets/stuff/keys/hello?pr=2 
{"bar":"foo"} 

После того как я убил один из узлов, r=2 еще читает хорошо, но не pr=2

[root@co-riak002 ~]# riak-admin ring-status 
================================== Claimant =================================== 
Claimant: 'riak@10.172.48.68' 
Status:  up 
Ring Ready: true 

============================== Ownership Handoff ============================== 
No pending changes. 

============================== Unreachable Nodes ============================== 
The following nodes are unreachable: ['riak@10.172.48.66'] 

С r=2:

[root@co-riak002 ~]# curl http://localhost:8098/types/testBucket/buckets/stuff/keys/hello?r=2 
{"bar":"foo"} 

С pr=2:

[root@co-riak002 ~]# curl http://localhost:8098/types/testBucket/buckets/stuff/keys/hello?pr=2 
PR-value unsatisfied: 1/2 

Я смущен - не должен 't Номер кворума r, используемый в операции чтения означает количество реплик/физических узлов, которые должны быть согласованы перед возвратом данных? Почему он не работает в этом случае? И почему pr работает в этом случае, когда это должно означать число vnodes?

Am довольно новый для этого пространства. Очень ценится для любых указателей.

Answer 1

Вы должны различать «sloppy quorum» и «строгий кворум».

Как вы, вероятно, знаете, к каждой клавише используется хэш-функция для вычисления того, где этот ключ должен располагаться в кластере Riak. Все пространство хэш-значений называется «кольцом» и разделено поровну между vnodes (виртуальными узлами), которые, в свою очередь, назначаются физическим узлам. Назначение выполняется таким образом, чтобы гарантировать, что смежные vnodes относятся к отдельным физическим узлам для надежности, хотя это не всегда возможно. Если репликация включена (т. Е. N_val> 1), ключ записывается не только в его назначение vnode, но также в несколько узлов, которые следуют за vnode на кольце (в большинстве случаев различные физические узлы - см. Выше). Теперь это первичные узлы для этого ключа. Однако в случае неаккуратного кворума (например, W = 2), если первичный узел недоступен, то копии ключа будут записаны в любой vnode, потенциально даже на том же физическом узле. Это нормально, потому что они будут переданы в «правильные» vnodes, как только проблема будет устранена, и станут доступны первичные узлы. Если вы не хотите, чтобы реплики записывались на один и тот же физический узел, даже временно, или хотите, чтобы клиент получал самые последние значения, вы можете explicitly require все или, по крайней мере, некоторые записи, которые должны быть сделаны только для первичных версий (PW = 2, «P» означает «первичный»). Это происходит за счет высокой доступности. Эта же логика работает для чтения.

Надеюсь, это поможет.

Я настоятельно рекомендую вам прочитать «A Little Riak Book». Кроме того, online documentation отлично.

Answer 2

не должен содержать число Кворума r, используемое в операции чтения, означает количество реплик/физических узлов, которые должны согласовываться перед возвратом данных?

Не совсем. Чтение кворума (r) - это число внодов, которые должны обеспечивать приемлемый ответ. Когда вы читаете с одним узлом вниз, остальная часть кластера (в этом случае - оставшийся узел) запускает резервные копии для любых отсутствующих vnodes по мере необходимости.

Когда ваш запрос на чтение с r = 2 поступает, поскольку один vnode в префиксе недоступен, запускается резервное копирование. Естественно, что при первом запуске этот резерв пуст, поэтому процесс чтения получает notfound от резервного и сохраненного объекта от другого.

Тут есть настройка notfound_ok в свойствах или запросах. Если оставить значение по умолчанию notfound_ok=true, то notfound считается действительным ответом, поэтому операция соответствует кворуму, ответ с данными перехватывает notfound, а клиент возвращает объект. Это также запускает восстановление чтения, которое будет заполнять резервную копию этого объекта, поэтому следующий запрос на получение получит 2 объекта и не будет обнаружен ответ.

Если notfound_ok является ложным, первый запрос на чтение будет видеть только 1 действительный ответ и сбой, но чтение исправления по-прежнему происходит, поэтому следующий запрос r = 2 завершается успешно, так как резервная копия также содержит данные.

Правильная тактика использования r = 1, notfound_ok = false для чтения, чтобы получить высокую доступность и максимально возможный ответ, сохраняя при этом разумные заверения, что вы не получите ложных неподтвержденных ответов при сбое узла.