...
| Table of Contents |
|---|
Replication conflict resolution in ALTIBASE HDB
We explained that a replication conflict is caused by either network delays or irregular sequence of transactions.
In a typical conflict situation, a Receiver cannot decide which record is correct between the current value and the before value in Xlog.
To help users to deal with such replication conflicts, ALTIBASE HDB provides a few different conflict resolution schemes, such as user-oriented scheme, a master-scheme and a time stamp based scheme.
Eager mode Replication
Overview
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Steps | Description |
|---|---|
1 | Local Transaction takes place and waits until the step #5 |
2 | Sender creates XLog |
3 | Sender sends XLog to Receiver |
4,5 | Receiver applies and returns the result back to Sender |
6 | Return errorCode to the application |
We already explained about the typical flow of Eager mode Replication.
Here is a typical flow for in case of a replication conflict: the transaction in the local server cannot be completed until the Sender receives an ACK from the Receiver in the remote server.
The Receiver checks whether any conflict has occurred in the remote server. If the transaction fails due to a conflict in the remote server, the Receiver sends an ACK containing the error information related to the conflict back to Sender. In this case, the transaction in the local server will also fail.
How to configure this mode?
User can specify the mode when creating a replication object as shown below:
| Code Block |
|---|
CREATE EAGER REPLICATION WITH '' ...
{code}
h3. Considerations
Performance of Eager mode replication is always slower than that of Lazy mode. If your priority is high performance, Eager mode replication is not a good choice.
h2. User-oriented scheme |
Considerations
Performance of Eager mode replication is always slower than that of Lazy mode. If your priority is high performance, Eager mode replication is not a good choice.
User-oriented scheme (REPLICATION_UPDATE_REPLACE
...
property)
...
Overview
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
...
|
Steps | Description |
|---|---|
1,2 | Local Transaction completes without waiting for an ACK from Receiver |
3 | Sender creates XLog |
3 | Sender sends XLog to Receiver |
4 | Receiver applies XLog regardless of a replication conflict |
REPLICATION_UPDATE_REPLACE
...
is
...
one
...
of
...
properties
...
in
...
ALTIBASE
...
HDB.
...
When
...
it
...
is
...
turn
...
on,
...
Receiver
...
does
...
not
...
check
...
for
...
a
...
conflict
...
any
...
more.
...
It
...
simply
...
overwrites
...
the
...
existing
...
record
...
even
...
if
...
there
...
is
...
a
...
replication
...
conflict.
...
In
...
the
...
above
...
diagram,
...
the
...
conflict
...
has
...
occurred
...
because
...
the
...
existing
...
value
...
("30")
...
is
...
different
...
from
...
the
...
before-value
...
("10")
...
of
...
XLog.
...
When
...
user
...
uses
...
this
...
method,
...
the
...
existing
...
data
...
in
...
the
...
remote
...
server
...
is
...
modified
...
to
...
"20".
...
How
...
to
...
configure
...
this
...
scheme?
...
Set
...
the
...
value
...
of
...
REPLICATION_UPDATE_REPLACE
...
property
...
to
...
"1"
...
in
...
$ALTIBASE_HOME/conf/altibase.properties
...
so
...
that
...
Receiver
...
does
...
not
...
check
...
for
...
any
...
conflict.
...
Considerations
Network delays can introduce mismatches for last values.
Time Stamp scheme
Overview
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
...
|
This method is similar to REPLICATION_UPDATE_REPLACE
...
method,
...
however,
...
Receiver
...
compares
...
the
...
timestamp
...
value
...
of
...
an
...
existing
...
record
...
with
...
the
...
timestamp
...
value
...
of
...
XLog
...
when
...
Receiver
...
applies
...
XLog
...
to
...
the
...
remote
...
server.
...
If
...
the
...
timestamp
...
value
...
of
...
XLog
...
is
...
bigger
...
than
...
the
...
existing
...
record,
...
XLog
...
will
...
be
...
applied,
...
otherwise,
...
the
...
replication
...
transaction
...
will
...
be
...
dropped.
...
In
...
the
...
above
...
diagram,
...
since
...
the
...
timestamp
...
value
...
(11:01)
...
of
...
XLog
...
is
...
smaller
...
than
...
the
...
timestamp
...
value
...
(11:02)
...
of
...
the
...
existing
...
data,
...
the
...
replication
...
transaction
...
can
...
not
...
be
...
applied
...
to
...
the
...
remote
...
server.
...
On
...
the
...
other
...
hand,
...
if
...
XLog
...
of
...
Node
...
B
...
has
...
been
...
sent
...
to
...
Node
...
A,
...
the
...
existing
...
data
...
would
...
be
...
replaced
...
with
...
the
...
XLog
...
from
...
Node
...
B
...
since
...
timestamp
...
value
...
of
...
Node
...
B
...
is
...
bigger
...
than
...
that
...
of
...
Node
...
B.
...
How
...
to
...
configure
...
this
...
scheme?
...
- Add
...
- a
...
- timestamp
...
- column
...
- to
...
- the
...
- table.
...
- set
...
- REPLICATION_TIMESTAMP_RESOLUTION
...
- value
...
- to
...
- "1"
...
- in
...
- $ALTIBASE_HOME/conf/altibase.properties.
...
Considerations
Since the size of timestamp data type is 8 bytes, the size of the record will be increased by 8 bytes.
System clocks should be synchronized across the servers to ensure accuracy of the operation.
Summary
Users should know that these methods do not guarantee the data consistency perfectly, they only allow users to control the behavior of Receiver when replication conflicts occur.
For more information, please refer to reference manual