Unsolved
This post is more than 5 years old
8 Posts
0
1122
February 8th, 2011 14:00
Best Practice for rebooting Replistor Source server
I am running Replistor 6.3 on a source server and replicating data to a second server across a VPN tunnel which is at the client's DR site. I occasionaly have to reboot Source server for maintenance and updates, etc.. My question is should I be disabling the specs prior to rebooting or should I just stop forwarding and mirroring? I would like to not have to re-synchronize every time I reboot this server. Thanks for any advice you can give on this topic.
No Events found!
bmartinik-axnd.
8 Posts
0
February 8th, 2011 16:00
Thanks for your help
yito1
262 Posts
0
February 8th, 2011 16:00
Hi,
You will not need to operate Disable or stop forwarding and mirroring.
Note
You had better upgrade it to 6.4SP2HF3.
RepliStor6.3.x is the version that is full of bugs.
jschrade1
106 Posts
0
February 9th, 2011 05:00
Brian,
As mentioned by others, it is not "generally" necessary to do anything before rebooting a server which has active specifications. However, this does not absolutely ensure that a sync will not be required after the machine has restarted. For example, if there is a process running on the machine, such as Exchange, the machine may take a very long time to stop the process and the Windows OS will force the machine down even though the process has not shut down cleanly. In a case like that RepliStor would not know where to restart sending queued file operations. RepliStor writes the ongoing file operations both to physical (RAM) memory and also to a file in the RepliStor Data Directory called KernelCache.rdf. When the machine is restarting RepliStor will pick up at the next operation in the KernelCache.rdf when the services are restarted. If RepliStor cannot find the correct starting point in the KernelCache.rdf file to resume processing, then it will force a message in the GUI that indicates that a new sync is required. It does all this automatically and it does this to keep from sending operations to the Target node that may not be in the same order as they occurred on the Source node.
The above just means that you should always check the RS GUI after a reboot to assess whether a new sync is required. RepliStor does all it can to prevent another sync but in circumstances similar to the above example it will alert the user that a new sync is necessary.
bmartinik-axnd.
8 Posts
0
February 9th, 2011 12:00
Good information here. Thanks!