IDS Forum

RE: database replication setup help

Posted By: Justin Killen
Date: Thursday, 23 May 2013, at 2:43 p.m.

In Response To: Re: database replication setup help (Art Kagel)

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.

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.