If you have failover set up correctly, then any application should be able to reconnect to the same address.
You shouldn't have to tell the application locations about secondary (tertiary, etc) servers. Typically what a cluster does when failing over a service (like a database) to a different node is after shutting down the service on the failing node and starting it up on the backup node, it switches the IP address over as well.
Then an application connecting to "db.mydomain.foo" connect to whatever server is currently running the database. | [reply] |
wouldn't it be possible to check the return value of connect and if it fails send another connect string?
| [reply] |
Yes, that's possible. The solution JavaFan mentions is a very nice way to handle the situation, but is not stricly necessary.
There are also the DBD::Multi, DBIx::HA, and DBD::Multiplex modules, each of which takes a slightly different application-level approach to easing the use of multiple database servers.
| [reply] |
Mja, that's possible. Not the way I'd set up things. But I'm confused, your question isn't "In Java I can check the return value of connect, and send another connect string if it fails, but I cannot do that in Perl", is it? In your original question, you said your Perl application was connecting to the same server, and I said that if set up properly, it should indeed connect to the same address - with the cluster taking care of moving addresses around.
| [reply] |
It is certainly possible to do this. I speculate that the problem that tohann may be having is that his script is dying on the first call to connect. This would either be because the RaiseError attribute is turned on, or because there is an or die after the connect call.
It would be nice to see some code.
| [reply]
[d/l]
[select] |
Thank you everyone for your replies so far!
It's a connect or die situation. Here is the code:
$fromDBH = DBI->connect("DBI:DB2:$fromDB", $username, $password, {Auto
+Commit => 0})
or closing('ReportAgg.pl', "Couldn't connect to $fromDB :\n\n" . D
+BI->errstr, FALSE, $fromSTH, $fromDBH, $toSTH, $toDBH);
the closing subroutine has a little more logging and then dies from the script.
One thing I failed to mention that might help is that we're using WebSphere for our application server and that handles the HADR failover nicely. Nothing needs to be tweaked there.
The Perl part of it is for various cronjobs that we run. There are probably around 20 Perl cronjobs that use the database that would be affected by the database failing. Using the code above, it just connects to the database name that is cataloged on that server. So if it's no there it's going to fail bigtime. It has no knowledge of the secondary db. So as far as what JavaFan is saying, that sure would be nice to have the IPs switched automatically, but it appears as if that is not the case here.
| [reply]
[d/l] |