diff --git a/ai/concepts/vector-search-overview.md b/ai/concepts/vector-search-overview.md index 74046af26c81f..51d902fc56187 100644 --- a/ai/concepts/vector-search-overview.md +++ b/ai/concepts/vector-search-overview.md @@ -27,7 +27,7 @@ aliases: ['/ja/tidb/stable/vector-search-overview/','/ja/tidb/dev/vector-search- ベクトル埋め込み（または埋め込み）とは、現実世界のオブジェクトを高次元空間で表現する数値のシーケンスです。これは、文書、画像、音声、動画などの非構造化データの意味と文脈を捉えます。 -ベクトル埋め込みは機械学習において不可欠であり、意味的類似性検索の基盤となる。 +ベクトル埋め込みは機械学習において不可欠であり、意味的類似性検索の基盤となります。 TiDB は、ベクトル埋め込みのストレージと検索を最適化するように設計された[ベクトルデータ型](/ai/reference/vector-search-data-types.md)と[ベクトル検索インデックス](/ai/reference/vector-search-index.md)を導入し、AI アプリケーションでの使用を強化します。ベクトル埋め込みを TiDB に保存し、ベクトル検索クエリを実行して、これらのデータ タイプを使用して最も関連性の高いデータを見つけることができます。 diff --git a/ai/integrations/tidb-mcp-server.md b/ai/integrations/tidb-mcp-server.md index 217bc7e6963b1..33a3f24c57ac4 100644 --- a/ai/integrations/tidb-mcp-server.md +++ b/ai/integrations/tidb-mcp-server.md @@ -11,11 +11,11 @@ TiDB MCP Serverは、自然言語による指示を用いてTiDBデータベー [モデルコンテキストプロトコル（MCP）](https://modelcontextprotocol.io/introduction)は、LLMと外部ツール間の通信を標準化するプロトコルです。 -MCPはクライアント/サーバーアーキテクチャを採用しており、ホストアプリケーションが複数の外部サーバーに接続できるようになっている。 +MCPはクライアント/サーバーアーキテクチャを採用しており、ホストアプリケーションが複数の外部サーバーに接続できるようになっています。 - **ホスト**：Claude DesktopやCursorなどのIDEといった、MCPサーバーへの接続を開始するAI搭載アプリケーション。 -- **クライアント**：ホストアプリケーションに組み込まれたコンポーネントで、個々のMCPサーバーと1対1の接続を確立する。 +- **クライアント**：ホストアプリケーションに組み込まれたコンポーネントで、個々のMCPサーバーと1対1の接続を確立します。 - **サーバー**： **TiDB MCPサーバー**などの外部サービスで、クライアントが外部システムとやり取りするためのツール、コンテキスト、およびプロンプトを提供します。 diff --git a/ai/quickstart-via-python.md b/ai/quickstart-via-python.md index dc2b55a53e99d..5a6fb32ca4740 100644 --- a/ai/quickstart-via-python.md +++ b/ai/quickstart-via-python.md @@ -13,7 +13,7 @@ aliases: ['/ja/tidb/stable/vector-search-get-started-using-python/','/ja/tidb/de - TiDB Python SDKを使用してTiDBに接続します。 - 一般的な埋め込みモデルを使用してテキスト埋め込みを生成します。 - ベクトルをTiDBテーブルに格納します。 -- ベクトル類似度を用いて意味検索を実行する。 +- ベクトル類似度を用いて意味検索を実行します。 > **Note:** > diff --git a/alert-rules.md b/alert-rules.md index 600d800468fc1..f5bdf9c6c7975 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -49,7 +49,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 解決： - リーダーのバランスが取れているかどうかを確認するには、[**TiKV詳細**>**クラスタ**ダッシュボード](/grafana-tikv-dashboard.md#cluster)を確認する。 + リーダーのバランスが取れているかどうかを確認するには、[**TiKV詳細**>**クラスタ**ダッシュボード](/grafana-tikv-dashboard.md#cluster)を確認します。 #### `TiDB_domain_load_schema_total` {#tidb_domain_load_schema_total} @@ -140,7 +140,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 解決： - TiKV の監視ステータスを確認する。 + TiKV の監視ステータスを確認します。 #### `TiDB_monitor_time_jump_back_error` {#tidb_monitor_time_jump_back_error} diff --git a/as-of-timestamp.md b/as-of-timestamp.md index bdced1f8f79cb..69f7b75405f2a 100644 --- a/as-of-timestamp.md +++ b/as-of-timestamp.md @@ -64,7 +64,7 @@ insert into t values (1), (2), (3); Query OK, 3 rows affected (0.00 sec) ``` -表内のデータを表示する。 +表内のデータを表示します。 ```sql select * from t; diff --git a/backup-and-restore-using-dumpling-lightning.md b/backup-and-restore-using-dumpling-lightning.md index d343aaea4765e..e14d2fb00a591 100644 --- a/backup-and-restore-using-dumpling-lightning.md +++ b/backup-and-restore-using-dumpling-lightning.md @@ -80,7 +80,7 @@ LIMIT ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットの TiKV クラスターのストレージ容量は**、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、ターゲットの TiKV クラスターは、データソースのサイズの 6 倍よりも大きなストレージ容量が必要です。この式に x 2 が含まれている理由は次のとおりです。 - インデックスには余分な容量が必要になる場合があります。 -- RocksDBには空間増幅がある。 +- RocksDBには空間増幅があります。 ## Dumplingを使用してフルデータをバックアップします {#use-dumpling-to-back-up-full-data} diff --git a/best-practices/_index.md b/best-practices/_index.md index 26fed08df4e93..84f0bd685c863 100644 --- a/best-practices/_index.md +++ b/best-practices/_index.md @@ -49,7 +49,7 @@ TiDBにおけるスキーマ設計のベストプラクティスを学びまし ## パフォーマンスチューニング {#performance-tuning} -TiKVやPDなどのTiDBコンポーネントのチューニング方法、および読み取り専用ストレージノードなどの機能を使用してさまざまなワークロード下でのパフォーマンスを向上させる方法を理解する。 +TiKVやPDなどのTiDBコンポーネントのチューニング方法、および読み取り専用ストレージノードなどの機能を使用してさまざまなワークロード下でのパフォーマンスを向上させる方法を理解しましょう。 | ベストプラクティスのトピック | 説明 | | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index 6da8e35ae5584..f934aa3d2e90f 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -215,4 +215,4 @@ TiDBは、以下のシナリオに適しています。 - シャーディングはしたくない - アクセスモードには明らかなホットスポットはありません - トランザクション、高い一貫性、およびディザスタリカバリが求められます。 -- リアルタイムのハイブリッドトランザクション/分析処理（HTAP）分析を実現し、データパイプラインを削減したいと考えている。 +- リアルタイムのハイブリッドトランザクション/分析処理（HTAP）分析を実現し、データパイプラインを削減したいと考えています。 diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index 65f5c888ed0ca..11aaf8e7f927e 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -11,7 +11,7 @@ BRは以下の要件を満たしています。 - クラスターデータを最短5分のRPO（目標復旧時点）でディザスタリカバリ（DR）システムにバックアップすることで、災害発生時のデータ損失を軽減します。 - アプリケーションの動作不良が発生した場合は、エラー発生前の時点までデータをロールバックすることで対処します。 -- 司法監督の要件を満たすために、履歴データの監査を実施する。 +- 司法監督の要件を満たすために、履歴データの監査を実施します。 - 本番環境を複製することで、トラブルシューティング、パフォーマンスチューニング、シミュレーションテストに便利になります。 ## 使用する前に {#before-you-use} diff --git a/check-before-deployment.md b/check-before-deployment.md index c5b46cb4c860a..0385c6d222381 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -21,7 +21,7 @@ summary: TiDB をデプロイする前に環境チェック操作について学 `/dev/nvme0n1`データ ディスクを例に挙げます。 -1. データ ディスクを表示する。 +1. データ ディスクを表示します。 ```bash fdisk -l @@ -54,7 +54,7 @@ summary: TiDB をデプロイする前に環境チェック操作について学 mkfs.ext4 /dev/nvme0n1p1 ``` -4. データ ディスクのパーティション UUIDを表示する。 +4. データ ディスクのパーティション UUIDを表示します。 この例では、nvme0n1p1 の UUID は`c51eb23b-195c-4061-92a9-3fad812cc12f`です。 diff --git a/clinic/clinic-data-instruction-for-tiup.md b/clinic/clinic-data-instruction-for-tiup.md index 9adec6a2d457b..0727233ad81f2 100644 --- a/clinic/clinic-data-instruction-for-tiup.md +++ b/clinic/clinic-data-instruction-for-tiup.md @@ -150,5 +150,5 @@ PingCAP Clinicによって収集された診断データは、クラスターの - `std` : ファイル名に`stderr`含まれるログファイル。 - `rocksdb` : プレフィックスが`rocksdb` 、サフィックスが`.info`ログ ファイル。 -- `slow` : クエリ ログ ファイルが遅い。 +- `slow` : スロークエリログファイル。 - `unknown` : 上記のいずれの種類にも一致しないログ ファイル。 diff --git a/configure-load-base-split.md b/configure-load-base-split.md index eee47692d3bbb..1cfaafd97be10 100644 --- a/configure-load-base-split.md +++ b/configure-load-base-split.md @@ -18,7 +18,7 @@ TiDBでは、負荷が特定のノードに集中すると、ホットスポッ 以前は、この問題の解決策として、1 つ以上のホットスポットリージョンを分割するコマンドを手動で実行していましたが、この方法には 2 つの問題がありました。 - リージョンを均等に分割することは、必ずしも最適な選択とは限りません。リクエストが少数のキーに集中する可能性があるためです。このような場合、均等分割後もホットスポットがいずれかのリージョンに残る可能性があり、目的を達成するには複数回の均等分割が必要になる場合があります。 -- 人間の介入はタイムリーでも簡単でもない。 +- 人間の介入はタイムリーでも簡単でもありません。 ## 実装原理 {#implementation-principles} diff --git a/dashboard/dashboard-profiling.md b/dashboard/dashboard-profiling.md index 4ba6876c76ecc..23d48483a2466 100644 --- a/dashboard/dashboard-profiling.md +++ b/dashboard/dashboard-profiling.md @@ -1,6 +1,6 @@ --- title: TiDB Dashboard Instance Profiling - Manual Profiling -summary: 手動プロファイリングを使用すると、TiDB、TiKV、PD、 TiFlashインスタンスの現在のパフォーマンスデータをオンデマンドで収集できます。エキスパートはCPUやメモリなどのリソース消費量の詳細を分析し、進行中のパフォーマンス問題を特定できます。このページには、TiDB Dashboardまたはブラウザからアクセスできます。対象インスタンスを選択してプロファイリングを開始し、必要に応じて期間を変更します。リアルタイムの進行状況を確認し、プロファイリング完了後にパフォーマンスデータをダウンロードできます。詳細な操作については、プロファイリング履歴を確認する。 +summary: 手動プロファイリングを使用すると、TiDB、TiKV、PD、 TiFlashインスタンスの現在のパフォーマンスデータをオンデマンドで収集できます。エキスパートはCPUやメモリなどのリソース消費量の詳細を分析し、進行中のパフォーマンス問題を特定できます。このページには、TiDB Dashboardまたはブラウザからアクセスできます。対象インスタンスを選択してプロファイリングを開始し、必要に応じて期間を変更します。リアルタイムの進行状況を確認し、プロファイリング完了後にパフォーマンスデータをダウンロードできます。詳細な操作については、プロファイリング履歴を確認します。 --- # TiDB Dashboardインスタンスプロファイリング - 手動プロファイリング {#tidb-dashboard-instance-profiling-manual-profiling} diff --git a/dashboard/top-sql.md b/dashboard/top-sql.md index 45087b9f5a64b..f32cd63db4afe 100644 --- a/dashboard/top-sql.md +++ b/dashboard/top-sql.md @@ -37,7 +37,7 @@ Top SQLは、パフォーマンスの問題を分析するのに適していま 以下のいずれかの方法で、Top SQLページにアクセスできます。 -- TiDB Dashboardにログイン後、左側のナビゲーションメニューにある**Top SQL**をクリックしてください。 +- TiDB Dashboardにログイン後、左側のナビゲーションメニューにある**Top SQL**をクリックします。 ![Top SQL](/media/dashboard/v8.5-top-sql-access.png) diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index a65fb68cf5a9f..814219a1ac906 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -120,7 +120,7 @@ connections = ((core_count * 2) + effective_spindle_count) - **core_countは**、 [ハイパースレッディング](https://en.wikipedia.org/wiki/Hyper-threading)有効にするかどうかに関わらず、物理コアの数です。 - データが完全にキャッシュされると、 **effective_spindle_count を**`0`に設定する必要があります。キャッシュのヒット率が低下すると、カウントは実際の数値である`HDD`に近づきます。 -- **この計算式が*SSD*にも有効かどうかは検証されておらず、不明である。** +- **この計算式が*SSD*にも有効かどうかは検証されておらず、不明です。** SSDを使用する場合は、経験に基づき、以下の式を使用することをお勧めします。 diff --git a/develop/dev-guide-sample-application-golang-sql-driver.md b/develop/dev-guide-sample-application-golang-sql-driver.md index eafd96d45f917..98ab41d78e8a2 100644 --- a/develop/dev-guide-sample-application-golang-sql-driver.md +++ b/develop/dev-guide-sample-application-golang-sql-driver.md @@ -310,10 +310,10 @@ openDB("mysql", func(db *sql.DB) { ### ドライバーまたはORMフレームワークを使用していますか？ {#using-driver-or-orm-framework} -Golangドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となる。 +Golangドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となります。 - データベース接続を手動で確立および解放します。 -- データベースのトランザクションを手動で管理する。 +- データベースのトランザクションを手動で管理します。 - データ行をデータオブジェクトに手動でマッピングします。 複雑なSQL文を書く必要がない限り、 [GORM](/develop/dev-guide-sample-application-golang-gorm.md)などの[ORM](https://en.wikipedia.org/w/index.php?title=Object-relational_mapping)フレームワークを使用して開発することをお勧めします。ORMフレームワークは、次のような点で役立ちます。 diff --git a/develop/dev-guide-sample-application-java-jdbc.md b/develop/dev-guide-sample-application-java-jdbc.md index f12198e0fd8e1..8234069611932 100644 --- a/develop/dev-guide-sample-application-java-jdbc.md +++ b/develop/dev-guide-sample-application-java-jdbc.md @@ -319,10 +319,10 @@ public void deletePlayer(String id) throws SQLException { ### ドライバーまたはORMフレームワークを使用していますか？ {#using-driver-or-orm-framework} -Javaドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となる。 +Javaドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となります。 - データベース接続を手動で確立および解放します。 -- データベースのトランザクションを手動で管理する。 +- データベースのトランザクションを手動で管理します。 - データ行をデータオブジェクトに手動でマッピングします。 複雑なSQL文を書く必要がない限り、 [Hibernate](/develop/dev-guide-sample-application-java-hibernate.md)、 [MyBatis](/develop/dev-guide-sample-application-java-mybatis.md) 、 [Spring Data JPA](/develop/dev-guide-sample-application-java-spring-boot.md)などの[ORM](https://en.wikipedia.org/w/index.php?title=Object-relational_mapping)フレームワークを開発に利用することをお勧めします。これにより、以下のようなメリットが得られます。 diff --git a/develop/dev-guide-sample-application-python-django.md b/develop/dev-guide-sample-application-python-django.md index 55f236ab18dec..369596b3b4554 100644 --- a/develop/dev-guide-sample-application-python-django.md +++ b/develop/dev-guide-sample-application-python-django.md @@ -243,11 +243,11 @@ python manage.py migrate 2. アプリケーションにアクセスするには、ブラウザを開いて`http://localhost:8000/`にアクセスしてください。サンプルアプリケーションでは、以下の操作が可能です。 - 新しいプレイヤーを作成します。 - - プレイヤーを一括作成する。 - - 全プレイヤーを表示する。 - - プレイヤーを更新する。 - - プレイヤーを削除する。 - - 2人のプレイヤー間で商品を取引する。 + - プレイヤーを一括作成します。 + - 全プレイヤーを表示します。 + - プレイヤーを更新します。 + - プレイヤーを削除します。 + - 2人のプレイヤー間で商品を取引します。 ## サンプルコードスニペット {#sample-code-snippets} diff --git a/develop/dev-guide-sample-application-python-mysql-connector.md b/develop/dev-guide-sample-application-python-mysql-connector.md index ee97e424098bf..3dcd681d657e8 100644 --- a/develop/dev-guide-sample-application-python-mysql-connector.md +++ b/develop/dev-guide-sample-application-python-mysql-connector.md @@ -297,10 +297,10 @@ with get_connection(autocommit=True) as conn: ### ドライバーまたはORMフレームワークを使用していますか？ {#using-driver-or-orm-framework} -Pythonドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となる。 +Pythonドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となります。 - データベース接続を手動で確立および解放します。 -- データベースのトランザクションを手動で管理する。 +- データベースのトランザクションを手動で管理します。 - データ行（ `mysql-connector-python`ではタプルまたは辞書として表現されます）をデータオブジェクトに手動でマッピングします。 複雑なSQL文を書く必要がない限り、 [SQLAlchemy](/develop/dev-guide-sample-application-python-sqlalchemy.md) 、 [Peewee](/develop/dev-guide-sample-application-python-peewee.md)、Django ORMなどの[ORM](https://en.wikipedia.org/w/index.php?title=Object-relational_mapping)フレームワークを使用して開発することをお勧めします。これにより、次のようなことが可能になります。 diff --git a/develop/dev-guide-sample-application-python-mysqlclient.md b/develop/dev-guide-sample-application-python-mysqlclient.md index 9c8dd465cbff9..96739eddd30a7 100644 --- a/develop/dev-guide-sample-application-python-mysqlclient.md +++ b/develop/dev-guide-sample-application-python-mysqlclient.md @@ -300,10 +300,10 @@ with get_mysqlclient_connection(autocommit=True) as conn: ### ドライバーまたはORMフレームワークを使用していますか？ {#using-driver-or-orm-framework} -Pythonドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となる。 +Pythonドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となります。 - データベース接続を手動で確立および解放します。 -- データベースのトランザクションを手動で管理する。 +- データベースのトランザクションを手動で管理します。 - データ行（ `mysqlclient`ではタプルとして表現されています）をデータオブジェクトに手動でマッピングします。 複雑なSQL文を書く必要がない限り、 [SQLAlchemy](/develop/dev-guide-sample-application-python-sqlalchemy.md) 、 [Peewee](/develop/dev-guide-sample-application-python-peewee.md)、Django ORMなどの[ORM](https://en.wikipedia.org/w/index.php?title=Object-relational_mapping)フレームワークを使用して開発することをお勧めします。これにより、次のようなことが可能になります。 diff --git a/develop/dev-guide-sample-application-python-pymysql.md b/develop/dev-guide-sample-application-python-pymysql.md index 865f534138c11..d1ca17963afa2 100644 --- a/develop/dev-guide-sample-application-python-pymysql.md +++ b/develop/dev-guide-sample-application-python-pymysql.md @@ -302,10 +302,10 @@ with get_connection(autocommit=True) as conn: ### ドライバーまたはORMフレームワークを使用していますか？ {#using-driver-or-orm-framework} -Pythonドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となる。 +Pythonドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となります。 - データベース接続を手動で確立および解放します。 -- データベースのトランザクションを手動で管理する。 +- データベースのトランザクションを手動で管理します。 - データ行（ `pymysql`ではタプルまたは辞書として表現されます）をデータオブジェクトに手動でマッピングします。 複雑なSQL文を書く必要がない限り、 [SQLAlchemy](/develop/dev-guide-sample-application-python-sqlalchemy.md) 、 [Peewee](/develop/dev-guide-sample-application-python-peewee.md)、Django ORMなどの[ORM](https://en.wikipedia.org/w/index.php?title=Object-relational_mapping)フレームワークを開発に使用することをお勧めします。これにより、次のようなメリットが得られます。 diff --git a/develop/dev-guide-tidb-basics.md b/develop/dev-guide-tidb-basics.md index 680599cd0d7bd..fe9e7abd410e4 100644 --- a/develop/dev-guide-tidb-basics.md +++ b/develop/dev-guide-tidb-basics.md @@ -8,7 +8,7 @@ summary: トランザクション メカニズムやアプリケーションが TiDB を使い始める前に、TiDB がどのように動作するかに関するいくつかの重要なメカニズムを理解する必要があります。 - TiDB でのトランザクションの仕組みを理解するには[TiDBトランザクションの概要](/transaction-overview.md) 、アプリケーション開発に必要なトランザクションの知識については[アプリケーション開発者向けトランザクションノート](/develop/dev-guide-transaction-overview.md)をお読みください。 -- [アプリケーションがTiDBと対話する方法](#the-way-applications-interact-with-tidb)理解する。 +- [アプリケーションがTiDBと対話する方法](#the-way-applications-interact-with-tidb)を理解してください。 - 分散データベース TiDB およびTiDB Cloud を構築するためのコア コンポーネントと概念を学習するには、無料のオンライン コース[TiDBの紹介](https://eng.edu.pingcap.com/catalog/info/id:203/?utm_source=docs-dev-guide)を参照してください。 ## TiDBトランザクションメカニズム {#tidb-transaction-mechanisms} diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index bba397e973335..e0addac7a342d 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -284,7 +284,7 @@ The last packet sent successfully to the server was 3600000 milliseconds ago. Th ## データアクセスフレームワーク {#data-access-framework} -アプリケーションは、データベースへのアクセスを簡素化するために、何らかのデータアクセスフレームワークを使用することが多い。 +アプリケーションは、データベースへのアクセスを簡素化するために、何らかのデータアクセスフレームワークを使用することが多いです。 ### MyBatis {#mybatis} diff --git a/develop/serverless-driver-kysely-example.md b/develop/serverless-driver-kysely-example.md index 36ef1f276f86c..c6e7e0cab5ad2 100644 --- a/develop/serverless-driver-kysely-example.md +++ b/develop/serverless-driver-kysely-example.md @@ -297,4 +297,4 @@ mysql://[username]:[password]@[host]/[database] ## 次は？ {#what-s-next} - [Kysely](https://kysely.dev/docs/intro)と[@tidbcloud/kysely](https://github.com/tidbcloud/kysely)についてもっと詳しく知りたい方はこちらをご覧ください。 -- [TiDB CloudとVercelを統合する](https://docs.pingcap.com/tidbcloud/integrate-tidbcloud-with-vercel)方法を学ぶ +- [TiDB CloudとVercelを統合する](https://docs.pingcap.com/tidbcloud/integrate-tidbcloud-with-vercel)方法を学びます。 diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md index 3865b38a0f8f0..76d4973780eda 100644 --- a/dm/dm-error-handling.md +++ b/dm/dm-error-handling.md @@ -170,7 +170,7 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ 5. `start-task`を使用して移行タスクを開始します。 -6. `query-status`を使用して移行タスクのステータスを確認する。元のエラーの原因となったリレーログファイルの移行が完了したら、 `safe-mode`元の値に戻して移行タスクを再開できます。 +6. `query-status`を使用して移行タスクのステータスを確認します。元のエラーの原因となったリレーログファイルの移行が完了したら、 `safe-mode`元の値に戻して移行タスクを再開できます。 ### タスクをクエリするかログを確認すると、 `Access denied for user 'root'@'172.31.43.27' (using password: YES)`表示されます。 {#access-denied-for-user-root172314327-using-password-yes-shows-when-you-query-the-task-or-check-the-log} diff --git a/dm/dm-handle-alerts.md b/dm/dm-handle-alerts.md index 808a9c6098358..d6d193f173005 100644 --- a/dm/dm-handle-alerts.md +++ b/dm/dm-handle-alerts.md @@ -32,7 +32,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 アラートを処理するには、次の手順を実行できます。 - 1. 対応する DM ワーカー ノードの動作ステータスを確認する。 + 1. 対応する DM ワーカー ノードの動作ステータスを確認します。 2. ノードが接続されているかどうかを確認します。 3. ログを通じてエラーをトラブルシューティングします。 diff --git a/dm/dm-webui-guide.md b/dm/dm-webui-guide.md index 7522ebd7fc3c7..77cbce3e32e51 100644 --- a/dm/dm-webui-guide.md +++ b/dm/dm-webui-guide.md @@ -57,8 +57,8 @@ DMでは、移行タスクの各サブタスクは、フルダンプ -> フ このページで移行タスクを作成するには、右上隅の「**追加」**ボタンをクリックします。移行タスクを作成するには、以下のいずれかの方法があります。 -- WebUIの指示に従ってください。WebUIで必要な情報を段階的に入力してください。この方法は初心者や日常的な使用に適しています。 -- 設定ファイルを使用する。JSON形式の設定ファイルを貼り付けるか書き込むことで、移行タスクを作成できます。この方法は、より多くのパラメータの調整をサポートしており、上級ユーザーに適しています。 +- WebUIの指示に従います。WebUIで必要な情報を段階的に入力します。この方法は初心者や日常的な使用に適しています。 +- 設定ファイルを使用します。JSON形式の設定ファイルを貼り付けるか書き込むことで、移行タスクを作成できます。この方法は、より多くのパラメータの調整をサポートしており、上級ユーザーに適しています。 ### レプリケーションの詳細 {#replication-detail} diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index ef77f6a464117..9f88348312959 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -33,7 +33,7 @@ summary: TiCDCに基づいたプライマリ・セカンダリディザスタリ - プライマリークラスター：リージョン1で稼働するアクティブなクラスターで、3つのレプリカを持ちます。このクラスターは読み取りおよび書き込みリクエストを処理します。 - セカンダリークラスター：リージョン2で稼働し、TiCDCを介してプライマリークラスターからデータを複製するスタンバイクラスター。 -このDRアーキテクチャはシンプルで使いやすい。リージョン障害に対応できるため、プライマリクラスタの書き込みパフォーマンスが低下しないことが保証され、セカンダリクラスタはレイテンシに影響されない読み取り専用処理を処理できる。このソリューションのリカバリポイント目標（RPO）は秒単位、リカバリ時間目標（RTO）は数分、あるいはそれ以下となる。多くのデータベースベンダーが重要な本番システム向けに推奨しているソリューションである。 +このDRアーキテクチャはシンプルで使いやすいです。リージョン障害に対応できるため、プライマリクラスタの書き込みパフォーマンスが低下しないことが保証され、セカンダリクラスタはレイテンシに影響されない読み取り専用処理を処理できます。このソリューションのリカバリポイント目標（RPO）は秒単位、リカバリ時間目標（RTO）は数分、あるいはそれ以下となります。多くのデータベースベンダーが重要な本番システム向けに推奨しているソリューションです。 > **Note:** > diff --git a/functions-and-operators/encryption-and-compression-functions.md b/functions-and-operators/encryption-and-compression-functions.md index e6bd4b0165a95..1c16b0738819e 100644 --- a/functions-and-operators/encryption-and-compression-functions.md +++ b/functions-and-operators/encryption-and-compression-functions.md @@ -305,7 +305,7 @@ SELECT UNCOMPRESSED_LENGTH(0x03000000789C72747206040000FFFF018D00C7); SET GLOBAL validate_password.enable=ON; ``` -- パスワード検証関連のシステム変数を表示する。 +- パスワード検証関連のシステム変数を表示します。 ```sql SHOW VARIABLES LIKE 'validate_password.%'; diff --git a/glossary.md b/glossary.md index fcae5bea677ac..184ace2b599ce 100644 --- a/glossary.md +++ b/glossary.md @@ -62,7 +62,7 @@ TiDBでは、 `br`はバックアップまたはリストアに使用される[b TiDBデータベースの分散アーキテクチャでは： - TiDBノードは、クライアントとのやり取りのためのスケーラブルなSQLレイヤーを提供します。 -- PDノードは、TiDBに対して堅牢なメタデータレイヤーを提供する。 +- PDノードは、TiDBに対して堅牢なメタデータレイヤーを提供します。 - TiKVノードは、 Raftプロトコルを使用することで、TiDB向けに高可用性、拡張性、および耐障害性に優れたストレージを提供します。 詳細については、 [TiDBアーキテクチャ](/tidb-architecture.md)を参照してください。 diff --git a/grafana-pd-dashboard.md b/grafana-pd-dashboard.md index 57a8993630eac..ed10f346bcf0e 100644 --- a/grafana-pd-dashboard.md +++ b/grafana-pd-dashboard.md @@ -55,7 +55,7 @@ PD ダッシュボード メトリック項目の説明は次のとおりです - ストア容量: TiKVインスタンスあたりの容量サイズ - 利用可能なストア: TiKVインスタンスあたりの利用可能な容量サイズ - 使用済みストア: TiKVインスタンスごとの使用済み容量サイズ -- サイズ増幅: TiKVインスタンスあたりのサイズ増幅率。これは、(ストアリージョンサイズ)/(ストア使用容量サイズ)に等しい。 +- サイズ増幅: TiKVインスタンスあたりのサイズ増幅率。これは、(ストアリージョンサイズ)/(ストア使用容量サイズ)に等しくなります。 - 利用可能なサイズ比率: TiKVインスタンスあたりの利用可能なサイズ比率。これは、(ストアの利用可能な容量サイズ)/(ストアの容量サイズ)に等しくなります。 - ストアリーダースコア: TiKVインスタンスごとのリーダースコア - ストアリージョンスコア: TiKVインスタンスごとのリージョンスコア diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index 9b610b51392b9..d914623797534 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -105,7 +105,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - KVバックオフ期間: KV再試行リクエストの合計継続時間。TiDBはTiKVへのリクエスト送信時にエラーが発生する可能性があります。TiDBはTiKVへのすべてのリクエストに対して再試行メカニズムを備えています。この`KV Backoff Duration`項目は、リクエストの再試行の合計時間を記録します。 - TiClientリージョンエラー OPS: TiKV によって返されたリージョン関連のエラー メッセージの数 - KVバックオフOPS: TiKVによって返されたエラーメッセージの数 -- ロック解決OPS: ロックを解決するためのTiDB操作の数。TiDBの読み取りまたは書き込み要求がロックに遭遇すると、ロックを解決しようとする。 +- ロック解決OPS: ロックを解決するためのTiDB操作の数。TiDBの読み取りまたは書き込み要求がロックに遭遇すると、ロックを解決しようとします。 - その他のエラー OPS: ロックのクリアや`SafePoint`の更新など、その他の種類のエラーの数 ### KVリクエスト {#kv-request} diff --git a/identify-slow-queries.md b/identify-slow-queries.md index a2a90d9d32566..683649e53675d 100644 --- a/identify-slow-queries.md +++ b/identify-slow-queries.md @@ -465,7 +465,7 @@ limit 2; +-------------+-----------------------------+------------------------------------------------------------------+ ``` -2. 同様のスロークエリをフィンガープリントを使って照会する。 +2. 同様のスロークエリをフィンガープリントを使って照会します。 ```sql select query, query_time diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index 9787696c88db8..4d87e5f589518 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -13,7 +13,7 @@ TiDB には、システム内の障害や隠れた問題を検出するための > > このテーブルは TiDB Self-Managed にのみ適用され、 [TiDB Cloud](https://docs.pingcap.com/tidbcloud/)では使用できません。 -`information_schema.inspection_result`診断結果表`information_schema.inspection_result`の構造は以下のとおりである。 +`information_schema.inspection_result`診断結果表`information_schema.inspection_result`の構造は以下のとおりです。 ```sql USE information_schema; diff --git a/information-schema/information-schema-user-privileges.md b/information-schema/information-schema-user-privileges.md index 3718dce1c505b..a0f9b001f4442 100644 --- a/information-schema/information-schema-user-privileges.md +++ b/information-schema/information-schema-user-privileges.md @@ -26,7 +26,7 @@ DESC USER_PRIVILEGES; 4 rows in set (0.00 sec) ``` -`USER_PRIVILEGES`表の情報を確認する。 +`USER_PRIVILEGES`表の情報を確認します。 ```sql SELECT * FROM USER_PRIVILEGES; diff --git a/metrics-schema.md b/metrics-schema.md index b79b588ef0a03..94df91d727b88 100644 --- a/metrics-schema.md +++ b/metrics-schema.md @@ -232,7 +232,7 @@ DESC SELECT * FROM metrics_schema.tidb_query_duration WHERE value is not null AN +---------------------+-------------------+----------+----------+-----------------+ ``` -3. 実行計画を表示する。結果から、実行計画の`PromQL`と`step`値が30秒に変更されていることも確認できます。 +3. 実行計画を表示します。結果から、実行計画の`PromQL`と`step`値が30秒に変更されていることも確認できます。 ```sql desc select * from metrics_schema.tidb_query_duration where value is not null and time>='2020-03-25 23:40:00' and time <= '2020-03-25 23:42:00' and quantile=0.99; diff --git a/migrate-from-csv-files-to-tidb.md b/migrate-from-csv-files-to-tidb.md index c52c74202d64b..dbab2a9b91bd8 100644 --- a/migrate-from-csv-files-to-tidb.md +++ b/migrate-from-csv-files-to-tidb.md @@ -34,7 +34,7 @@ CSVファイルにはスキーマ情報が含まれていないため、CSVフ - `CREATE DATABASE`ファイルに`${db_name}-schema-create.sql` } ステートメントを追加します。 - `CREATE TABLE`ファイルに`${db_name}.${table_name}-schema.sql` } ステートメントを追加します。 -- **方法2** ：対象テーブルのスキーマを手動で作成する。 +- **方法2** ：対象テーブルのスキーマを手動で作成します。 ## ステップ3．設定ファイルを作成する {#step-3-create-the-configuration-file} diff --git a/migrate-from-parquet-files-to-tidb.md b/migrate-from-parquet-files-to-tidb.md index 071a8e5c025a2..ca3f88ffe9c24 100644 --- a/migrate-from-parquet-files-to-tidb.md +++ b/migrate-from-parquet-files-to-tidb.md @@ -56,7 +56,7 @@ ParquetファイルからTiDBにデータをインポートする前に、ター - `CREATE DATABASE`ファイルに`${db_name}-schema-create.sql` } ステートメントを追加します。 - `CREATE TABLE`ファイルに`${db_name}.${table_name}-schema.sql` } ステートメントを追加します。 -- **方法2** ：対象テーブルのスキーマを手動で作成する。 +- **方法2** ：対象テーブルのスキーマを手動で作成します。 ## ステップ3．設定ファイルを作成する {#step-3-create-the-configuration-file} @@ -114,7 +114,7 @@ pd-addr = "${ip}:${port}" # The address of the PD cluster, e.g.: 172.16.31.3:237 2. インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 - - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進捗状況を確認してください。 + - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進捗状況を確認します。 TiDB Lightningはインポートが完了すると自動的に終了します。 diff --git a/migrate-large-mysql-to-tidb.md b/migrate-large-mysql-to-tidb.md index e39d07ed7435c..9f9d1018eefe5 100644 --- a/migrate-large-mysql-to-tidb.md +++ b/migrate-large-mysql-to-tidb.md @@ -65,7 +65,7 @@ LIMIT ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットの TiKV クラスターのストレージ容量は**、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、ターゲットの TiKV クラスターは、データソースのサイズの 6 倍よりも大きなストレージ容量が必要です。この式に`x 2`が含まれている理由は次のとおりです。 - インデックスには余分な容量が必要になる場合があります。 -- RocksDBには空間増幅がある。 +- RocksDBには空間増幅があります。 ## ステップ1. MySQLからすべてのデータをエクスポートする {#step-1-export-all-data-from-mysql} diff --git a/mysql-compatibility.md b/mysql-compatibility.md index f0d53a838b2a9..11b80416c9ca3 100644 --- a/mysql-compatibility.md +++ b/mysql-compatibility.md @@ -299,7 +299,7 @@ TiDBは、以下の点を考慮して、名前付きタイムゾーンをサポ TiDBは、MySQLで非推奨となった特定の機能を実装していません。例えば、以下の機能などです。 -- 浮動小数点型の精度を指定する。MySQL 8.0 ではこの機能[非推奨](https://dev.mysql.com/doc/refman/8.0/en/floating-point-types.html)、代わりに`DECIMAL`型を使用することをお勧めします。 +- 浮動小数点型の精度を指定します。MySQL 8.0 ではこの機能[非推奨](https://dev.mysql.com/doc/refman/8.0/en/floating-point-types.html)、代わりに`DECIMAL`型を使用することをお勧めします。 - `ZEROFILL`属性。MySQL 8.0ではこの機能[非推奨](https://dev.mysql.com/doc/refman/8.0/en/numeric-type-attributes.html)、代わりにアプリケーションで数値をパディングすることをお勧めします。 ### `CREATE RESOURCE GROUP` 、 `DROP RESOURCE GROUP` 、および`ALTER RESOURCE GROUP`ステートメント {#create-resource-group-drop-resource-group-and-alter-resource-group-statements} diff --git a/online-unsafe-recovery.md b/online-unsafe-recovery.md index 763c64a962e9b..93dce2ac6a720 100644 --- a/online-unsafe-recovery.md +++ b/online-unsafe-recovery.md @@ -25,7 +25,7 @@ TiDBでは、ユーザーが定義したレプリカルールに従って、同 - ストアが永久的に破損すると、ストアを再起動できなくなるため、アプリケーション サービスのデータは読み取りおよび書き込み不能になります。 - データの損失を受け入れ、影響を受けるデータを読み取りおよび書き込み可能にすることができます。 -- ワンストップのオンラインデータ復旧操作を実行したい。 +- ワンストップのオンラインデータ復旧操作を実行したいと考えています。 ## 使用法 {#usage} diff --git a/optimistic-transaction.md b/optimistic-transaction.md index 7e5e4e2d7f0d9..20cff0fd8ce1e 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -164,9 +164,9 @@ tidb_retry_limit = 10 ### 再試行の制限 {#limits-of-retry} -デフォルトでは、TiDB はトランザクションを再試行しません。これは、更新の損失や[`REPEATABLE READ`分離](/transaction-isolation-levels.md)破損につながる可能性があるためです。 。 +デフォルトでは、TiDB はトランザクションを再試行しません。これは、更新の損失や[`REPEATABLE READ`分離](/transaction-isolation-levels.md)の破損につながる可能性があるためです。 -その理由は、再試行の手順から明らかである。 +その理由は、再試行の手順から明らかです。 1. 新しいタイムスタンプを割り当てて、それを`start_ts`とマークします。 2. 書き込み操作を含むSQL文を再試行してください。 diff --git a/partitioned-table.md b/partitioned-table.md index 4efd22b9d5bf6..21a1b52cea7e2 100644 --- a/partitioned-table.md +++ b/partitioned-table.md @@ -380,7 +380,7 @@ ALTER TABLE t ADD PARTITION (PARTITION pDef DEFAULT); ALTER TABLE t ADD PARTITION (PARTITION pDef VALUES IN (DEFAULT)); ``` -このようにすることで、どのパーティションの値セットにも一致しない新規挿入値は、自動的にデフォルトパーティションに格納される。 +このようにすることで、どのパーティションの値セットにも一致しない新規挿入値は、自動的にデフォルトパーティションに格納されます。 ```sql INSERT INTO t VALUES (7, 7); diff --git a/pd-control.md b/pd-control.md index b0b9c31a1e1bb..118d5986becd6 100644 --- a/pd-control.md +++ b/pd-control.md @@ -407,7 +407,7 @@ gRPC API リクエストの最大同時実行数（ `GetRegion` API リクエス config set service-middleware grpc-rate-limit GetRegion concurrency 10 ``` -変更された構成を表示する。 +変更された構成を表示します。 ```bash config show service-middleware diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md index f35abde48ac73..eb014049cb180 100644 --- a/performance-tuning-methods.md +++ b/performance-tuning-methods.md @@ -328,7 +328,7 @@ TiDB、TiKV、PDのCPU/メモリパネルでは、平均CPU、最大CPU、デル - クライアントサーバーの構成が低すぎるため、CPU リソースが使い果たされています。 - HAProxy は TiDB クラスター プロキシとして使用され、HAProxy CPU リソースが使い果たされています。 - HAProxy は TiDB クラスター プロキシとして使用され、高ワークロードでは HAProxyサーバーのネットワーク帯域幅が消費されます。 -- アプリケーションサーバーからデータベースへのネットワークレイテンシーが高い。例えば、パブリッククラウド環境では、アプリケーションとTiDBクラスタが同じリージョンに存在しない、またはDNSワークロードバランサとTiDBクラスタが同じリージョンに存在しない場合、ネットワークレイテンシーが高くなります。 +- アプリケーションサーバーからデータベースへのネットワークレイテンシーが高いです。例えば、パブリッククラウド環境では、アプリケーションとTiDBクラスタが同じリージョンに存在しない、またはDNSワークロードバランサとTiDBクラスタが同じリージョンに存在しない場合、ネットワークレイテンシーが高くなります。 - ボトルネックとなっているのはクライアントアプリケーションです。アプリケーションサーバーのCPUコアとNumaリソースを最大限に活用できていません。例えば、TiDBへの数千ものJDBC接続を確立するのに、たった1つのJVMしか使用されていません。 「接続数」パネルでは、総接続数と各TiDBノードの接続数を確認できます。これにより、総接続数が正常かどうか、また各TiDBノードの接続数が不均衡かどうかを確認できます。`active connections`はアクティブな接続数を示し、これは1秒あたりのデータベース時間に相当します。右側のY軸（ `disconnection/s` ）は、クラスター内の1秒あたりの切断数を示しており、アプリケーションが短い接続を使用しているかどうかを判断するのに役立ちます。 diff --git a/pessimistic-transaction.md b/pessimistic-transaction.md index 93abf5bc1ed0d..07f9ce7ec8dd5 100644 --- a/pessimistic-transaction.md +++ b/pessimistic-transaction.md @@ -142,7 +142,7 @@ TiDBは、悲観的トランザクションモードにおいて、以下の2つ ## 悲観的なトランザクションコミットプロセス {#pessimistic-transaction-commit-process} -トランザクションのコミット処理において、悲観的トランザクションと楽観的トランザクションは同じロジックを持つ。どちらのトランザクションも2フェーズコミット（2PC）方式を採用する。悲観的トランザクションの重要な特徴は、DML実行である。 +トランザクションのコミット処理において、悲観的トランザクションと楽観的トランザクションは同じロジックを持ちます。どちらのトランザクションも2フェーズコミット（2PC）方式を採用します。悲観的トランザクションの重要な特徴は、DML実行です。 ```mermaid --- @@ -239,7 +239,7 @@ sequenceDiagram - 同じデータを変更する他のトランザクションはブロックできません。アプリケーションロジックがロックまたはロック待機メカニズムに依存している場合、アプリケーションロジックの正確性に影響が出ます。 -- トランザクションのコミットが失敗する確率は低いが、トランザクションの正当性には影響しない。 +- トランザクションのコミットが失敗する確率は低いが、トランザクションの正当性には影響しません。 diff --git a/post-installation-check.md b/post-installation-check.md index 5ffa10ff372fa..a5d2bb97a429c 100644 --- a/post-installation-check.md +++ b/post-installation-check.md @@ -162,7 +162,7 @@ Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. 1 row in set (0.00 sec) ``` -- TiKV のストア状態、 `store_id` 、容量、および稼働時間を表示する。 +- TiKV のストア状態、 `store_id` 、容量、および稼働時間を表示します。 ```sql select STORE_ID,ADDRESS,STORE_STATE,STORE_STATE_NAME,CAPACITY,AVAILABLE,UPTIME from INFORMATION_SCHEMA.TIKV_STORE_STATUS; diff --git a/quick-start-with-tidb.md b/quick-start-with-tidb.md index 48d8823f6bec3..1ac635d2da373 100644 --- a/quick-start-with-tidb.md +++ b/quick-start-with-tidb.md @@ -451,7 +451,7 @@ TiDBクラスタの最小トポロジーは、以下のインスタンスで構 - TiDB [http://{pd-ip}:2379/dashboard](http://%7Bpd-ip%7D:2379/dashboard) [TiDB Dashboard](/dashboard/dashboard-intro.md)。デフォルトのユーザー名は`root`で、パスワードは空です。 -10. （オプション）クラスタ一覧とトポロジーを表示する。 +10. （オプション）クラスタ一覧とトポロジーを表示します。 - クラスター一覧を表示するには： diff --git a/read-historical-data.md b/read-historical-data.md index 784e62e5489a1..9412ac0c3cae3 100644 --- a/read-historical-data.md +++ b/read-historical-data.md @@ -59,7 +59,7 @@ TiDBでは、ガベージコレクション（GC）が定期的に実行され Query OK, 3 rows affected (0.00 sec) ``` -2. 表内のデータを表示する。 +2. 表内のデータを表示します。 ```sql mysql> select * from t; @@ -73,7 +73,7 @@ TiDBでは、ガベージコレクション（GC）が定期的に実行され 3 rows in set (0.00 sec) ``` -3. テーブルのタイムスタンプを表示する。 +3. テーブルのタイムスタンプを表示します。 ```sql mysql> select now(); diff --git a/releases/release-5.0.0.md b/releases/release-5.0.0.md index 3c8e27761ff72..24c25a572b5f8 100644 --- a/releases/release-5.0.0.md +++ b/releases/release-5.0.0.md @@ -288,7 +288,7 @@ CREATE TABLE `t` (`a` VARCHAR(255) PRIMARY KEY CLUSTERED, `b` INT); TiDBのスケジューリングプロセスは、I/O、ネットワーク、CPU、メモリなどのリソースを消費します。TiDBがスケジュールされたタスクを制御しない場合、リソースの優先実行により、QPS（1秒あたりの処理数）や遅延が発生し、パフォーマンスの変動が生じる可能性があります。 -以下の最適化後、8時間の性能試験において、TPC-C tpmCの標準偏差は2%を超えない。 +以下の最適化後、8時間の性能試験において、TPC-C tpmCの標準偏差は2%を超えません。 #### 不要なスケジューリングとパフォーマンスのジッターを軽減するために、新しいスケジューリング計算式を導入する。 {#introduce-new-scheduling-calculation-formulas-to-reduce-unnecessary-scheduling-and-performance-jitter} diff --git a/releases/release-5.1.0.md b/releases/release-5.1.0.md index b754245c93519..9dd00d7bda581 100644 --- a/releases/release-5.1.0.md +++ b/releases/release-5.1.0.md @@ -12,7 +12,7 @@ TiDB バージョン: 5.1.0 バージョン5.1における主な新機能または改善点は以下のとおりです。 - SQL文の可読性と実行効率を向上させるため、MySQL 8.0の共通テーブル式（CTE）機能をサポートします。 -- コード開発の柔軟性を向上させるため、列の型をオンラインで変更できる機能をサポートする。 +- コード開発の柔軟性を向上させるため、列の型をオンラインで変更できる機能をサポートします。 - クエリの安定性を向上させるための新しい統計タイプを導入しました。これは実験的機能としてデフォルトで有効になっています。 - MySQL 8.0の動的権限機能をサポートし、特定の操作に対するよりきめ細かな制御を実現します。 - 読み取りレイテンシーを削減し、クエリパフォーマンスを向上させるために、 ステイル読み取り機能を使用してローカルレプリカから直接データを読み取ることをサポートします（Experimental）。 @@ -211,7 +211,7 @@ TiDBは、実行ステータスと失敗ステータスを含む、TiDBクラス - `Union All` 、 `TopN` 、および`Limit`関数をサポートします。 - MPPモードでの左外部結合およびセミアンチ結合を含むデカルト積をサポートします。 - - ロック操作を最適化して、実行中の DDL ステートメントと読み取り操作が互いにブロックされないようにする。 + - ロック操作を最適化して、実行中の DDL ステートメントと読み取り操作が互いにブロックされないようにします。 - TiFlashによる期限切れデータのクリーンアップを最適化 - TiFlashストレージレベルで`timestamp`列に対するクエリフィルタのさらなるフィルタリングをサポートします。 - クラスタ内に多数のテーブルが存在する場合のTiFlashの起動速度と拡張性を向上させる diff --git a/releases/release-5.2.0.md b/releases/release-5.2.0.md index 73be13f244482..755dda9941d20 100644 --- a/releases/release-5.2.0.md +++ b/releases/release-5.2.0.md @@ -16,11 +16,11 @@ TiDB バージョン: 5.2.0 バージョン5.2の主な新機能と改善点は以下のとおりです。 - 式インデックスで複数の関数を使用することをサポートし、クエリのパフォーマンスを大幅に向上させます。 -- 最適な実行計画の選択を支援するために、オプティマイザのカーディナリティ推定の精度を向上させる。 +- 最適な実行計画の選択を支援するために、オプティマイザのカーディナリティ推定の精度を向上させます。 - トランザクションのロックイベントを監視し、デッドロックの問題をトラブルシューティングするためのロックビュー機能の一般提供（GA）を発表します。 - TiFlashの読み書きの安定性を向上させるため、 TiFlash I/Oトラフィック制限機能を追加しました。 - TiKVは、従来のRocksDB書き込み停止メカニズムに代わる新しいフロー制御メカニズムを導入し、TiKVフロー制御の安定性を向上させています。 -- データ移行（DM）の運用と保守を簡素化し、管理コストを削減する。 +- データ移行（DM）の運用と保守を簡素化し、管理コストを削減します。 - TiCDCは、TiCDCタスクの管理にHTTPプロトコルOpenAPIをサポートしています。これにより、Kubernetes環境とセルフホスト環境の両方において、よりユーザーフレンドリーな操作方法を提供します。（Experimental機能） ## 互換性の変更 {#compatibility-changes} diff --git a/releases/release-5.4.0.md b/releases/release-5.4.0.md index 66ea7233710eb..787a97b180c18 100644 --- a/releases/release-5.4.0.md +++ b/releases/release-5.4.0.md @@ -105,7 +105,7 @@ TiDB バージョン: 5.4.0 ### パフォーマンス {#performance} -- **カラム型ストレージエンジンTiFlashおよび演算エンジンMPPの安定性とパフォーマンスの向上を継続する。** +- **カラム型ストレージエンジンTiFlashおよび演算エンジンMPPの安定性とパフォーマンスの向上を継続します。** - MPPエンジンへの関数委譲をさらに強化する： diff --git a/releases/release-6.2.0.md b/releases/release-6.2.0.md index fdf3e1bc39a58..2487e7ebd1495 100644 --- a/releases/release-6.2.0.md +++ b/releases/release-6.2.0.md @@ -186,9 +186,9 @@ TiDBバージョン: 6.2.0-DMR PITRは、ログとスナップショットのバックアップおよび復元に基づいて実装されています。これにより、クラスタの履歴上の任意の時点のスナップショットを新しいクラスタに復元できます。この機能は、以下のニーズを満たします。 - - ディザスタリカバリにおけるRPO（目標復旧時点）を20分未満に短縮する。 + - ディザスタリカバリにおけるRPO（目標復旧時点）を20分未満に短縮します。 - アプリケーションからの書き込みエラーが発生した場合は、例えば、エラー発生前の状態にデータをロールバックするなどの方法で対処します。 - - 法令の要件を満たすため、履歴データの監査を実施する。 + - 法令の要件を満たすため、履歴データの監査を実施します。 この機能には使用上の制限があります。詳細はユーザーマニュアルを参照してください。 diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 0b1887c86ce93..e00bd60be081a 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -227,7 +227,7 @@ TiDBバージョン: 6.4.0-DMR TiDB クラスターが EKS 上にデプロイされ、AWS EBS ボリュームを使用している場合、TiDB クラスター データのバックアップ時に以下の要件を満たす必要がある場合は、 TiDB Operatorを使用してボリューム スナップショットとメタデータによるデータを AWS S3 にバックアップできます。 - - バックアップの影響を最小限に抑える。例えば、QPSとトランザクションレイテンシーへの影響を5%未満に抑え、クラスタのCPUとメモリを消費しないようにする。 + - バックアップの影響を最小限に抑えます。例えば、QPSとトランザクションレイテンシーへの影響を5%未満に抑え、クラスタのCPUとメモリを消費しないようにします。 - 短時間でデータのバックアップと復元が可能です。例えば、1時間以内にバックアップを完了し、2時間以内にデータを復元できます。 詳細については、 [ユーザー向けドキュメント](https://docs.pingcap.com/tidb-in-kubernetes/v1.4/backup-to-aws-s3-by-snapshot)を参照してください。 diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index b2782aa8cd950..409885b786e83 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -58,7 +58,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - `INSERT` 、 `REPLACE` 、 `UPDATE` 、 `DELETE` を含む非トランザクションDMLステートメントを完全にサポート [#33485](https://github.com/pingcap/tidb/issues/33485) @[ekexium](https://github.com/ekexium) - 大規模データ処理のシナリオでは、大規模なトランザクションを含む単一のSQL文が、クラスタの安定性とパフォーマンスに悪影響を及ぼす可能性があります。非トランザクションDML文とは、内部実行のために複数のSQL文に分割されたDML文です。分割された文はトランザクションの原子性と独立性を損なう一方で、クラスタの安定性を大幅に向上させます。TiDBはバージョン6.1.0以降、非トランザクション`DELETE`文をサポートしており、バージョン6.5.0以降、非トランザクション`INSERT`文`REPLACE`サポートしてい`UPDATE` 。 + 大規模データ処理のシナリオでは、大規模なトランザクションを含む単一のSQL文が、クラスタの安定性とパフォーマンスに悪影響を及ぼす可能性があります。非トランザクションDML文とは、内部実行のために複数のSQL文に分割されたDML文です。分割された文はトランザクションの原子性と独立性を損なう一方で、クラスタの安定性を大幅に向上させます。TiDBはバージョン6.1.0以降、非トランザクション`DELETE`文をサポートしており、バージョン6.5.0以降、非トランザクション`INSERT`文、`REPLACE`文、および`UPDATE`文をサポートしています。 詳細については、 [非トランザクションDMLステートメント](/non-transactional-dml.md)および[`BATCH`構文](/sql-statements/sql-statement-batch.md)を参照してください。 diff --git a/replicate-between-primary-and-secondary-clusters.md b/replicate-between-primary-and-secondary-clusters.md index 558504e897a4a..ed470bfa79193 100644 --- a/replicate-between-primary-and-secondary-clusters.md +++ b/replicate-between-primary-and-secondary-clusters.md @@ -8,7 +8,7 @@ summary: プライマリクラスタからセカンダリクラスタへデー このドキュメントでは、TiDBプライマリ（アップストリーム）クラスタとTiDBまたはMySQLセカンダリ（ダウンストリーム）クラスタを構成し、プライマリクラスタからセカンダリクラスタへ増分データをレプリケートする方法について説明します。プロセスには以下の手順が含まれます。 1. TiDBプライマリクラスタと、TiDBまたはMySQLセカンダリクラスタを設定します。 -2. プライマリクラスタからセカンダリクラスタへ、増分データを複製する。 +2. プライマリクラスタからセカンダリクラスタへ、増分データを複製します。 3. プライマリクラスタがダウンした場合でも、リドゥログを使用してデータの確実な復旧を実現します。 実行中の TiDB クラスタからセカンダリ クラスタに増分データを複製するには、Backup & Restore [BR](/br/backup-and-restore-overview.md)と[TiCDC](/ticdc/ticdc-overview.md)を使用できます。 @@ -106,7 +106,7 @@ summary: プライマリクラスタからセカンダリクラスタへデー > - 本番のクラスタでは、GCを無効にした状態でバックアップを実行すると、クラスタのパフォーマンスに影響を与える可能性があります。パフォーマンスの低下を避けるため、データのバックアップはピーク時以外の時間帯に行い、RATE_LIMITを適切な値に設定することをお勧めします。 > - アップストリームとダウンストリームのクラスタのバージョンが異なる場合は、 [BR互換性](/br/backup-and-restore-overview.md#some-tips)を確認してください。このドキュメントでは、アップストリームとダウンストリームのクラスタのバージョンが同じであることを前提としています。 -1. GCを無効にする。 +1. GCを無効にします。 増分移行中に新しく書き込まれたデータが削除されないようにするには、バックアップ前にアップストリームクラスタのガベージコレクション（GC）を無効にする必要があります。こうすることで、履歴データが削除されるのを防ぐことができます。 @@ -243,7 +243,7 @@ summary: プライマリクラスタからセカンダリクラスタへデー チェンジフィード構成の詳細については、 [TiCDC Changefeedフィード構成](/ticdc/ticdc-changefeed-config.md)を参照してください。 -3. GCを有効にする。 +3. GCを有効にします。 TiCDC を使用した増分移行では、GC はレプリケートされた履歴データのみを削除します。したがって、変更フィードを作成した後、次のコマンドを実行して GC を有効にする必要があります。詳細については、 [TiCDCのガベージコレクション（GC）セーフポイントの完全な動作とはどのようなものですか？](/ticdc/ticdc-faq.md#what-is-the-complete-behavior-of-ticdc-garbage-collection-gc-safepoint)を参照してください。 diff --git a/scale-tidb-using-tiup.md b/scale-tidb-using-tiup.md index eae103493a0b0..4eebe0acaadc8 100644 --- a/scale-tidb-using-tiup.md +++ b/scale-tidb-using-tiup.md @@ -181,7 +181,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する > > 上記のコマンドは、コマンドを実行するユーザーと新しいマシンの間で相互信頼が構築されていることを前提としています。相互信頼を構築できない場合は、 `-p`オプションを使用して新しいマシンのパスワードを入力するか、 `-i`オプションを使用して秘密鍵ファイルを指定します。 -3. クラスターのステータスを表示する。 +3. クラスターのステータスを表示します。 ```shell tiup cluster display @@ -227,7 +227,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する > > 上記のコマンドは、コマンドを実行するユーザーと新しいマシンの間で相互信頼が構築されていることを前提としています。相互信頼を構築できない場合は、 `-p`オプションを使用して新しいマシンのパスワードを入力するか、 `-i`オプションを使用して秘密鍵ファイルを指定します。 -3. クラスターのステータスを表示する。 +3. クラスターのステータスを表示します。 ```shell tiup cluster display @@ -255,7 +255,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する > - TiKVおよびTiFlashコンポーネントは非同期的にオフラインになり、停止処理に時間がかかるため、 TiUPはこれらのコンポーネントを別の方法でオフラインにします。詳細については、 [コンポーネントのオフラインプロセスの特別な処理](/tiup/tiup-component-cluster-scale-in.md#particular-handling-of-components-offline-process)を参照してください。 > - TiKVのPDクライアントは、PDノードのリストをキャッシュします。現在のバージョンのTiKVには、PDノードを自動的かつ定期的に更新するメカニズムが搭載されており、TiKVによってキャッシュされたPDノードのリストが期限切れになる問題を軽減するのに役立ちます。ただし、PDをスケールアウトした後は、スケールアウト前に存在していたすべてのPDノードを一度に削除することは避けてください。必要に応じて、既存のPDノードをすべてオフラインにする前に、PDリーダーを新しく追加されたPDノードに切り替えてください。 -1. ノード ID 情報を表示する。 +1. ノード ID 情報を表示します。 ```shell tiup cluster display @@ -374,7 +374,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する tiup cluster scale-in --node 10.0.1.4:9000 ``` -3. 削除されたTiFlashノードのステータスを表示する。 +3. 削除されたTiFlashノードのステータスを表示します。 ```shell tiup cluster display @@ -454,7 +454,7 @@ tiup cluster display tiup cluster scale-in --node 10.0.1.4:8300 ``` -2. クラスターのステータスを表示する。 +2. クラスターのステータスを表示します。 ```shell tiup cluster display diff --git a/schema-cache.md b/schema-cache.md index a612ceea1fa91..253665aa14880 100644 --- a/schema-cache.md +++ b/schema-cache.md @@ -47,7 +47,7 @@ summary: TiDBは、スキーマ情報に対してLRU（Least Recently Used：最 - テーブルへのアクセスが不規則な場合（例えば、あるテーブル群が時刻1にアクセスされ、別のテーブル群が時刻2にアクセスされる場合など）、 `tidb_schema_cache_size`の値が小さいと、スキーマ情報が頻繁に削除およびキャッシュされ、パフォーマンスの変動につながる可能性があります。この機能は、頻繁にアクセスされるデータベースやテーブルが比較的固定されているシナリオに適しています。 -- 統計情報は適時に収集されない可能性がある。 +- 統計情報は適時に収集されない可能性があります。 - 一部のメタデータ情報へのアクセス速度が低下する可能性があります。 diff --git a/sql-statements/sql-statement-alter-user.md b/sql-statements/sql-statement-alter-user.md index df865a89b8215..8eafa3d2c7de1 100644 --- a/sql-statements/sql-statement-alter-user.md +++ b/sql-statements/sql-statement-alter-user.md @@ -179,7 +179,7 @@ ALTER USER 'newuser' RESOURCE GROUP rg1; Query OK, 0 rows affected (0.02 sec) ``` -現在のユーザーにバインドされているリソース グループを表示する。 +現在のユーザーにバインドされているリソース グループを表示します。 ```sql SELECT USER, JSON_EXTRACT(User_attributes, "$.resource_group") FROM mysql.user WHERE user = "newuser"; diff --git a/sql-statements/sql-statement-create-index.md b/sql-statements/sql-statement-create-index.md index 5245450488733..1ce14cd0e360f 100644 --- a/sql-statements/sql-statement-create-index.md +++ b/sql-statements/sql-statement-create-index.md @@ -300,7 +300,7 @@ mysql> INSERT INTO customers VALUES (1, 'pingcap', '{"zipcode": [2,3]}'); ERROR 1062 (23000): Duplicate entry '2' for key 'customers.zips' ``` -同じレコード内に重複する値が存在することは許容されるが、異なるレコード内に重複する値が存在する場合はエラーが報告される。 +同じレコード内に重複する値が存在することは許容されるが、異なるレコード内に重複する値が存在する場合はエラーが報告されます。 ```sql -- Insert succeeded diff --git a/sql-statements/sql-statement-explain-analyze.md b/sql-statements/sql-statement-explain-analyze.md index f207532370ae2..b87775d6356b7 100644 --- a/sql-statements/sql-statement-explain-analyze.md +++ b/sql-statements/sql-statement-explain-analyze.md @@ -169,7 +169,7 @@ inner:{total:4.297515932s, concurrency:5, task:17, construct:97.96291ms, fetch:4 `IndexHashJoin`演算子の実行プロセスは`IndexJoin`演算子と同様です。`IndexHashJoin`演算子も1つの外部ワーカーとN個の内部ワーカーで並列実行されますが、出力順序は外部テーブルと一致するとは限りません。詳細な実行プロセスは以下のとおりです。 1. 外側のワーカーは N 個の外側の行を読み取り、タスクを構築して、それを内側のワーカー チャネルに送信します。 -2. 内部ワーカーは内部ワーカーチャネルからタスクを受け取り、各タスクに対して以下の3つの操作を順番に実行します。a. 外部行からハッシュテーブルを構築する。b. 外部行からキー範囲を構築し、内部行を取得する。c. ハッシュテーブルをプローブし、結合結果を結果チャネルに送信する。注：ステップaとステップbは同時に実行されます。 +2. 内部ワーカーは内部ワーカーチャネルからタスクを受け取り、各タスクに対して以下の3つの操作を順番に実行します。a. 外部行からハッシュテーブルを構築します。b. 外部行からキー範囲を構築し、内部行を取得します。c. ハッシュテーブルをプローブし、結合結果を結果チャネルに送信します。注：ステップaとステップbは同時に実行されます。 3. `IndexHashJoin`のメイン スレッドは、結果チャネルから結合結果を受信します。 `IndexHashJoin`演算子には次の実行情報が含まれています。 diff --git a/sql-statements/sql-statement-select.md b/sql-statements/sql-statement-select.md index 1c0348f7481a8..1bf98257c8358 100644 --- a/sql-statements/sql-statement-select.md +++ b/sql-statements/sql-statement-select.md @@ -102,7 +102,7 @@ TableSample ::= | `Window window_definition` | これはウィンドウ関数の構文であり、通常は分析計算を行うために使用されます。詳細については、 [ウィンドウ機能](/functions-and-operators/window-functions.md)を参照してください。 | | `FOR UPDATE` | `SELECT FOR UPDATE`句は、結果セット内のすべてのデータをロックして、他のトランザクションからの同時更新を検出します。クエリ条件に一致するが結果セットに存在しないデータは、読み取りロックされません。たとえば、現在のトランザクションが開始された後に他のトランザクションによって書き込まれた行データなどです。TiDB が[楽観的トランザクションモード](/optimistic-transaction.md)モードを使用する場合、ステートメント実行フェーズではトランザクションの競合は検出されません。したがって、現在のトランザクションは、PostgreSQL などの他のデータベースのように、他のトランザクションが`UPDATE` 、 `DELETE` 、または`SELECT FOR UPDATE`を実行するのをブロックしません。コミットフェーズでは、 `SELECT FOR UPDATE`によって読み取られた行は 2 つのフェーズでコミットされるため、競合検出に参加することもできます。書き込み競合が発生した場合、 `SELECT FOR UPDATE`句を含むすべてのトランザクションのコミットは失敗します。競合が検出されなかった場合、コミットは成功します。また、ロックされた行に対して新しいバージョンが生成されるため、コミットされていない他のトランザクションが後でコミットされるときに書き込み競合を検出できます。 TiDB が[悲観的なトランザクションモード](/pessimistic-transaction.md)を使用する場合、動作は基本的に他のデータベースと同じです。詳細については、 [MySQL InnoDBとの違い](/pessimistic-transaction.md#differences-from-mysql-innodb)を参照してください。 TiDB は`NOWAIT`の`FOR UPDATE`修飾子をサポートしています。詳細については[TiDB悲観的トランザクションモード](/pessimistic-transaction.md#behaviors)を参照してください。 | | `LOCK IN SHARE MODE` | 互換性を保証するため、TiDBはこれら3つの修飾子を解析しますが、無視します。 | -| `TABLESAMPLE` | テーブルから行のサンプルを取得する。 | +| `TABLESAMPLE` | テーブルから行のサンプルを取得します。 | > **Note:** > diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index f21935b6d76ec..16f491b638540 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -253,7 +253,7 @@ SHOW VARIABLES LIKE 'tidb\_auto\_analyze%'; - 表の統計はすでにデータを適切に表しています。 - テーブルが非常に大きいため、統計の収集には時間がかかります。 -- 特定の時間枠内でのみ統計を維持したい。 +- 特定の時間枠内でのみ統計を維持したい場合があります。 テーブルの統計をロックするには、 [`LOCK STATS table_name`](/sql-statements/sql-statement-lock-stats.md)ステートメントを使用できます。 diff --git a/statement-summary-tables.md b/statement-summary-tables.md index b2be92ed44f78..c05b5cbbc4113 100644 --- a/statement-summary-tables.md +++ b/statement-summary-tables.md @@ -299,7 +299,7 @@ SELECT sum_latency, avg_latency, exec_count, query_sample_text ORDER BY sum_latency DESC LIMIT 3; ``` -結果によると、以下の3つのカテゴリのSQL文が合計で最も長い時間を消費しており、これらは高い優先順位で最適化する必要がある。 +結果によると、以下の3つのカテゴリのSQL文が合計で最も長い時間を消費しており、これらは高い優先順位で最適化する必要があります。 ```sql +-------------+-------------+------------+-----------------------------------------------------------------------+ diff --git a/statistics.md b/statistics.md index f502cb8d9499f..269e6cdca1733 100644 --- a/statistics.md +++ b/statistics.md @@ -706,7 +706,7 @@ mysql> SHOW WARNINGS; | ----------------------------------- | ------------ | ------------------------------------------ | -------------------------------------------- | ---------------------- | ------------------------------------------------ | ------------------------------------------------ | ----------------------------------------- | | パーティションテーブルがロックされています | ロックが無効です | TiDBが古いテーブルを削除するため、ロック情報も削除され、ロックは無効になります。 | / | / | / | / | / | | パーティションテーブルと、テーブル全体がロックされています | ロックが無効です | TiDBが古いテーブルを削除するため、ロック情報も削除され、ロックは無効になります。 | 古いパーティションロック情報は無効であり、新しいパーティションは自動的にロックされます。 | 新しいパーティションは自動的にロックされます | 削除されたパーティションのロック情報はクリアされ、テーブル全体のロックは引き続き有効になります。 | 削除されたパーティションのロック情報がクリアされ、新しいパーティションが自動的にロックされます。 | ロック情報は交換テーブルに転送され、新しいパーティションは自動的にロックされます。 | -| パーティションテーブルで、一部のパーティションのみがロックされている。 | ロックが無効です | TiDBが古いテーブルを削除するため、ロック情報も削除され、ロックは無効になります。 | TiDBが古いテーブルを削除するため、ロック情報も削除され、ロックは無効になります。 | / | 削除されたパーティションロック情報はクリアされます | 削除されたパーティションロック情報はクリアされます | ロック情報は交換テーブルに転送されます | +| パーティションテーブルで、一部のパーティションのみがロックされています。 | ロックが無効です | TiDBが古いテーブルを削除するため、ロック情報も削除され、ロックは無効になります。 | TiDBが古いテーブルを削除するため、ロック情報も削除され、ロックは無効になります。 | / | 削除されたパーティションロック情報はクリアされます | 削除されたパーティションロック情報はクリアされます | ロック情報は交換テーブルに転送されます | ## `ANALYZE`タスクと並行処理を管理する {#manage-analyze-tasks-and-concurrency} diff --git a/system-variables.md b/system-variables.md index b08b1214f7020..0fdcb59830f0e 100644 --- a/system-variables.md +++ b/system-variables.md @@ -40,7 +40,7 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; > - バイト単位の場合、安全な値は通常、システムメモリの量よりも小さくなります。 > - 時間を表す単位は秒またはミリ秒の場合があることに注意してください。 > -> 同じ単位を使用する変数は、同じリソースを巡って競合する可能性がある。 +> 同じ単位を使用する変数は、同じリソースを巡って競合する可能性があります。 バージョン 7.4.0 以降では、 [`SET_VAR`](/optimizer-hints.md#set_varvar_namevar_value)を使用してステートメントの実行中に一部の`SESSION`変数の値を一時的に変更できます。ステートメントの実行後、現在のセッションのシステム変数の値は自動的に元の値に戻ります。このヒントは、オプティマイザとエグゼキュータに関連する一部のシステム変数を変更するために使用できます。このドキュメントの変数には`Applies to hint SET_VAR`設定があり、 `Yes`または`No`に設定できます。 @@ -432,7 +432,7 @@ mysql> SELECT * FROM t1; - デフォルト値: `300` - 範囲: `[0, 2147483647]` - 単位：ミリ秒 -- 実行時間がしきい値を超えたDDL操作をログに記録する。 +- 実行時間がしきい値を超えたDDL操作をログに記録します。 ### default_authentication_plugin @@ -2969,7 +2969,7 @@ Query OK, 0 rows affected (0.09 sec) - デフォルト値: `OFF` - この変数は、TSOFollowerプロキシ機能を有効にするかどうかを制御します。値が`OFF`の場合、TiDBはPDリーダーからのみTSOを取得します。値が`ON`の場合、TiDBはTSO要求をすべてのPDサーバーに均等に分散し、PDフォロワーもTSO要求を処理できるため、PDリーダーのCPU負荷が軽減されます。 - TSOFollowerプロキシを有効にするシナリオ： - - TSOリクエストの負荷が高いため、PDリーダーのCPUがボトルネックとなり、TSO RPCリクエストのレイテンシーが増大する。 + - TSOリクエストの負荷が高いため、PDリーダーのCPUがボトルネックとなり、TSO RPCリクエストのレイテンシーが増大します。 - TiDBクラスタには多数のTiDBインスタンスが存在するため、 [`tidb_tso_client_batch_max_wait_time`](#tidb_tso_client_batch_max_wait_time-new-in-v530)の値を増やしても、TSO RPCリクエストの高レイテンシーの問題は解消されません。 > **Note:** @@ -5012,7 +5012,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL;
tidb_opt_range_max_size使用例 -この変数のデフォルト値を表示する。結果から、オプティマイザがスキャン範囲の構築に最大64MiBのメモリを使用していることがわかります。 +この変数のデフォルト値を表示します。結果から、オプティマイザがスキャン範囲の構築に最大64MiBのメモリを使用していることがわかります。 ```sql SELECT @@tidb_opt_range_max_size; @@ -6514,7 +6514,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - TiDBで使用されるPDクライアントは、PDからTSOリクエストを取得する際、同時に受信したTSOリクエストを可能な限り多く収集します。そして、収集したリクエストをバッチ処理で1つのRPCリクエストに統合し、PDに送信します。これにより、PDへの負荷を軽減できます。 - この変数を`0`より大きい値に設定した後、TiDBは各バッチマージの終了前に、この値の最大期間待機します。これは、より多くのTSOリクエストを収集し、バッチ操作の効果を向上させるためです。 - この変数の値を増加させるシナリオ： - - TSOリクエストの負荷が高いため、PDリーダーのCPUがボトルネックとなり、TSO RPCリクエストのレイテンシーが増大する。 + - TSOリクエストの負荷が高いため、PDリーダーのCPUがボトルネックとなり、TSO RPCリクエストのレイテンシーが増大します。 - クラスター内にはTiDBインスタンスは多くありませんが、すべてのTiDBインスタンスは高い同時実行性で動作しています。 - この変数はできるだけ小さい値に設定することをお勧めします。 @@ -6545,7 +6545,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 以下の条件が満たされた場合、パフォーマンスの向上を目的として、この変数を`PARALLEL`または`PARALLEL-FAST`に切り替えることを検討してください。 - - TSOの待機時間は、SQLクエリの総実行時間の大部分を占める。 + - TSOの待機時間は、SQLクエリの総実行時間の大部分を占めています。 - PDにおけるTSOの割り当ては、まだボトルネックに達していません。 - PDノードとTiDBノードは十分なCPUリソースを備えている。 - TiDBとPD間のネットワークレイテンシーは、PDがTSOを割り当てるのにかかる時間よりもかなり長い（つまり、TSO RPCの実行時間の大部分はネットワークレイテンシーによるものである）。 diff --git a/ticdc/deploy-ticdc.md b/ticdc/deploy-ticdc.md index cba977e3437af..6ffb58b8838bc 100644 --- a/ticdc/deploy-ticdc.md +++ b/ticdc/deploy-ticdc.md @@ -102,7 +102,7 @@ TiCDCクラスタをアップグレードする際には、以下の点に注意 - TiCDCはバージョン6.3.0以降です。 - TiUPはバージョン1.11.3以降です。 - - クラスター内では、少なくとも2つのTiCDCインスタンスが稼働している。 + - クラスター内では、少なくとも2つのTiCDCインスタンスが稼働しています。 ## TiUPを使用してTiCDCクラスタ構成を変更します。 {#modify-ticdc-cluster-configurations-using-tiup} diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 278f8ee50fec3..4cb7a03dedef3 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -24,7 +24,7 @@ TiCDCには、以下の主要な機能があります。 - TiDBクラスタ間の双方向レプリケーションにより、TiCDCを使用してマルチアクティブTiDBソリューションを構築できます。 - TiDBクラスタからMySQLデータベースまたはその他のMySQL互換データベースへ、低レイテンシーで増分データを複製します。 - TiDB クラスターから Kafka クラスターへの増分データのレプリケーション。推奨されるデータ形式には、 [Canal-JSON](/ticdc/ticdc-canal-json.md) 、[Avro](/ticdc/ticdc-avro-protocol.md)、[Debezium](/ticdc/ticdc-debezium.md)が含まれます。 -- TiDBクラスタからAmazon S3、GCS、Azure Blob Storage、NFSなどのストレージサービスへ増分データを複製する。 +- TiDBクラスタからAmazon S3、GCS、Azure Blob Storage、NFSなどのストレージサービスへ増分データを複製します。 - データベース、テーブル、DML、DDLをフィルタリングする機能を備えたテーブルの複製。 - 単一障害点のない高可用性を実現し、TiCDCノードの動的な追加と削除をサポートします。 - [OpenAPI](/ticdc/ticdc-open-api-v2.md)を介したクラスタ管理。タスクの状態照会、タスク構成の動的な変更、タスクの作成または削除などが含まれます。 @@ -62,7 +62,7 @@ TiCDCは、PDのetcdを介して高可用性を実現するTiDB用の増分デ 2. TiCDCはデータの変更を分類して統合します。 3. TiCDCは、複数のレプリケーションタスク（チェンジフィード）を通じて、データの変更を複数の下流システムに複製します。 -TiCDCのアーキテクチャを次の図に示す。 +TiCDCのアーキテクチャを次の図に示します。 ![TiCDC architecture](/media/ticdc/cdc-architecture.png) diff --git a/ticdc/ticdc-sink-to-mysql.md b/ticdc/ticdc-sink-to-mysql.md index dce47fbfe61e6..431dcea996d57 100644 --- a/ticdc/ticdc-sink-to-mysql.md +++ b/ticdc/ticdc-sink-to-mysql.md @@ -135,8 +135,8 @@ TiCDC の最終整合性レプリケーション機能は、リドゥログを TiCDCのレプリケーション遅延は、以下のシナリオで増加します。 -- TPSは短時間で大幅に増加する。 -- 上流工程では、大規模または長時間のトランザクションが発生する。 +- TPSは短時間で大幅に増加します。 +- 上流工程では、大規模または長時間のトランザクションが発生します。 - アップストリームのTiKVまたはTiCDCクラスタが再ロードまたはアップグレードされます。 - `add index`のような時間のかかる DDL ステートメントは、上流で実行されます。 - PDは積極的なスケジューリング戦略で構成されており、その結果、リージョンリーダーの頻繁な異動、あるいはリージョンの統合や分割が頻繁に発生します。 diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index 71ec1dd022d8c..c28626857032d 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -180,7 +180,7 @@ TiDBノードを複数デプロイすることで、水平方向に拡張し、 - **リージョンベースのデータストレージ** - データは[リージョン](https://docs.pingcap.com/tidb/dev/glossary#regionpeerraft-group)ごとに分割され、それぞれが特定のキー範囲（左端が閉じ、右端が開いた区間： `StartKey`から`EndKey` ）をカバーします。 - - 効率的なデータ配信を確保するため、各TiKVノード内には複数のリージョンが共存している。 + - 効率的なデータ配信を確保するため、各TiKVノード内には複数のリージョンが共存しています。 - **トランザクションサポート** diff --git a/tidb-cloud/backup-and-restore-concepts.md b/tidb-cloud/backup-and-restore-concepts.md index 64e39654a855c..8ba6ccc77866d 100644 --- a/tidb-cloud/backup-and-restore-concepts.md +++ b/tidb-cloud/backup-and-restore-concepts.md @@ -44,9 +44,9 @@ TiDB Cloud Dedicatedのデュアルリージョンバックアップ機能は、 ポイントインタイム復元は、任意の時点のデータを新しい TiDB クラスターまたはインスタンスに復元できる機能です。この機能は、以下の目的で使用できます。 -- ディザスタリカバリにおけるRPO（目標復旧時点）を削減する。 +- ディザスタリカバリにおけるRPO（目標復旧時点）を削減します。 - データ書き込みエラーが発生した場合は、エラー発生前の時点にデータを復元することで解決します。 -- 企業の過去のデータを監査する。 +- 企業の過去のデータを監査します。 ポイントインタイム復元を実行する場合は、以下の点に注意してください。 diff --git a/tidb-cloud/backup-and-restore.md b/tidb-cloud/backup-and-restore.md index d48b09bf4e6d9..ba57d05addcf3 100644 --- a/tidb-cloud/backup-and-restore.md +++ b/tidb-cloud/backup-and-restore.md @@ -44,9 +44,9 @@ TiDB Cloud Dedicated は、 [スナップショットバックアップ](https:/ この機能は、任意の時点のデータを新しいクラスターに復元することをサポートします。この機能は、以下の目的で使用できます。 -- ディザスタリカバリにおけるRPO（目標復旧時点）を削減する。 +- ディザスタリカバリにおけるRPO（目標復旧時点）を削減します。 - データ書き込みエラーが発生した場合は、エラー発生前の時点にデータを復元することで解決します。 -- 企業の過去のデータを監査する。 +- 企業の過去のデータを監査します。 この機能をオンにすることを強くお勧めします。コストはスナップショットバックアップと同じです。詳細については、 [データバックアップ費用](https://www.pingcap.com/tidb-dedicated-pricing-details#backup-storage-cost)を参照してください。 diff --git a/tidb-cloud/changefeed-sink-to-apache-kafka.md b/tidb-cloud/changefeed-sink-to-apache-kafka.md index e5a5bbf582938..071eb6eabab54 100644 --- a/tidb-cloud/changefeed-sink-to-apache-kafka.md +++ b/tidb-cloud/changefeed-sink-to-apache-kafka.md @@ -80,7 +80,7 @@ Apache KafkaサービスがインターネットにアクセスできないAWS V 3. Apache KafkaのURLにホスト名が含まれている場合、 TiDB CloudがApache KafkaブローカーのDNSホスト名を解決できるようにする必要があります。 1. [VPCピアリング接続のDNS解決を有効にする](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-dns.html)の手順に従います。 - 2. **Accepter DNS resolution**オプションを有効にする。 + 2. **Accepter DNS resolution**オプションを有効にします。 Apache Kafka サービスがインターネットにアクセスできない Google Cloud VPC 内にある場合は、以下の手順を実行してください。 diff --git a/tidb-cloud/changefeed-sink-to-apache-pulsar.md b/tidb-cloud/changefeed-sink-to-apache-pulsar.md index 6dcf0337af8e5..8c8dbbd0d0d4b 100644 --- a/tidb-cloud/changefeed-sink-to-apache-pulsar.md +++ b/tidb-cloud/changefeed-sink-to-apache-pulsar.md @@ -50,7 +50,7 @@ Apache PulsarサービスがインターネットにアクセスできないAWS 3. Apache PulsarのURLにホスト名が含まれている場合、 TiDB CloudがApache PulsarブローカーのDNSホスト名を解決できるようにする必要があります。 1. [VPCピアリング接続のDNS解決を有効にする](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-dns.html)の手順に従います。 - 2. **Accepter DNS resolution**オプションを有効にする。 + 2. **Accepter DNS resolution**オプションを有効にします。 Apache Pulsar サービスがインターネットにアクセスできない Google Cloud VPC 内にある場合は、以下の手順を実行してください。 diff --git a/tidb-cloud/changefeed-sink-to-mysql.md b/tidb-cloud/changefeed-sink-to-mysql.md index 02d8434380359..7fbfa74bedc24 100644 --- a/tidb-cloud/changefeed-sink-to-mysql.md +++ b/tidb-cloud/changefeed-sink-to-mysql.md @@ -49,7 +49,7 @@ MySQLサービスがパブリックインターネットアクセスを持たな 3. MySQLのURLにホスト名が含まれている場合、 TiDB CloudがMySQLサービスのDNSホスト名を解決できるようにする必要があります。 1. [VPCピアリング接続のDNS解決を有効にする](https://docs.aws.amazon.com/vpc/latest/peering/modify-peering-connections.html#vpc-peering-dns)の手順に従います。 - 2. **Accepter DNS resolution**オプションを有効にする。 + 2. **Accepter DNS resolution**オプションを有効にします。 MySQL サービスがパブリック インターネット アクセスのない Google Cloud VPC 内にある場合は、以下の手順を実行してください。 diff --git a/tidb-cloud/database-schema-concepts.md b/tidb-cloud/database-schema-concepts.md index e685252c5f9fb..1ed3cd5ecdf97 100644 --- a/tidb-cloud/database-schema-concepts.md +++ b/tidb-cloud/database-schema-concepts.md @@ -161,9 +161,9 @@ TiDBはバージョン6.6.0以降、実験的機能として外部キー制約 ビューは仮想テーブルとして機能し、そのスキーマはビューを作成する`SELECT`ステートメントによって定義されます。ビューを使用することには、次のような利点があります。 -- 基となるテーブルに保存されている機密性の高いフィールドとデータのセキュリティを確保するため、安全なフィールドとデータのみをユーザーに公開する。 +- 基となるテーブルに保存されている機密性の高いフィールドとデータのセキュリティを確保するため、安全なフィールドとデータのみをユーザーに公開します。 -- 複雑なクエリをより簡単かつ便利にするために、ビューとして頻繁に出現する複雑なクエリを定義する。 +- 複雑なクエリをより簡単かつ便利にするために、ビューとして頻繁に出現する複雑なクエリを定義します。 詳細については、[ビュー](/views.md)を参照してください。 diff --git a/tidb-cloud/get-started-with-cli.md b/tidb-cloud/get-started-with-cli.md index 109f52f1c40cc..77fb7d3473afe 100644 --- a/tidb-cloud/get-started-with-cli.md +++ b/tidb-cloud/get-started-with-cli.md @@ -129,7 +129,7 @@ ticloud serverless create ## TiDB Cloud CLIを使用する {#use-the-tidb-cloud-cli} -利用可能なすべてのコマンドを確認する。 +利用可能なすべてのコマンドを確認します。 ```shell ticloud --help @@ -151,7 +151,7 @@ ticloud update TiDB Cloud CLI は[TiUP](https://tiup.io/)からも利用可能で、コンポーネント名は`cloud`です。 -利用可能なすべてのコマンドを確認する。 +利用可能なすべてのコマンドを確認します。 ```shell tiup cloud --help diff --git a/tidb-cloud/integrate-tidbcloud-with-airbyte.md b/tidb-cloud/integrate-tidbcloud-with-airbyte.md index 48f637b7b282c..ff1950a83ebd2 100644 --- a/tidb-cloud/integrate-tidbcloud-with-airbyte.md +++ b/tidb-cloud/integrate-tidbcloud-with-airbyte.md @@ -13,7 +13,7 @@ Airbyteは、わずか数ステップでローカル環境にデプロイでき 1. ワークスペースに[Docker](https://www.docker.com/products/docker-desktop)をインストールします。 -2. Airbyteのソースコードをクローンする。 +2. Airbyteのソースコードをクローンします。 ```shell git clone https://github.com/airbytehq/airbyte.git && \ diff --git a/tidb-cloud/migrate-from-mysql-using-aws-dms.md b/tidb-cloud/migrate-from-mysql-using-aws-dms.md index 12f6e70f84d06..154cbf11914fa 100644 --- a/tidb-cloud/migrate-from-mysql-using-aws-dms.md +++ b/tidb-cloud/migrate-from-mysql-using-aws-dms.md @@ -160,7 +160,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ - **Editing mode**：**ウィザード**を選択してください。 - **ソーストランザクションのカスタムCDC停止モード**：デフォルト設定を使用します。 - **Target table preparation mode**：必要に応じて**Do nothing**またはその他のオプションを選択してください。この例では、 **Do nothing**を選択します。 - - **フルロード完了後にタスクを停止する**：デフォルト設定を使用する。 + - **フルロード完了後にタスクを停止する**：デフォルト設定を使用します。 - **LOB列をレプリケーションに含める**：**Limited LOB mode**を選択します。 - **LOBの最大サイズ（KB）** ：デフォルト値の**32**を使用します。 - **Turn on validation**：必要に応じて選択してください。 diff --git a/tidb-cloud/migrate-from-mysql-using-data-migration.md b/tidb-cloud/migrate-from-mysql-using-data-migration.md index c1b3143cdca3c..8365bcd530901 100644 --- a/tidb-cloud/migrate-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-from-mysql-using-data-migration.md @@ -574,7 +574,7 @@ MySQLサービスがAWS VPC内にある場合は、以下の手順を実行し 3. MySQLのURLにDNSホスト名が含まれている場合、 TiDB CloudがMySQLサービスのホスト名を解決できるようにする必要があります。 1. [VPCピアリング接続のDNS解決を有効にする](https://docs.aws.amazon.com/vpc/latest/peering/modify-peering-connections.html#vpc-peering-dns)の手順に従います。 - 2. **Accepter DNS resolution**オプションを有効にする。 + 2. **Accepter DNS resolution**オプションを有効にします。
diff --git a/tidb-cloud/migrate-from-op-tidb.md b/tidb-cloud/migrate-from-op-tidb.md index f4445635db159..36a42c33e2f9c 100644 --- a/tidb-cloud/migrate-from-op-tidb.md +++ b/tidb-cloud/migrate-from-op-tidb.md @@ -9,7 +9,7 @@ summary: TiDB Self-ManagedからTiDB Cloudへのデータ移行方法を学び 全体の手順は以下のとおりです。 -1. 環境を構築し、ツールを準備する。 +1. 環境を構築し、ツールを準備します。 2. 全データを移行します。手順は以下のとおりです。 1. Dumplingを使用して、TiDB Self-ManagedからAmazon S3にデータをエクスポートします。 2. Amazon S3 からTiDB Cloudへデータをインポートします。 diff --git a/tidb-cloud/monitor-built-in-alerting.md b/tidb-cloud/monitor-built-in-alerting.md index 9b9c62b3f49c9..0b99c86262d26 100644 --- a/tidb-cloud/monitor-built-in-alerting.md +++ b/tidb-cloud/monitor-built-in-alerting.md @@ -118,7 +118,7 @@ TiDB Cloudは、そのプランで利用可能[特徴](/tidb-cloud/features.md) | データ移行ジョブのデータインポート中にエラーが発生しました | エラーを確認し、ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | | データ移行ジョブで増分移行中にエラーが発生しました | エラーを確認し、ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | | データ移行ジョブが増分移行中に6時間以上一時停止しています | データの増分移行中に、データ移行ジョブが 6 時間以上一時停止されました。アップストリーム データベースのbinlogがパージされる可能性があり (データベースのbinlogパージ戦略によって異なります)、増分移行が失敗する可能性があります。ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | -| レプリケーション遅延は10分を超え、20分以上経過しても増加し続けている。 | ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | +| レプリケーション遅延は10分を超え、20分以上経過しても増加し続けています。 | ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | ### TiDB Cloud Dedicatedの変更フィードアラート {#changefeed-alerts-for-tidb-cloud-dedicated} diff --git a/tidb-cloud/notifications.md b/tidb-cloud/notifications.md index 4fbd9196fd7c1..a8d9e32bef18f 100644 --- a/tidb-cloud/notifications.md +++ b/tidb-cloud/notifications.md @@ -48,7 +48,7 @@ TiDB Cloudコンソールでは、次のようなさまざまな種類の通知 | Starterインスタンスの支出制限しきい値アラート | 組織内のTiDB Cloud Starterインスタンスの[支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)に達しました。 | `Organization Owner` 、 `Organization Billing Manager` 、 `Organization Billing Viewer` 、および`Project Owner` | | クレジットの更新 | 組織の [クレジット](/tidb-cloud/tidb-cloud-billing.md#credits)が適用、完全に使用、回収、または期限切れになります。 | `Organization Owner` 、 `Organization Billing Manager` 、および`Organization Billing Viewer` | | 割引情報 | 組織向けの[割引](/tidb-cloud/tidb-cloud-billing.md#discounts)は、適用、回収、または期限切れとなります。 | `Organization Owner` 、 `Organization Billing Manager` 、および`Organization Billing Viewer` | -| マーケットプレイスのアップデート | 組織は、クラウドプロバイダーのマーケットプレイスを通じて、サブスクリプション契約またはサブスクリプション解除契約を締結している。 | 組織のすべてのメンバー | +| マーケットプレイスのアップデート | 組織は、クラウドプロバイダーのマーケットプレイスを通じて、サブスクリプション契約またはサブスクリプション解除契約を締結しています。 | 組織のすべてのメンバー | | サポートプランの更新 | 組織のサポートプランの契約内容が変更されました。 | 組織のすべてのメンバー | ## 通知を確認する {#view-notifications} diff --git a/tidb-cloud/premium/migrate-from-op-tidb-premium.md b/tidb-cloud/premium/migrate-from-op-tidb-premium.md index f2ae6c1eb5924..9c6c43cf9382a 100644 --- a/tidb-cloud/premium/migrate-from-op-tidb-premium.md +++ b/tidb-cloud/premium/migrate-from-op-tidb-premium.md @@ -9,7 +9,7 @@ summary: TiDB Self-ManagedからTiDB Cloud Premiumへのデータ移行方法を 全体の手順は以下のとおりです。 -1. 環境を構築し、ツールを準備する。 +1. 環境を構築し、ツールを準備します。 2. 全データを移行します。手順は以下のとおりです。 1. Dumplingを使用して、TiDB Self-ManagedからAmazon S3にデータをエクスポートします。 2. Amazon S3からTiDB Cloud Premiumにデータをインポートします。 diff --git a/tidb-cloud/premium/premium-export.md b/tidb-cloud/premium/premium-export.md index 5a5c22adae619..2f207eeb022a2 100644 --- a/tidb-cloud/premium/premium-export.md +++ b/tidb-cloud/premium/premium-export.md @@ -88,7 +88,7 @@ TiDB Cloudコンソールは、選択したデータベースとテーブルを - `gzip` (デフォルト): `gzip`を使用してエクスポートされたデータを圧縮します。 - `snappy` : `snappy`を使用してエクスポートされたデータを圧縮します。 - `zstd` : `zstd`を使用してエクスポートされたデータを圧縮します。 -- `none` : エクスポートされたデータを圧縮しない。 +- `none` : エクスポートされたデータを圧縮しません。 ## 例 {#examples} diff --git a/tidb-cloud/releases/release-notes-2024.md b/tidb-cloud/releases/release-notes-2024.md index 3b1cb542aa664..cda5d0935fb59 100644 --- a/tidb-cloud/releases/release-notes-2024.md +++ b/tidb-cloud/releases/release-notes-2024.md @@ -158,7 +158,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのデータインポートエクスペリエンスを向上させます。 - - **インポート**ページのレイアウトをより分かりやすいものに改善する。 + - **インポート**ページのレイアウトをより分かりやすいものに改善します。 - TiDB Cloud Serverless クラスターとTiDB Cloud Dedicatedクラスターのインポート手順を統一します。 - AWSロールARNの作成プロセスを簡素化し、接続設定を容易にします。 @@ -230,7 +230,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ 詳細については、 [定義済みのシステムエンドポイントを追加します](/tidb-cloud/data-service-manage-endpoint.md#add-a-predefined-system-endpoint)を参照してください。 -- スロークエリのデータストレージを強化する。 +- スロークエリのデータストレージを強化します。 [TiDB Cloudコンソール](https://tidbcloud.com)におけるクエリアクセスの遅延は、より安定し、データベースのパフォーマンスに影響を与えなくなりました。 @@ -428,7 +428,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ **全般的な変更** -- プロジェクトにおけるCIDR構成を強化する。 +- プロジェクトにおけるCIDR構成を強化します。 - 各プロジェクトごとに、地域レベルのCIDRを直接設定できます。 - より幅広いCIDR値の中から、CIDR構成を選択できます。 diff --git a/tidb-cloud/security-concepts.md b/tidb-cloud/security-concepts.md index c2c75149b7f01..193ba383baa95 100644 --- a/tidb-cloud/security-concepts.md +++ b/tidb-cloud/security-concepts.md @@ -61,7 +61,7 @@ TiDB Cloudは、ユーザーベースおよびロールベースの権限設定 - 最小権限の原則を実践するため、ユーザーにはそれぞれの役割に必要な権限のみを付与してください。 - - 組織の要件の変化に合わせて、ユーザーアクセス権限を定期的に監査および更新する。 + - 組織の要件の変化に合わせて、ユーザーアクセス権限を定期的に監査および更新します。 ### データベースユーザーアカウント {#database-user-accounts} @@ -89,7 +89,7 @@ TiDBの権限管理システムはMySQL 5.7をベースとしており、デー - テーブル、ビュー、インデックス、ユーザー、その他のオブジェクトを含むデータベースオブジェクトに基づいた、きめ細かなアクセス制御をサポートします。 -- *例：特定のテーブルに対するSELECT権限をユーザーに付与する。* +- *例：特定のテーブルに対するSELECT権限をユーザーに付与します。* **動的な権限** @@ -101,7 +101,7 @@ TiDBの権限管理システムはMySQL 5.7をベースとしており、デー - 権限を役割ごとにグループ化し、ユーザーに割り当てられるようにすることで、権限管理の効率化と動的な更新が可能になります。 -- 例：アナリストに読み書き権限を割り当てることで、ユーザーアクセス制御を簡素化する。 +- 例：アナリストに読み書き権限を割り当てることで、ユーザーアクセス制御を簡素化します。 このシステムは、組織の方針に準拠しながら、ユーザーアクセス管理における柔軟性と正確性を確保します。 @@ -285,7 +285,7 @@ TiDB Cloudコンソール上で行われた主要な操作（ユーザーの招 - ログをSIEMツールと統合することで、リアルタイムの監視とアラートを実現します。 -- 法令遵守要件を満たすようにデータ保持ポリシーを設定する。 +- 法令遵守要件を満たすようにデータ保持ポリシーを設定します。 ### データベース監査ログ {#database-audit-logging} diff --git a/tidb-cloud/set-up-vpc-peering-connections.md b/tidb-cloud/set-up-vpc-peering-connections.md index f1ef56d0c832a..13ab746f901c5 100644 --- a/tidb-cloud/set-up-vpc-peering-connections.md +++ b/tidb-cloud/set-up-vpc-peering-connections.md @@ -50,7 +50,7 @@ VPCピアリングリクエストをリージョンに追加するには、そ > - 172.30.0.0 - 172.31.255.255 > - TiDB Cloud は、リージョンの CIDR ブロック サイズに基づいて、プロジェクトのリージョン内のTiDB Cloudノードの数を制限します。 -5. クラウド プロバイダーと特定のリージョンの CIDR を確認する。 +5. クラウド プロバイダーと特定のリージョンの CIDR を確認します。 CIDRはデフォルトで無効になっています。CIDRを有効にするには、対象リージョンにクラスターを作成する必要があります。リージョンのCIDRが有効な場合は、そのリージョンにVPCピアリングを作成できます。 diff --git a/tidb-cloud/tidb-cloud-glossary.md b/tidb-cloud/tidb-cloud-glossary.md index 77a4500c6f861..5d1c95be88f96 100644 --- a/tidb-cloud/tidb-cloud-glossary.md +++ b/tidb-cloud/tidb-cloud-glossary.md @@ -158,7 +158,7 @@ TiDB Cloudでは、プロジェクトを使用してTiDBリソースをグルー ### レプリカ {#replica} -同一または異なるリージョンに配置される、同じデータを含む独立したデータベース。レプリカは、ディザスタリカバリ目的やパフォーマンス向上のためによく使用される。 +同一または異なるリージョンに配置される、同じデータを含む独立したデータベース。レプリカは、ディザスタリカバリ目的やパフォーマンス向上のためによく使用されます。 ### レプリケーション容量ユニット（RCU） {#replication-capacity-unit-rcu} diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index b116efc9b85a5..1dc138aa3c3b1 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -897,7 +897,7 @@ TiDBサービスの状態に関するコンフィグレーション。 ### `engines` {#engines} -- TiDBがデータを読み取ることを許可するエンジンを制御する。 +- TiDBがデータを読み取ることを許可するエンジンを制御します。 - デフォルト値: ["tikv", "tiflash", "tidb"]。これは、エンジンがオプティマイザによって自動的に選択されることを示します。 - 値のオプション: 「tikv」、「tiflash」、「tidb」の任意の組み合わせ。例: ["tikv", "tidb"] または ["tiflash", "tidb"] diff --git a/tidb-external-ts.md b/tidb-external-ts.md index e3228cb97572d..d8b9fe7d845c8 100644 --- a/tidb-external-ts.md +++ b/tidb-external-ts.md @@ -37,7 +37,7 @@ summary: tidb_external_ts` 変数を使用して履歴データを読み取る Query OK, 3 rows affected (0.00 sec) -2. 表内のデータを表示する。 +2. 表内のデータを表示します。 ```sql SELECT * FROM t; diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md index 522a8cdff024d..f9fc03ba72763 100644 --- a/tidb-lightning/tidb-lightning-data-source.md +++ b/tidb-lightning/tidb-lightning-data-source.md @@ -22,7 +22,7 @@ TiDB Lightningが実行されると、 `data-source-dir`パターンに一致す | スキーマファイル | `CREATE TABLE` DDL文が含まれています | `${db_name}.${table_name}-schema.sql` | | スキーマファイル | `CREATE DATABASE` DDL文が含まれています | `${db_name}-schema-create.sql` | | データファイル | データファイルにテーブル全体のデータが含まれている場合、ファイルは`${db_name}.${table_name}`名前のテーブルにインポートされます。 | `${db_name}.${table_name}.${csv|sql|parquet}` | -| データファイル | テーブルのデータが複数のデータファイルに分割されている場合、各データファイルのファイル名に数字を付ける必要がある。 | `${db_name}.${table_name}.001.${csv|sql|parquet}` | +| データファイル | テーブルのデータが複数のデータファイルに分割されている場合、各データファイルのファイル名に数字を付ける必要があります。 | `${db_name}.${table_name}.001.${csv|sql|parquet}` | | 圧縮ファイル | ファイルに`gzip` 、 `snappy` 、 `zstd`などの圧縮サフィックスが含まれている場合、 TiDB Lightning はインポート前にファイルを解凍します。Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)形式である必要があります。その他の Snappy 圧縮形式はサポートされていません。 | `${db_name}.${table_name}.${csv|sql|parquet}.{compress}` | TiDB Lightningは、可能な限り並列でデータを処理します。ファイルは順番に読み取る必要があるため、データ処理の同時実行性はファイルレベル（ `region-concurrency`で制御）で制御されます。そのため、インポートするファイルのサイズが大きい場合、インポートのパフォーマンスが低下します。最適なパフォーマンスを得るには、インポートするファイルのサイズを256MiB以下に制限することをお勧めします。 diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md index 8076603abb9e9..d9a5fce923baf 100644 --- a/tidb-lightning/tidb-lightning-distributed-import.md +++ b/tidb-lightning/tidb-lightning-distributed-import.md @@ -137,7 +137,7 @@ nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out & インポートを開始した後、次のいずれかの方法で進行状況を確認できます。 - `grep` log キーワード`progress`で進捗状況を確認します。デフォルトでは5分ごとに更新されます。 -- 監視コンソールで進行状況を確認してください。詳細は[TiDB Lightning監視](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 +- 監視コンソールで進行状況を確認します。詳細は[TiDB Lightning監視](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 すべてのTiDB Lightningインスタンスが終了するまで待機すると、インポート全体が完了します。 diff --git a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md index 154bbdaee5413..fbab279b780ad 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md @@ -229,7 +229,7 @@ TPCCを使用してオンラインアプリケーションをシミュレート - TPMの列の数値は、TPMの減少率（パーセント）を示しています。 - P99、P90、およびAVG列の数値は、レイテンシーの増加率を示しています。 -テスト結果によると、同時実行数が少ないほど、データインポートがTPCCの結果に与える影響は大きくなる。同時実行数が64以上の場合、データインポートがTPCCの結果に与える影響はごくわずかである。 +テスト結果によると、同時実行数が少ないほど、データインポートがTPCCの結果に与える影響は大きくなります。同時実行数が64以上の場合、データインポートがTPCCの結果に与える影響はごくわずかです。 したがって、TiDBクラスタにレイテンシに敏感なアプリケーションがあり、かつ同時実行数が少ない場合は、 TiDB Lightningを使用してクラスタにデータをインポートし**ないこと**を強くお勧めします。これは、オンラインアプリケーションに大きな影響を与える可能性があります。 diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md index ac08db7f32f08..ec22237e89e60 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -219,7 +219,7 @@ snap-io-max-bytes-per-sec = "300MiB" - 列数の多い大きな表。 - 複雑なSQLクエリ。 -- 同時接続数が多い。 +- 多数の同時接続。 - 多様なクエリパターン。 #### メモリ効率 {#memory-efficiency} diff --git a/tidb-resource-control-background-tasks.md b/tidb-resource-control-background-tasks.md index b0bde3fd5ddde..244542abc9ac2 100644 --- a/tidb-resource-control-background-tasks.md +++ b/tidb-resource-control-background-tasks.md @@ -70,7 +70,7 @@ TiDB は次の種類のバックグラウンド タスクをサポートして ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES=""); ``` -4. `default`リソース グループのバックグラウンド タスクの種類を表示する。 +4. `default`リソース グループのバックグラウンド タスクの種類を表示します。 ```sql SELECT * FROM information_schema.resource_groups WHERE NAME="default"; diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index f23c460fb8002..47d297045c9ba 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -62,11 +62,11 @@ summary: TiDBでよく発生するエラーのトラブルシューティング - 原因2：他のコンポーネント（PD/TiKV）とのネットワークの問題。 - - 原因3：TiDBの初期バージョン（v3.0.8より前）は、多数のゴルーチンが高並行性で動作するため、内部負荷が非常に高い。 + - 原因3：TiDBの初期バージョン（v3.0.8より前）は、多数のゴルーチンが高並行性で動作するため、内部負荷が非常に高いです。 - 原因4：初期バージョン（v2.1.15およびv3.0.0-rc1未満のバージョン）では、PDインスタンスがTiDBキーを削除できず、すべてのDDL変更が2リース分待機することになります。 - - その他の原因不明の場合は[バグを報告する](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)。 + - その他の原因不明の場合は[バグを報告してください](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)。 - 解決： @@ -163,7 +163,7 @@ OOM のトラブルシューティングの詳細については、 [TiDBのメ - 統計情報を更新します。問題の原因が統計情報にあるとおおよそ確信できる場合は、[統計情報を捨てる](/statistics.md#export-statistics)。原因が古い統計情報である場合、例えば`modify count/row count`の`show stats_meta`が特定の値 (例えば 0.3) より大きい場合、またはテーブルに時間列のインデックスがある場合、 `analyze table`を使用して復旧を試みることもできます。 `auto analyze`が設定されている場合は、 `tidb_auto_analyze_ratio`システム変数が大きすぎる (例えば 0.3 より大きい) かどうか、および現在時刻が`tidb_auto_analyze_start_time`と`tidb_auto_analyze_end_time`の間にあるかどうかを確認してください。 - - その他の状況については、 [バグを報告する](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)。 + - その他の状況については、 [バグを報告してください](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)。 ### 3.4 SQL実行エラー {#34-sql-execution-error} @@ -215,7 +215,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND この問題は想定内のものです。仮想マシンの`fsync`は信頼性が低いため、 `tikv-ctl`を使用してリージョンを復元する必要があります。 -- 4.1.2 その他の予期せぬ原因については、 [バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 +- 4.1.2 その他の予期せぬ原因については、 [バグを報告してください](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 ### 4.2 TiKV OOM {#42-tikv-oom} @@ -273,7 +273,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 4.4.1 TiKVが再起動されたため再選が行われる - - TiKVがパニックを起こした後、systemdによって起動され、正常に動作します。TiKVログを確認することで[バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)panicが発生したかどうかを確認できます。この問題は予期しないため、発生した場合。 + - TiKVがパニックを起こした後、systemdによって起動され、正常に動作します。TiKVログを確認することで、panicが発生したかどうかを確認できます。この問題は予期しないものであるため、発生した場合は[バグを報告してください](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 - TiKV が第三者によって停止または強制終了され、その後 systemd によって起動されました。原因を確認するには`dmesg`と TiKV ログを参照してください。 @@ -293,13 +293,13 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND prewrite/commit の`scheduler command duration`が`scheduler latch wait duration`と`storage async write duration`の合計よりも長くなっています。スケジューラワーカーの CPU 要求が高く、例えば`scheduler-worker-pool-size` * 100% の 80% を超えているか、マシン全体の CPU リソースが比較的限られています。書き込みワークロードが大きい場合は、 `[storage] scheduler-worker-pool-size`の設定が小さすぎないか確認してください。 - その他の状況については、 [バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 + その他の状況については、 [バグを報告してください](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 -- 4.5.3 ログの追加処理が遅い。 +- 4.5.3 ログの追加処理が遅いです。 TiKV Grafana の**Raft IO** / `append log duration`値が高い場合、通常はディスク書き込み操作が遅いことが原因です。RocksDB - raft の`WAL Sync Duration max`の値を確認することで原因を特定できます。 - その他の状況については、 [バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 + その他の状況については、 [バグを報告してください](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 - 4.5.4 raftstore スレッドがビジー状態です。 @@ -308,7 +308,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - `[raftstore] store-pool-size`の設定値が小さすぎないか確認してください。値は`1`と`5`の間に設定し、大きすぎないようにすることをお勧めします。 - マシンのCPUリソースが不足していないか確認してください。 -- 4.5.5 適用処理が遅い。 +- 4.5.5 適用処理が遅いです。 TiKV Grafana の**Raft IO** / `apply log duration`が高い状態です。これは通常、 **Raft Propose** / `apply wait duration`が高い状態と関連しています。考えられる原因は以下のとおりです。 @@ -318,11 +318,11 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - リージョン書き込みホットスポット。単一の適用スレッドでCPU使用率が高くなっています。現在、単一のリージョンでのホットスポット問題を適切に処理することはできませんが、改善中です。各スレッドのCPU使用率を表示するには、Grafana式を変更して`by (instance, name)`を追加してください。 - - RocksDBへの書き込みが遅い。RocksDB**のkv** / `max write duration`が高い。1つのRaftログに複数のKVが含まれる可能性がある。RocksDBへの書き込み時には、1回の書き込みバッチで128個のKVがRocksDBに書き込まれる。そのため、適用ログはRocksDBへの複数の書き込みに関連付けられる可能性がある。 + - RocksDBへの書き込みが遅いです。RocksDB**のkv** / `max write duration`が高いです。1つのRaftログに複数のKVが含まれる可能性があります。RocksDBへの書き込み時には、1回の書き込みバッチで128個のKVがRocksDBに書き込まれます。そのため、適用ログはRocksDBへの複数の書き込みに関連付けられる可能性があります。 - - その他の状況については、 [バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 + - その他の状況については、 [バグを報告してください](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 -- 4.5.6 Raftのコミットログが遅い。 +- 4.5.6 Raftのコミットログが遅いです。 TiKV Grafana の**Raft IO** / `commit log duration`が高い (このメトリックは Grafana v4.x 以降でのみサポートされています)。各リージョンは独立したRaftグループに対応します。Raftには、TCP のスライディング ウィンドウ メカニズムと同様のフロー制御メカニズムがあります。スライディング ウィンドウのサイズは`[raftstore] raft-max-inflight-msgs = 256`パラメータを設定することで制御できます。書き込みホットスポットがあり、 `commit log duration`が高い場合は、 `1024`に増やすなど、パラメータを調整できます。 @@ -356,9 +356,9 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 原因 2: ネットワーク。PD ログに`lost the TCP streaming connection`が表示されます。PD ノード間のネットワークに問題がないか確認し、モニター**Grafana** -> **PD** -> **etcd**で`round trip`を表示して原因を検証する必要があります。中国語の[ケース177](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case177.md)を参照してください。 - - 原因3：システム負荷が高い。ログには`server is likely overloaded`と表示されます。中国語の[ケース214](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case214.md)を参照してください。 + - 原因3：システム負荷が高いです。ログには`server is likely overloaded`と表示されます。中国語の[ケース214](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case214.md)を参照してください。 -- 5.2.2 PDはLeaderを選出できないか、選挙が遅い。 +- 5.2.2 PDはLeaderを選出できないか、選挙が遅いです。 - PD はLeaderを選出できません: PD ログには`lease is not expired`が表示されます。 [この問題は](https://github.com/etcd-io/etcd/issues/10355)v3.0.x および v2.1.19 で修正されました。中国語の[ケース875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md)を参照してください。 @@ -370,17 +370,17 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - ネットワークの問題です。Grafana -> **blackbox_exporter** -> **ping レイテンシー**モニターにアクセスして、 **TiDB**から PD Leaderへのネットワークが正常に動作しているかどうかを確認してください。 - - PD パニック。 [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 + - PD パニック。 [バグを報告してください](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 - PDはOOMです[5.3](#53-pd-oom)を参照してください。 - - 問題に他の原因がある場合は、 `curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2`を実行して goroutine を取得し、 [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 + - 問題に他の原因がある場合は、 `curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2`を実行して goroutine を取得し、 [バグを報告してください](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 - 5.2.4 その他の問題 - PD は`FATAL`エラーを報告し、ログには`range failed to find revision pair`と表示されます。この問題は v3.0.8 ( [#2040](https://github.com/pingcap/pd/pull/2040) ) で修正されました。詳細は、中国語の[ケース947](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case947.md)を参照してください。 - - その他の状況については、 [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 + - その他の状況については、 [バグを報告してください](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 ### 5.3 PD OOM {#53-pd-oom} @@ -518,7 +518,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 7.1.4 `distsql.go`は`inconsistent index`を報告します。 - データインデックスに矛盾があるようです。報告されたインデックスが存在するテーブルで`admin check table `コマンドを実行してください。チェックが失敗した場合は、次のコマンドを実行して[バグを報告する](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)ガベージコレクションを無効にしてください。: + データインデックスに矛盾があるようです。報告されたインデックスが存在するテーブルで`admin check table `コマンドを実行してください。チェックが失敗した場合は、次のコマンドを実行してガベージコレクションを無効にし、[バグを報告してください](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md): ```sql SET GLOBAL tidb_gc_enable = 0; diff --git a/tiflash/tiflash-pipeline-model.md b/tiflash/tiflash-pipeline-model.md index 723dcc420903d..09d564b1e321d 100644 --- a/tiflash/tiflash-pipeline-model.md +++ b/tiflash/tiflash-pipeline-model.md @@ -18,7 +18,7 @@ summary: TiFlashパイプライン実行モデルについて学びましょう TiFlashのオリジナルのストリームモデルは、スレッドスケジューリングによる実行モデルです。各クエリは独立して複数のスレッドに適用され、それらのスレッドが連携して実行されます。 -スレッドスケジューリングモデルには、以下の2つの欠陥がある。 +スレッドスケジューリングモデルには、以下の2つの欠陥があります。 - 高並行処理シナリオでは、スレッド数が多すぎるとコンテキストスイッチが大量に発生し、結果としてスレッドスケジューリングのコストが高くなります。 - スレッドスケジューリングモデルでは、クエリのリソース使用量を正確に測定したり、きめ細かなリソース制御を行うことはできません。 diff --git a/tiflash/troubleshoot-tiflash.md b/tiflash/troubleshoot-tiflash.md index 9e54636e768ad..18a1d60b3d87e 100644 --- a/tiflash/troubleshoot-tiflash.md +++ b/tiflash/troubleshoot-tiflash.md @@ -73,7 +73,7 @@ TiFlashのワークロードが大きすぎてTiFlashデータのレプリケー > > テーブルのTiFlashレプリケーション ルールを手動で削除した後、このテーブルに対して`RECOVER TABLE` 、または`FLASHBACK DATABASE` `FLASHBACK TABLE`を実行すると、このテーブルのTiFlashレプリカは復元されません。 - 1. 現在の PD インスタンス内のTiFlashに関連するすべてのデータ複製ルールを表示する。 + 1. 現在の PD インスタンス内のTiFlashに関連するすべてのデータ複製ルールを表示します。 ```shell curl http://:/pd/api/v1/config/rules/group/tiflash diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 03b1c619e8c04..eeb17c6e87eb5 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -495,7 +495,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### `scheduler-concurrency` {#scheduler-concurrency} -- キーに対する同時操作を防止するための内蔵メモリロック機構。各キーは異なるスロットにハッシュ値が格納されている。 +- キーに対する同時操作を防止するための内蔵メモリロック機構。各キーは異なるスロットにハッシュ値が格納されています。 - デフォルト値: `524288` - 最小値: `1` diff --git a/tikv-in-memory-engine.md b/tikv-in-memory-engine.md index 16bda249b1db5..d3d888ca6023c 100644 --- a/tikv-in-memory-engine.md +++ b/tikv-in-memory-engine.md @@ -25,7 +25,7 @@ TiKV MVCCインメモリエンジンは、最新の書き込み済みMVCCバー - 左側（インメモリエンジンが無効になっている場合）：テーブルレコードは、主キーに基づいて昇順でRocksDBに格納され、同じ行のすべてのMVCCバージョンが隣接して配置されます。 - 右側（インメモリエンジン有効）：RocksDB内のデータは左側のデータと同じですが、インメモリエンジンは2つの行それぞれについて最新の2つのMVCCバージョンをキャッシュします。 - TiKVが範囲`[k1, k2]` 、開始タイムスタンプ`8`のスキャン要求を処理する場合： - - インメモリエンジン（左図）がない場合、11個のMVCCバージョンを処理する必要がある。 + - インメモリエンジン（左図）がない場合、11個のMVCCバージョンを処理する必要があります。 - インメモリエンジン（右図）では、処理するMVCCバージョンは4つだけなので、リクエストのレイテンシーとCPU消費量が削減されます。 - TiKVが範囲`[k1, k2]` 、開始タイムスタンプ`7`のスキャン要求を処理する場合： - メモリ内エンジン（右図）に必要な履歴バージョンが欠落しているため、キャッシュが無効になり、TiKVはRocksDBからデータを読み込むようにフォールバックします。 @@ -68,7 +68,7 @@ mvcc-amplification-threshold = 10 1. リージョンは、最近の`next` （RocksDB Iterator next API）および`prev` （RocksDB Iterator prev API）の呼び出し回数に基づいてソートされます。 2. 領域は、 `mvcc-amplification-threshold`構成パラメータを使用してフィルタリングされます。デフォルト値は`10`です。MVCC 増幅は、( `next` + `prev` ) / `processed_keys`として計算されるリード増幅を測定します。 -3. MVCC増幅が著しい上位N個の領域がロードされる。ここでNはメモリ推定に基づいて決定される。 +3. MVCC増幅が著しい上位N個の領域がロードされます。ここでNはメモリ推定に基づいて決定されます。 インメモリエンジンは定期的にリージョンを削除します。そのプロセスは以下のとおりです。 diff --git a/tiproxy/tiproxy-grafana.md b/tiproxy/tiproxy-grafana.md index ddf41c45c25b3..e97f59ca2b44e 100644 --- a/tiproxy/tiproxy-grafana.md +++ b/tiproxy/tiproxy-grafana.md @@ -27,7 +27,7 @@ TiProxy には 4 つのパネルグループがあります。これらのパネ - 接続作成 OPM: 各 TiProxy インスタンスで 1 分ごとに作成される接続の数 - 切断OPM：1分ごとの切断理由別の数。切断理由には以下が含まれます。 - 成功: クライアントは正常に切断されます - - クライアントネットワークの切断：クライアントが切断前に`QUIT`コマンドを送信しない。ネットワークの問題やクライアントのシャットダウンによっても発生する可能性がある。 + - クライアントネットワークの切断：クライアントが切断前に`QUIT`コマンドを送信しません。ネットワークの問題やクライアントのシャットダウンによっても発生する可能性があります。 - クライアントのハンドシェイク失敗: クライアントがTiProxyとのハンドシェイクに失敗しました - 認証失敗: TiDBによってアクセスが拒否されました - SQL エラー: TiDB は他の SQL エラーを返します diff --git a/tiproxy/tiproxy-overview.md b/tiproxy/tiproxy-overview.md index d44ae8ad06e2c..e747e488e7d49 100644 --- a/tiproxy/tiproxy-overview.md +++ b/tiproxy/tiproxy-overview.md @@ -189,7 +189,7 @@ TiProxyがデプロイされていないクラスターの場合、TiProxyイン status_port: 3080 ``` -2. TiProxyをスケールアウトする。 +2. TiProxyをスケールアウトします。 TiProxyインスタンスをスケールアウトするには、 [`tiup cluster scale-out`](/tiup/tiup-component-cluster-scale-out.md)コマンドを使用します。例： diff --git a/tiproxy/tiproxy-traffic-replay.md b/tiproxy/tiproxy-traffic-replay.md index 3c6bb1d433549..9994b2625c7b5 100644 --- a/tiproxy/tiproxy-traffic-replay.md +++ b/tiproxy/tiproxy-traffic-replay.md @@ -77,7 +77,7 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア 詳細については[`tiproxyctl traffic replay`](/tiproxy/tiproxy-command-line-flags.md#traffic-replay)を参照してください。 -5. リプレイレポートを確認する。 +5. リプレイレポートを確認します。 再生が完了すると、レポートはテストクラスターのデータベース`tiproxy_traffic_replay`に保存されます。このデータベースには、テーブル`fail`と`other_errors` 2つのテーブルが含まれています。 diff --git a/transaction-isolation-levels.md b/transaction-isolation-levels.md index 04d0083be42bc..71396709d2b7c 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -99,7 +99,7 @@ MySQLのRead Committed分離レベルは、ほとんどの場合、Consistent Re トランザクション分離レベルは次のように表示および変更できます。 -現在のセッションのトランザクション分離レベルを表示する。 +現在のセッションのトランザクション分離レベルを表示します。 ```sql SHOW VARIABLES LIKE 'transaction_isolation'; diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index 8d49281a89ba4..6c046c715d920 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -52,7 +52,7 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ - PD がLeaderを選出できません: PD ログには`lease is not expired`が表示されます。[この号](https://github.com/etcd-io/etcd/issues/10355)は v3.0.x および v2.1.19 で修正されました。 -- リーダー選出が遅い。リージョンの読み込み時間が長い。この問題は、PDログで`grep "regions cost"`を実行することで確認できます。結果が`load 460927 regions cost 11.77099s`秒など秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0では、 `use-region-storage`を`true`に設定することで`region storage`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。 +- リーダー選出が遅いです。リージョンの読み込み時間が長いです。この問題は、PDログで`grep "regions cost"`を実行することで確認できます。結果が`load 460927 regions cost 11.77099s`秒など秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0では、 `use-region-storage`を`true`に設定することで`region storage`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。 - TiDBとPD間のネットワークに問題があります。Grafana -> **blackbox_exporter** -> **ping レイテンシー**モニターにアクセスして、TiDBからPD Leaderへのネットワークが正常に動作しているかどうかを確認してください。 @@ -62,9 +62,9 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ - ローリングアップグレード中にPD OOMが発生しました。gRPCメッセージのサイズに制限がなく、モニターでは`TCP InSegs`が比較的大きいと表示されます。この問題はv3.0.6（ [＃1952](https://github.com/pingcap/pd/pull/1952) ）で修正されました。 -- PDがパニックになります。[バグを報告する](https://github.com/tikv/pd/issues/new?labels=kind/bug&template=bug-report.md) 。 +- PDがパニックになります。[バグを報告してください](https://github.com/tikv/pd/issues/new?labels=kind/bug&template=bug-report.md)。 -- その他の原因。`curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2`を実行してgoroutineを取得し、 [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 +- その他の原因。`curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2`を実行してgoroutineを取得し、 [バグを報告してください](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 ### TiKVの異常 {#tikv-anomalies} @@ -77,7 +77,7 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ - `gRPC duration`のメトリックを確認してください。このメトリックは、TiKVにおけるgRPCリクエストの合計実行時間を表します。TiKVの`gRPC duration`とTiDBの`KV duration`を比較することで、潜在的なネットワークの問題を特定できます。例えば、gRPCの実行時間は短いのにTiDBのKV実行時間が長い場合、TiDBとTiKV間のネットワークレイテンシーが高いか、TiDBとTiKV間のNIC帯域幅が完全に占有されている可能性があります。 - TiKVが再開されたため再選。 - - TiKVがパニック状態になった後、 `systemd`引き上げられ、正常に動作します。panicが発生したかどうかは、TiKVのログを確認することで確認できます。この問題は予期せぬものであるため、発生した場合は[バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md) 。 + - TiKVがパニック状態になった後、 `systemd`引き上げられ、正常に動作します。panicが発生したかどうかは、TiKVのログを確認することで確認できます。この問題は予期せぬものであるため、発生した場合は[バグを報告してください](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 - TiKVは第三者によって停止または強制終了され、その後`systemd`によってプルアップされます。`dmesg`とTiKVログを確認して原因を確認してください。 - TiKV は OOM であり、再起動を引き起こします。 - `THP` (Transparent Hugepage) を動的に調整しているため、TiKV がハングします。 @@ -106,7 +106,7 @@ CPU リソースの使用量がボトルネックになります。 #### 考えられる理由 {#possible-reasons} - ホットスポットの問題 -- 全体的な負荷が高い。TiDBのスロークエリと負荷の高いクエリを確認してください。インデックスを追加するか、クエリをバッチ処理で実行することで、実行中のクエリを最適化してください。別の解決策としては、クラスターをスケールアウトすることです。 +- 全体的な負荷が高いです。TiDBのスロークエリと負荷の高いクエリを確認してください。インデックスを追加するか、クエリをバッチ処理で実行することで、実行中のクエリを最適化してください。別の解決策としては、クラスターをスケールアウトすることです。 ## その他の原因 {#other-causes} diff --git a/troubleshoot-tidb-cluster.md b/troubleshoot-tidb-cluster.md index 8924fc884e818..d002475e1e77a 100644 --- a/troubleshoot-tidb-cluster.md +++ b/troubleshoot-tidb-cluster.md @@ -5,7 +5,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 # TiDBクラスタシューティング ガイド {#tidb-cluster-troubleshooting-guide} -このガイドは、TiDBの使用中に発生する基本的な問題の診断と解決に役立ちます。問題が解決しない場合は、以下の情報を収集して、 [バグを報告する](/support.md) . +このガイドは、TiDBの使用中に発生する基本的な問題の診断と解決に役立ちます。問題が解決しない場合は、以下の情報を収集して、 [バグを報告する](/support.md)ことができます。 - 正確なエラーメッセージとエラー発生時の操作 - すべてのコンポーネントの状態 @@ -27,7 +27,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 - すべてのプロセスが実行中の場合は、 `tidb-server`ログをチェックして、次のメッセージが表示されているかどうかを確認します。 - 情報スキーマが古くなっています: `tikv-server`に接続できない場合にこのメッセージが表示されます。`pd-server`と`tikv-server`の状態とログを確認してください。 - - panic：プログラムに問題が発生した場合、このメッセージが表示されます。詳細なpanicログをご提供いただければ、 [バグを報告する](/support.md) . + - panic：プログラムに問題が発生した場合、このメッセージが表示されます。詳細なpanicログをご提供いただければ、 [バグを報告する](/support.md)ことができます。 3. データがクリアされ、サービスが再デプロイされる場合は、次の点を確認してください。 @@ -95,7 +95,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 ## TiDB panic {#tidb-panic} -panicログをご提供いただければ、 [バグを報告する](/support.md)できます。 +panicログをご提供いただければ、 [バグを報告する](/support.md)ことができます。 ## 接続が拒否されました {#the-connection-is-rejected} diff --git a/troubleshoot-tidb-oom.md b/troubleshoot-tidb-oom.md index 9caa18d3338af..c864c0ddfe6b0 100644 --- a/troubleshoot-tidb-oom.md +++ b/troubleshoot-tidb-oom.md @@ -172,7 +172,7 @@ OOM 問題の根本原因を特定するには、次の情報を収集する必 - より多くのメモリを消費する SQL ステートメントを確認します。 - - TiDB Dashboardで、SQL ステートメントの分析、スロークエリ、メモリ使用量を確認する。 + - TiDB Dashboardで、SQL ステートメントの分析、スロークエリ、メモリ使用量を確認します。 - `INFORMATION_SCHEMA`の`SLOW_QUERY`と`CLUSTER_SLOW_QUERY`を確認してください。 - 各 TiDB ノードで`tidb_slow_query.log`をチェックします。 - `grep "expensive_query" tidb.log`を実行して、対応するログ エントリを確認します。 diff --git a/user-account-management.md b/user-account-management.md index e5fd4c8678483..6c187ee1df8ce 100644 --- a/user-account-management.md +++ b/user-account-management.md @@ -184,7 +184,7 @@ TiDBはパスワードを[`mysql.user`](/mysql-schema/mysql-schema-user.md)シ 2. tidb-server プロセスを停止します。 - 1. tidb-server プロセスを表示する。 + 1. tidb-server プロセスを表示します。 ```bash ps aux | grep tidb-server