update MD by dispatch event pingcap/docs i18n-ja-release-8.5

Author: github-actions

markdown-pages/ja/tidb/release-8.5/best-practices/pd-scheduling-best-practices.md

@@ -299,4 +299,4 @@ v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニ
 
 > **Note:**
 >
-> **Leaderの排除は**、PDがTiKVの低速ノードにスケジューリング要求を送信し、TiKVが受信したスケジューリング要求を順次実行することで実現されます。**低速I/O**などの要因により、低速ノードでは要求が蓄積され、一部のリーダーは遅延した要求が処理されるまで**Leaderの排除**要求を処理できない場合があります。その結果**、Leaderの排除**にかかる時間が全体的に長くなります。したがって、 `evict-slow-store-scheduler`を有効にする場合は、この状況を緩和するために[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)も有効にすることをお勧めします。
+> **Leaderの排除**は、PDがTiKVの低速ノードにスケジューリング要求を送信し、TiKVが受信したスケジューリング要求を順次実行することで実現されます。**低速I/O**などの要因により、低速ノードでは要求が蓄積され、一部のリーダーは遅延した要求が処理されるまで**Leaderの排除**要求を処理できない場合があります。その結果、**Leaderの排除**にかかる時間が全体的に長くなります。したがって、 `evict-slow-store-scheduler`を有効にする場合は、この状況を緩和するために[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)も有効にすることをお勧めします。

markdown-pages/ja/tidb/release-8.5/column-privilege-management.md

@@ -15,7 +15,7 @@ summary: TiDBは、MySQL互換の列レベルの権限管理メカニズムを
 
 列レベルの権限を付与および取り消すための構文は、テーブルレベルの権限の構文と似ていますが、以下の点が異なります。
 
-- 列名リストは**、テーブル名**の後ではなく、**権限タイプ**の後に記述してください。
+- 列名リストは、**テーブル名**の後ではなく、**権限タイプ**の後に記述してください。
 - 複数の列名はカンマで区切られます（ `,` ）。
 
 ```sql

markdown-pages/ja/tidb/release-8.5/dashboard/dashboard-key-visualizer.md

@@ -114,7 +114,7 @@ Key Visualizer を開くと、デフォルトで過去 6時間のデータベー
 
 ![Select metrics](https://docs-download.pingcap.com/media/images/docs/dashboard/dashboard-keyviz-select-type.png)
 
-関心のあるメトリックを表示するには**、メトリック選択ボックス**(上記のインターフェイスの`Write (bytes)`の位置) でこのメトリックを選択します。
+関心のあるメトリックを表示するには、**メトリック選択ボックス**(上記のインターフェイスの`Write (bytes)`の位置) でこのメトリックを選択します。
 
 - `Read (bytes)` : トラフィックを読み取ります。
 - `Write (bytes)` : トラフィックを書き込みます。

markdown-pages/ja/tidb/release-8.5/dashboard/dashboard-ops-reverse-proxy.md

@@ -60,7 +60,7 @@ http://192.168.0.123:2379/dashboard/
 
     > **Warning:**
     >
-    > **このパス内のサービスのみが**リバースプロキシの背後にあることを保証するには、 `use_backend`ディレクティブの`if`部分を保持する必要があります。そうしないと、セキュリティリスクが発生する可能性があります。[TiDB Dashboardのセキュリティ保護](/dashboard/dashboard-ops-security.md)を参照してください。
+    > **このパス内のサービスのみ**がリバースプロキシの背後にあることを保証するには、 `use_backend`ディレクティブの`if`部分を保持する必要があります。そうしないと、セキュリティリスクが発生する可能性があります。[TiDB Dashboardのセキュリティ保護](/dashboard/dashboard-ops-security.md)を参照してください。
 
 2. 設定を有効にするには、HAProxy を再起動します。
 
@@ -212,7 +212,7 @@ backend tidb_dashboard_back
 
 > **Warning:**
 >
-> **このパス内のサービスのみが**リバースプロキシの背後にあることを保証するには、 `use_backend`ディレクティブの`if`部分を保持する必要があります。そうしないと、セキュリティリスクが発生する可能性があります。[TiDB Dashboardのセキュリティ保護](/dashboard/dashboard-ops-security.md)を参照してください。
+> **このパス内のサービスのみ**がリバースプロキシの背後にあることを保証するには、 `use_backend`ディレクティブの`if`部分を保持する必要があります。そうしないと、セキュリティリスクが発生する可能性があります。[TiDB Dashboardのセキュリティ保護](/dashboard/dashboard-ops-security.md)を参照してください。
 
 TiDB Dashboard サービスをルートパス ( `http://example.com:8033/`など) で実行する場合は、次の構成を使用します。
 
