This discussion is archived
5 Replies Latest reply: Jan 10, 2013 5:23 AM by ChrisJenkins RSS

Bidirectional replication conflict resolving

Molchanov Newbie
Currently Being Moderated
Hi!

I'm testing bidirectional replication:

Command> repschemes;

Replication Scheme TIMESTEN.TTBIREP:

Element: DSNODE01
Type: Datastore
Master Store: TTGSRT01NODE01 on TA3-TEST Transmit Durable
Subscriber Store: TTGSRT01NODE02 on TA3-TEST

Excluded Tables:
None

Excluded Cache Groups:
CACHEUSER.CG_TTREPUSER
Included Cache Groups:
CACHEUSER.CG_TTREP

Excluded sequences:
None

Element: DSNODE02
Type: Datastore
Master Store: TTGSRT01NODE02 on TA3-TEST Transmit Durable
Subscriber Store: TTGSRT01NODE01 on TA3-TEST

Excluded Tables:
None

Excluded Cache Groups:
CACHEUSER.CG_TTREPUSER
Included Cache Groups:
CACHEUSER.CG_TTREP

Excluded sequences:
None

Store: TTGSRT01NODE01 on TA3-TEST
Port: (auto)
Log Fail Threshold: (none)
Retry Timeout: 120 seconds
Compress Traffic: Disabled

Store: TTGSRT01NODE02 on TA3-TEST
Port: (auto)
Log Fail Threshold: (none)
Retry Timeout: 120 seconds
Compress Traffic: Disabled

Replication Scheme TTREP._AWTREPSCHEME:

Element: _718064
Type: Table MMOLCHAN.TTREP
Master Store: TTGSRT01NODE01 on TA3-TEST Transmit Durable
Subscriber Store: _ORACLE from TA3-TEST

Store: TTGSRT01NODE01 on TA3-TEST
Port: (auto)
Log Fail Threshold: (none)
Retry Timeout: 120 seconds
Compress Traffic: Disabled

Store: _ORACLE from TA3-TEST
Port: (auto)
Log Fail Threshold: (none)
Retry Timeout: 120 seconds
Compress Traffic: Disabled


I try to find how TimesTen resolves conflict with "DATASTORE" element in replication schema, but unfortunately I don't.
In documentation describes only how to resolve conflict with "TABLE" elements by using TIMESTAMP.

Can some one help me to find or to understand how it (conflict resolving) works in DATASTORE mode?



TimesTen Release 11.2.1.8.2 (64 bit HPUX/IPF) (s1121_64:53388) 2011-03-26T06:26:28Z
Instance admin: timesten
Instance home directory: /opt/timesten/TimesTen/s1121_64
Group owner: ttadmin
Daemon home directory: /opt/timesten/TimesTen/s1121_64/info
PL/SQL enabled.
  • 1. Re: Bidirectional replication conflict resolving
    ChrisJenkins Guru
    Currently Being Moderated
    Conflict resolution is not available in DATASTORE mode replication (as per the syntax in the documentation). We do not encourage bi-directional replciation in general and certainly not when cache tabels are involved. If you eplicate a cache table bi-directionally then you will run into consistency issues and problems recovering to a consistent point after certain kinds of failures.

    Our recommended replication model is explicit active standby pair (CREATE ACTIVE STANDBY PAIR) and using this is a must if cache tables are involved.

    Chris
  • 2. Re: Bidirectional replication conflict resolving
    Molchanov Newbie
    Currently Being Moderated
    Thks Chris!

    So, only one way it is to use TABLE mode for conflict resolving in replication that replicate AWT cache grop

    ACTIVE STANDBY PAIR - it is good, but : "Writes on replicated tables are not allowed on the standby database and the subscriber databases.", so in this configuration we can't do DML operations on standby DB. And ofcourse we need to do some manipulation to activate standby DB while switch|fail over operation, but this is a time lag. It is bad for some purposes.
  • 3. Re: Bidirectional replication conflict resolving
    ChrisJenkins Guru
    Currently Being Moderated
    Yes, you need to use TABLE level replication if you want conflict detection. But as I said it is not recommended to use this with cache tables, especially AWT tables.

    Chris
  • 4. Re: Bidirectional replication conflict resolving
    Molchanov Newbie
    Currently Being Moderated
    I try it, but unfortunately it is not working.
    When I Try to create replication for AWT CG I get a error:

    Command> CREATE REPLICATION gsr.ttbirep
    > ELEMENT NODE01_ART_TERMINAL_SERVICE TABLE gsr.ART_TERMINAL_SERVICE
    > CHECK CONFLICTS BY ROW TIMESTAMP
    > COLUMN last_modify_date
    > UPDATE BY SYSTEM
    > ON EXCEPTION ROLLBACK WORK
    > REPORT TO '/oradata2/timesten/replication.err' FORMAT STANDARD
    > MASTER ttgsrt01node01 ON "ta3-test"
    > SUBSCRIBER ttgsrt01node02 ON "ta3-test"
    > ELEMENT NODE02_ART_TERMINAL_SERVICE TABLE gsr.ART_TERMINAL_SERVICE
    > CHECK CONFLICTS BY ROW TIMESTAMP
    > COLUMN last_modify_date
    > UPDATE BY SYSTEM
    > ON EXCEPTION ROLLBACK WORK
    > REPORT TO '/oradata2/timesten/replication.err' FORMAT STANDARD
    > MASTER ttgsrt01node02 ON "ta3-test"
    > SUBSCRIBER ttgsrt01node01 ON "ta3-test"
    > ELEMENT NODE01_ART_ATTRIBUTE_VALUE TABLE gsr.ART_ATTRIBUTE_VALUE
    > CHECK CONFLICTS BY ROW TIMESTAMP
    > COLUMN last_modify_date
    > UPDATE BY SYSTEM
    > ON EXCEPTION ROLLBACK WORK
    > REPORT TO '/oradata2/timesten/replication.err' FORMAT STANDARD
    > MASTER ttgsrt01node01 ON "ta3-test"
    > SUBSCRIBER ttgsrt01node02 ON "ta3-test"
    > ELEMENT NODE02_ART_ATTRIBUTE_VALUE TABLE gsr.ART_ATTRIBUTE_VALUE
    > CHECK CONFLICTS BY ROW TIMESTAMP
    > COLUMN last_modify_date
    > UPDATE BY SYSTEM
    > ON EXCEPTION ROLLBACK WORK
    > REPORT TO '/oradata2/timesten/replication.err' FORMAT STANDARD
    > MASTER ttgsrt01node02 ON "ta3-test"
    > SUBSCRIBER ttgsrt01node01 ON "ta3-test";
    8060: Cannot specify replication timestamp column on a cached table
    The command failed.
  • 5. Re: Bidirectional replication conflict resolving
    ChrisJenkins Guru
    Currently Being Moderated
    Ah yes, I forgot; you can't use conflict resolution on cache tables either.

    Seriously, if you really want to replicate cache tables you have to use A/S pair and architect your solution accordingly.

    Chris

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points