DBSERVERNAME Best Practice Pri/HDR/RSS
Dave asked whether all nodes in a Primary/HDR/RSS cluster could share one DBSERVERNAME (using HA_ALIAS to tell them apart), prompted by ON-Bar/NetBackup log restores failing after a failover because ixbar entries/image names carry the DBSERVERNAME of the server that made the backup. Respondents (Madison Pruet, Andrew Ford, Art Kagel) said identical DBSERVERNAMEs are not acceptable; instead use a common base name with suffixes (a/b/c, _hdr/_rss1, or location), plus DBSERVERALIASES/HA_ALIAS and an sqlhosts group or Connection Manager for client routing. Suggested workarounds for the restore problem were editing the ixbar file or taking a level-0 archive right after failover; no clean resolution was recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Are there any suggestions related to best practices for naming the
DBSERVERNAME in a Primary/ HDR/ multiple RSS cluster?
Would it be ok have the exact same DBSERVERNAME for all instances in the
cluster i.e. PRI / HDR / and multiple RSS servers? Then use separate names
for HA_ALIAS (and in onmode commands) to distinctly identify each server
name?
Any suggestions or caveats to be aware of?
Thank You,
--Dave
--089e0103ecc8cbd2490538128f17
I just append an 'a', 'b', 'c', etc. to a common name that describes the
group of servers.
I.e. dbsvr01a, dbsvr01b, dbsvr01c is a group of servers that participate in
HDR/RSS for the dbsvr01 data. I then use a group called g_dbsvr01 in
INFORMIXSQLHOSTS to represent all 3.
I don't like the idea of having the same DBSERVERNAME, it might not even be
doable. Not 100% sure on that.
I also don't like the idea of indicating primary or sds or rss or secondary
in the dbservername (i.e. dbsvr01_pri, dbsvr01_sec, dbsvr01_sds,
dbsvr01_rss) because if there is a failover your dbsvr01_sec could actually
be the primary and that is confusing.
Stick to a common base DBSERVERNAME name with an 'a', 'b', 'c' appended and
use an INFORMIXSQLHOSTS group to let the client automatically connect to the
primary or use the connection manager.
If you don't like 'a', 'b', 'c' then maybe still use the same base
DBSERVERNAME but append geographical location like dbsvr01_omaha,
dbsvr01_austin, dbsvr01_bahstin, etc. if you have geographical redundancy in
your HDR/RSS configuration.
Andrew
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Informix DBA
Sent: Wednesday, July 20, 2016 10:08 AM
To: ids@iiug.org
Subject: DBSERVERNAME Best Practice Pri/HDR/RSS [37448]
Are there any suggestions related to best practices for naming the
DBSERVERNAME in a Primary/ HDR/ multiple RSS cluster?
Would it be ok have the exact same DBSERVERNAME for all instances in the
cluster i.e. PRI / HDR / and multiple RSS servers? Then use separate names
for HA_ALIAS (and in onmode commands) to distinctly identify each server
name?
Any suggestions or caveats to be aware of?
Thank You,
--Dave
--089e0103ecc8cbd2490538128f17
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
It would not be OK to give each of the servers the same DBSERVERNAME, but you
could place each of the servers within a group and then connect via the group
name. That would always direct your connection to the current primary server.
Madison Pruet
Retired and Loving it
On Wednesday, July 20, 2016 7:08 AM, Informix DBA <in4mixdba@gmail.com> wrote:
Are there any suggestions related to best practices for naming the
DBSERVERNAME in a Primary/ HDR/ multiple RSS cluster?
Would it be ok have the exact same DBSERVERNAME for all instances in the
cluster i.e. PRI / HDR / and multiple RSS servers? Then use separate names
for HA_ALIAS (and in onmode commands) to distinctly identify each server
name?
Any suggestions or caveats to be aware of?
Thank You,
--Dave
--089e0103ecc8cbd2490538128f17
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Thank you Andrew.
The reason I ask is we were having a challenge restoring logs from Orig
Primary and new Primary (prev HDR) using onbar and netbackup since onbar
writes the DBSERVERNAME to the ixbar file (see my other thread titled
"Backup/Restore Primary/HDR"). On a restore onbar requests the logs from
the storage manager using the first DBSERVERNAME in the ixbar file. Onbar
gets confused when the DBSERVERNAME changes due to the PRI ---> HDR
switchover and fails on the log restore that was backed up by the orig HDR.
IBM support suggested making all the nodes in the PRI/HDR/RSS have the same
DBSERVERNAME so that any logs getting backed up will have the same
DBSERVERNAME entry listed in the ixbar file. I know we can utilize the
HA_ALIAS in combo with DBSERVERALIASES to distinctly ID each server.
Though I have never seen it done this way and was curious how other people
handle this scenario.
Thank You,
--Dave
On Wed, Jul 20, 2016 at 11:45 AM, Andrew Ford <andrew@informix-dba.com>
wrote:
> I just append an 'a', 'b', 'c', etc. to a common name that describes the
> group of servers.
>
> I.e. dbsvr01a, dbsvr01b, dbsvr01c is a group of servers that participate in
> HDR/RSS for the dbsvr01 data. I then use a group called g_dbsvr01 in
> INFORMIXSQLHOSTS to represent all 3.
>
> I don't like the idea of having the same DBSERVERNAME, it might not even be
> doable. Not 100% sure on that.
>
> I also don't like the idea of indicating primary or sds or rss or secondary
> in the dbservername (i.e. dbsvr01_pri, dbsvr01_sec, dbsvr01_sds,
> dbsvr01_rss) because if there is a failover your dbsvr01_sec could actually
> be the primary and that is confusing.
>
> Stick to a common base DBSERVERNAME name with an 'a', 'b', 'c' appended and
> use an INFORMIXSQLHOSTS group to let the client automatically connect to
> the
> primary or use the connection manager.
>
> If you don't like 'a', 'b', 'c' then maybe still use the same base
> DBSERVERNAME but append geographical location like dbsvr01_omaha,
> dbsvr01_austin, dbsvr01_bahstin, etc. if you have geographical redundancy
> in
> your HDR/RSS configuration.
>
> Andrew
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Informix DBA
> Sent: Wednesday, July 20, 2016 10:08 AM
> To: ids@iiug.org
> Subject: DBSERVERNAME Best Practice Pri/HDR/RSS [37448]
>
> Are there any suggestions related to best practices for naming the
> DBSERVERNAME in a Primary/ HDR/ multiple RSS cluster?
>
> Would it be ok have the exact same DBSERVERNAME for all instances in the
> cluster i.e. PRI / HDR / and multiple RSS servers? Then use separate names
> for HA_ALIAS (and in onmode commands) to distinctly identify each server
> name?
>
> Any suggestions or caveats to be aware of?
>
> Thank You,
>
> --Dave
>
> --089e0103ecc8cbd2490538128f17
>
>
> ****************************************************************************
> ***
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a11423b4231cc0e053813e3b6
Can you make a backup copy of the ixbar file and manually modify the
DBSERVERNAME ixbar using to stop confusing onbar?
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Informix DBA
Sent: Wednesday, July 20, 2016 11:43 AM
To: ids@iiug.org
Subject: Re: DBSERVERNAME Best Practice Pri/HDR/RSS [37451]
Thank you Andrew.
The reason I ask is we were having a challenge restoring logs from Orig
Primary and new Primary (prev HDR) using onbar and netbackup since onbar
writes the DBSERVERNAME to the ixbar file (see my other thread titled
"Backup/Restore Primary/HDR"). On a restore onbar requests the logs from the
storage manager using the first DBSERVERNAME in the ixbar file. Onbar gets
confused when the DBSERVERNAME changes due to the PRI ---> HDR switchover
and fails on the log restore that was backed up by the orig HDR.
IBM support suggested making all the nodes in the PRI/HDR/RSS have the same
DBSERVERNAME so that any logs getting backed up will have the same
DBSERVERNAME entry listed in the ixbar file. I know we can utilize the
HA_ALIAS in combo with DBSERVERALIASES to distinctly ID each server.
Though I have never seen it done this way and was curious how other people
handle this scenario.
Thank You,
--Dave
On Wed, Jul 20, 2016 at 11:45 AM, Andrew Ford <andrew@informix-dba.com>
wrote:
> I just append an 'a', 'b', 'c', etc. to a common name that describes
> the group of servers.
>
> I.e. dbsvr01a, dbsvr01b, dbsvr01c is a group of servers that
> participate in HDR/RSS for the dbsvr01 data. I then use a group called
> g_dbsvr01 in INFORMIXSQLHOSTS to represent all 3.
>
> I don't like the idea of having the same DBSERVERNAME, it might not
> even be doable. Not 100% sure on that.
>
> I also don't like the idea of indicating primary or sds or rss or
> secondary in the dbservername (i.e. dbsvr01_pri, dbsvr01_sec,
> dbsvr01_sds,
> dbsvr01_rss) because if there is a failover your dbsvr01_sec could
> actually be the primary and that is confusing.
>
> Stick to a common base DBSERVERNAME name with an 'a', 'b', 'c'
> appended and use an INFORMIXSQLHOSTS group to let the client
> automatically connect to the primary or use the connection manager.
>
> If you don't like 'a', 'b', 'c' then maybe still use the same base
> DBSERVERNAME but append geographical location like dbsvr01_omaha,
> dbsvr01_austin, dbsvr01_bahstin, etc. if you have geographical
> redundancy in your HDR/RSS configuration.
>
> Andrew
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Informix DBA
> Sent: Wednesday, July 20, 2016 10:08 AM
> To: ids@iiug.org
> Subject: DBSERVERNAME Best Practice Pri/HDR/RSS [37448]
>
> Are there any suggestions related to best practices for naming the
> DBSERVERNAME in a Primary/ HDR/ multiple RSS cluster?
>
> Would it be ok have the exact same DBSERVERNAME for all instances in
> the cluster i.e. PRI / HDR / and multiple RSS servers? Then use
> separate names for HA_ALIAS (and in onmode commands) to distinctly
> identify each server name?
>
> Any suggestions or caveats to be aware of?
>
> Thank You,
>
> --Dave
>
> --089e0103ecc8cbd2490538128f17
>
>
> **********************************************************************
> ******
> ***
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
****************************************************************************
***
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a11423b4231cc0e053813e3b6
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
I tens to use a base name that indicates purpose - (like "acctng") or
whimsy (like "snoopy") and add _hdr, _rss1, _rss2, _sds1, etc.
Art
On Jul 20, 2016 11:08 AM, "Informix DBA" <in4mixdba@gmail.com> wrote:
> Are there any suggestions related to best practices for naming the
> DBSERVERNAME in a Primary/ HDR/ multiple RSS cluster?
>
> Would it be ok have the exact same DBSERVERNAME for all instances in the
> cluster i.e. PRI / HDR / and multiple RSS servers? Then use separate names
> for HA_ALIAS (and in onmode commands) to distinctly identify each server
> name?
>
> Any suggestions or caveats to be aware of?
>
> Thank You,
>
> --Dave
>
> --089e0103ecc8cbd2490538128f17
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a1144c0d63e2f9d0538152c26
I have not found a nice way to really trick onbar/storage manager since
onbar sends the DBSERVERNAME to the storage manager as the image name
getting backed up. Then when onbar requests the restore it uses the
DBSERVERNAME of the first entry as the image name for the phys and logical
restore. So when it gets to the logs from the HDR server it fails as the
image doesn't match the DBSERVERNAME.
The only "trick" I discovered is after the log restore fails (trying to
restore the orig_HDR logs) I can trick onbar and delete all the
"orig_Primary" entries and restart the log restore, though I am hoping
there is a more elegant way to achieve this. Though this method requires
that the log restore fails, modify ixbar file, restart log restore.
Thank You,
--Dave
On Wed, Jul 20, 2016 at 12:49 PM, Andrew Ford <andrew@informix-dba.com>
wrote:
> Can you make a backup copy of the ixbar file and manually modify the
> DBSERVERNAME ixbar using to stop confusing onbar?
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Informix DBA
> Sent: Wednesday, July 20, 2016 11:43 AM
> To: ids@iiug.org
> Subject: Re: DBSERVERNAME Best Practice Pri/HDR/RSS [37451]
>
> Thank you Andrew.
>
> The reason I ask is we were having a challenge restoring logs from Orig
> Primary and new Primary (prev HDR) using onbar and netbackup since onbar
> writes the DBSERVERNAME to the ixbar file (see my other thread titled
> "Backup/Restore Primary/HDR"). On a restore onbar requests the logs from
> the
> storage manager using the first DBSERVERNAME in the ixbar file. Onbar gets
> confused when the DBSERVERNAME changes due to the PRI ---> HDR switchover
> and fails on the log restore that was backed up by the orig HDR.
>
> IBM support suggested making all the nodes in the PRI/HDR/RSS have the same
> DBSERVERNAME so that any logs getting backed up will have the same
> DBSERVERNAME entry listed in the ixbar file. I know we can utilize the
> HA_ALIAS in combo with DBSERVERALIASES to distinctly ID each server.
> Though I have never seen it done this way and was curious how other people
> handle this scenario.
>
> Thank You,
>
> --Dave
>
> On Wed, Jul 20, 2016 at 11:45 AM, Andrew Ford <andrew@informix-dba.com>
> wrote:
>
> > I just append an 'a', 'b', 'c', etc. to a common name that describes
> > the group of servers.
> >
> > I.e. dbsvr01a, dbsvr01b, dbsvr01c is a group of servers that
> > participate in HDR/RSS for the dbsvr01 data. I then use a group called
> > g_dbsvr01 in INFORMIXSQLHOSTS to represent all 3.
> >
> > I don't like the idea of having the same DBSERVERNAME, it might not
> > even be doable. Not 100% sure on that.
> >
> > I also don't like the idea of indicating primary or sds or rss or
> > secondary in the dbservername (i.e. dbsvr01_pri, dbsvr01_sec,
> > dbsvr01_sds,
> > dbsvr01_rss) because if there is a failover your dbsvr01_sec could
> > actually be the primary and that is confusing.
> >
> > Stick to a common base DBSERVERNAME name with an 'a', 'b', 'c'
> > appended and use an INFORMIXSQLHOSTS group to let the client
> > automatically connect to the primary or use the connection manager.
> >
> > If you don't like 'a', 'b', 'c' then maybe still use the same base
> > DBSERVERNAME but append geographical location like dbsvr01_omaha,
> > dbsvr01_austin, dbsvr01_bahstin, etc. if you have geographical
> > redundancy in your HDR/RSS configuration.
> >
> > Andrew
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > Informix DBA
> > Sent: Wednesday, July 20, 2016 10:08 AM
> > To: ids@iiug.org
> > Subject: DBSERVERNAME Best Practice Pri/HDR/RSS [37448]
> >
> > Are there any suggestions related to best practices for naming the
> > DBSERVERNAME in a Primary/ HDR/ multiple RSS cluster?
> >
> > Would it be ok have the exact same DBSERVERNAME for all instances in
> > the cluster i.e. PRI / HDR / and multiple RSS servers? Then use
> > separate names for HA_ALIAS (and in onmode commands) to distinctly
> > identify each server name?
> >
> > Any suggestions or caveats to be aware of?
> >
> > Thank You,
> >
> > --Dave
> >
> > --089e0103ecc8cbd2490538128f17
> >
> >
> > **********************************************************************
> > ******
> > ***
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
> >
> >
>
> ****************************************************************************
> ***
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --001a11423b4231cc0e053813e3b6
>
>
> ****************************************************************************
> ***
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a113d9e9695842505381572c9
Thank you Art. Are you doing that on the DBSERVERNAME or for the HA_ALIAS
names?
--Dave
On Wed, Jul 20, 2016 at 2:14 PM, Art Kagel <art.kagel@gmail.com> wrote:
> I tens to use a base name that indicates purpose - (like "acctng") or
> whimsy (like "snoopy") and add _hdr, _rss1, _rss2, _sds1, etc.
>
> Art
>
> On Jul 20, 2016 11:08 AM, "Informix DBA" <in4mixdba@gmail.com> wrote:
>
> > Are there any suggestions related to best practices for naming the
> > DBSERVERNAME in a Primary/ HDR/ multiple RSS cluster?
> >
> > Would it be ok have the exact same DBSERVERNAME for all instances in the
> > cluster i.e. PRI / HDR / and multiple RSS servers? Then use separate
> names
> > for HA_ALIAS (and in onmode commands) to distinctly identify each server
> > name?
> >
> > Any suggestions or caveats to be aware of?
> >
> > Thank You,
> >
> > --Dave
> >
> > --089e0103ecc8cbd2490538128f17
> >
> >
> >
> >
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --001a1144c0d63e2f9d0538152c26
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--089e013d19ee9f5d670538157548
I went back and reread your original question.
This part is a little confusing, so I want to clear it up.
> The reason I ask is we were having a challenge restoring logs from Orig
Primary and new Primary (prev HDR)
Is this your use case?
2 servers, dbsvr01a and dbsvr01b. dbsvr01a is primary and dbsvr01b is the
HDR secondary.
Level 0 archive is taken against dbsvr01a
Logical Logs 1, 2 and 3 on dbsvr01a are filled and backed up
You fail over to dbsvr01b, making it the primary and dbsvr01a the secondary
Logical Logs 4 and 5 on dbsvr01b are filled and backed up
Something bad happens and you want to
Restore the Level 0 archive taken against dbsvr01a to dbsvr01b
Apply logical logs 1, 2 and 3 taken against dbsvr01a to dbsvr01b
Apply logical logs 4 and 5 taken on dbsvr01b to dbsvr01b
?
I would say always take a level 0 archive immediately after a failover, that
would solve your recoverability problem but it wouldn't let you do any point
in time restores if you needed to unless you resolve this issue.
Andrew
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Informix DBA
Sent: Wednesday, July 20, 2016 1:34 PM
To: ids@iiug.org
Subject: Re: DBSERVERNAME Best Practice Pri/HDR/RSS [37454]
I have not found a nice way to really trick onbar/storage manager since
onbar sends the DBSERVERNAME to the storage manager as the image name
getting backed up. Then when onbar requests the restore it uses the
DBSERVERNAME of the first entry as the image name for the phys and logical
restore. So when it gets to the logs from the HDR server it fails as the
image doesn't match the DBSERVERNAME.
The only "trick" I discovered is after the log restore fails (trying to
restore the orig_HDR logs) I can trick onbar and delete all the
"orig_Primary" entries and restart the log restore, though I am hoping there
is a more elegant way to achieve this. Though this method requires that the
log restore fails, modify ixbar file, restart log restore.
Thank You,
--Dave
On Wed, Jul 20, 2016 at 12:49 PM, Andrew Ford <andrew@informix-dba.com>
wrote:
> Can you make a backup copy of the ixbar file and manually modify the
> DBSERVERNAME ixbar using to stop confusing onbar?
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Informix DBA
> Sent: Wednesday, July 20, 2016 11:43 AM
> To: ids@iiug.org
> Subject: Re: DBSERVERNAME Best Practice Pri/HDR/RSS [37451]
>
> Thank you Andrew.
>
> The reason I ask is we were having a challenge restoring logs from
> Orig Primary and new Primary (prev HDR) using onbar and netbackup
> since onbar writes the DBSERVERNAME to the ixbar file (see my other
> thread titled "Backup/Restore Primary/HDR"). On a restore onbar
> requests the logs from the storage manager using the first
> DBSERVERNAME in the ixbar file. Onbar gets confused when the
> DBSERVERNAME changes due to the PRI ---> HDR switchover and fails on
> the log restore that was backed up by the orig HDR.
>
> IBM support suggested making all the nodes in the PRI/HDR/RSS have the
> same DBSERVERNAME so that any logs getting backed up will have the
> same DBSERVERNAME entry listed in the ixbar file. I know we can
> utilize the HA_ALIAS in combo with DBSERVERALIASES to distinctly ID each
server.
> Though I have never seen it done this way and was curious how other
> people handle this scenario.
>
> Thank You,
>
> --Dave
>
> On Wed, Jul 20, 2016 at 11:45 AM, Andrew Ford
> <andrew@informix-dba.com>
> wrote:
>
> > I just append an 'a', 'b', 'c', etc. to a common name that describes
> > the group of servers.
> >
> > I.e. dbsvr01a, dbsvr01b, dbsvr01c is a group of servers that
> > participate in HDR/RSS for the dbsvr01 data. I then use a group
> > called
> > g_dbsvr01 in INFORMIXSQLHOSTS to represent all 3.
> >
> > I don't like the idea of having the same DBSERVERNAME, it might not
> > even be doable. Not 100% sure on that.
> >
> > I also don't like the idea of indicating primary or sds or rss or
> > secondary in the dbservername (i.e. dbsvr01_pri, dbsvr01_sec,
> > dbsvr01_sds,
> > dbsvr01_rss) because if there is a failover your dbsvr01_sec could
> > actually be the primary and that is confusing.
> >
> > Stick to a common base DBSERVERNAME name with an 'a', 'b', 'c'
> > appended and use an INFORMIXSQLHOSTS group to let the client
> > automatically connect to the primary or use the connection manager.
> >
> > If you don't like 'a', 'b', 'c' then maybe still use the same base
> > DBSERVERNAME but append geographical location like dbsvr01_omaha,
> > dbsvr01_austin, dbsvr01_bahstin, etc. if you have geographical
> > redundancy in your HDR/RSS configuration.
> >
> > Andrew
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf
> > Of Informix DBA
> > Sent: Wednesday, July 20, 2016 10:08 AM
> > To: ids@iiug.org
> > Subject: DBSERVERNAME Best Practice Pri/HDR/RSS [37448]
> >
> > Are there any suggestions related to best practices for naming the
> > DBSERVERNAME in a Primary/ HDR/ multiple RSS cluster?
> >
> > Would it be ok have the exact same DBSERVERNAME for all instances in
> > the cluster i.e. PRI / HDR / and multiple RSS servers? Then use
> > separate names for HA_ALIAS (and in onmode commands) to distinctly
> > identify each server name?
> >
> > Any suggestions or caveats to be aware of?
> >
> > Thank You,
> >
> > --Dave
> >
> > --089e0103ecc8cbd2490538128f17
> >
> >
> > ********************************************************************
> > **
> > ******
> > ***
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
> >
> >
>
> **********************************************************************
> ******
> ***
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --001a11423b4231cc0e053813e3b6
>
>
> **********************************************************************
> ******
> ***
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
****************************************************************************
***
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a113d9e9695842505381572c9
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
Andrew,
Yes correct that is our exact scenario we are looking to verify. We also
have another CLR (Continuous Log Restore) server running and would like to
keep that running without fiddling with the ixbar file and restarting CLR
each time we switchover.
The community consensus was that HDR does sync the logs and it will pick up
exactly where the primary left off for the purposes of a restore and point
in time restores. I was trying to test and verify this scenario before
going live in Production.
Thank You,
--Dave
On Wed, Jul 20, 2016 at 2:46 PM, Andrew Ford <andrew@informix-dba.com>
wrote:
> I went back and reread your original question.
>
> This part is a little confusing, so I want to clear it up.
>
> > The reason I ask is we were having a challenge restoring logs from Orig
> Primary and new Primary (prev HDR)
>
> Is this your use case?
>
> 2 servers, dbsvr01a and dbsvr01b. dbsvr01a is primary and dbsvr01b is the
> HDR secondary.
>
> Level 0 archive is taken against dbsvr01a
> Logical Logs 1, 2 and 3 on dbsvr01a are filled and backed up
> You fail over to dbsvr01b, making it the primary and dbsvr01a the secondary
> Logical Logs 4 and 5 on dbsvr01b are filled and backed up
>
> Something bad happens and you want to
>
> Restore the Level 0 archive taken against dbsvr01a to dbsvr01b
> Apply logical logs 1, 2 and 3 taken against dbsvr01a to dbsvr01b
> Apply logical logs 4 and 5 taken on dbsvr01b to dbsvr01b
>
> ?
>
> I would say always take a level 0 archive immediately after a failover,
> that
> would solve your recoverability problem but it wouldn't let you do any
> point
> in time restores if you needed to unless you resolve this issue.
>
> Andrew
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Informix DBA
> Sent: Wednesday, July 20, 2016 1:34 PM
> To: ids@iiug.org
> Subject: Re: DBSERVERNAME Best Practice Pri/HDR/RSS [37454]
>
> I have not found a nice way to really trick onbar/storage manager since
> onbar sends the DBSERVERNAME to the storage manager as the image name
> getting backed up. Then when onbar requests the restore it uses the
> DBSERVERNAME of the first entry as the image name for the phys and logical
> restore. So when it gets to the logs from the HDR server it fails as the
> image doesn't match the DBSERVERNAME.
>
> The only "trick" I discovered is after the log restore fails (trying to
> restore the orig_HDR logs) I can trick onbar and delete all the
> "orig_Primary" entries and restart the log restore, though I am hoping
> there
> is a more elegant way to achieve this. Though this method requires that the
> log restore fails, modify ixbar file, restart log restore.
>
> Thank You,
>
> --Dave
>
> On Wed, Jul 20, 2016 at 12:49 PM, Andrew Ford <andrew@informix-dba.com>
> wrote:
>
> > Can you make a backup copy of the ixbar file and manually modify the
> > DBSERVERNAME ixbar using to stop confusing onbar?
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > Informix DBA
> > Sent: Wednesday, July 20, 2016 11:43 AM
> > To: ids@iiug.org
> > Subject: Re: DBSERVERNAME Best Practice Pri/HDR/RSS [37451]
> >
> > Thank you Andrew.
> >
> > The reason I ask is we were having a challenge restoring logs from
> > Orig Primary and new Primary (prev HDR) using onbar and netbackup
> > since onbar writes the DBSERVERNAME to the ixbar file (see my other
> > thread titled "Backup/Restore Primary/HDR"). On a restore onbar
> > requests the logs from the storage manager using the first
> > DBSERVERNAME in the ixbar file. Onbar gets confused when the
> > DBSERVERNAME changes due to the PRI ---> HDR switchover and fails on
> > the log restore that was backed up by the orig HDR.
> >
> > IBM support suggested making all the nodes in the PRI/HDR/RSS have the
> > same DBSERVERNAME so that any logs getting backed up will have the
> > same DBSERVERNAME entry listed in the ixbar file. I know we can
> > utilize the HA_ALIAS in combo with DBSERVERALIASES to distinctly ID each
> server.
> > Though I have never seen it done this way and was curious how other
> > people handle this scenario.
> >
> > Thank You,
> >
> > --Dave
> >
> > On Wed, Jul 20, 2016 at 11:45 AM, Andrew Ford
> > <andrew@informix-dba.com>
> > wrote:
> >
> > > I just append an 'a', 'b', 'c', etc. to a common name that describes
> > > the group of servers.
> > >
> > > I.e. dbsvr01a, dbsvr01b, dbsvr01c is a group of servers that
> > > participate in HDR/RSS for the dbsvr01 data. I then use a group
> > > called
> > > g_dbsvr01 in INFORMIXSQLHOSTS to represent all 3.
> > >
> > > I don't like the idea of having the same DBSERVERNAME, it might not
> > > even be doable. Not 100% sure on that.
> > >
> > > I also don't like the idea of indicating primary or sds or rss or
> > > secondary in the dbservername (i.e. dbsvr01_pri, dbsvr01_sec,
> > > dbsvr01_sds,
> > > dbsvr01_rss) because if there is a failover your dbsvr01_sec could
> > > actually be the primary and that is confusing.
> > >
> > > Stick to a common base DBSERVERNAME name with an 'a', 'b', 'c'
> > > appended and use an INFORMIXSQLHOSTS group to let the client
> > > automatically connect to the primary or use the connection manager.
> > >
> > > If you don't like 'a', 'b', 'c' then maybe still use the same base
> > > DBSERVERNAME but append geographical location like dbsvr01_omaha,
> > > dbsvr01_austin, dbsvr01_bahstin, etc. if you have geographical
> > > redundancy in your HDR/RSS configuration.
> > >
> > > Andrew
> > >
> > > -----Original Message-----
> > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf
> > > Of Informix DBA
> > > Sent: Wednesday, July 20, 2016 10:08 AM
> > > To: ids@iiug.org
> > > Subject: DBSERVERNAME Best Practice Pri/HDR/RSS [37448]
> > >
> > > Are there any suggestions related to best practices for naming the
> > > DBSERVERNAME in a Primary/ HDR/ multiple RSS cluster?
> > >
> > > Would it be ok have the exact same DBSERVERNAME for all instances in
> > > the cluster i.e. PRI / HDR / and multiple RSS servers? Then use
> > > separate names for HA_ALIAS (and in onmode commands) to distinctly
> > > identify each server name?
> > >
> > > Any suggestions or caveats to be aware of?
> > >
> > > Thank You,
> > >
> > > --Dave
> > >
> > > --089e0103ecc8cbd2490538128f17
> > >
> > >
> > > ********************************************************************
> > > **
> > > ******
> > > ***
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> > >
> > >
> >
> > **********************************************************************
> > ******
> > ***
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --001a11423b4231cc0e053813e3b6
> >
> >
> > **********************************************************************
> > ******
> > ***
> > Forum N
DBSERVERNAME and DBSERVERALIASES and using something like
<DBSERVERNAME>_tcp as one of the aliases and the HA_ALIAS.
Art
Art S. Kagel, President and Principal Consultant
ASK Database Management
www.askdbmgt.com
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on the IIUG, nor any other organization with which I am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.
On Wed, Jul 20, 2016 at 2:35 PM, Informix DBA <in4mixdba@gmail.com> wrote:
> Thank you Art. Are you doing that on the DBSERVERNAME or for the HA_ALIAS
> names?
>
> --Dave
>
> On Wed, Jul 20, 2016 at 2:14 PM, Art Kagel <art.kagel@gmail.com> wrote:
>
> > I tens to use a base name that indicates purpose - (like "acctng") or
> > whimsy (like "snoopy") and add _hdr, _rss1, _rss2, _sds1, etc.
> >
> > Art
> >
> > On Jul 20, 2016 11:08 AM, "Informix DBA" <in4mixdba@gmail.com> wrote:
> >
> > > Are there any suggestions related to best practices for naming the
> > > DBSERVERNAME in a Primary/ HDR/ multiple RSS cluster?
> > >
> > > Would it be ok have the exact same DBSERVERNAME for all instances in
> the
> > > cluster i.e. PRI / HDR / and multiple RSS servers? Then use separate
> > names
> > > for HA_ALIAS (and in onmode commands) to distinctly identify each
> server
> > > name?
> > >
> > > Any suggestions or caveats to be aware of?
> > >
> > > Thank You,
> > >
> > > --Dave
> > >
> > > --089e0103ecc8cbd2490538128f17
> > >
> > >
> > >
> > >
> >
> >
>
>
*******************************************************************************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --001a1144c0d63e2f9d0538152c26
> >
> >
> >
> >
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --089e013d19ee9f5d670538157548
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a1143e546a4375305381728ed