Latency protection has two components, its mode, and the
latency_low_mark which specify when the protection is active or inactive. The
latency_high_mark specifies the maximum number of waiting updates in the SRL before the protection becomes active and writes stall or fail, depending on the mode of latency protection.
latency_low_mark must be a number lower than the
latency_low_mark is the number of writes in the SRL when the protection becomes inactive and writes succeed. You can set up latency protection by setting the
latencyprot attribute to either
fail. Setting the attribute to
off, which is the default, disables latency protection.
Setting the attribute to
override enables latency protection. The following sections explain how VVR controls replication depending on the setting of the
latencyprot attribute of the RLINK when the Primary and Secondary either connected or disconnected.
The following table summarizes how the state of the RLINK affects the latency protection:
latencyprot=fail or override
Under normal operation, if the number of waiting writes increase and reach the
latency_high_mark, following writes are stalled in the operating system of the Primary until the SRL drains sufficiently to bring the number of waiting writes below the
Primary and Secondary are said to be disconnected when they are in the paused state or are disconnected because of a network outage, or an outage of the Secondary node.
VVR allows the number of writes in the SRL to exceed the
latency_high_mark. In this case, VVR causes latency protection to be overridden and allows incoming writes from the application whose data is being replicated. VVR does not stall incoming writes because the SRL is currently not draining and incoming writes may be stalled indefinitely. Stalling of incoming writes is undesirable for the writing application. Most system administrators set
If replication is paused and not resumed, or if there is an extended network outage, the outstanding writes can exceed the latency high mark. When the Secondary reconnects either because replication is resumed or the network becomes available, VVR starts stalling writes until the writes in the SRL reach the latency low mark. The time required for the Primary to send the accumulated writes to the Secondary can take a long time depending on the amount of data to be sent and the bandwidth of the network. The application perceives this as VVR being unresponsive and some applications may time out resulting in application error.
If the number of writes in the SRL reaches the
latency_high_mark while the Primary and the Secondary are disconnected, VVR causes new writes at the Primary to fail. This prevents the Secondary from falling further behind than specified by the