Gridgain: как перераспределить кеш в режиме секционирования при выходе из строя одного узла

Я новичок в gridgain, и мы делаем POC с помощью gridgain. Мы сделали несколько простых примеров с использованием секционированного кеша, он работает хорошо, однако мы обнаружили, что когда мы отключаем узел, кеш этого узла исчезает. поэтому мои вопросы: если мы продолжаем использовать режим разделения, есть ли способ перераспределить кеш, когда узел (или несколько узлов) не развернут. если нет, есть ли хороший способ сделать это? Спасибо!

Код конфигурации:

<context:component-scan base-package="com.test" />
 <bean id="hostGrid" class="org.gridgain.grid.GridSpringBean">
    <property name="configuration">
       <bean class="org.gridgain.grid.GridConfiguration">
    <property name="localHost" value="127.0.0.1"/>
    <property name="peerClassLoadingEnabled" value="false"/>
    <property name="marshaller">
        <bean class="org.gridgain.grid.marshaller.optimized.GridOptimizedMarshaller">  
            <property name="requireSerializable" value="false"/>
        </bean>
    </property
    <property name="cacheConfiguration">
        <list>
            <bean class="org.gridgain.grid.cache.GridCacheConfiguration">
                <property name="name" value="CACHE"/>
                <property name="cacheMode" value="PARTITIONED"/>
                <property name="store" >
                    <bean class="com.test.CacheJdbcPOCStore"></bean>
                </property>
            </bean>

        </list>
    </property>
</bean>
     </property>
 </bean>

Мы развернули ту же войну (используя приведенную выше конфигурацию) на 3 серверах tomcat 7. мы не указывали номер резервной копии, поэтому по умолчанию он должен быть равен 1.

продолжить

Я решил эту проблему, поставив в конфигурации backups=1. похоже, что ранее он не создавал резервную копию. однако он должен сделать 1 копию, так как это по умолчанию. Кроме того, когда я попытался вывести из строя 2 узла одновременно, я увидел, что часть кеша исчезла, поэтому я установил backups=2 и на этот раз не обнаружил потери кеша. так что похоже, что в очень плохом случае, когда все узлы, кроме основного узла, выходят из строя, нам нужно иметь # узлов -1 резервных копий, чтобы предотвратить потерю данных. но если я это сделаю, то это похоже на реплицированный режим, а реплицированный режим имеет меньше ограничений на запросы и транзакции. Итак, мой вопрос: если нам нужно воспользоваться преимуществами параллельных вычислений и в то же время мы хотим предотвратить потерю данных при сбое узлов, какова наилучшая практика?

Спасибо!


gridgain
person Aaron L    schedule 03.12.2014    source источник
comment
Можете ли вы предоставить свою конфигурацию? Сколько резервных узлов вы настроили?   -  person Dmitriy    schedule 04.12.2014
comment
Проблема @Dmitriy решена, но остался один вопрос, я добавил его в свой предыдущий пост. Спасибо!   -  person Aaron L    schedule 04.12.2014

Ответы (1)


arrow_upward
0
arrow_downward

  1. По умолчанию количество резервных копий 0. Документация исправлена.
  2. Вы правы насчет режима REPLICATED. Если вы беспокоитесь о какой-либо потере данных, режим REPLICATED — единственный способ гарантировать это. Недостатком здесь является то, что запись будет происходить медленнее, так как все узлы в кластере будут обновлены. Преимущество заключается в том, что данные доступны на каждом узле, поэтому вы можете легко получить к ним доступ из своих вычислений, не беспокоясь о том, на какой узел их отправить.
person Dmitriy    schedule 04.12.2014
comment
Итак, если я использую РЕПЛИКАЦИОННЫЙ РЕЖИМ, могу ли я по-прежнему выполнять параллельные вычисления между узлами таким образом, как «приведение функции к данным» в РЕЖИМЕ РАЗДЕЛЕНИЯ? первое, что приходит мне в голову, это разделить список ключей кеша на списки и отправить на каждый узел, но это может снизить производительность, поскольку требуется пройти большой кеш, содержащий все данные, есть ли хороший способ добиться этого? Спасибо! - person Aaron L; 05.12.2014
comment
@AaronL Я не уверен, что понял концепцию списка списков. О режиме REPLICATED я могу сказать вам, что внутри он рассматривается как режим PARTITIONED, где каждый ключ имеет основной узел, а остальные узлы кластера являются резервными. Вы по-прежнему можете выполнять итерации только по первичному набору, и вам по-прежнему доступна привязка ключей к узлам. - person Dmitriy; 05.12.2014