Merge branch 'jun/d1/rr-v2' of github.com:cloudflare/cloudflare-docs into jun/d1/rr-v2

Author: Oxyjun

src/content/docs/d1/best-practices/read-replication.mdx

@@ -8,7 +8,7 @@ sidebar:
 
 import { GlossaryTooltip, Details, GitHubCode, APIRequest, Tabs, TabItem, TypeScriptExample } from "~/components"
 
-D1 read replication can lower latency for read queries and scale read throughput by adding read-only database copies, called read replicas, across global regions closer to clients.
+D1 read replication can lower latency for read queries and scale read throughput by adding read-only database copies, called read replicas, across regions globally closer to clients.
 
 Your application can use read replicas with D1 [Sessions API](/d1/worker-api/d1-database/#withsession). A Session encapsulates all the queries from one logical session for your application. For example, a Session may correspond to all queries coming from a particular web browser session. All queries within a Session read from a database instance which is as up-to-date as your query needs it to be. Sessions API ensures [sequential consistency](/d1/best-practices/read-replication/#replica-lag-and-consistency-model) for all queries in a Session.
 
@@ -172,7 +172,7 @@ Even though a user may be located far away from the primary database instance, t
 D1 asynchronously replicates changes from the primary database instance to all read replicas. This means that at any given time, a read replica may be arbitrarily out of date. The time it takes for the latest committed data in the primary database instance to be replicated to the read replica is known as the <GlossaryTooltip term="replica lag"> replica lag </GlossaryTooltip>. Replica lag and non-deterministic routing to individual replicas can lead to application data consistency issues.
 The D1 Sessions API solves this by ensuring sequential consistency.
 For more information, refer to [replica lag and consistency model](/d1/best-practices/read-replication/#replica-lag-and-consistency-model).
-
+All write queries are still forwarded to the primary database instance. Read replication only improves the response time for read query requests.
 :::note
 All write queries are still forwarded to the primary database instance. Read replication only improves the response time for read query requests.
 :::
@@ -369,7 +369,7 @@ async function getBillStatement(accountId: string, billId: string, bookmark: str
 
 ### Start a Session from previous context (bookmark)
 
-To create a new Session from the context of a previous Session, pass a `bookmark` parameter to guarantee that the Session starts with database state as of or later than the provided `bookmark`. `bookmark` could be saved in HTTP header from previous Session.
+To create a new Session from the context of a previous Session, pass a `bookmark` parameter to guarantee that the Session starts with a database version that is at least as up-to-date as the provided `bookmark`.
 
 ```ts
 const bookmark = request.headers.get('x-d1-bookmark') ?? 'first-unconstrained';
@@ -382,7 +382,7 @@ const result = await session
 response.headers.set('x-d1-bookmark', session.getBookmark() ?? "")
 ```
 
-- Starting a Session with a `bookmark` ensures the new Session has all the same context as the previous Session.
+- Starting a Session with a `bookmark` ensures the new Session will be at least as up-to-date as the previous Session that generated the given `bookmark`.
 - Refer to the [D1 Workers Binding API documentation](/d1/worker-api/d1-database#withsession).
 
 {/* #### Example of using `bookmark`
@@ -493,7 +493,6 @@ console.log({
 ```
 
 - `served_by_region` and `served_by_primary` fields are present for all D1 remote requests, regardless of whether read replication is enabled or if the Sessions API is used. On local development, `npx wrangler dev`, these fields are `undefined`.
-- You can also manually calculate the query latency using `Date.now()` before and after your query.
 
 ## Read replica locations