Update write modes

cockroachdb · Nov 5, 2024 · 59140ce · 59140ce
1 parent 7365b79
commit 59140ce
Showing 1 changed file with 2 additions and 2 deletions.
diff --git a/src/current/v24.3/set-up-logical-data-replication.md b/src/current/v24.3/set-up-logical-data-replication.md
@@ -130,8 +130,8 @@ In this step, you'll start the LDR job from the destination cluster. You can rep
 
 _Modes_ determine how LDR replicates the data to the destination cluster. There are two modes:
 
-- `immediate` (default): Inserts data at the [KV layer]({% link {{ page.version.version }}/architecture/storage-layer.md %}), which means that LDR does not encounter issues with updates and deletes. `immediate` mode does not insert at the [SQL layer]({% link {{ page.version.version }}/architecture/sql-layer.md %}), which means that the replication will not follow SQL constraints. As a result, you can only use `immediate` mode if you do not have [foreign key]({% link {{ page.version.version }}/foreign-key.md %}) constraints on the replicating table. `immediate` mode provides faster replication compared to `validated` mode.  
-- `validated`: Inserts data at the SQL layer, which means that all SQL constraints are adhered to. If a row is unable to apply due to a SQL constraint, it will be put in the [dead letter queue (DLQ)]({% link {{ page.version.version }}/manage-logical-data-replication.md %}#dead-letter-queue-dlq) for manual resolution. SQL does not recognize deletion records used by [MVCC]({% link {{ page.version.version }}/architecture/storage-layer.md %}#mvcc), therefore an update to the same key from cluster A will successfully apply on cluster B even if that key was deleted on cluster B before the cluster A update was replicated.
+- `immediate` (default): Attempts to replicate the changed row directly into the destination table, without re-running constraint validations or triggers. It does not support writing into tables with [foreign key]({% link {{ page.version.version }}/foreign-key.md %}) constraints.
+- `validated`: Attempts to apply the write in a similar way to a user-run query, which would re-run all constraint validations or triggers relevant to the destination table(s). It will potentially reject the change if it fails rather than writing it, which will cause the row change to enter the DLQ instead.
 
 {{site.data.alerts.callout_info}}
 If you would like to ignore TTL deletes in LDR, you can use the `discard = ttl-deletes` option in the `CREATE LOGICAL REPLICATION STREAM` statement.