「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 File DistributorGroupHandlerPhase1.cc PID: 16776 [Info] 通常フェーズ1のキャッシュ・メモリーが不足しています m_GroupGridCopyRID = (groupCopyRID=(kVolSlot=XXXXXXXXXX,globalCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXXXXX) 0) ),gridCopyID=0) XXXX/XX/XX 18:59: 25.694-#2-16911/16776-RemoteLogSender: イベントを受け取りました (uniqueId=0、eventTime=1584471565693987)、EventID_KBOX_ASSERTION_FAILED (3031)、SiteUID (0xxxxxxxxxxxxxxxxx)、seDetails=Sender=replication、 Topic=DistributorGroupHandler、msg=アサーションに失敗しました: bIsPhase1CacheMemorySufficient Line 1825 File DistributorGroupHandlerPhase1.cc PID: 16776 [INFO] 通常のフェーズ1のキャッシュ・メモリーが不足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 (0xXXXXXXXXXXXX) 0) gridID = 0): { 統計: name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 説明: init nc one phase speed . 統計情報: name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 8秒ウィンドウ: 平均：1.14e + 03 MB/秒 統計情報: name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 77秒のウィンドウ: 平均：1.06e + 03 MB/秒 コンシステンシー グループが初期化状態です。 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-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)

対処方法: 微調整 t_phase1CacheMemoryThreadSleepTime の値を5000に変更します。(待機時間を10マイクロ秒から5ミリ秒に増加)。これにより、スレッドがメモリを 5 ミリ秒待機するまでアサートされなくなります。問題が引き続き発生する場合は、次の手順を実行します。1.本番サイトのログも収集してください。問題発生時に本番環境から送信されたデータの量がわかるためです。2.微調整t_maxNoOfTriesToWaitForPhase1CacheMemoryの値を10に変更します。注：これらの調整は、バージョン5.1.3以降にのみ関連します。コード バージョンが5.1.3以降でない場合、これらの調整機能を利用するには、RecoverPointを最新のコードにアップグレードする必要があります。解像度：Dell EMCエンジニアリングでは現在この問題を調査中です。恒久対策はまだ準備中です。Dell EMCカスタマー サポート センターまたはサービス担当者に連絡して、このソリューションIDを伝えてください。