No you cannot do do this. The IP's used within the connection string should all be for the same Centera.
Should the primay Centera become unavailable, it would require that this connection string be changed to the secondary Centera. Bi-directional replication should be enabled to ensure the clusters stay in sync should you ever have to do this.
Should portions of the primary Centera become unavailable where requested data resides on offline nodes, the Centera SDK automatically does read failovers to the replica to retrieve the requested data. The failover is only done for read operations.
An automatic failover is typically not what people want as the disruption to the primary could be temporarily and the application would have switched prod to the secondary already. An automatic failback would not happen when the primary becomes available again. Network and latency would sometimes make this automatic failover problematic too.
The read failover of the SDK ensures reads are still possible. The failover of production is then a manual process after the decision for it to happen.
EMCDennis
124 Posts
0
March 3rd, 2010 14:00
No you cannot do do this. The IP's used within the connection string should all be for the same Centera.
Should the primay Centera become unavailable, it would require that this connection string be changed to the secondary Centera. Bi-directional replication should be enabled to ensure the clusters stay in sync should you ever have to do this.
Should portions of the primary Centera become unavailable where requested data resides on offline nodes, the Centera SDK automatically does read failovers to the replica to retrieve the requested data. The failover is only done for read operations.
holgerjakob_c0722c
2 Intern
•
337 Posts
0
March 3rd, 2010 21:00
Hi Al
An automatic failover is typically not what people want as the disruption to the primary could be temporarily and the application would have switched prod to the secondary already. An automatic failback would not happen when the primary becomes available again. Network and latency would sometimes make this automatic failover problematic too.
The read failover of the SDK ensures reads are still possible. The failover of production is then a manual process after the decision for it to happen.
Best regards, Holger