alexey.rassokhin/tet123
1
0
Fork 0
Code Issues Pull Requests 1 Packages Projects Releases Wiki Activity

DBZ-1480 Add documentation of read_committed isolation mode

Browse Source
This commit is contained in:
Grzegorz Kołakowski 2019-11-18 20:34:42 +01:00 committed by Gunnar Morling
parent ce1857e172
commit e27de6cbe9
1 changed files with 12 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
documentation/modules/ROOT/pages/connectors/sqlserver.adoc
View File

@ -1274,15 +1274,20 @@ The following _advanced_ configuration properties have good defaults that will w
|`snapshot.isolation.mode`
|_repeatable_read_
|Mode to control which transaction isolation level is used and how long the connector locks the monitored tables. There are four possible values `read_uncommitted`, `repeatable_read`, `snapshot`, and `exclusive`. +
|Mode to control which transaction isolation level is used and how long the connector locks the monitored tables.
There are five possible values: `read_uncommitted`, `read_committed`, `repeatable_read`, `snapshot`, and `exclusive` (
in fact, `exclusive` mode uses repeatable read isolation level, however, it takes the exclusive lock on all tables
to be read). +
`repeatable_read` In this mode connector will use exclusive locks only during schema snapshot. +
It is worth documenting that `snapshot`, `read_committed` and `read_uncommitted` modes do not prevent other
transactions from updating table rows during initial snapshot, while `exclusive` and `repeatable_read` do. +
`read_uncommitted` In this mode neither table nor row-level locks are acquired, but connector does not guarantee snapshot consistency. +
`snapshot` In this mode connector runs the initial snapshot in SNAPSHOT isolation level, which guarantees snapshot consistency. In addition, neither table nor row-level locks are held. +
`exclusive` In this mode connector holds the exclusive lock (and thus prevents any reads and updates) for all monitored tables during the entire snapshot duration.
Another aspect is data consistency. Only `exclusive` and `snapshot` modes guarantee full consistency, that is, initial
snapshot and streaming logs constitute a linear history.
In case of `repeatable_read` and `read_committed` modes, it might happen that, for instance, a record added appears
twice - once in initial snapshot and once in streaming phase. Nonetheless, that consistency level should do for
data mirroring.
For `read_uncommitted` there are no data consistency guarantees at all (some data might be lost or corrupted).
|`poll.interval.ms`
|`1000`