SQL запросов, возвращающих неверные результаты во время высокой нагрузки - PullRequest
Новая
       22

SQL запросов, возвращающих неверные результаты во время высокой нагрузки

0 голосов
/ 21 апреля 2020

У меня есть таблица, в которой во время выполнения производительности вставки происходят в начале, когда начинается задание, во время вставки в эту таблицу также выполняются параллельные операции (запросы GET / UPDATE). Операция Get также обновляет значение в столбце, помечая эту запись как выбранную. Однако при следующем выполнении таблицы снова возвращается та же запись, даже если запись была помечена как выполняемая.

PS -> обе операции выполняются одним и тем же потоком, существующим в системе. Журналы ниже для справки, запись, отмеченная в ходе выполнения в строке 1 20: 36: 42 864 , однако она возвращается обратно в результирующий набор запросов, выполненных после 20: 36: 42 891 по той же теме. Мы также заметили, что во время высокой нагрузки (обычно в том же сценарии, как упомянуто выше) некоторые операции обновления (прерывистые) не выполняются в таблице, даже когда обновление выполнено успешно (проверяется с использованием возвращенного результата, а затем выполняется проверка сразу после этого для проверки обновленное значение) без исключения.

13 апр. 2020 г. 20: 36: 42,864 [SHT-4083-initial] FINEST - AbstractCacheHelper.markContactInProgress: 2321 - Состояние действия после пометки в ходе выполнения contactId.ATTR =: 514409 для jobId: 4083 is actionState: 128

13 апреля 2020 г. 20: 36: 42 891 [SHT-4083-initial] FINEST - CacheAdvListMgmtHelper.getNextContactToProcess: 347 - Запрос: выбрать приоритет, contact_id, action_state, action_state, pim_contact_storeid_ retry_session_id, try_type, zone_id, action_pos из pim_4083, где handler_id =? и try_type! =? и next_attempt_after <=? и action_state =? и исключить_флаг =? упорядочить по типу попытки c, приоритету c, следующему_паттеру_after как c, contact_id как c limit 1 </p>

Это обычно происходит во время прогонов производительности, когда запущены параллельные JOB, которые работают над Ignite. Кто-нибудь может подсказать, что можно сделать, чтобы избежать такой ситуации ..?

У нас есть 2 узла воспламенения данных, которые развернуты как springBootService, развернутые в доступном кластере, 3 клиентскими узлами. Версия Ignite -> 2.7.6, конфигурация кэша следующая, 

IgniteConfiguration cfg = new IgniteConfiguration();
   CacheConfiguration cachecfg = new CacheConfiguration(CACHE_NAME);
   cachecfg.setRebalanceThrottle(100);
   cachecfg.setBackups(1);
   cachecfg.setCacheMode(CacheMode.REPLICATED);
   cachecfg.setRebalanceMode(CacheRebalanceMode.ASYNC);
   cachecfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
   cachecfg.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
   // Defining and creating a new cache to be used by Ignite Spring Data repository.
   CacheConfiguration ccfg = new CacheConfiguration(CACHE_TEMPLATE);
   ccfg.setStatisticsEnabled(true);
   ccfg.setCacheMode(CacheMode.REPLICATED);
   ccfg.setBackups(1);
       DataStorageConfiguration dsCfg = new DataStorageConfiguration();
           dsCfg.getDefaultDataRegionConfiguration().setPersistenceEnabled(true);
           dsCfg.setStoragePath(storagePath);
           dsCfg.setWalMode(WALMode.FSYNC);
           dsCfg.setWalPath(walStoragePath);
           dsCfg.setWalArchivePath(archiveWalStoragePath);
           dsCfg.setWriteThrottlingEnabled(true);
           cfg.setAuthenticationEnabled(true);
       dsCfg.getDefaultDataRegionConfiguration()
            .setInitialSize(Long.parseLong(cacheInitialMemSize) * 1024 * 1024);
       dsCfg.getDefaultDataRegionConfiguration().setMaxSize(Long.parseLong(cacheMaxMemSize) * 1024 * 1024);
       cfg.setDataStorageConfiguration(dsCfg);

   cfg.setClientConnectorConfiguration(clientCfg);
   // Run the command to alter the default user credentials
   // ALTER USER "ignite" WITH PASSWORD 'new_passwd'
   cfg.setCacheConfiguration(cachecfg);
   cfg.setFailureDetectionTimeout(Long.parseLong(cacheFailureTimeout));
   ccfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
   ccfg.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
   ccfg.setRebalanceMode(CacheRebalanceMode.ASYNC);
   ccfg.setRebalanceThrottle(100);
   int pool = cfg.getSystemThreadPoolSize();
       cfg.setRebalanceThreadPoolSize(2);
   cfg.setLifecycleBeans(new MyLifecycleBean());
   logger.info(methodName, "Starting ignite service");
   ignite = Ignition.start(cfg);
   ignite.cluster().active(true);
   // Get all server nodes that are already up and running.
   Collection<ClusterNode> nodes = ignite.cluster().forServers().nodes();
   // Set the baseline topology that is represented by these nodes.
   ignite.cluster().setBaselineTopology(nodes);
   ignite.addCacheConfiguration(ccfg);
...