RecoverPoint: 1단계 캐시 메모리가 부족해지면 복제 프로세스가 충돌함

정합성 보장 그룹의 상태는 계속 초기화 중이지만 정규 분포가 시작되지 않는 것으로 보이며 CG가 활성 상태로 전환되지 않습니다. 1단계 캐시 메모리가 충분하지 않고 타겟 측 RecoverPoint Appliance가 타겟 저널에 쓸 수 없는 경우 어설션이 기록된 복제 프로세스가 충돌합니다. /home/kos/replication 로그에서 발견된 증상: 주장: XXXX/XX/XX 18:59:25.693 - #2 - 17936/16776 - AssertLogSender: 로그 전송: topic=DistributorGroupHandler, msg=어설션 실패: bIsPhase1CacheMemorySufficient Line 1825 파일 DistributorGroupHandlerPhase1.cc PID: 16776 정보 : 일반 phase1 캐시 메모리가 충분하지 않음 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=어설션 실패: bIsPhase1CacheMemorySufficient Line 1825 PID DistributorGroupHandlerPhase1.cc 파일: 16776 정보 : 일반 phase1 캐시 메모리가 충분하지 않음 m_GroupGridCopyRID = (groupCopyRID=(kVolSlot=XXXXXXXXXX,globalCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXX) 0)),gridCopyID=0) 높은 데이터 흐름을 보여주는 통계: XXXX/XX/XX 18:52:41.520 - #2 - 7676/7665 - AccumulatorFormatManager::p rintStatistics: 그룹에 대한 그룹 통계 옵션(kVolSlot = XXXXXXXXXX groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXX) 0) gridID = 0): { 통계: name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 설명: init nc 단상 속도. 통계: name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 8초 기간: 평균의: 1.14e+03MB/초 통계: name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 77초 기간: 평균의: 1.06e+03MB/초 정합성 보장 그룹이 초기화 상태입니다. 2020/03/17 18:56:05.070 - #2 - 7954/7665 - InitNCState::D istributeOnePhase: 1상 배포 m_groupID = (groupCopyRID=( kVolSlot=XXXXXXXXXX,globalCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXXX) 0) ),gridCopyID=0) 이 정합성 보장 그룹의 1단계 소비자는 어설션에서 높은 사용량을 보이고 있습니다. XXXX/XX/XX 18:56:05.241 - #2 - 7954/7665 - MemoryManager: 어설션 시 viscus + 카운트다운 = 2413/390 + 최소 메모리 요구량 = 433429(고정 329537 유연한 103892) + 유연한 사용 공간 = 37977/3864963 + 풀 공간 사용량 = 37985/4194500(최대 143544) >> 1160635626647715840 :p하세1#22 >> (groupTaskID=(sessionID=1817723153,replicationLinkID=(kVolSlot=XXXXXXXXX,srcCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXXX) >> 0) ,destCopyID=GlobalCopy(SiteUID 복제 스택 추적은 다음과 같은 경험도 있습니다. 2020/03/17 18:56:05.278 - #0 - 7954/7665 - 스택 추적: errno=0 3: /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZNK6Kashya23DistributorGroupHandler21waitForMemoryIfNeededEv+0x5b2) [0xxxxxxxxxxxxx] 2020/03/17 18 : 56 : 05.278-#0-7954/7665-스택 추적 : 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-스택 추적 : 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-스택 추적 : 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 - 스택 추적: 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 - 스택 추적: errno=0 8: /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZN6Kashya16SequencesRequest21continueHandleRequestERNS_28JournalRegulationRequestBase14RequestHandlerE+0x30b) 2020/03/17 18:56:05.278 - #0 - 7954/7665 - 스택 추적: errno=0 9: /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZN6Kashya31JournalRegulationThread_AO_IMPL9process_iERKNS_16GroupGridCopyRIDE+0x36f)

해결 방법: 미세 조정 t_phase1CacheMemoryThreadSleepTime 값을 5000으로 변경합니다. (대기 시간을 10마이크로초에서 5밀리초로 증가) 이렇게 하면 스레드가 5밀리초 동안 메모리를 기다릴 때까지 어설션하지 않습니다. 문제가 계속 발생하는 경우: 1. 운영 사이트 로그도 수집하십시오. 문제 발생 당시 프로덕션에서 전송되는 데이터의 양을 알려주기 때문입니다. 2. 조정 t_maxNoOfTriesToWaitForPhase1CacheMemory 값을 10으로 변경합니다. 참고: 이러한 조정은 버전 5.1.3 이상에만 해당됩니다. 코드 버전이 5.1.3 이상이 아닌 경우 이러한 미세 조정을 활용하려면 RecoverPoint를 최신 코드로 업그레이드해야 합니다. 해결 방법: 현재 Dell EMC 엔지니어링 팀에서 이 문제를 조사하고 있습니다. 영구 수정 작업이 진행 중입니다. Dell EMC 고객 지원 센터 또는 서비스 담당자에게 연락하여 지원을 요청하고 이 솔루션 ID를 참조하십시오.