|
|
|
|
|
You can use IBC Messaging to notify the Secondary that the data volumes in the Primary RVG are consistent at the application-level.
Click the thumbnail above to view full-sized image.
Using IBC messaging, you can inject a user-defined control message into the update stream of an RVG at a point when the Primary is consistent at the application level. When the IBC message reaches the Secondary, data volumes on the Secondary are frozen and any new updates received after the IBC message are logged into the Secondary SRL. As a result, the Secondary does not reflect further updates to data volumes until the user acknowledges the IBC message.
The Secondary data volumes are now consistent at the application level.
Click the thumbnail above to view full-sized image.
While replication is frozen, take snapshots of the data volumes on the Secondary. The created snapshot volumes are consistent at the application level and require less time to recover when the application on the Secondary starts.
An application must be in a quiesced mode before the IBC message is sent to the Secondary, to achieve application-level consistency. For a database application running on the Primary host, an IBC message can be inserted at a point at which the application considers its raw volume contents to be consistent, such as during the database hot-backup mode.
In the case of a file system, when you enter the sync command on the Primary to flush the previously unwritten file system buffers to the data volume, the file modifications up to that point are saved to the data volume. You can insert an IBC message on the Primary to notify the Secondary that the sync command is complete. In general, there is no way to keep the file system in the synced state while you generate the IBC; however, if this is done as soon as the sync completes, there should be little to recover on the Secondary.
Even if you are using synchronous replication, IBC Messaging is useful to notify the Secondary when the consistency point is reached and to ensure that the writes on the Secondary are written to the data volumes after the snapshot is taken.
When the IBC reaches the Secondary, the subsequent updates are logged into the SRL, and the data volumes are frozen. Now, the Secondary data volumes are consistent at the application level, and you can take a snapshot. If you take a backup of the snapshot volumes, the file systems on the backup volumes are consistent.
Click the thumbnail above to view full-sized image.
An IBC message is delivered to the Secondary host in causal order with respect to other activity on the data volumes. Before delivery of the message to the Secondary host, any previous update activity is flushed. You have the option of allowing subsequent updates to be applied immediately to the Secondary data volumes, or logging the subsequent updates into the SRL until released by unfreezing the Secondary RVG. Since the purpose of the IBC message is to achieve a sync point on the Secondary, choose the option to stop subsequent updates until the snapshot is taken. This is the default option in the examples below.
IBC messages are guaranteed to be delivered at least once and might be delivered more than once if an error such as a network outage or machine crash occurs during the delivery. The script you write to perform the IBC operation must be able to manage receiving the multiple delivery of the same IBC message.
If the Secondary crashes before it receives the IBC, the receiving program must be restarted when the Secondary comes up again. Note that in a shared disk group environment, if the node that is the current master leaves the cluster, the IBC program must re-register the application name on the node that becomes the master.