From fea64d041822573d0a41069a0a8dfc29445b8ff1 Mon Sep 17 00:00:00 2001 From: Kathryn May Date: Tue, 5 Nov 2024 15:51:54 -0500 Subject: [PATCH] Alicia feedback --- .../_includes/v24.3/ldr/show-logical-replication-responses.md | 1 + src/current/v24.3/logical-data-replication-monitoring.md | 2 +- src/current/v24.3/logical-data-replication-overview.md | 2 +- 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/current/_includes/v24.3/ldr/show-logical-replication-responses.md b/src/current/_includes/v24.3/ldr/show-logical-replication-responses.md index 0ddf2c0912d..3b8fce3b67c 100644 --- a/src/current/_includes/v24.3/ldr/show-logical-replication-responses.md +++ b/src/current/_includes/v24.3/ldr/show-logical-replication-responses.md @@ -6,3 +6,4 @@ Field | Response `replicated_time` | The latest timestamp at which the destination cluster has consistent data. This time advances automatically as long as the LDR job proceeds without error. `replicated_time` is updated periodically (every 30s). {% comment %}To confirm this line is accurate{% endcomment %} `replication_start_time` | The start time of the LDR job. `conflict_resolution_type` | The type of [conflict resolution]({% link {{ page.version.version }}/manage-logical-data-replication.md %}#conflict-resolution): `LWW` last write wins. +`description` | Description of the job including the replicating table(s) and the source cluster connection. diff --git a/src/current/v24.3/logical-data-replication-monitoring.md b/src/current/v24.3/logical-data-replication-monitoring.md index 4e0344a8f18..2c9b0b7a411 100644 --- a/src/current/v24.3/logical-data-replication-monitoring.md +++ b/src/current/v24.3/logical-data-replication-monitoring.md @@ -61,7 +61,7 @@ SHOW LOGICAL REPLICATION JOBS WITH details; ## Recommended LDR metrics to track -- Replication latency: The commit-to-commit replication latency. A _commit_ is when the LDR job either adds a row to the [dead letter queue (DLQ)]({% link {{ page.version.version }}/manage-logical-data-replication.md %}#dead-letter-queue-dlq) or applies a row successfully to the destination cluster. +- Replication latency: The commit-to-commit replication latency, which is tracked from when a row is committed on the source cluster, to when it is "committed" on the destination cluster. A _commit_ is when the LDR job either adds a row to the [dead letter queue (DLQ)]({% link {{ page.version.version }}/manage-logical-data-replication.md %}#dead-letter-queue-dlq) or applies a row successfully to the destination cluster. - `logical_replication.commit_latency-p50` - `logical_replication.commit_latency-p99` - Replication lag: How far behind the source cluster is from the destination cluster at a specific point in time. The replication lag is equivalent to [RPO]({% link {{ page.version.version }}/disaster-recovery-overview.md %}) during a disaster. diff --git a/src/current/v24.3/logical-data-replication-overview.md b/src/current/v24.3/logical-data-replication-overview.md index 8f7f962b97c..e0523ac9ab6 100644 --- a/src/current/v24.3/logical-data-replication-overview.md +++ b/src/current/v24.3/logical-data-replication-overview.md @@ -38,7 +38,7 @@ Isolate critical application workloads from non-critical application workloads i - **Table-level replication**: When you initiate LDR, it will replicate all of the source table's existing data to the destination table. From then on, LDR will replicate the source table's data to the destination table to achieve eventual consistency. - **Last write wins conflict resolution**: LDR uses [_last write wins (LWW)_ conflict resolution]({% link {{ page.version.version }}/manage-logical-data-replication.md %}#conflict-resolution), which will use the latest MVCC timestamp to resolve a conflict in row insertion. - **Dead letter queue (DLQ)**: When LDR starts, the job will create a [DLQ table]({% link {{ page.version.version }}/manage-logical-data-replication.md %}#dead-letter-queue-dlq) with each replicating table in order to track unresolved conflicts. You can interact and manage this table like any other SQL table. -- **Replication modes**: In LDR, you can use different _modes_ to apply different configurations to the replication. The modes will allow you to configure for throughput. +- **Replication modes**: LDR offers different _modes_ that apply data differently during replication, which allows you to consider optimizing for throughput or constraints during replication. - **Monitoring**: To [monitor]({% link {{ page.version.version }}/logical-data-replication-monitoring.md %}) LDR's initial progress, current status, and performance, you can metrics available in the DB Console, Prometheus, and Metrics Export. ## Get started