update stale read doc for ga (#6047)

as-of-timestamp.md

@@ -9,12 +9,10 @@ This document describes how to perform the [Stale Read](/stale-read.md) feature
 
 > **Warning:**
 >
-> Currently, Stale Read is an experimental feature. It is not recommended to use it in the production environment.
->
 > Currently, you cannot use Stale Read together with TiFlash. If your SQL query contains the `AS OF TIMESTAMP` clause and TiDB might read data from TiFlash replicas, you might encounter an error with a message like `ERROR 1105 (HY000): stale requests require tikv backend`.
 >
 > To fix the problem, disable TiFlash replicas for your Stale Read query. To do that, perform one of the following operations:
-> 
+>
 > - Use the `set session tidb_isolation_read_engines='tidb,tikv'` variable.
 > - Use the [hint](/optimizer-hints.md#read_from_storagetiflasht1_name--tl_name--tikvt2_name--tl_name-) to enforce TiDB to read data from TiKV.
 
@@ -47,9 +45,7 @@ Here are some examples of the `AS OF TIMESTAMP` clause:
 >
 > In addition to specifying a timestamp, the most common use of the `AS OF TIMESTAMP` clause is to read data that is several seconds old. If this approach is used, it is recommended to read historical data older than 5 seconds.
 >
-> You need to deploy the NTP service for your TiDB and PD nodes when you use Stale Read. This avoids the situation where the specified timestamp used by TiDB goes ahead of the latest TSO allocating progress (such as a timestamp several seconds ahead), or is later than the GC safe point timestamp. When the specified timestamp goes beyond the service scope, TiDB returns an error or waits for the transaction to commit.
->
-> The `Prepare` statement and the `AS OF TIMESTAMP` syntax are not perfectly compatible. It is not recommended to use them together.
+> You need to deploy the NTP service for your TiDB and PD nodes when you use Stale Read. This avoids the situation where the specified timestamp used by TiDB goes ahead of the latest TSO allocating progress (such as a timestamp several seconds ahead), or is later than the GC safe point timestamp. When the specified timestamp goes beyond the service scope, TiDB returns an error.
 
 ## Usage examples
 

experimental-features.md

@@ -30,7 +30,6 @@ This document introduces the experimental features of TiDB in different versions
 + [User-Defined Variables](/user-defined-variables.md).
 + [JSON data type](/data-type-json.md) and [JSON functions](/functions-and-operators/json-functions.md).
 + [View](/information-schema/information-schema-views.md).
-+ [Stale Read](/stale-read.md).
 
 ## Configuration management
 

stale-read.md

@@ -9,10 +9,6 @@ This document describes the usage scenarios of Stale Read. Stale Read is a mecha
 
 When you are using Steal Read, TiDB will randomly select a replica for data reading, which means that all replicas are available for data reading. If your application cannot tolerate reading non-real-time data, do not use Stale Read; otherwise, the data read from the replica might not be the latest data written into TiDB.
 
-> **Warning:**
->
-> Currently, Stale Read is an experimental feature. It is not recommended to use it in the production environment.
-
 ## Scenario examples
 
 + Scenario one: If a transaction only involves read operations and is tolerant of data staleness to some extent, you can use Stale Read to get historical data. Using Stale Read, TiDB makes the query requests sent to any replica at the expense of some real-time performance, and thus increases the throughput of query executions. Especially in some scenarios where small tables are queried, if strongly consistent reads are used, leader might be concentrated on a certain storage node, causing the query pressure to be concentrated on that node as well. Therefore, that node might become a bottleneck for the whole query. Stale Read, however, can improve the overall query throughput and significantly improve the query performance.