Prefered DB redundancy mode?

[orxata]

Hi every one.

I was wondering if you had gathered some best practices when it comes to DB redundancy for a dual site platform?

I have seen different implementation on each project and it seems like there is always more cons than pros.

[cavagnaro]

For me I always talk this matters with customer DBA and our DBA. Customer may have already a plan tested and working. Also depends on which DB you use, Oracle, MSQL, Postgre, Informix, DB2, etc...
Usually they do have much more experience than we do Personally speaking of course.
It would be weird a customer willing to have a big implementation and leave such tasks on Genesys hands, normally they would have procedures and standards already defined.

[Steve]

I tend to work on hosted platforms, and as a company we set up and own everything. When we talk about multi-site, resilient, distributed platforms, we are talking Unix and Oracle.

To answer the original question, I always specify 2 node hardware clustering for database servers. Ideally the cluster will be split across the sites but this depends on how far apart they are, too far and latency becomes an issue. You can get round this by having a cluster at the primary site and a DR database server at the other one, this can be kept in sync with Oracle DataGuard.

Switching to the DR site is a manual process, but if you have lost a cluster you have got a major issue. So having to manually switch database is a minor problem.

[orxata]

Yeah, I am deploying the same kind of platform that you Steve and I also fall down to the manual step of reconfig when switching to the DR site.

I was thinking recently of having the HA dbserver pair with only the primary started and then having a script to start the backup dbserver.
primary dbserver would have TNSNAMES (or equivalent) pointing to main cluster and backup dbserver would have TNSNAMES pointing to DR database.
It requires bi directional sync between DB to be able to come back to initial setup though.

Anyone who would have something like that?

+

[Steve]

You could have 1 way sync, if you accept that DR is there for emergencies only and that you must have already had 2 failures before you switch to it.

[Fra]

Steve,
[quote author=Steve link=topic=7796.msg33862#msg33862 date=1367578665]
To answer the original question, I always specify 2 node hardware clustering for database servers. Ideally the cluster will be split across the sites but this depends on how far apart they are, too far and latency becomes an issue. You can get round this by having a cluster at the primary site and a DR database server at the other one, this can be kept in sync with Oracle DataGuard.
[/quote]
do you usually specify both the primary and the DR cluster in the TNSNAMES file? And would both DB Server of an HA pair have the same TNS?

[quote author=Steve link=topic=7796.msg33862#msg33862 date=1367578665]
Switching to the DR site is a manual process, but if you have lost a cluster you have got a major issue. So having to manually switch database is a minor problem.
[/quote]
Are you referring to the procedure to switch to the Oracle DR cluster here? What are the implications on the Genesys side of things?

Fra

[Steve]

Fra, yes both the primary and the DR are in the TNSNAMES but with different aliases, switching the apps DBServer, Config Server and any DAPs to use the DR alias is a manual process. Maybe it could be automated?

In a cluster the TNSNAMES points to a database on the virtual host, so it doesn't matter which phyiscal machine is hosting the DB at the time.

A DR Cluster is a bit too much (in my opinion), a DR server mkes more sense. Clustering is expensive and a DR site is only going to be used for short periods after 2 other servers have failed, ideally it will never be used. But as with all things resilient it comes down to how you perceive the risk and how much you are happy to spend.

Genesys is generally fine, you stop all the apps, point them to the DR database and restart them. They read their config and hopefully work. I have heard of issues with ETL jobs, but if you have had a major failure getting your call routing back is far more important.

[Fra]

[quote author=Steve link=topic=7796.msg35532#msg35532 date=1383749421]
Fra, yes both the primary and the DR are in the TNSNAMES but with different aliases, switching the apps DBServer, Config Server and any DAPs to use the DR alias is a manual process. Maybe it could be automated?

In a cluster the TNSNAMES points to a database on the virtual host, so it doesn't matter which phyiscal machine is hosting the DB at the time.

A DR Cluster is a bit too much (in my opinion), a DR server mkes more sense. Clustering is expensive and a DR site is only going to be used for short periods after 2 other servers have failed, ideally it will never be used. But as with all things resilient it comes down to how you perceive the risk and how much you are happy to spend.

Genesys is generally fine, you stop all the apps, point them to the DR database and restart them. They read their config and hopefully work. I have heard of issues with ETL jobs, but if you have had a major failure getting your call routing back is far more important.
[/quote]

Steve, what you said makes sense.
However, what if instead of having two aliases, there's a single alias which points to both the active cluster nodes AND the DR ones? I'm not an Oracle expert, but if the TNSNAMES is populated correctly and only one cluster is up & running, it should work ok and would have the benefit of not having to stop & restart the Genesys app and not having to modify DAPs & stuff?

Fra