/
conflicts.ad
138 lines (99 loc) · 7.97 KB
/
conflicts.ad
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
=== Conflicts
Conflict detection is the act of determining if an insert, update or delete is in "conflict" due to the target data row not
being consistent with the data at the source prior to the insert/update/delete.
Without any overriding configuration, the system uses a detection of USE_CHANGED_DATA and a resolution of NEWER_WINS by default.
ifdef::pro[]
image::conflict.png[]
endif::pro[]
.Conflicts are broken into 3 key components in SymmetricDS:
. Detection - How to detect a conflict when loading data at the target.
. Resolution - When a row is in conflict, what to do with it when loading at the target.
. Ping Back - What data to capture at target during resolution, if any, that will be sent back to source.
ifndef::pro[]
Conflict detection and resolution strategies are configured in the <<CONFLICT>> table. They are configured at minimum for a specific
NODE_GROUP_LINK . The configuration can also be specific to a CHANNEL and/or table.
Conflict detection is configured in the detect_type and detect_expression columns of <<CONFLICT>>. The value for detect_expression
depends on the detect_type.
endif::pro[]
ifdef::pro[]
.Required Fields
endif::pro[]
Conflict Id:: Unique identifier for a specific conflict detection setting.
Group Link:: References a node group link.
Detection Type:: Indicates the strategy to use for detecting conflicts during a dml action.
IMPORTANT: Conflicts are detected while data is being loaded into a target system.
.Detection Types
[cols=".^2,8"]
|===
|USE_PK_DATA|Indicates that only the primary key is used to detect a conflict. If a row exists with the same primary key, then
no conflict is detected during an update or a delete. Updates and deletes rows are resolved using only the primary key columns.
If a row already exists during an insert then a conflict has been detected.
|USE_CHANGED_DATA|Indicates that the primary key plus any data that has changed on the source system will be used to detect a conflict.
If a row exists with the same old values on the target system as they were on the source system for the columns that have changed
on the source system, then no conflict is detected during an update or a delete. If a row already exists during an insert then a conflict has been detected.
|USE_OLD_DATA|Indicates that all of the old data values are used to detect a conflict. Old data is the data values of the row on the
source system prior to the change. If a row exists with the same old values on the target system as they were on the source system,
then no conflict is detected during an update or a delete. If a row already exists during an insert then a conflict has been detected.
|USE_TIMESTAMP|Indicates that the primary key plus a timestamp column (as configured in detect_expression ) will indicate whether
a conflict has occurred. If the target timestamp column is not equal to the old source timestamp column, then a conflict has been detected.
If a row already exists during an insert then a conflict has been detected.
ifndef::pro[]
_You must specify the name of the column containing a timestamp to use in the detect_expression._
endif::pro[]
|USE_VERSION|Indicates that the primary key plus a version column (as configured in detect_expression ) will indicate whether a conflict
has occurred. If the target version column is not equal to the old source version column, then a conflict has been detected. If a row already
exists during an insert then a conflict has been detected.
ifndef::pro[]
_You must specify the name of the column containing a version number to use in the detect_expression._
endif::pro[]
|===
Resolution Type:: The choice of how to resolve a detected conflict is configured via the resolve type.
.Resolution Types
[cols=".^2,8"]
|===
|NEWER_WINS|Indicates that when a conflict is detected that the either the source or the target will win
based on which side has the newer timestamp or higher version number. With USE_TIMESTAMP detection, the column specified
in detect_expression is used, otherwise the time of capture is used.
|FALLBACK|Indicates that when a conflict is detected the system should automatically apply the changes anyway. If the source
operation was an insert, then an update will be attempted. If the source operation was an update and the row does not exist, then
an insert will be attempted. If the source operation was a delete and the row does not exist, then the delete will be ignored.
|IGNORE|Indicates that when a conflict is detected the system should automatically ignore the incoming change. Use IGNORE between two node groups
in one direction, and FALLBACK in the other direction to establish which group wins a conflict.
|MANUAL|Indicates that when a conflict is detected, the batch will remain in error until manual intervention occurs. A row in error
is inserted into the INCOMING_ERROR table, which includes the conflict ID, old data, new data, and current data at the target.
The user can specify the resolve data to use on the next load attempt.
The resolve_ignore flag can also be used to indicate that the row should be ignored.
|===
TIP: To make a primary node group always win a conflict, use a "fallback" resolution on group links where primary is the source
and an "ignore" resolution on group links where primary is the target.
ifndef::pro[]
Ping Back:: For each configured conflict, you also have the ability to control if and how much "resolved" data is sent back to the
node whose data change is in conflict. This "ping back" behavior is specified by the following options.
.Ping Backs
[cols=".^2,8"]
|===
|REMAINING_ROWS|The resolved data of the single row in the batch in conflict, along with the entire remainder of the batch, is sent back to the originating node.
|SINGLE_ROW|The resolved data of the single row in the batch that caused the conflict is sent back to the originating node. Recommended use with MANUAL resolution, so the resolved data is sent back to the originating node.
|OFF|No data is sent back to the originating node, even if the resolved data doesn't match the data the node sent. Recommended use with resolution types that choose a winning row, including NEWER_WINS and when IGNORE and FALLBACK are used on opposing group links.
|===
endif::pro[]
Detection Expression:: An expression that provides additional information about the detection mechanism. If the detection
mechanism is use_timestamp or use_version then this expression will be the name of the timestamp or version column.
The detect_expression is also used to exclude certain column names from being used. For example, to exclude column1 and column2,
the expression is "excluded_column_names=column1,column2".
ifdef::pro[]
.Advanced Options
endif::pro[]
ifndef::pro[]
Resolve Changes Only:: Indicates that when applying changes during an update that only data that has changed should be applied.
Otherwise, all the columns will be updated. This really only applies to updates.
Resolve Row Only:: Ignore only the row in conflict when true, or ignore the entire batch when false. Used by IGNORE and NEWER_WINS resolvers. Recommended setting is true.
endif::pro[]
Channel:: Optional channel that this setting will be applied to.
Target Catalog:: Optional database catalog that the target table belongs to. Only use this if the target table is not in the default catalog.
Target Schema:: Optional database schema that the target table belongs to. Only use this if the target table is not in the default schema.
Target Table:: Optional database table that this setting will apply to. If left blank, the setting will be for any table in the channel (if set) and in the specified node group link.
IMPORTANT: Be aware that conflict detection will not detect changes to binary columns in the case where use_stream_lobs is true in the trigger for the table.
In addition, some databases do not allow comparisons of binary columns whether use_stream_lobs is true or not.
WARNING: Some platforms do not support comparisons of binary columns. Conflicts in binary column values will not be detected on the
following platforms: DB2, DERBY, ORACLE, and SQLSERVER.