MirrorView - Syncing Consistency Group - Cannot Sync A Group That Is Already Synchronized

Even then every few seconds (30 I think it is by default) a sync of changed blocks is done.

Are you aware that there’s an Ask the Expert discussion on Replication going on right now? Go see it, ask questions and learn! https://community.emc.com/community/support/ask_the_expert

Why would you want to do that? If the group is already in sync, let the array do it’s job. Every write to the primary LUNs will automatically replicate to the secondary array. The only way to force a complete new sync is to break down the CG, break down each replica from it’s primary LUN and configure it all from scratch, but once again: Why would you do that?

Thanks for the response!

It is not my understanding that a write to the primary will get shipped to the secondary array. Once the group and mirrors complete synchronization you need to resync in order to push fresh data. Please note that we are running MirrorView/A.

We don't have the consistency groups set to ship on a regular basis, we are set for Manual Update. We have scripts in place that force a SYNC of the consistency groups on a daily basis to refresh data in our DR site. Here is an example of the SYNC command that we are running:

naviseccli -h xxx.xxx.xxx.xxx mirror -async -syncgroup -name group name -synctype startnow -o

The Mirrors in the consistency group show that they were last updated weeks ago, hence the desire to force a SYNC of the group. Lastly, a query of the Mirror from the CLI that we report with shows that the last update was 14590 minutes ago.

I look forward to your response!

This could be a link issue as you have mentioned that the updates are triggered manually everyday and when checked the CG info it states that the CG’s were updated weeks before. Few things that I would want to gather info from you

1. I would want you to check the links between the Primary and the secondary.
2. How many mirrors are there and is this error happening on only one mirror or all.
3. Shoot this command : naviseccli –h mirror -async -info (Please paste the output informing about the mirror conditions)
4. After this you should give naviseccli -h mirror -async -listgroups -name : to see the current state for a particular group on which you are running the updates periodically.

Note : If you are running the  commands in a sequence you need to add delays between then to ensure that the previous task is completed. The script has be to adjusted. More specifically, add delays in the script between the commands as well as checks to confirm whether the previous command has completed successfully. The busier the array is, the more activity and possibly the more MV/A mirrors there are trying to resynchronize at the same time. As a result, the exact timing of how long the preparation steps take will vary depending on many other factors such as load on the array and the SPs.

When a primary cannot communicate with a secondary consistency group, the group’s condition changes to system fractured. When a consistency group is system fractured, no writes are propagated to the secondary consistency group. The primary storage system attempts to minimize the amount of work required to synchronize the secondary after it recovers. It keeps track of the write requests to the consistency group, so that only modified areas will be copied to the secondary during recovery. Also, consider the case where the consistency group has some members whose primary image LUNs reside on SP A and some on SP B. If the MirrorView/A connection is broken between SP Bs of the primary and the secondary storage system, the consistency group is system fractured to maintain the consistent state of the consistency group.

If the above steps does not help then we will have to dig in the logs to get the root of the issue.

Further issues, As RRR suggested the link is https://community.emc.com/community/support/ask_the_expert

Lets discuss it there!!!