RecoverPoint : Le processus de réplication se bloque lorsque la mémoire cache de la phase 1 devient insuffisante

L’état du groupe de cohérence reste en initialisation, mais la distribution normale ne semble jamais démarrer et le groupe de cohérence ne passe pas à l’état actif. Un processus de réplication se bloque avec une assertion consignée, lorsque la mémoire cache de phase 1 n’est pas suffisante et que les appliances RecoverPoint côté cible ne sont pas en mesure d’écrire dans le journal cible. Symptômes détectés dans les logs /home/kos/replication : Assertion: XXXX/XX/XX 18:59:25.693 - #2 - 17936/16776 - AssertLogSender : sending log : topic=DistributorGroupHandler, msg=Assertion failed : bIsPhase1CacheMemorySufficient Line 1825 File DistributorGroupHandlerPhase1.cc PID : 16776 Info : la mémoire cache de phase 1 normale n’est pas suffisante m_GroupGridCopyRID = (groupCopyRID=(kVolSlot=XXXXXXXXXX,globalCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXXXXX) 0) ),gridCopyID=0) XXXX/XX/XX 18:59:25.694 - #2 - 16911/16776 - RemoteLogSender : got event (uniqueId=0, eventTime=1584471565693987), EventID_KBOX_ASSERTION_FAILED(3031), SiteUID(0xxxxxxxxxxxxxxxxx), seDetails=Sender=replication, Topic=DistributorGroupHandler, msg=Assertion failed : bIsPhase1CacheMemorySufficient Line 1825 File DistributorGroupHandlerPhase1.cc PID : 16776 Info : la mémoire cache phase 1 normale n’est pas suffisante m_GroupGridCopyRID = (groupCopyRID=(kVolSlot=XXXXXXXXXX,globalCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXX) 0) ),gridCopyID=0) Statistiques qui montrent un flux de données élevé : XXXX/XX/XX 18:52:41.520 - #2 - 7676/7665 - AccumulatorFormatManager ::p rintStatistics : Statistiques de groupe pour le groupe Option( kVolSlot = XXXXXXXXXX groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXX) 0) gridID = 0) : { STATISTIQUES : name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 description : init nc vitesse monophasée . STATISTIQUES : name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 8 sec window : Moyenne: 1,14e+03 Mo/s STATISTIQUES : name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 77 sec window : Moyenne: 1,06e+03 Mo/s Un groupe de cohérence est à l’état d’initialisation : 2020/03/17 18:56:05.070 - #2 - 7954/7665 - InitNCState ::D istributeOnePhase : distributing one phase m_groupID = (groupCopyRID=( kVolSlot=XXXXXXXXXX,globalCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXXX) 0) ),gridCopyID=0) Le consommateur de la phase 1 de ce groupe de cohérence affiche une consommation élevée sur l’assertion : XXXX/XX/XX 18:56:05.241 - #2 - 7954/7665 - MemoryManager : viscus on assert + comptes à rebours = 2413/390 + demande minimale de mémoire = 433429 (fixe 329537 flexible 103892) + Espace d’utilisation flexible = 37977/3864963 + Utilisation de l’espace de pool = 37 985/41 94 500 (143544 max.) >> 1160635626647715840 :p hase1#22 >> (groupTaskID=(sessionID=1817723153,replicationLinkID=(kVolSlot=XXXXXXXXX,srcCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXXX) >> 0) ,destCopyID=GlobalCopy(SiteUID Une Replication StackTrace est également rencontrée : 2020/03/17 18:56:05.278 - #0 - 7954/7665 - StackTrace : errno=0 3 : /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZNK6Kashya23DistributorGroupHandler21waitForMemoryIfNeededEv+0x5b2) [0xxxxxxxxxxxxx] 2020/03/17 18:56:05.278 - #0 - 7954/7665 - StackTrace : errno=0 4 : /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZN6Kashya23DistributorGroupHandler25addSequencesToPhase1CacheENS_9SequencesERNS_15ReplicationModeE+0x939) 2020/03/17 18:56:05.278 - #0 - 7954/7665 - StackTrace : errno=0 5 : /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZN6Kashya23DistributorGroupHandler23handleSplittedSequencesENS_9SequencesERKNS_15ReplicationModeERKb+0x20a) 2020/03/17 18:56:05.278 - #0 - 7954/7665 - StackTrace : errno=0 6 : /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZN6Kashya23DistributorGroupHandler15handleSequencesENS_9SequencesERKNS_15ReplicationModeERKb+0x577) 2020/03/17 18:56:05.278 - #0 - 7954/7665 - StackTrace : errno=0 7 : /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZN6Kashya19Distributor_AO_IMPL23continueHandleSequencesENS_9SequencesENS_15ReplicationModeEbRKNS_10GridCopyIDE+0xf7) 2020/03/17 18:56:05.278 - #0 - 7954/7665 - StackTrace : errno=0 8 : /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZN6Kashya16SequencesRequest21continueHandleRequestERNS_28JournalRegulationRequestBase14RequestHandlerE+0x30b) 2020/03/17 18:56:05.278 - #0 - 7954/7665 - StackTrace : errno=0 9 : /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZN6Kashya31JournalRegulationThread_AO_IMPL9process_iERKNS_16GroupGridCopyRIDE+0x36f)

Solution de contournement : Remplacez la valeur de l’option t_phase1CacheMemoryThreadSleepTime par 5000. (Augmentation du temps d’attente de 10 microsecondes à 5 millisecondes). Cela permet de s’assurer que nous n’effectuerons pas d’assertion tant que le thread n’attend pas la mémoire pendant 5 millisecondes. Si le problème persiste : 1. Veuillez également collecter les journaux du site de production. En effet, cela nous permet de connaître la quantité de données envoyées par la production au moment du problème. 2. Remplacez la valeur du t_maxNoOfTriesToWaitForPhase1CacheMemory d’ajustement par 10. Remarque : Ces ajustements ne concernent que les versions 5.1.3 et ultérieures. Si la version du code n’est pas 5.1.3 ou supérieure, RecoverPoint DOIT être mis à niveau vers le code le plus récent pour utiliser ces ajustements. Résolution : Les ingénieurs Dell EMC sont en train d’examiner ce problème. Un correctif permanent est encore en cours d’exécution. Contactez le Centre de support client Dell EMC ou votre responsable de services pour obtenir de l’aide et consultez l’ID de cette solution.