Far Sync is a great technology. When implementing a Disaster Recovery (DR) scenario, the first remark is usually “We want zero Data Loss”. This is exactly what Data Guard is meant for in Synchronous mode. Together with that usually comes “But our second site is really far away”. Those two requirements, don’t mix very well, that is where Far Sync comes into play.

Recently I received a question: “but what happens if the network on the Far Sync location is unstable”?
Well, we can solve that by adding an alternate Far Sync instance and adding Redo Routes and, as of 12.2, priorities (and eventually groups).

So let me illustrate this with an example. I won’t dig into the how-to-set-this-up as the Oracle Documentation contains great information on how to do this correctly.
I would definitely recommend you to use the Data Guard broker, as this massively eases the administration and the setup of this installation.

My configuration looks like this

And in the broker it looks like this:

So primary sends redo to FS1 and that one sends it to the standby. 
In this case following redo routes are active

Then I kill the dgdemovm1fs1 far_sync and we expect that dgdemovm1fs1a takes over, and end up with following situation:

So let’s verify.

So it’s dead now.
In the alertlog of the FS1

So this one is definitely dead.
When we now check the broker lag, because that refreshes on execution of the command:

We see that fs1a took over as expected.
So now we will bring back the fs1 instance:

And we now expect to be in this situation again

Does it do that?

It does!
This is also one of the reasons I also use Virtual box, so I can simulate things easily. I loaded my system heavily so it gives time to check logs and check broker status, and in the meantime DURING the FS1 Far sync came back, you can see that temporarily they are there both:

You see? FS1 has a higher priority than FS1A so the moment that one comes back it gets our preference. However, before it is fully functional, we still trust FS1A to do the job before we fully switch to FS1 again.

Ok let’s play with priorities here.
These are the Redo routes what we got in place remember:

Before we can play with RedoRoutes and priorities, it is necessary to disable fast start failover (FSFO). It is not relevant for this blog post to have it enabled anyway.

There we go.
We can now update the priorities.

Trust but verify

So we are good to go. What we did here is that we put the same priority for FS1 and FS1A. This means, they should be treated equally and not go back to the other FS-instance the moment the previous one comes back.

So let’s show this.
We will kill pmon from FS1 again to get from this

to this again

There goes poor pmon again

As we saw before, the alternate takes over as expected

Notice the ORA-12514 Warning. It is true! So even we know something is wrong, just by looking at the broker.

So what happens now when we bring it back?What you think? It has the same priority right?

Then we verify in the broker

It clears the warning, but it does NOT fail back to FS1. They have the same priority, so for the redo stream all is ok to use this route.

The moment we kill fs1a

We expect to fall back to the original route.
So, lets do this

Then we see that fs1 takes over again

With the same Warning, but this time for FS1A.
When we then bring back FS1A

And we check in the broker and we expect no changes apart of getting rid of ORA-12514, right?

And that is basically what it does!
As you see, I did nothing manually and basically it comes down to the question “against what do you want to be protected”? 
But an unstable Far Sync can be handled by setting equal priorities. Real High Availability, can be achieved by prioritising the one over the other. 

This is how we can provide Zero Data Loss, at ANY distance.

As always, questions, remarks? 
find me on twitter @vanpupi