@@ -247,7 +247,7 @@ server {
 
 > **Warning:**
 >
-> `proxy_pass`ディレクティブの`/dashboard/`パスは必ず保持し**、このパス内のサービスのみが**リバースプロキシの背後にあるようにする必要があります。そうしないと、セキュリティリスクが発生する可能性があります。[TiDB Dashboardのセキュリティ保護](/dashboard/dashboard-ops-security.md)を参照してください。
+> `proxy_pass`ディレクティブの`/dashboard/`パスは必ず保持し、**このパス内のサービスのみ**がリバースプロキシの背後にあるようにする必要があります。そうしないと、セキュリティリスクが発生する可能性があります。[TiDB Dashboardのセキュリティ保護](/dashboard/dashboard-ops-security.md)を参照してください。
 
 TiDB Dashboard サービスをルートパス ( `http://example.com:8033/`など) で実行する場合は、次の構成を使用します。
 

markdown-pages/ja/tidb/release-8.5/develop/dev-guide-create-table.md

@@ -94,7 +94,7 @@ CREATE TABLE `bookshop`.`books` (
 このテーブルには`users`テーブルよりも多くのデータ型が含まれています。
 
 - [整数](/data-type-numeric.md#integer-types): ディスク使用量の過剰使用やパフォーマンスへの影響（型範囲が大きすぎる場合）またはデータオーバーフロー（データ型範囲が小さすぎる場合）を避けるため、適切なサイズの型を使用することをお勧めします。
-- :[日時](/data-type-date-and-time.md)型は**、**時間値を格納できます。
+- [日時](/data-type-date-and-time.md)型は、時間値を格納できます。
 - [列挙型](/data-type-string.md#enum-type): enum型は、限られた値の選択を格納するために使用できます。
 
 ## 主キーを選択 {#select-primary-key}
@@ -109,9 +109,9 @@ CREATE TABLE `bookshop`.`books` (
 >
 > - TiDBでは、**主キー**は一意であり、NULLであってはなりません。ただし、主キーが**クラスター化インデックス**であることは保証されていません。代わりに、別のキーワードセット`CLUSTERED` / `NONCLUSTERED`によって、**主キー**が**クラスター化インデックス**であるかどうかが制御されます。キーワードが指定されていない場合は、システム変数`@@global.tidb_enable_clustered_index`によって制御されます（[クラスター化インデックス](https://docs.pingcap.com/tidb/stable/clustered-indexes)に記載のとおり）。
 
-**主キー**は`CREATE TABLE`ステートメントで定義されます。[主キー制約](/constraints.md#primary-key)制約付き列すべてに NULL 以外の値のみが含まれることを要求します。
+**主キー**は`CREATE TABLE`ステートメントで定義されます。[主キー制約](/constraints.md#primary-key)は、制約付き列すべてに NULL 以外の値のみが含まれることを要求します。
 
-テーブルは**、主キー**なし、または非整数の**主キー**を使用して作成できます。この場合、TiDB は**暗黙の主キー**として`_tidb_rowid`を作成します。暗黙の主キー`_tidb_rowid`単調増加する性質を持つため、書き込み負荷の高いシナリオでは書き込みホットスポットが発生する可能性があります。したがって、アプリケーションが書き込み負荷の高い場合は、 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)および[`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions)パラメータを使用してデータをシャーディングすることを検討してください。ただし、これにより読み取り増幅が発生する可能性があるため、トレードオフを独自に判断する必要があります。
+テーブルは、**主キー**なし、または非整数の**主キー**を使用して作成できます。この場合、TiDB は**暗黙の主キー**として`_tidb_rowid`を作成します。暗黙の主キー`_tidb_rowid`は単調増加する性質を持つため、書き込み負荷の高いシナリオでは書き込みホットスポットが発生する可能性があります。したがって、アプリケーションが書き込み負荷の高い場合は、 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)および[`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions)パラメータを使用してデータをシャーディングすることを検討してください。ただし、これにより読み取り増幅が発生する可能性があるため、トレードオフを独自に判断する必要があります。
 
 テーブルの**主キー**が[整数型](/data-type-numeric.md#integer-types)で`AUTO_INCREMENT`が使用されている場合、 `SHARD_ROW_ID_BITS`を使用してもホットスポットを回避することはできません。ホットスポットを回避する必要があり、かつ連続的かつ増分的な主キーが必要ない場合は、 `AUTO_INCREMENT`の代わりに[`AUTO_RANDOM`](/auto-random.md)を使用して行 ID の連続性を排除できます。
 

markdown-pages/ja/tidb/release-8.5/develop/dev-guide-sample-application-ruby-rails.md

@@ -251,7 +251,7 @@ production:
 
 > **Note**
 >
-> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、パブリックエンドポイントを使用する際には**、** `ssl_mode`の`verify_identity`クエリパラメータを`DATABASE_URL`に設定して TLS 接続を有効にする必要がありますが、mysql2 gem が特定の順序で既存の CA 証明書を検索してファイルが見つかるまで検索するため、 `DATABASE_URL`を介して SSL CA 証明書を指定する必要**はあり**ません。
+> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、パブリックエンドポイントを使用する際には、`ssl_mode`の`verify_identity`クエリパラメータを`DATABASE_URL`に設定して TLS 接続を有効にする必要がありますが、mysql2 gem が特定の順序で既存の CA 証明書を検索してファイルが見つかるまで検索するため、 `DATABASE_URL`を介して SSL CA 証明書を指定する必要は**ありません**。
 
 ### データを挿入する {#insert-data}
 

markdown-pages/ja/tidb/release-8.5/develop/dev-guide-transaction-restraints.md

@@ -10,15 +10,15 @@ aliases: ['/ja/tidb/stable/dev-guide-transaction-restraints/','/ja/tidb/dev/dev-
 
 ## 隔離レベル {#isolation-levels}
 
-TiDBがサポートする分離レベルは**、RC（Read Committed）**と**SI（Snapshot Isolation）**であり、 **SI**は基本的に**RR（Repeatable Read）**分離レベルと同等です。
+TiDBがサポートする分離レベルは、**RC（Read Committed）**と**SI（Snapshot Isolation）**であり、 **SI**は基本的に**RR（Repeatable Read）**分離レベルと同等です。
 
 ![isolation level](https://docs-download.pingcap.com/media/images/docs/develop/transaction_isolation_level.png)
 
 ## スナップショット分離により、ファントムリードを回避できます。 {#snapshot-isolation-can-avoid-phantom-reads}
 
 TiDB の`SI`分離レベルでは**ファントム リード**を回避できますが、ANSI/ISO SQL 標準の`RR`では回避できません。
 
-以下の2つの例は**、ファントムリード**がどのようなものかを示しています。
+以下の2つの例は、**ファントムリード**がどのようなものかを示しています。
 
 - 例 1:**トランザクションA は**、まずクエリに従って`n`行を取得し、次に**トランザクションB は**、これらの`m`行以外の`n`行を変更するか、**トランザクションA**のクエリに一致する`m`行を追加します。**トランザクションA**が再度クエリを実行すると、条件に一致する`n+m`行が存在することがわかります。これはファントムのようなものなので、**ファントム リード**と呼ばれます。
 

markdown-pages/ja/tidb/release-8.5/develop/dev-guide-update-data.md

@@ -105,7 +105,7 @@ INSERT INTO {table} ({columns}) VALUES ({values})
 
 ### `INSERT ON DUPLICATE KEY UPDATE`のベストプラクティス {#insert-on-duplicate-key-update-best-practices}
 
-- `INSERT ON DUPLICATE KEY UPDATE`は、一意キーが 1つだけのテーブルでのみ使用してください。このステートメントは***、一意キー***(主キーを含む) の競合が検出された場合、データを更新します。競合する行が複数ある場合、更新されるのは 1 行のみです。したがって、競合する行が 1つだけであることを保証できない限り、一意キーが複数あるテーブルで`INSERT ON DUPLICATE KEY UPDATE`ステートメントを使用することはお勧めしません。
+- `INSERT ON DUPLICATE KEY UPDATE`は、一意キーが 1つだけのテーブルでのみ使用してください。このステートメントは、一意キー(主キーを含む) の競合が検出された場合、データを更新します。競合する行が複数ある場合、更新されるのは 1 行のみです。したがって、競合する行が 1つだけであることを保証できない限り、一意キーが複数あるテーブルで`INSERT ON DUPLICATE KEY UPDATE`ステートメントを使用することはお勧めしません。
 - データを作成または更新する際に、このステートメントを使用してください。
 
 ### `INSERT ON DUPLICATE KEY UPDATE`例 {#insert-on-duplicate-key-update-example}

markdown-pages/ja/tidb/release-8.5/dm/dm-safe-mode.md

@@ -12,7 +12,7 @@ summary: DMセーフモードについて、その目的、動作原理、およ
 チェックポイントからデータレプリケーションタスクを再開した後、DMは一部のbinlogイベントを繰り返しレプリケートする可能性があり、その結果、以下の問題が発生します。
 
 - 増分レプリケーションでは、DMLの実行操作とチェックポイントの書き込み操作は同時に行われません。チェックポイントの書き込み操作とダウンストリームデータベースへのデータの書き込み操作はアトミックではありません。そのため、 **DMが異常終了した場合、チェックポイントには終了ポイントの直前の復元ポイントのみが記録される可能性があります**。
-- DMがレプリケーションタスクを再開し、チェックポイントから増分レプリケーションを再開する場合、チェックポイントと終了ポイントの間のデータの一部は、異常終了前に既に処理されている可能性があります。これにより**、一部のSQLステートメントが繰り返し実行されること**があります。
+- DMがレプリケーションタスクを再開し、チェックポイントから増分レプリケーションを再開する場合、チェックポイントと終了ポイントの間のデータの一部は、異常終了前に既に処理されている可能性があります。これにより、**一部のSQLステートメントが繰り返し実行されること**があります。
 - `INSERT`ステートメントが繰り返し実行されると、主キーまたは一意インデックスで競合が発生し、レプリケーションエラーが発生する可能性があります。 `UPDATE`ステートメントが繰り返し実行されると、フィルタ条件が以前に更新されたレコードを見つけられない可能性があります。
 
 セーフモードでは、DMはSQL文を書き換えて上記の問題を解決できます。

markdown-pages/ja/tidb/release-8.5/dm/relay-log.md

@@ -13,7 +13,7 @@ summary: DM リレーログのディレクトリ構造、初期移行ルール
 
 MySQLではストレージ容量が限られているため、最大保存期間に達するとbinlogは自動的に消去されます。上流データベースがbinlogを消去すると、DMは消去されたbinlogを取得できず、移行タスクは失敗します。移行タスクごとに、DMは上流データベースに接続を作成し、binlogを取得します。接続数が多すぎると、上流データベースの負荷が増大する可能性があります。
 
-リレーログを有効にすると、同じ上流データベースを持つ複数の移行タスクで、ローカルディスクにプルされたリレーログを再利用できます。これにより**、上流データベースへの負荷が軽減されます**。
+リレーログを有効にすると、同じ上流データベースを持つ複数の移行タスクで、ローカルディスクにプルされたリレーログを再利用できます。これにより、**上流データベースへの負荷が軽減されます**。
 
 完全データ移行タスクと増分データ移行タスク（ `task-mode=all` ）では、DMはまず完全データを移行し、その後、binlogに基づいて増分移行を実行する必要があります。完全移行フェーズに時間がかかると、上流のbinlogが消去され、増分移行が失敗する可能性があります。このような状況を回避するには、リレーログ機能を有効にすることで、DMがローカルディスクに十分なログを自動的に保持し、**増分移行タスクが正常に実行されるようにします**。