IDS Forum

RE: DBSERVERNAME Best Practice Pri/HDR/RSS

Posted By: Andrew Ford
Date: Wednesday, 20 July 2016, at 2:46 p.m.

In Response To: Re: DBSERVERNAME Best Practice Pri/HDR/RSS (Informix DBA)

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.

Messages In This Thread

• DBSERVERNAME Best Practice Pri/HDR/RSS
  Informix DBA -- Wednesday, 20 July 2016, at 11:07 a.m.
  • RE: DBSERVERNAME Best Practice Pri/HDR/RSS
    Andrew Ford -- Wednesday, 20 July 2016, at 11:45 a.m.
    • Re: DBSERVERNAME Best Practice Pri/HDR/RSS
      Informix DBA -- Wednesday, 20 July 2016, at 12:42 p.m.
      • RE: DBSERVERNAME Best Practice Pri/HDR/RSS
        Andrew Ford -- Wednesday, 20 July 2016, at 12:49 p.m.
        • Re: DBSERVERNAME Best Practice Pri/HDR/RSS
          Informix DBA -- Wednesday, 20 July 2016, at 2:34 p.m.
          • RE: DBSERVERNAME Best Practice Pri/HDR/RSS
            Andrew Ford -- Wednesday, 20 July 2016, at 2:46 p.m.
            • Re: DBSERVERNAME Best Practice Pri/HDR/RSS
              Informix DBA -- Wednesday, 20 July 2016, at 4:13 p.m.
  • Re: DBSERVERNAME Best Practice Pri/HDR/RSS
    Madison Pruet -- Wednesday, 20 July 2016, at 12:37 p.m.
  • Re: DBSERVERNAME Best Practice Pri/HDR/RSS
    Art Kagel -- Wednesday, 20 July 2016, at 2:14 p.m.
    • Re: DBSERVERNAME Best Practice Pri/HDR/RSS
      Informix DBA -- Wednesday, 20 July 2016, at 2:35 p.m.
      • Re: DBSERVERNAME Best Practice Pri/HDR/RSS
        Art Kagel -- Wednesday, 20 July 2016, at 4:36 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.