i18n(ja): restore text dropped by the translation pipeline

as-of-timestamp.md

@@ -21,9 +21,9 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標
 -   [`START TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-start-transaction.md)
 -   [`SET TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-set-transaction.md)
 
-正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには「2016-10-08 16:45:26」のように秒単位で十分です。3 関数を使用して、現在時刻を`NOW(3)`秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。
+正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには「2016-10-08 16:45:26」のように秒単位で十分です。`NOW(3)`関数を使用して、現在時刻をミリ秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。
 
-時間範囲を指定する場合は、句内で[`TIDB_BOUNDED_STALENESS()`](/functions-and-operators/tidb-functions.md#tidb_bounded_staleness)関数を使用できます。この関数を使用すると、TiDB は指定された時間範囲内で適切なタイムスタンプを選択します。「適切」とは、このタイムスタンプより前に開始され、アクセス先のレプリカにコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセス先のレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされていないことを意味します。この関数を呼び出すには`TIDB_BOUNDED_STALENESS(t1, t2)`使用する必要があります。5 と`t2` `t1`範囲の両端であり、datetime 値または時間関数を使用して指定できます。
+時間範囲を指定する場合は、句内で[`TIDB_BOUNDED_STALENESS()`](/functions-and-operators/tidb-functions.md#tidb_bounded_staleness)関数を使用できます。この関数を使用すると、TiDB は指定された時間範囲内で適切なタイムスタンプを選択します。「適切」とは、このタイムスタンプより前に開始され、アクセス先のレプリカにコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセス先のレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされていないことを意味します。この関数を呼び出すには`TIDB_BOUNDED_STALENESS(t1, t2)`を使用する必要があります。`t1`と`t2`は範囲の両端であり、datetime 値または時間関数を使用して指定できます。
 
 `AS OF TIMESTAMP`句の例をいくつか示します。
 

benchmark/benchmark-tidb-using-ch.md

@@ -62,7 +62,7 @@ TiFlashをデプロイした後、 TiFlash はTiKV データを自動的に複
 
     ALTER DATABASE tpcc SET tiflash replica 2;
 
-`tpcc`データベース内のすべてのテーブルのレプリケーションが完了しているかどうかを確認するには、次のステートメントを実行します。3 句は、確認するデータベースとテーブルを指定します。すべてのデータベースのレプリケーション状態を確認する場合は、ステートメントから`WHERE`句`WHERE`削除します。
+`tpcc`データベース内のすべてのテーブルのレプリケーションが完了しているかどうかを確認するには、次のステートメントを実行します。`WHERE`句は、確認するデータベースとテーブルを指定します。すべてのデータベースのレプリケーション状態を確認する場合は、ステートメントから`WHERE`句を削除します。
 
 ```sql
 SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'tpcc';

benchmark/online-workloads-and-add-index-operations.md

@@ -82,7 +82,7 @@ sysbench $testname \
 ## テストプラン1: <code>ADD INDEX</code>文の対象列への書き込み操作を頻繁に実行する {#test-plan-1-frequently-perform-write-operations-to-the-target-column-of-the-code-add-index-code-statement}
 
 1.  `oltp_read_write`テストを開始します。
-2.  手順`alter table sbtest1 add index c_idx(c)`と同時に実行します。1 を使用してインデックスを追加します。
+2.  手順 1 と同時に実行します。`alter table sbtest1 add index c_idx(c)`を使用してインデックスを追加します。
 3.  手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_write`を停止します。
 4.  `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。
 5.  2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。
@@ -217,7 +217,7 @@ sysbench $testname \
 ## テストプラン 2: <code>ADD INDEX</code>ステートメントのターゲット列への書き込み操作を実行しない (クエリのみ) {#test-plan-2-do-not-perform-write-operations-to-the-target-column-of-the-code-add-index-code-statement-query-only}
 
 1.  `oltp_read_only`テストを開始します。
-2.  手順`alter table sbtest1 add index c_idx(c)`と同時に実行します。1 を使用してインデックスを追加します。
+2.  手順 1 と同時に実行します。`alter table sbtest1 add index c_idx(c)`を使用してインデックスを追加します。
 3.  手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_only`を停止します。
 4.  `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。
 5.  2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。
@@ -279,7 +279,7 @@ sysbench $testname \
 ## テストプラン3: <code>ADD INDEX</code>文のターゲット列はオンラインワークロードとは無関係です {#test-plan-3-the-target-column-of-the-code-add-index-code-statement-is-irrelevant-to-online-workloads}
 
 1.  `oltp_read_write`テストを開始します。
-2.  手順`alter table test add index pad_idx(pad)`と同時に実行します。1 を使用してインデックスを追加します。
+2.  手順 1 と同時に実行します。`alter table test add index pad_idx(pad)`を使用してインデックスを追加します。
 3.  手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_only`を停止します。
 4.  `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。
 5.  2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。

best-practices/pd-scheduling-best-practices.md

@@ -213,7 +213,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー
 
 -   オペレータが正常に生成されていても、スケジュール処理が遅い場合は、次のことが考えられます。
 
-    -   スケジューリング速度は、負荷分散を目的としてデフォルトで制限されています。1 または`region-schedule-limit` `leader-schedule-limit`を大きくしても、通常のサービスに大きな影響はありません。また、 `max-pending-peer-count`および`max-snapshot-count`で指定された制限を適切に緩和することもできます。
+    -   スケジューリング速度は、負荷分散を目的としてデフォルトで制限されています。`leader-schedule-limit`または`region-schedule-limit`を大きくしても、通常のサービスに大きな影響はありません。また、 `max-pending-peer-count`および`max-snapshot-count`で指定された制限を適切に緩和することもできます。
     -   他のスケジューリングタスクが同時に実行されているため、バランシングの速度が低下しています。この場合、バランシングが他のスケジューリングタスクよりも優先される可能性がある場合は、他のタスクを停止するか、速度を制限することができます。例えば、バランシングの実行中に一部のノードをオフラインにすると、両方の操作でクォータ`region-schedule-limit`が消費されます。このような場合、スケジューラの速度を制限してノードを削除するか、 `enable-replace-offline-replica = false`設定して一時的に無効にすることができます。
     -   スケジューリングプロセスが遅すぎます。原因を確認するには`RemovePeer` **Operator ステップの所要時間**メトリックを確認してください。通常、スナップショットの送受信を伴わないステップ（ `TransferLeader` `PromoteLearner` ）は数ミリ秒で完了するはずですが、スナップショットを伴うステップ（ `AddLearner` `AddPeer` ）は数十秒で完了すると予想されます。所要時間が明らかに長すぎる場合は、TiKV の負荷が高いか、ネットワークのボトルネックが発生している可能性があります。具体的な分析が必要です。
 
@@ -229,8 +229,8 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー
 
 オペレーターは正常に生成されたが、スケジュール プロセスが遅い場合は、次の理由が考えられます。
 
--   スケジューリング速度はデフォルトで制限されています。1 または`leader-schedule-limit` `replica-schedule-limit`値を大きく調整できます。同様に、 `max-pending-peer-count`と`max-snapshot-count`の制限を緩和することも検討できます。
--   他のスケジューリングタスクが同時に実行され、システム内のリソースを奪い合っています。解決策は[リーダー/リージョンが均等に分布していない](#leaders-regions-are-not-evenly-distributed)を参照してください。
+-   スケジューリング速度はデフォルトで制限されています。`leader-schedule-limit`または`replica-schedule-limit`の値を大きく調整できます。同様に、 `max-pending-peer-count`と`max-snapshot-count`の制限を緩和することも検討できます。
+-   他のスケジューリングタスクが同時に実行され、システム内のリソースを奪い合っています。解決策は[リーダー/リージョンが均等に分布していない](#leadersregions-are-not-evenly-distributed)を参照してください。
 -   単一ノードをオフラインにすると、処理対象となるリージョンリーダー（レプリカ3台構成では約1/3）が削除対象のノードに分散されます。そのため、処理速度はこの単一ノードによるスナップショット生成速度によって制限されます。「 `evict-leader-scheduler`を手動で追加することで、リージョンリーダーの移行速度を上げることができます。
 
 対応する演算子の生成に失敗した場合、考えられる理由は次のとおりです。
@@ -240,7 +240,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー
 
 ### ノードをオンラインにするのが遅い {#bringing-nodes-online-is-slow}
 
-現在、ノードのオンライン化はバランスリージョンメカニズムを通じてスケジュールされています。トラブルシューティングについては[リーダー/リージョンが均等に分布していない](#leaders-regions-are-not-evenly-distributed)を参照してください。
+現在、ノードのオンライン化はバランスリージョンメカニズムを通じてスケジュールされています。トラブルシューティングについては[リーダー/リージョンが均等に分布していない](#leadersregions-are-not-evenly-distributed)を参照してください。
 
 ### ホットリージョンが均等に分布していない {#hot-regions-are-not-evenly-distributed}