From e27de6cbe9a5d069bbb741e875b79c0adfaccc17 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Grzegorz=20Ko=C5=82akowski?= Date: Mon, 18 Nov 2019 20:34:42 +0100 Subject: [PATCH] DBZ-1480 Add documentation of read_committed isolation mode --- .../ROOT/pages/connectors/sqlserver.adoc | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/documentation/modules/ROOT/pages/connectors/sqlserver.adoc b/documentation/modules/ROOT/pages/connectors/sqlserver.adoc index 535c67fc1..d90343b3b 100644 --- a/documentation/modules/ROOT/pages/connectors/sqlserver.adoc +++ b/documentation/modules/ROOT/pages/connectors/sqlserver.adoc @@ -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`