Unsolved
This post is more than 5 years old
8 Posts
0
1675
March 28th, 2011 13:00
Working with merged PEA files
Folks,
We have a set of PEA files that allow us to write to our primary Centera and then replicate to our remote Centera. Also if the primary Centera is down, we can connect to the replica (and replicate back to the original when it returns).
The issue I have, is that if the secondary Centera is unavailable, I cannot write to the primary Centera since the PEA file cannot validate against the replicated Centera. Is this working correctly or have we done something wrong along the way?
Thanks
Jim
No Events found!
holgerjakob_c0722c
2 Intern
•
337 Posts
0
March 30th, 2011 01:00
Hi Jim
Which application are you connecting with?
There are pool open options like lazy pool open to tell the application not trying to connect to the secondary unless it is necessary for read failover.
I'm not sure if this can be set in an environment variable if your application does not allow to configure this.
It may also be that it just takes extremely long for the pool open command to complete and your application does not wait long enough.
Holger
holgerjakob_c0722c
2 Intern
•
337 Posts
0
March 30th, 2011 06:00
Hi Jim
The lazy pool open does not have a direkt link to replication and the replication not being able to replicate.
The lazy pool open will let you connect during the time the replica system is down instead of timing out as no connection to the secondary is possible.
Replication will keep new objects in the replication queue until they can be replicated. It may be that the replication goes into a paused state but then a "replication resume" will start it again. Just make sure you don't do a set cluster replication to disable replication. In this case the queue will be lost. But even that is not really a problem as you could just perform a partial restore for the timeframe that the secondary was not reachable.
From my point of view a lazy pool open should help you out. Centera will take care of replication itself.
If you want I could also have a quick look on the systems to check their basic health and if they are in synch now. Just need a remote session and an open Centera Viewer.
Holger
thepops
8 Posts
0
March 30th, 2011 06:00
My concern is that I may know that the replica Centera will be down (perhaps they are doing facility maintainence and need to power down, or they are doing network upgrades that will cause the network to be down) but still want to be able to write to the primary Centera and then let replication catch up after the planned outage is over. (and obviously that would work the same for an unplanned outage as well). So it sounds like using the lazy pool open in my application (it's a homegrown application) will handle this situation?
thanks
Jim
holgerjakob_c0722c
2 Intern
•
337 Posts
0
April 1st, 2011 07:00
Hi John
There's no need to re-write; it's just another parameter in the pool open call.
Your application will still have the secondary IP's stored in the API unless you reconnect after reconfiguring replication.
Depending on the situation your scenario will definitely come in very handy.
We've used similar stuff for testing failover scenarios. Have another profile point in the same pool and use the second ip address. Mostly used it to test applications behaviour.
Best regards, Holger