Сценарий «Настойчивость и разделение мозгов»

1. Как ignite справляется со сценарием разделения мозга в кластерном режиме?

2. В случае putAll, он попадает в постоянное хранилище для каждой записи или все сразу помещается в хранилище?

3. Как работает putAll в отношении постоянного хранилища, если мы устанавливаем размер пакета?

4. В случае разделения с резервной копией, в каком порядке перемещаются данные? первичный-> резервный-> постоянство или первичный-> резервное копирование тем временем асинхронно в постоянство?

5. Если обновление выполняется в хранилище сохраняемости, что нужно сделать, чтобы отразить его в кеше без перезагрузки? (Как обрабатывать внутренние обновления)

6. При выполнении обновления в бэкэнде и отражении изменений в кеше, если мы перезагружаем кеш с помощью loadCache, изменения не обновляются в кеше или если мы сразу используем get(), также обновления не отражаются. Обновления отражаются только после однократной очистки кеша и последующего вызова loadcache или get api. Это правильный способ перезагрузить кеш?

 Person p1 = new Person(1, "Benakaraj", "KS", 11, 26, 1000);
    Person p2 = new Person(2, "Ashwin", "Konale", 13, 26, 10000);
    Connection con = null;
    Statement stmt = null;

    con = ds.getConnection();
    stmt = con.createStatement();
    String sql =
        "create table Person(per_id int,name varchar(20),last_name varchar(20),org_id int,age int,salary REAL,primary key(per_id))";
    stmt.executeUpdate(sql);

    ROCCacheConfiguration<Integer, Person> pesonConfig = new ROCCacheConfiguration<>();
    pesonConfig.setName("bkendupdtCache");
    pesonConfig.setCacheMode(CacheMode.PARTITIONED);
    JdbcType jdbcType = new JdbcType();

    jdbcType.setCacheName("bkendupdtCache");
    jdbcType.setDatabaseSchema("ROC4Test");
    jdbcType.setDatabaseTable("Person");
    jdbcType.setKeyType(Integer.class);
    jdbcType.setValueType(Person.class);
    // Key fields for PERSON.

    Collection<JdbcTypeField> keys = new ArrayList<>();
    keys.add(new JdbcTypeField(Types.INTEGER, "per_id", int.class, "perId"));
    jdbcType.setKeyFields(keys.toArray(new JdbcTypeField[keys.size()]));

    // Value fields for PERSON.
    Collection<JdbcTypeField> vals = new ArrayList<>();
    vals.add(new JdbcTypeField(Types.INTEGER, "per_id", int.class, "perId"));
    vals.add(new JdbcTypeField(Types.VARCHAR, "name", String.class, "name"));
    vals.add(new JdbcTypeField(Types.VARCHAR, "last_name", String.class, "lastName"));
    vals.add(new JdbcTypeField(Types.INTEGER, "org_id", int.class, "orgId"));
    vals.add(new JdbcTypeField(Types.INTEGER, "age", int.class, "age"));
    vals.add(new JdbcTypeField(Types.FLOAT, "salary", Float.class, "salary"));
    jdbcType.setValueFields(vals.toArray(new JdbcTypeField[vals.size()]));

    Collection<JdbcType> jdbcTypes = new ArrayList<>();

    jdbcTypes.add(jdbcType);

    CacheJdbcPojoStoreFactory<Integer, Organization> cacheJdbcdPojoStorefactory4 =
        context.getBean(CacheJdbcPojoStoreFactory.class);
    cacheJdbcdPojoStorefactory4.setTypes(jdbcTypes.toArray(new JdbcType[jdbcTypes.size()]));

    pesonConfig.setCacheStoreFactory((Factory<? extends CacheStore<Integer, Person>>) cacheJdbcdPojoStorefactory4);
    pesonConfig.setReadThrough(true);
    pesonConfig.setWriteThrough(true);
    ROCCache<Integer, Person> personCache2 = rocCachemanager.createCache(pesonConfig);
    personCache2.put(1, p1);
    personCache2.put(2, p2);
    assertEquals(personCache2.get(2).getName(), "Ashwin");
    sql = assertEquals(personCache2.get(2).getName(), "Abhi");

"update Person set name='Abhi' where per_id=2";
        stmt.execute(sql);

        //fails and asks for assertion with the stale value
        personCache.loadcache(null);
        assertEquals(personCache2.get(2).getName(), "Abhi");

        //works fine
        personCache2.clear(2);
        assertEquals(personCache2.get(2).getName(), "Abhi");

        //works fine
        personCache2.clear();
        personCache2.loadcache(null);
        assertEquals(personCache2.get(2).getName(), "Abhi");

        sql = "drop table Person";
        stmt.executeUpdate(sql);
        con.close();
        stmt.close();
        rocCachemanager.destroyCache("bkendupdtCache");

person Abhishek Shenoy    schedule 17.03.2016    source источник


Ответы (1)


  1. По умолчанию вы получите два независимых кластера, которые больше никогда не соединятся друг с другом (иначе возможна несогласованность данных). Вам придется вручную остановить один из кластеров и перезапустить его после восстановления сети. Однако автоматическое разрешение может быть реализовано в виде плагина. Например, GridGain предоставляет эту функциональность «из коробки»: https://gridgain.readme.io/docs/network-segmentation

  2. Ignites пытается максимально минимизировать вызовы хранилища сохраняемости. Если ваше хранилище поддерживает пакетное чтение и запись, рекомендуется воспользоваться этим преимуществом при реализации методов loadAll, writeAll и removeAll.

  3. Операция пакетного обновления разделит пакет на основе сопоставлений узлов. Каждая часть пакета будет сохранена сразу на соответствующем первичном узле.

  4. Store обновляется атомарно с основным узлом (если запись в хранилище не удалась, кэш не обновляется, и наоборот). По умолчанию резервные копии обновляются асинхронно в фоновом режиме.

  5. Если возможно, вам следует избегать этого и рассматривать Ignite как основное хранилище данных с дополнительным хранилищем на сервере (т. е. всегда получать доступ к данным через Ignite API). Нет простого способа распространять обновления БД в Ignite.

  6. Вы можете сделать записи недействительными, используя метод clear/clearAll, или перезагрузить их, используя метод loadAll. Другой вариант — использовать сроки действия: https://apacheignite.readme.io/docs/expiry-policies< /а>

person Valentin Kulichenko    schedule 18.03.2016
comment
Под размером пакета я имею в виду количество записей в кэше за раз - person Abhishek Shenoy; 18.03.2016
comment
Во время записи даже хранилище обновляется асинхронно? резервная копия по-прежнему будет обновляться асинхронно? - person Abhishek Shenoy; 18.03.2016
comment
С отложенной записью хранилище обновляется асинхронно, это правильно. Будут ли резервные копии обновляться синхронно, определяется свойством CacheConfiguration.writeSynchronizationMode. По умолчанию используется PRIMARY_SYNC, при котором синхронно обновляется только первичный узел. В режиме FULL_SYNC клиент будет ждать всех узлов. - person Valentin Kulichenko; 19.03.2016
comment
Так что же произойдет с несколькими кэшами? В основном три случая: 1) Кэш обновляется более чем в 1 сегменте, но никогда не до одного и того же ключа 2) Кэш обновляется более чем в 1 сегменте, но один и тот же ключ обновляется с обеих сторон (конфликт) 3) Кэш обновляется только в одном сегменте Будут ли три случая обрабатываться по-разному? Будет ли оператор независимых кластеров применяться только к кешу в сценарии 2 или он будет применяться и к 1 и/или 3? - person MotiNK; 10.05.2019