|
|
|
|
|
Latency protection has two components, its mode, and the latency_high_mark and 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.
The latency_low_mark must be a number lower than the latency_high_mark; 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 override or fail. Setting the attribute to latencyprot=off, which is the default, disables latency protection.
Setting the attribute to latencyprot=fail or 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:
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 latency_low_mark.
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 latencyprot=override.
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 latency_high_mark.