RecoverPoint: Il processo di replica si arresta in modo anomalo quando la memoria cache di fase 1 diventa insufficiente

Lo stato del consistency group continua a essere in inizializzazione, ma la distribuzione normale sembra non avviarsi mai e il CG non passa a uno stato attivo. Un processo di replica si arresta in modo anomalo con un'asserzione registrata quando la memoria cache di fase 1 non è sufficiente e i RecoverPoint Appliance lato destinazione non sono in grado di scrivere nel journal di destinazione. Sintomi riscontrati nei log /home/kos/replication: Asserzione: XXXX/XX/XX 18:59:25.693 - #2 - 17936/16776 - AssertLogSender: invio log: topic=DistributorGroupHandler, msg=Asserzione non riuscita: bIsPhase1CacheMemorySufficient Riga 1825 File DistributorGroupHandlerPhase1.cc PID: 16776 Info: memoria cache di fase 1 regolare non sufficiente m_GroupGridCopyRID = (groupCopyRID=(kVolSlot=XXXXXXXXXX,globalCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXXXXX) 0) ),gridCopyID=0) XXXX/XX/XX 18:59:25.694 - #2 - 16911/16776 - RemoteLogSender: ha ricevuto l'evento (uniqueId=0, eventTime=1584471565693987), EventID_KBOX_ASSERTION_FAILED(3031), SiteUID(0xxxxxxxxxxxxxxxxxxxx), seDetails=Sender=replica, Topic=DistributorGroupHandler, msg=Asserzione non riuscita: bIsPhase1CacheMemorySufficient Riga 1825 File DistributorGroupHandlerPhase1.cc PID: 16776 Info: regular phase1 cache memory not sufficient m_GroupGridCopyRID = (groupCopyRID=(kVolSlot=XXXXXXXXXX,globalCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXX) 0) ),gridCopyID=0) Statistiche che mostrano un flusso di dati elevato: XXXX/XX/XX 18:52:41.520 - #2 - 7676/7665 - AccumulatorFormatManager::p rintStatistics: Statistiche di gruppo per gruppo Opzione( kVolSlot = XXXXXXXXXX groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXX) 0) gridID = 0): { STATISTICHE: name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 descrizione: init nc velocità monofase . STATISTICHE: name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 Finestra di 8 sec: Nella media: 1,14e+03 MB/sec STATISTICHE: name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 Finestra di 77 sec: Nella media: 1,06e+03 MB/sec Un consistency group è in stato di inizializzazione: 17/03/2020 18:56:05.070 - #2 - 7954/7665 - InitNCState::D istributeOnePhase: distribuzione di una fase m_groupID = (groupCopyRID=( kVolSlot=XXXXXXXXXX,globalCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXXX) 0) ),gridCopyID=0) Il consumer della fase 1 per questo consistency group mostra un consumo elevato sull'asserzione: XXXX/XX/XX 18:56:05.241 - #2 - 7954/7665 - MemoryManager: visualizzazioni su asserzione + conti alla rovescia = 2413/390 + Richiesta minima di memoria = 433429 (103892 fissa 329537 flessibile) + spazio di utilizzo flessibile = 37977/3864963 + utilizzo dello spazio del pool = 37985/4194500 (massimo 143544) >> 1160635626647715840 :p hase1#22 >> (groupTaskID=(sessionID=1817723153,replicationLinkID=(kVolSlot=XXXXXXXXX,srcCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXXX) >> 0) ,destCopyID=GlobalCopy(SiteUID Viene inoltre riscontrato StackTrace di replica: 17/03/2020 18:56:05.278 - #0 - 7954/7665 - StackTrace: errno=0 3: /home/kos/kashya/archivio/lib/libreplication_libsrelease.so(_ZNK6Kashya23DistributorGroupHandler21waitForMemoryIfNeededEv+0x5b2) [0xxxxxxxxxxxxx] 17/03/2020 18:56:05.278 - #0 - 7954/7665 - StackTrace: errno=0 4: /home/kos/kashya/archivio/lib/libreplication_libsrelease.so(_ZN6Kashya23DistributorGroupHandler25addSequencesToPhase1CacheENS_9SequencesERNS_15ReplicationModeE+0x939) 17/03/2020 18:56:05.278 - #0 - 7954/7665 - StackTrace: errno=0 5: /home/kos/kashya/archivio/lib/libreplication_libsrelease.so(_ZN6Kashya23DistributorGroupHandler23handleSplittedSequencesENS_9SequencesERKNS_15ReplicationModeERKb+0x20a) 17/03/2020 18:56:05.278 - #0 - 7954/7665 - StackTrace: errno=0 6: /home/kos/kashya/archivio/lib/libreplication_libsrelease.so(_ZN6Kashya23DistributorGroupHandler15handleSequencesENS_9SequencesERKNS_15ReplicationModeERKb+0x577) 17/03/2020 18:56:05.278 - #0 - 7954/7665 - StackTrace: errno=0 7: /home/kos/kashya/archivio/lib/libreplication_libsrelease.so(_ZN6Kashya19Distributor_AO_IMPL23continueHandleSequencesENS_9SequencesENS_15ReplicationModeEbRKNS_10GridCopyIDE+0xf7) 17/03/2020 18:56:05.278 - #0 - 7954/7665 - StackTrace: errno=0 8: /home/kos/kashya/archivio/lib/libreplication_libsrelease.so(_ZN6Kashya16SequencesRequest21continueHandleRequestERNS_28JournalRegulationRequestBase14RequestHandlerE+0x30b) 17/03/2020 18:56:05.278 - #0 - 7954/7665 - StackTrace: errno=0 9: /home/kos/kashya/archivio/lib/libreplication_libsrelease.so(_ZN6Kashya31JournalRegulationThread_AO_IMPL9process_iERKNS_16GroupGridCopyRIDE+0x36f)

Soluzione alternativa: Modificare il valore dell't_phase1CacheMemoryThreadSleepTime di modifica impostandolo su 5000. (Aumento del tempo di attesa da 10 microsecondi a 5 millisecondi). In questo modo non verrà eseguita un'asserzione fino a quando il thread non rimane in attesa di memoria per 5 millisecondi. Se il problema persiste: 1. Raccogliere anche i registri del sito di produzione. Poiché ci farà sapere la quantità di dati inviati dalla produzione al momento del problema. 2. Modificare il valore del tweak t_maxNoOfTriesToWaitForPhase1CacheMemory impostandolo su 10. Nota: Queste modifiche sono rilevanti solo per le versioni 5.1.3 e successive. Se la versione del codice non è 5.1.3 o successiva, RecoverPoint DEVE essere aggiornato al codice più recente per utilizzare queste modifiche. Risoluzione: Dell EMC Engineering sta attualmente esaminando questo problema. Non è ancora disponibile una correzione permanente. Contattare Dell EMC Customer Support Center o un responsabile del servizio per assistenza e riportare l'ID di questa soluzione.