IDS Forum

Re: database replication setup help

Posted By: Art Kagel
Date: Thursday, 23 May 2013, at 4:18 p.m.

In Response To: RE: database replication setup help (Justin Killen)

No offense taken, I guess I'm just in a cranky mood. Not your fault dude.
Let's take this offline. Will contact you directly.

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, May 23, 2013 at 4:03 PM, Justin Killen <
jkillen@allamericanasphalt.com> wrote:

> Art,
>
> I'm sorry if I offended, that was not my intention. I see your
> contributions
> to this community and I respect your advice and opinions. I am quite
> certain
> that I am just simply misunderstanding some core concept (in my defense,
> IBM
> has done a pretty good job of providing an abundance of acronyms and
> options
> as to make everything complicated IMHO).
>
> So then, when you say I can continue to process transactions, you mean that
> the primary HDR at HQ continues to run, even in the event that the
> connection
> to an HDR secondary/RSS is severed, and that any nodes connected to the now
> disconnected HDR secondary/RSS will work for read requests but get an
> error on
> write requests. The question here then is what's the difference between an
> HDR
> secondary and an RSS? I thought the difference was that when applying a
> transaction, the changes were guaranteed on a secondary because it happens
> at
> the same time as the primary update, but for RSS it is not guaranteed
> because
> the change is delayed?
>
> -Justin
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
> Kagel
> Sent: Thursday, May 23, 2013 11:55 AM
> To: ids@iiug.org
> Subject: Re: database replication setup help [30335]
>
> First, you are misreading and combining two of my points. As relates to
> RSS secondaries (same applies to HDR secondary BTW), I said: "If the WAN
> goes down, you could still use the local RSS secondary at Site1 as a
> read-only query server, but would have to get the WAN back up in order to
> process updates (read that as transactions) locally again." I only said
> that you could "continue to process transactions locally" with reference to
> ER nodes where you might run into the conflict issues that you alluded to
> in your post.
>
> Now, I mentioned this when Larry said you could have two HDR secondaries,
> but let me repeat it:
>
> YOU CANNOT HAVE MORE THAN ONE HDR SECONDARY CONFIGURED AT THE SAME TIME!
>
> After the one, single, lone, solitary (did I emphasize that enough?) HDR
> secondary all other secondary servers have to be either SDS secondaries
> attached to a primary server's disk drives or RSS secondaries which is what
> you want to configure at Site1.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, May 23, 2013 at 2:43 PM, Justin Killen <
> jkillen@allamericanasphalt.com> wrote:
>
> > Art,
> >
> > You say "If the RSS or HDR secondary is writable, the writes are still
> > happening on the primary" and then later "If the WAN goes down you could
> > continue to process transactions locally". I'm confused by this - if all
> > writes are happening on the primary, then how could I continue to process
> > transaction locally?
> >
> > I guess my big question here is if I should be using an RSS at Site1 or
> an
> > HDR
> > secondary. I was under the impression that if I was using an HDR
> secondary
> > and
> > the WAN link went down, then the HDR primary at HQ would not be able to
> > process transactions (insert/update/delete) because it could not sync
> with
> > the
> > offline HDR secondary at Site1 - am I wrong on this?
> >
> > -Justin
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art
> > Kagel
> > Sent: Thursday, May 23, 2013 10:53 AM
> > To: ids@iiug.org
> > Subject: Re: database replication setup help [30329]
> >
> > OK, here are some points:
> >
> > - If the RSS or HDR secondary is writable, the writes are still
> >
> > happening on the primary (passed through by the secondary) and then
> >
> > propagate to the secondaries including the secondary the originated the
> >
> > write. There is no danger of the secondary getting out-of-sync with the
> >
> > primary and having local transactions that the primary doesn't know
> about.
> >
> > If the WAN goes down, you could still use the local RSS secondary at
> Site1
> >
> > as a read-only query server, but would have to get the WAN back up in
> order
> >
> > to process updates locally again.
> >
> > - If you make the secondary read-only, then you apps will have to be
> >
> > aware of that and either update the primary using distributed queries (ie
> >
> > access the table's using the primary's servername: insert into
> >
> > mydatabase@primary:mytable ...) or they could keep two connections open
> >
> > (assuming the host language supports multiple connections (ESQL/C, C++,
> all
> >
> > 4GL variants, and Java do) one locally on the secondary for reading and
> one
> >
> > remoted directly to the primary for updating. The writable option is
> >
> > actually preferrable.
> >
> > - You could use ER. If the WAN goes down you could continue to process
> >
> > transactions locally, but when the LAN comes back up then conflict
> >
> > resolution rules would have to resolve any problems caused by rows
> updated
> >
> > on multiple servers.
> >
> > - HDR and RSS secondaries will remain in sync for schema changes because
> >
> > all logical log records (which include all DDL commands) are propagated
> to
> >
> > the secondaries and applied there replicating changes happening on the
> >
> > primary. Only index builds are slightly different. They can be configured
> >
> > such that the secondary just gets notice of a new index and has to build
> it
> >
> > locally or such that the actual log records generated by the index build
> >
> > are sent over to the secondary replicating the index page-by-page. Your
> >
> > choice. Indexes built the first way, the default, will remain locked on
> >
> > the primary until the secondaries complete their build (unless the
> >
> > connection is down).
> >
> > - Flexible Grid is just a new internal communication protocol that lets
> >
> > you issue commands that are processed across all servers on a named grid.
> >
> > Those servers can be ER participants or independent servers. Prior to
> >
> > v12.10 this could only be used for ER commands and DDL. In 12.10 you can
> >
> > also distribute queries across the grid and return data from multiple
> >
> > servers with a single SELECT.
> >
> > Art
> >
> > Art S. Kagel
> > Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Thu, May 23, 2013 at 1:31 PM, Justin Killen <
> > jkillen@allamericanasphalt.com> wrote:
> >
> > > Hi.
> > >
> > > For the last several years, we've been running an Informix database for
> > our
> > > accounting and production systems. We have two primary locations, which
> > for
> > > the purpose of this email I'll call HQ and Site1. Site1 is connected to
> > HQ
> > > over a WAN link (T1, etc), but we are investigating possible options to
> > > change
> > > this to use Informix's replication (mainly to speed up access). HQ and
> > > Site1
> > > both work on the same data sets, so in the event the line goes down, we
> > > would
> > > prefer Site1 be read-only to avoid any data conflicts. Additionally, we
> > > like
> > > to add redundancy in the HQ location to prevent down-time in the event
> of
> > > server hardware failure, etc.
> > >
> > > After some research and reading, here's what we've come up with:
> > >
> > > HQ location:
> > > 1 HDR primary server
> > > 1 HDR secondary server
> > >
> > > Site1:
> > > 1 RSS server (readonly)
> > >
> > > Does this sound reasonable?
> > > When a program is run from Site1, and an update/insert/delete statement
> > is
> > > run, how do we set it up so that the statement gets sent up to the HQ
> > > primary
> > > transparently?
> > > I read that schema change propagation only happens in Flexible Grid and
> > > not in
> > > ER, so when a schema change is made on the HDR primary, does it
> > > automatically
> > > propagate down to the secondary and RSS servers? I'm a little confused
> > > about
> > > the difference between Flexible Grid and ER and how they work together.
> > >
> > > Thanks In Advance,
> > > -Justin
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
> *******************************************************************************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --089e0160a3b8e43e8c04dd6658f1
> >
> >
> >
> >
>
>
> *******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
> >
> >
>
>
> *******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --047d7b3a82365e732f04dd67377f
>
>
>
> *******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
> *******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>

--089e0160a3b8a1f06404dd6863c7

Messages In This Thread

• database replication setup help
  Justin Killen -- Thursday, 23 May 2013, at 1:31 p.m.
  • Re: database replication setup help
    Art Kagel -- Thursday, 23 May 2013, at 1:52 p.m.
    • RE: database replication setup help
      Justin Killen -- Thursday, 23 May 2013, at 2:43 p.m.
      • Re: database replication setup help
        Art Kagel -- Thursday, 23 May 2013, at 2:55 p.m.
        • RE: database replication setup help
          Justin Killen -- Thursday, 23 May 2013, at 4:03 p.m.
          • Re: database replication setup help
            Art Kagel -- Thursday, 23 May 2013, at 4:18 p.m.
      • RE: database replication setup help
        Everett Mills -- Thursday, 23 May 2013, at 3:24 p.m.
  • RE: database replication setup help
    LARRY SORENSEN -- Thursday, 23 May 2013, at 2:05 p.m.
    • Re: database replication setup help
      Art Kagel -- Thursday, 23 May 2013, at 2:33 p.m.
  • Re: database replication setup help
    Madison Pruet -- Thursday, 23 May 2013, at 2:08 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.