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

Question

Я новичок в 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 кота 7 сервера. мы не указали количество резервных копий, поэтому по умолчанию должно быть 1.

следить за

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

Спасибо!

Answer 1

1. Количество резервных копий 0 по умолчанию. Документация исправлена.
2. Вы правы в режиме REPLICATED. Если вас беспокоит любая потеря данных, режим REPLICATED - единственный способ гарантировать это. Недостатком здесь является то, что записи будут медленнее, так как все узлы в кластере будут обновлены. Преимущество состоит в том, что данные доступны на каждом узле, поэтому вы можете легко получить к нему доступ из своих вычислений, не беспокоясь о том, к какому узлу их отправлять.