diff --git a/faq/backup-and-restore-faq.md b/faq/backup-and-restore-faq.md index ebd5c8397af1b..b0349ad135ed1 100644 --- a/faq/backup-and-restore-faq.md +++ b/faq/backup-and-restore-faq.md @@ -148,17 +148,17 @@ v6.0.0より前では、 BRは[配置ルール](/placement-rules-in-sql.md)サ たとえば、 `samba`で構築されたネットワーク ディスクにデータをバックアップするときに、 `Code: 22(invalid argument)`エラーが発生する可能性があります。 -### 復元中に`rpc error: code = Unavailable desc =...` error occurred in restore?」を処理するにはどうすればよいですか? {#what-should-i-do-to-handle-the-rpc-error-code--unavailable-desc--error-occurred-in-restore} +### 復元中に発生した`rpc error: code = Unavailable desc =...`エラーを処理するにはどうすればよいですか? {#what-should-i-do-to-handle-the-rpc-error-code--unavailable-desc--error-occurred-in-restore} このエラーは、復元するクラスターの容量が不足している場合に発生する可能性があります。このクラスターの監視メトリックまたはTiKVログを確認することで、原因をさらに確認できます。 この問題に対処するには、クラスター リソースをスケールアウトし、復元の値`tikv-max-restore-concurrency`を減らして、オプション`ratelimit`を有効にしてみてください。 -### `the entry too large, the max entry size is 6291456, the size of data is 7690800` 」というエラーメッセージが表示されて復元が失敗した場合は、どうすればよいでしょうか。 {#what-should-i-do-if-the-restore-fails-with-the-error-message-the-entry-too-large-the-max-entry-size-is-6291456-the-size-of-data-is-7690800} +### `the entry too large, the max entry size is 6291456, the size of data is 7690800`というエラーメッセージが表示されて復元が失敗した場合は、どうすればよいでしょうか。 {#what-should-i-do-if-the-restore-fails-with-the-error-message-the-entry-too-large-the-max-entry-size-is-6291456-the-size-of-data-is-7690800} -`--ddl-batch-size` ～ `128`またはそれより小さい値を設定することで、バッチで作成されるテーブルの数を減らすことができます。 +`--ddl-batch-size`を`128`またはそれより小さい値に設定することで、バッチで作成されるテーブルの数を減らすことができます。 -BRを使用して[`--ddl-batch-size`](/br/br-batch-create-table.md#use-batch-create-table)の値が`1`より大きいバックアップデータを復元する場合、TiDB はテーブル作成の DDL ジョブを TiKV が管理する DDL ジョブキューに書き込みます。このとき、ジョブ メッセージの最大値がデフォルトで`6 MB`であるため (この値を変更することは**推奨されません**。詳細については、 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)と[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)を参照してください)、TiDB が一度に送信するすべてのテーブルスキーマの合計サイズは 6 MB を超えてはなりません。したがって、 `--ddl-batch-size`過度に大きな値に設定すると、TiDB が一度にバッチで送信するテーブルのスキーマ サイズが指定値を超え、 BR が`entry too large, the max entry size is 6291456, the size of data is 7690800`エラーを報告します。 +BRを使用して[`--ddl-batch-size`](/br/br-batch-create-table.md#use-batch-create-table)の値が`1`より大きいバックアップデータを復元する場合、TiDB はテーブル作成の DDL ジョブを TiKV が管理する DDL ジョブキューに書き込みます。このとき、ジョブ メッセージの最大値がデフォルトで`6 MB`であるため (この値を変更することは**推奨されません**。詳細については、 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)と[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)を参照してください)、TiDB が一度に送信するすべてのテーブルスキーマの合計サイズは 6 MB を超えてはなりません。したがって、 `--ddl-batch-size`を過度に大きな値に設定すると、TiDB が一度にバッチで送信するテーブルのスキーマ サイズが指定値を超え、 BR が`entry too large, the max entry size is 6291456, the size of data is 7690800`エラーを報告します。 ### `local`ストレージを使用する場合、バックアップされたファイルはどこに保存されますか? {#where-are-the-backed-up-files-stored-when-i-use-local-storage} @@ -172,7 +172,7 @@ BRを使用して[`--ddl-batch-size`](/br/br-batch-create-table.md#use-batch-cre データを復元する場合、各ノードは**すべての**バックアップファイル（SSTファイル）にアクセスできる必要があります。デフォルトでは、ストレージを`local`を使用している場合、バックアップファイルが複数のノードに分散しているため、データを復元できません。そのため、各TiKVノードのバックアップファイルを他のTiKVノードにコピーする必要があります。**バックアップデータは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、またはNFSに保存することをお勧めします**。 -### ルートを使用して`br`を実行しようとしたがうまくいかなかった場合、「 `Permission denied` 」または`No such file or directory` 」というエラーを処理するにはどうすればよいでしょうか? {#what-should-i-do-to-handle-the-permission-denied-or-no-such-file-or-directory-error-even-if-i-have-tried-to-run-br-using-root-in-vain} +### ルートを使用して`br`を実行しようとしたがうまくいかなかった場合、 `Permission denied`または`No such file or directory`というエラーを処理するにはどうすればよいでしょうか? {#what-should-i-do-to-handle-the-permission-denied-or-no-such-file-or-directory-error-even-if-i-have-tried-to-run-br-using-root-in-vain} TiKVがバックアップディレクトリにアクセスできるかどうかを確認する必要があります。データをバックアップするには、TiKVに書き込み権限があるかどうかを確認してください。データを復元するには、TiKVに読み取り権限があるかどうかを確認してください。 @@ -311,7 +311,7 @@ v4.0.9では、 BRはデフォルトで統計情報をバックアップしま ## 回復プロセスが中断された場合、すでに回復されたデータを削除して、回復を再度開始する必要がありますか? {#if-the-recovery-process-is-interrupted-is-it-necessary-to-delete-the-already-recovered-data-and-start-the-recovery-again} -いいえ、必要ありません。BR以降では、ブレークポイントからのデータの再開をサポートしています。予期せぬ状況でリカバリが中断された場合は、リカバリタスクを再開するだけで、中断したところから再開されます。 +いいえ、必要ありません。v7.1.0以降のBRでは、ブレークポイントからのデータの再開をサポートしています。予期せぬ状況でリカバリが中断された場合は、リカバリタスクを再開するだけで、中断したところから再開されます。 ## リカバリが完了したら、特定のテーブルを削除して再度リカバリできますか? {#after-the-recovery-is-complete-can-i-delete-a-specific-table-and-then-recover-it-again} diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 703e1d1fcc0a8..494bf45b2f75d 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -31,7 +31,7 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ - PDはクラスタのメタデータを保存し、頻繁に読み取りおよび書き込みリクエストが発生します。そのため、高いI/Oディスクを必要とします。ディスクパフォーマンスが低いと、クラスタ全体のパフォーマンスに影響します。SSDディスクの使用をお勧めします。また、リージョン数が多いほど、CPUとメモリの要件が高くなります。 - TiKVはCPU、メモリ、ディスクに対する要件が厳しく、SSDの使用が必須です。 -詳細は[ソフトウェアとハードウェアの推奨事項](/hardware-and-software-requirements.md)参照。 +詳細は[ソフトウェアとハードウェアの推奨事項](/hardware-and-software-requirements.md)を参照してください。 ## インストールとデプロイ {#installation-and-deployment} diff --git a/faq/manage-cluster-faq.md b/faq/manage-cluster-faq.md index b5b92cf7fa1d8..26170a51d8e35 100644 --- a/faq/manage-cluster-faq.md +++ b/faq/manage-cluster-faq.md @@ -128,11 +128,11 @@ TiDBは、ビジネスの成長に合わせて拡張できます。 ### なぜトランザクションは非同期コミットまたはワンフェーズコミット機能を使用しないのですか？ {#why-does-the-transaction-not-use-the-async-commit-or-the-one-phase-commit-feature} -TiDB は、トランザクションで書き込まれるキーと値のペアが 256 個以下で、キーの合計サイズが 4 KB 以下の場合にのみ、非同期コミットまたはワンフェーズコミット機能を使用します。それ以外の場合は、システム変数を使用して 機能と[非同期コミット](/system-variables.md#tidb_enable_async_commit-new-in-v50)機能を有効にしても、TiDB はこれらの機能を使用しません。これは、大量のデータを書き込むトランザクションでは、非同期コミットを使用して[ワンフェーズコミット](/system-variables.md#tidb_enable_1pc-new-in-v50)パフォーマンスが大幅に向上しないためです。 +TiDB は、トランザクションで書き込まれるキーと値のペアが 256 個以下で、キーの合計サイズが 4 KB 以下の場合にのみ、非同期コミットまたはワンフェーズコミット機能を使用します。それ以外の場合は、システム変数を使用して[非同期コミット](/system-variables.md#tidb_enable_async_commit-new-in-v50)機能と[ワンフェーズコミット](/system-variables.md#tidb_enable_1pc-new-in-v50)機能を有効にしても、TiDB はこれらの機能を使用しません。これは、大量のデータを書き込むトランザクションでは、非同期コミットを使用してもパフォーマンスが大幅に向上しないためです。 ## PD管理 {#pd-management} -このセクションでは、PD（パーキンソン病）の管理中に遭遇する可能性のある一般的な問題、その原因、および解決策について説明します。 +このセクションでは、PD 管理中に遭遇する可能性のある一般的な問題、その原因、および解決策について説明します。 ### PDにアクセスすると、 `TiKV cluster is not bootstrapped`メッセージが表示されます。 {#the-tikv-cluster-is-not-bootstrapped-message-is-displayed-when-i-access-pd} @@ -231,7 +231,7 @@ TiClientリージョンエラーインジケータは、TiDBサーバーがク ### テーブルの作成時刻を確認するにはどうすればよいですか？ {#how-to-view-the-creation-time-of-a-table} -`create_time`内のテーブルの`information_schema`は作成時刻です。 +`information_schema`内のテーブルの`create_time`は作成時刻です。 ### TiDBログにおける`EXPENSIVE_QUERY`の意味は何ですか？ {#what-is-the-meaning-of-expensive-query-in-the-tidb-log} @@ -345,7 +345,7 @@ TiKVはRocksDBのカラムファミリー（CF）機能を実装しています ### ノードがダウンした場合、サービスに影響はありますか？影響がある場合、どのくらいの期間影響しますか？ {#if-a-node-is-down-will-the-service-be-affected-if-yes-how-long} -TiKVはRaftを使用して、複数のレプリカ間でデータを複製します（デフォルトでは、各リージョンにつき3つのレプリカ）。1つのレプリカに障害が発生した場合でも、他のレプリカがデータのRaft性を保証します。Raftプロトコルに基づき、ノードのダウンにより単一のリーダーが故障した場合、別のノードのフォロワーがリース時間（10秒）の2倍の時間が経過すると、リージョンのリーダーとして選出されます。 +TiKVはRaftを使用して、複数のレプリカ間でデータを複製します（デフォルトでは、各リージョンにつき3つのレプリカ）。1つのレプリカに障害が発生した場合でも、他のレプリカがデータの安全性を保証します。Raftプロトコルに基づき、ノードのダウンにより単一のリーダーが故障した場合、別のノードのフォロワーがリース時間（10秒）の2倍の時間が経過すると、リージョンのリーダーとして選出されます。 ### TiKVにおいて、I/O、メモリ、CPUを大量に消費し、パラメータ設定を超えるシナリオとはどのようなものですか？ {#what-are-the-tikv-scenarios-that-take-up-high-i-o-memory-cpu-and-exceed-the-parameter-configuration} diff --git a/faq/migration-tidb-faq.md b/faq/migration-tidb-faq.md index 0efba233b3442..7c4223a11d1cb 100644 --- a/faq/migration-tidb-faq.md +++ b/faq/migration-tidb-faq.md @@ -88,7 +88,7 @@ Db2 または Oracle から TiDB にすべてのデータを移行するか、 現在はOGGの使用が推奨されています。 -### エラー: java.sql.BatchUpdateException: Sqoop を使用して TiDB にデータを`batches`で書き込むときに`java.sql.BatchUpdateException:statement count 5001 exceeds the transaction limitation` {#error-javasqlbatchupdateexceptionstatement-count-5001-exceeds-the-transaction-limitation-while-using-sqoop-to-write-data-into-tidb-in-batches} +### エラー: Sqoop を使用して TiDB にデータを`batches`で書き込むときに`java.sql.BatchUpdateException:statement count 5001 exceeds the transaction limitation` {#error-javasqlbatchupdateexceptionstatement-count-5001-exceeds-the-transaction-limitation-while-using-sqoop-to-write-data-into-tidb-in-batches} Sqoopでは、 `--batch`各バッチで100個の`statement`文をコミットすることを意味しますが、デフォルトでは各`statement`に100個のSQL文が含まれます。つまり、100 * 100 = 10000個のSQL文となり、単一のTiDBトランザクションで許可される最大SQL文数である5000を超えてしまいます。 diff --git a/faq/sql-faq.md b/faq/sql-faq.md index d766639a6ba99..0927b030b827a 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -58,7 +58,7 @@ DROP GLOBAL BINDING for ## TiDB と互換性のある MySQL 変数は何ですか? {#what-are-the-mysql-variables-that-tidb-is-compatible-with} -[システム変数](/system-variables.md)参照。 +[システム変数](/system-variables.md)を参照してください。 ## `ORDER BY`を省略した場合、結果の順序はMySQLと異なります。 {#the-order-of-results-is-different-from-mysql-when-order-by-is-omitted} @@ -128,9 +128,9 @@ TiDB では、システム変数[`tidb_enable_ordered_result_mode`](/system-vari はい。悲観的ロック（TiDB v3.0.8以降のデフォルト）を使用する場合、 `SELECT FOR UPDATE`実行はMySQLと同様に動作します。 -楽観的ロックを使用する場合、トランザクションの開始時にはデータをロックしませ`SELECT FOR UPDATE`が、トランザクションのコミット時に競合をチェックします。チェックで競合が見つかった場合、コミットしたトランザクションはロールバックされます。 +楽観的ロックを使用する場合、 `SELECT FOR UPDATE`はトランザクションの開始時にはデータをロックしませんが、トランザクションのコミット時に競合をチェックします。競合が見つかった場合、トランザクションはロールバックされます。 -詳細は[`SELECT`構文要素の説明](/sql-statements/sql-statement-select.md#description-of-the-syntax-elements)参照。 +詳細は[`SELECT`構文要素の説明](/sql-statements/sql-statement-select.md#description-of-the-syntax-elements)を参照してください。 ## TiDBのコーデックはUTF-8文字列がmemcomparableであることを保証できますか？キーがUTF-8をサポートする必要がある場合、コーディングに関する提案はありますか？ {#can-the-codec-of-tidb-guarantee-that-the-utf-8-string-is-memcomparable-is-there-any-coding-suggestion-if-our-key-needs-to-support-utf-8} @@ -153,7 +153,7 @@ TiDB は、SESSION または GLOBAL ベースで[`sql_mode`](/system-variables.m - [`GLOBAL`](/sql-statements/sql-statement-set-variable.md)スコープの変数への変更は、クラスター内の残りのサーバーに伝播し、再起動後も保持されます。つまり、各 TiDBサーバーで`sql_mode`値を変更する必要はありません。 - `SESSION`スコープ変数への変更は、現在のクライアントセッションにのみ影響します。サーバーを再起動すると、変更は失われます。 -## エラー: `java.sql.BatchUpdateException:statement count 5001 exceeds the transaction limitation` {#error-javasqlbatchupdateexceptionstatement-count-5001-exceeds-the-transaction-limitation-while-using-sqoop-to-write-data-into-tidb-in-batches} +## エラー: Sqoop を使用して TiDB にデータを`batches`で書き込むときに`java.sql.BatchUpdateException:statement count 5001 exceeds the transaction limitation` {#error-javasqlbatchupdateexceptionstatement-count-5001-exceeds-the-transaction-limitation-while-using-sqoop-to-write-data-into-tidb-in-batches} Sqoopでは、 `--batch`各バッチで100文をコミットすることを意味しますが、デフォルトでは各文に100個のSQL文が含まれます。つまり、100 * 100 = 10000のSQL文となり、単一のTiDBトランザクションで許可される文の最大数である5000を超えてしまいます。 @@ -252,7 +252,7 @@ DDL操作がブロックされておらず、各TiDBサーバーがスキーマ | DDL操作タイプ | 推定所要時間 | | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------- | | 再編成DDL（ `ADD INDEX`など`MODIFY COLUMN` （再編成タイプのデータ変更） | データ量、システム負荷、DDL パラメータ設定によって異なります。 | -| `ALTER TABLE ADD`的なDDL `DROP DATABASE` `TRUNCATE TABLE` `CREATE TABLE` `CREATE DATABASE` `ALTER TABLE DROP` `DROP TABLE`のみ変更） `DROP INDEX` `MODIFY COLUMN` | 約1秒 | +| 一般DDL（Reorg以外のDDLタイプ）（ `CREATE DATABASE`、 `CREATE TABLE`、 `DROP DATABASE`、 `DROP TABLE`、 `TRUNCATE TABLE`、 `ALTER TABLE ADD`、 `ALTER TABLE DROP`、 `MODIFY COLUMN` （メタデータのみ変更）、 `DROP INDEX`など） | 約1秒 | > **Note:** > @@ -291,11 +291,11 @@ v6.4.0 以降、TiDB は[メタデータロックメカニズム](/metadata-lock > **Note:** > -> - 現在、TiDB はバージョン`schema`の変更をすべてキャッシュするわけではありません。 +> - 現在、TiDB は`schema`バージョンの変更をすべてキャッシュするわけではありません。 > - 各 DDL 操作では、 `schema`バージョンの変更の数は、対応する`schema state`バージョンの変更の数と同じです。 -> - DDL操作によって、バージョン`schema`の変更回数は異なります。例えば、 `CREATE TABLE`文ではバージョン`schema`変更が1回発生しますが、 `ADD COLUMN`文ではバージョン5の変更が4回発生します。 +> - DDL操作によって、`schema`バージョンの変更回数は異なります。例えば、 `CREATE TABLE`文では`schema`バージョンが1回変更されますが、 `ADD COLUMN`文では`schema`バージョンが4回変更されます。 -### 「Information schema is out of date」というエラーの原因は何ですか? {#what-are-the-causes-of-the-information-schema-is-out-of-date-error} +### `Information schema is out of date`というエラーの原因は何ですか? {#what-are-the-causes-of-the-information-schema-is-out-of-date-error} DML文の実行時に、TiDBがDDLリース（デフォルトでは45秒）内に最新のスキーマをロードできない場合、エラー`Information schema is out of date`が発生する可能性があります。考えられる原因は以下のとおりです。 @@ -345,10 +345,10 @@ JDBC URL に`connectionCollation`が設定されていない場合、次の2つ **シナリオ 1** : JDBC URL に`connectionCollation`も`characterEncoding`も設定されていない - Connector/J 8.0.25以前のバージョンでは、JDBCドライバはサーバーのデフォルトの文字セットを使用しようとします。TiDBのデフォルトの文字セットは`utf8mb4`であるため、ドライバは接続照合順序として`utf8mb4_bin`を使用します。 -- Connector/J 8.0.26 以降のバージョンでは、JDBC ドライバーは`utf8mb4`文字セットを使用し、戻り値`SELECT VERSION()`に基づいて照合順序を自動的に選択します。 +- Connector/J 8.0.26 以降のバージョンでは、JDBC ドライバーは`utf8mb4`文字セットを使用し、 `SELECT VERSION()`の戻り値に基づいて照合順序を自動的に選択します。 - 戻り値が`8.0.1`未満の場合、ドライバは接続照合順序として`utf8mb4_general_ci`を使用します。TiDB はドライバに従い、照合順序として`utf8mb4_general_ci`を使用します。 - - 戻り値が`8.0.1`以上の場合、ドライバは接続照合順序として`utf8mb4_0900_ai_ci`を使用します。TiDB v7.4.0 以降のバージョンではドライバに従い、照合順序として`utf8mb4_0900_ai_ci`を使用しますが、TiDB v7.4.0 より前のバージョンでは`utf8mb4_0900_ai_ci`照合順序がサポートされていないため、デフォルトの照合照合順序`utf8mb4_bin`が使用されます。 + - 戻り値が`8.0.1`以上の場合、ドライバは接続照合順序として`utf8mb4_0900_ai_ci`を使用します。TiDB v7.4.0 以降のバージョンではドライバに従い、照合順序として`utf8mb4_0900_ai_ci`を使用しますが、TiDB v7.4.0 より前のバージョンでは`utf8mb4_0900_ai_ci`照合順序がサポートされていないため、デフォルトの照合順序`utf8mb4_bin`が使用されます。 **シナリオ2** ：JDBC URLに`characterEncoding=utf8`が設定されていますが、 `connectionCollation`が設定されていません。JDBCドライバーはマッピングルールに従って`utf8mb4`文字セットを使用します。照合順序はシナリオ1で説明したルールに従って決定されます。 @@ -405,11 +405,11 @@ SELECT 'café' = 'cafe' COLLATE utf8mb4_0900_ai_ci; -- Returns 1 (TRUE) ### TiDB実行計画の説明 {#tidb-execution-plan-description} -[クエリ実行計画を理解する](/explain-overview.md)参照。 +[クエリ実行計画を理解する](/explain-overview.md)を参照してください。 ### 統計収集 {#statistics-collection} -[統計入門](/statistics.md)参照。 +[統計入門](/statistics.md)を参照してください。 ### `select count(1)`を最適化するにはどうすればいいでしょうか? {#how-to-optimize-select-count1} @@ -471,11 +471,11 @@ RUNNING_JOBS: ID:121, Type:add index, State:running, SchemaState:write reorganiz ### TiDBオプションを編集する {#edit-tidb-options} -[TiDBコマンドオプション](/command-line-flags-for-tidb-configuration.md)参照。 +[TiDBコマンドオプション](/command-line-flags-for-tidb-configuration.md)を参照してください。 ### ホットスポットの問題を回避し、負荷分散を実現するにはどうすればよいですか？ TiDB ではホットパーティションまたはホット範囲が問題になりますか？ {#how-to-avoid-hotspot-issues-and-achieve-load-balancing-is-hot-partition-or-range-an-issue-in-tidb} -ホットスポットが発生するシナリオについては、 [一般的な鍋料理](/troubleshoot-hot-spot-issues.md#common-hotspots)を参照してください。以下の TiDB 機能は、ホットスポットの問題を解決するために設計されています。 +ホットスポットが発生するシナリオについては、 [一般的なホットスポット](/troubleshoot-hot-spot-issues.md#common-hotspots)を参照してください。以下の TiDB 機能は、ホットスポットの問題を解決するために設計されています。 - [`SHARD_ROW_ID_BITS`](/troubleshoot-hot-spot-issues.md#use-shard_row_id_bits-to-process-hotspots)属性。この属性を設定すると、行IDが複数のリージョンに分散して書き込まれるため、書き込みホットスポットの問題を軽減できます。 - [`AUTO_RANDOM`](/troubleshoot-hot-spot-issues.md#handle-auto-increment-primary-key-hotspot-tables-using-auto_random)属性は、AUTO_INCREMENT主キーによってもたらされるホットスポットを解決するのに役立ちます。 diff --git a/faq/tidb-faq.md b/faq/tidb-faq.md index a128a90b4fb4e..f12e7cefd64da 100644 --- a/faq/tidb-faq.md +++ b/faq/tidb-faq.md @@ -21,7 +21,7 @@ summary: TiDB に関するよくある質問 (FAQ) について説明します --> -TiDB [TiDB](https://github.com/pingcap/tidb)は、ハイブリッドトランザクションおよび分析処理（HTAP）ワークロードをサポートするオープンソースの分散SQLデータベースです。MySQLと互換性があり、水平スケーラビリティ、強力な一貫性、高可用性を備えています。TiDBの目標は、OLTP（オンライントランザクション処理）、OLAP（オンライン分析処理）、そしてHTAPサービスをカバーするワンストップデータベースソリューションをユーザーに提供することです。TiDBは、大規模データで高可用性と強力な一貫性が求められる様々なユースケースに適しています。 +[TiDB](https://github.com/pingcap/tidb)は、ハイブリッドトランザクションおよび分析処理（HTAP）ワークロードをサポートするオープンソースの分散SQLデータベースです。MySQLと互換性があり、水平スケーラビリティ、強力な一貫性、高可用性を備えています。TiDBの目標は、OLTP（オンライントランザクション処理）、OLAP（オンライン分析処理）、そしてHTAPサービスをカバーするワンストップデータベースソリューションをユーザーに提供することです。TiDBは、大規模データで高可用性と強力な一貫性が求められる様々なユースケースに適しています。 ### TiDB のアーキテクチャとは何ですか? {#what-is-tidb-s-architecture} @@ -118,12 +118,12 @@ TiFlashはデフォルトで強力なデータ整合性を維持します。Raft ### データストレージ用のTiKV {#tikv-for-data-storage} -[TiDB 内部 (I) - データストレージ](https://www.pingcap.com/blog/tidb-internal-data-storage/?from=en)参照。 +[TiDB 内部 (I) - データストレージ](https://www.pingcap.com/blog/tidb-internal-data-storage/?from=en)を参照してください。 ### データコンピューティングのためのTiDB {#tidb-for-data-computing} -[TiDB 内部 (II) - コンピューティング](https://www.pingcap.com/blog/tidb-internal-computing/?from=en)参照。 +[TiDB 内部 (II) - コンピューティング](https://www.pingcap.com/blog/tidb-internal-computing/?from=en)を参照してください。 ### スケジュールのPD {#pd-for-scheduling} -[TiDB内部（III） - スケジューリング](https://www.pingcap.com/blog/tidb-internal-scheduling/?from=en)参照。 +[TiDB内部（III） - スケジューリング](https://www.pingcap.com/blog/tidb-internal-scheduling/?from=en)を参照してください。 diff --git a/faq/upgrade-faq.md b/faq/upgrade-faq.md index f35b4d523d186..37d2dfb1feb81 100644 --- a/faq/upgrade-faq.md +++ b/faq/upgrade-faq.md @@ -29,7 +29,7 @@ TiDBサービスにローリングアップデートを適用すると、実行 ### バイナリを使用して TiDB をアップグレードするにはどうすればよいですか? {#how-to-upgrade-tidb-using-the-binary} -バイナリを使用してTiDBをアップグレードすることは推奨されません。代わりに、バージョンの一貫性と互換性を確保するために、バージョン[TiUPを使用して TiDB をアップグレードする](/upgrade-tidb-using-tiup.md)または[Kubernetes上のTiDBクラスターをアップグレードする](https://docs.pingcap.com/tidb-in-kubernetes/stable/upgrade-a-tidb-cluster)へのアップグレードをお勧めします。 +バイナリを使用してTiDBをアップグレードすることは推奨されません。代わりに、バージョンの一貫性と互換性を確保するために、[TiUPを使用して TiDB をアップグレードする](/upgrade-tidb-using-tiup.md)または[Kubernetes上のTiDBクラスターをアップグレードする](https://docs.pingcap.com/tidb-in-kubernetes/stable/upgrade-a-tidb-cluster)ことをお勧めします。 ## アップグレード後のFAQ {#after-upgrade-faqs} diff --git a/tiproxy/tiproxy-command-line-flags.md b/tiproxy/tiproxy-command-line-flags.md index b77ced6b04e55..212a469c6dc67 100644 --- a/tiproxy/tiproxy-command-line-flags.md +++ b/tiproxy/tiproxy-command-line-flags.md @@ -104,7 +104,7 @@ tiproxyctl --host 127.0.0.1 --port 3080 config get - tiproxyctl のログレベルを指定します。 - タイプ: `string` - デフォルト: `"warn"` -- `debug` `info` `error`でき`panic` `warn` +- `debug` 、 `info` 、 `warn` 、 `error` 、 `panic`を指定できます。 #### `-k, --insecure` {#k-insecure} diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index 3424a73518774..f4aaf71d421c3 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -58,7 +58,7 @@ SQL ポートの設定。 - デフォルト値: `0` - ホットリロードのサポート: はい - 単位: 秒 -- TiProxyがシャットダウンすると、HTTPステータスはunhealthyを返しますが、SQLポートは`graceful-wait-before-shutdown`秒間は新規接続を受け付けます。その後、新規接続は拒否され、クライアントの負荷が増大します。クライアントとTiProxyの間に他のプロキシ（NLBなど）が存在しない場合は、この値を`0`に設定することをお勧めします。 +- TiProxyがシャットダウンすると、HTTPステータスはunhealthyを返しますが、SQLポートは`graceful-wait-before-shutdown`秒間は新規接続を受け付けます。その後、新規接続は拒否され、クライアントをドレインします。クライアントとTiProxyの間に他のプロキシ（NLBなど）が存在しない場合は、この値を`0`に設定することをお勧めします。 #### `graceful-close-conn-timeout` {#graceful-close-conn-timeout} @@ -90,7 +90,7 @@ SQL ポートの設定。 - デフォルト値: `""` - ホットリロードのサポート: はい、ただし新規接続のみ -- 可能な`"v2"` : `""` +- 値のオプション: `""` 、 `"v2"` - ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)を有効にしてください。PROXYプロトコルを有効にすると、TiProxyは実際のクライアントIPアドレスをTiDBに渡すことができます。`"v2"` PROXYプロトコルバージョン2の使用を示し、 `""` PROXYプロトコルの無効化を示します。TiProxyでPROXYプロトコルが有効になっている場合は、TiDBサーバーでも[PROXYプロトコル](/tidb-configuration-file.md#proxy-protocol)を有効にする必要があります。 ### API {#api} @@ -107,7 +107,7 @@ HTTP ゲートウェイの構成。 - デフォルト値: `""` - ホットリロードのサポート: いいえ -- 可能な`"v2"` : `""` +- 値のオプション: `""` 、 `"v2"` - ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)を有効にします。`"v2"` PROXY プロトコル バージョン 2 を使用することを示し、 `""` PROXY プロトコルを無効にすることを示します。 ### バランス {#balance} @@ -125,10 +125,10 @@ TiProxy の負荷分散ポリシーの構成。 - デフォルト値: `resource` - ホットリロードのサポート: はい -- `location` `connection`値: `resource` +- 値のオプション: `resource` 、 `location` 、 `connection` - 負荷分散ポリシーを指定します。各値の意味については、 [TiProxy 負荷分散ポリシー](/tiproxy/tiproxy-load-balance.md#configure-load-balancing-policies)を参照してください。 -### ハ {#ha} +### HA {#ha} TiProxy の高可用性構成。 @@ -173,7 +173,7 @@ TiProxy v1.3.1以降、複数の仮想IPアドレスの設定がサポートさ - デフォルト値: `info` - ホットリロードのサポート: はい -- `info` `error` `panic` `warn` `debug` +- 値のオプション: `debug` 、 `info` 、 `warn` 、 `error` 、 `panic` - ログレベルを指定します。レベル`panic`の場合、TiProxyはエラー発生時にpanicになります。 #### `encoder` {#encoder} @@ -247,7 +247,7 @@ TLS オブジェクト フィールド: - サーバー証明書の検証をスキップするには、 `ca`または`skip-ca`を設定する必要があります。 - オプションで、サーバー側のクライアント検証に合格するために`cert`または`key`を設定できます。 -- 役に立たないフィールド: 自動証明書。 +- 効果のないフィールド: `auto-certs`。 サーバーTLS オブジェクトの場合: diff --git a/tiproxy/tiproxy-deployment-topology.md b/tiproxy/tiproxy-deployment-topology.md index c3e7461025ddb..f551b5afdb5fc 100644 --- a/tiproxy/tiproxy-deployment-topology.md +++ b/tiproxy/tiproxy-deployment-topology.md @@ -42,5 +42,5 @@ TiProxy のテンプレートの詳細については、 [TiProxyトポロジの > **Note:** > -> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPTiUPコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 +> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUP クラスターコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 > - デプロイメントディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/tiproxy/tiproxy-grafana.md b/tiproxy/tiproxy-grafana.md index 2aed4dd5e4ac1..0d9e90a0c4b47 100644 --- a/tiproxy/tiproxy-grafana.md +++ b/tiproxy/tiproxy-grafana.md @@ -18,46 +18,46 @@ TiProxy には 4つのパネルグループがあります。これらのパネ - **TiProxy-Backend** : TiProxy が接続する可能性のある TiDB ノードに関する情報。 - **TiProxy-Balance** : 負荷分散メトリック。 -## サーバ {#server} - -- CPU使用率: 各TiProxyインスタンスのCPU使用率 -- メモリ使用量: 各 TiProxy インスタンスのメモリ使用量 -- 稼働時間: 前回の再起動以降の各 TiProxy インスタンスの実行時間 -- 接続数: 各 TiProxy インスタンスに接続されているクライアントの数 -- 接続作成 OPM: 各 TiProxy インスタンスで 1分ごとに作成される接続の数 -- 切断OPM：1分ごとの切断理由別の数。切断理由には以下が含まれます。 - - 成功: クライアントは正常に切断されます - - クライアントネットワークの切断：クライアントが切断前に`QUIT`コマンドを送信しません。ネットワークの問題やクライアントのシャットダウンによっても発生する可能性があります。 - - クライアントのハンドシェイク失敗: クライアントがTiProxyとのハンドシェイクに失敗しました - - 認証失敗: TiDBによってアクセスが拒否されました - - SQL エラー: TiDB は他の SQL エラーを返します - - プロキシのシャットダウン: TiProxy はシャットダウンしています - - 不正なパケット: TiProxy は MySQL パケットを解析できません - - バックエンドの取得失敗: TiProxy は接続に利用可能なバックエンドを見つけることができません - - プロキシエラー: その他の TiProxy エラー - - バックエンドネットワークの中断: TiDBの読み取りまたは書き込みに失敗しました。これは、ネットワークの問題、またはTiDBサーバーのシャットダウンが原因である可能性があります。 - - バックエンドのハンドシェイク失敗: TiProxy が TiDBサーバーとのハンドシェイクに失敗しました -- Goroutine 数: 各 TiProxy インスタンス上の Goroutine の数 -- 所有者: 様々なタスクを実行するTiProxyインスタンス。例えば、 `10.24.31.1:3080 - vip` `10.24.31.1:3080`のTiProxyインスタンスが仮想IPにバインドされていることを示します。タスクには以下が含まれます。 +## Server {#server} + +- CPU Usage: 各TiProxyインスタンスのCPU使用率 +- Memory Usage: 各 TiProxy インスタンスのメモリ使用量 +- Uptime: 前回の再起動以降の各 TiProxy インスタンスの実行時間 +- Connection Count: 各 TiProxy インスタンスに接続されているクライアントの数 +- Create Connection OPM: 各 TiProxy インスタンスで 1分ごとに作成される接続の数 +- Disconnection OPM: 1分ごとの切断理由別の数。切断理由には以下が含まれます。 + - success: クライアントは正常に切断されます + - client network break: クライアントが切断前に`QUIT`コマンドを送信しません。ネットワークの問題やクライアントのシャットダウンによっても発生する可能性があります。 + - client handshake fail: クライアントがTiProxyとのハンドシェイクに失敗しました + - auth fail: TiDBによってアクセスが拒否されました + - SQL error: TiDB はその他の SQL エラーを返します + - proxy shutdown: TiProxy はシャットダウンしています + - malformed packet: TiProxy は MySQL パケットを解析できません + - get backend fail: TiProxy は接続に利用可能なバックエンドを見つけることができません + - proxy error: その他の TiProxy エラー + - backend network break: TiDBの読み取りまたは書き込みに失敗しました。これは、ネットワークの問題、またはTiDBサーバーのシャットダウンが原因である可能性があります。 + - backend handshake fail: TiProxy が TiDBサーバーとのハンドシェイクに失敗しました +- Goroutine Count: 各 TiProxy インスタンス上の Goroutine の数 +- Owner: 様々なタスクを実行するTiProxyインスタンス。例えば、 `10.24.31.1:3080 - vip`は、 `10.24.31.1:3080`のTiProxyインスタンスが仮想IPにバインドされていることを示します。タスクには以下が含まれます。 - vip: 仮想IPをバインドする - metric_reader: TiDBサーバーから監視データを読み取ります -## クエリサマリー {#query-summary} +## Query-Summary {#query-summary} -- 所要時間: 平均、P95、P99 SQL文の実行時間。TiDBサーバーでのSQL文の実行時間も含まれるため、TiDB Grafanaパネルで表示される時間よりも長くなります。 -- インスタンスごとのP99実行時間: 各TiProxyインスタンスのP99ステートメント実行時間 -- バックエンド別のP99実行時間: 各TiDBインスタンスで実行されるステートメントのP99ステートメント実行時間 -- インスタンスごとの CPS: 各 TiProxy インスタンスの 1秒あたりのコマンド数 -- バックエンド別の CPS: 各 TiDB インスタンスの 1秒あたりのコマンド数 +- Duration: 平均、P95、P99 SQL文の実行時間。TiDBサーバーでのSQL文の実行時間も含まれるため、TiDB Grafanaパネルで表示される時間よりも長くなります。 +- P99 Duration By Instance: 各TiProxyインスタンスのP99ステートメント実行時間 +- P99 Duration By Backend: 各TiDBインスタンスで実行されるステートメントのP99ステートメント実行時間 +- CPS by Instance: 各 TiProxy インスタンスの 1秒あたりのコマンド数 +- CPS by Backend: 各 TiDB インスタンスの 1秒あたりのコマンド数 - CPS by CMD: SQL コマンドの種類別にグループ化された 1秒あたりのコマンド数 -- ハンドシェイク期間: クライアントと TiProxy 間のハンドシェイク フェーズの平均、P95、および P99 期間 +- Handshake Duration: クライアントと TiProxy 間のハンドシェイク フェーズの平均、P95、および P99 期間 -## バランス {#balance} +## Balance {#balance} -- バックエンド接続: 各TiDBインスタンスと各TiProxyインスタンス間の接続数。例えば、 `10.24.31.1:6000 | 10.24.31.2:4000` TiProxyインスタンス`10.24.31.1:6000`とTiDBインスタンス`10.24.31.2:4000`間の接続数を示します。 -- セッション移行OPM: 1分ごとに発生したセッション移行の数。TiDBインスタンスが別のインスタンスに移行したセッションを記録します。たとえば、 `succeed: 10.24.31.2:4000 => 10.24.31.3:4000` TiDBインスタンス`10.24.31.2:4000`からTiDBインスタンス`10.24.31.3:4000`に正常に移行されたセッションの数を示します。 -- セッション移行期間: 平均、P95、P99 セッション移行期間。 -- セッション移行の理由: 1分ごとに発生したセッション移行の数とその理由。理由には以下が含まれます。 +- Backend Connections: 各TiDBインスタンスと各TiProxyインスタンス間の接続数。例えば、 `10.24.31.1:6000 | 10.24.31.2:4000`は、TiProxyインスタンス`10.24.31.1:6000`とTiDBインスタンス`10.24.31.2:4000`間の接続数を示します。 +- Session Migration OPM: 1分ごとに発生したセッション移行の数。TiDBインスタンスが別のインスタンスに移行したセッションを記録します。たとえば、 `succeed: 10.24.31.2:4000 => 10.24.31.3:4000`は、TiDBインスタンス`10.24.31.2:4000`からTiDBインスタンス`10.24.31.3:4000`に正常に移行されたセッションの数を示します。 +- Session Migration Duration: 平均、P95、P99 セッション移行期間。 +- Session Migration Reasons: 1分ごとに発生したセッション移行の数とその理由。理由には以下が含まれます。 - `status` : TiProxy が[ステータスベースの負荷分散](/tiproxy/tiproxy-load-balance.md#status-based-load-balancing)を実行しました。 - `label` : TiProxy が[ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)を実行しました。 - `health` : TiProxy が[ヘルスベースの負荷分散](/tiproxy/tiproxy-load-balance.md#health-based-load-balancing)を実行しました。 @@ -66,16 +66,16 @@ TiProxy には 4つのパネルグループがあります。これらのパネ - `location` : TiProxy が[ロケーションベースの負荷分散](/tiproxy/tiproxy-load-balance.md#location-based-load-balancing)を実行しました。 - `conn` : TiProxy が[接続数ベースの負荷分散](/tiproxy/tiproxy-load-balance.md#connection-count-based-load-balancing)を実行しました。 -## バックエンド {#backend} +## Backend {#backend} -- バックエンド期間の取得: TiProxy が TiDB インスタンスに接続する平均、p95、p99 期間 -- Pingバックエンド期間: 各TiProxyインスタンス間のネットワークレイテンシー。例えば、 `10.24.31.1:6000 | 10.24.31.2:4000` TiProxyインスタンス`10.24.31.1:6000`とTiDBインスタンス`10.24.31.2:4000`間のネットワークレイテンシーを示します。 -- ヘルスチェックサイクル: TiProxyインスタンスとすべてのTiDBインスタンス間のヘルスチェックサイクルの所要時間。例えば、 `10.24.31.1:6000` TiProxyインスタンス`10.24.31.1:6000`すべてのTiDBインスタンスに対して実行する最新のヘルスチェックの所要時間を示します。この所要時間が3秒を超える場合、TiProxyはバックエンドのTiDBリストを適切なタイミングで更新できない可能性があります。 +- Get Backend Duration: TiProxy が TiDB インスタンスに接続する平均、p95、p99 期間 +- Ping Backend Duration: 各TiProxyインスタンス間のネットワークレイテンシー。例えば、 `10.24.31.1:6000 | 10.24.31.2:4000`は、TiProxyインスタンス`10.24.31.1:6000`とTiDBインスタンス`10.24.31.2:4000`間のネットワークレイテンシーを示します。 +- Health Check Cycle: TiProxyインスタンスとすべてのTiDBインスタンス間のヘルスチェックサイクルの所要時間。例えば、 `10.24.31.1:6000`は、TiProxyインスタンス`10.24.31.1:6000`がすべてのTiDBインスタンスに対して実行する最新のヘルスチェックの所要時間を示します。この所要時間が3秒を超える場合、TiProxyはバックエンドのTiDBリストを適切なタイミングで更新できない可能性があります。 -## 渋滞 {#traffic} +## Traffic {#traffic} -- バックエンドからのバイト/秒: 各 TiDB インスタンスから各 TiProxy インスタンスに 1秒あたりに送信されたデータの量 (バイト単位)。 -- バックエンドからのパケット/秒: 各 TiDB インスタンスから各 TiProxy インスタンスに 1秒あたりに送信された MySQL パケットの数。 -- バックエンドへのバイト/秒: 各 TiProxy インスタンスから各 TiDB インスタンスに 1秒あたりに送信されたデータの量 (バイト単位)。 -- バックエンドへのパケット数/秒: 各 TiProxy インスタンスから各 TiDB インスタンスに 1秒あたりに送信される MySQL パケットの数。 -- クロスロケーション バイト/秒: 各 TiProxy インスタンスから異なる場所にある TiDB インスタンスに 1秒あたりに送信されるデータの量 (バイト単位)。 +- Bytes/Second from Backends: 各 TiDB インスタンスから各 TiProxy インスタンスに 1秒あたりに送信されたデータの量 (バイト単位)。 +- Packets/Second from Backends: 各 TiDB インスタンスから各 TiProxy インスタンスに 1秒あたりに送信された MySQL パケットの数。 +- Bytes/Second to Backends: 各 TiProxy インスタンスから各 TiDB インスタンスに 1秒あたりに送信されたデータの量 (バイト単位)。 +- Packets/Second to Backends: 各 TiProxy インスタンスから各 TiDB インスタンスに 1秒あたりに送信される MySQL パケットの数。 +- Cross Location Bytes/Second: 各 TiProxy インスタンスから異なる場所にある TiDB インスタンスに 1秒あたりに送信されるデータの量 (バイト単位)。 diff --git a/tiproxy/tiproxy-load-balance.md b/tiproxy/tiproxy-load-balance.md index 92cd9ca1711a2..59fa1b8d00665 100644 --- a/tiproxy/tiproxy-load-balance.md +++ b/tiproxy/tiproxy-load-balance.md @@ -102,7 +102,7 @@ pd_servers: ## ヘルスベースの負荷分散 {#health-based-load-balancing} -TiProxyは、TiDBサーバーの健全性を判断します。他のサーバーが正常なのに、あるTiDBサーバーの健全性に異常がある場合、TiProxyはそのサーバーから正常なTiDBサーバーへ接続を移行し、自動フェイルオーバーを実現します。 +TiProxyは、エラー数をクエリすることでTiDBサーバーの健全性を判断します。他のサーバーが正常なのに、あるTiDBサーバーの健全性に異常がある場合、TiProxyはそのサーバーから正常なTiDBサーバーへ接続を移行し、自動フェイルオーバーを実現します。 このポリシーは、次のシナリオに適しています。 @@ -111,7 +111,7 @@ TiProxyは、TiDBサーバーの健全性を判断します。他のサーバー ## メモリベースの負荷分散 {#memory-based-load-balancing} -TiProxy は TiDB サーバのメモリ使用量を照会します。TiDBサーバーのメモリ使用量が急増したり、高いレベルに達したりした場合、TiProxy はそのサーバーからメモリ使用量の低い TiDBサーバーに接続を移行し、OOM による不要な接続切断を防止します。TiProxy は、TiDB サーバ間でメモリ使用量が同一であることを保証するものではありません。このポリシーは、TiDBサーバーがOOM の危険にさらされている場合にのみ有効になります。 +TiProxy は TiDB サーバーのメモリ使用量を照会します。TiDBサーバーのメモリ使用量が急増したり、高いレベルに達したりした場合、TiProxy はそのサーバーからメモリ使用量の低い TiDBサーバーに接続を移行し、OOM による不要な接続切断を防止します。TiProxy は、TiDB サーバー間でメモリ使用量が同一であることを保証するものではありません。このポリシーは、TiDBサーバーがOOM の危険にさらされている場合にのみ有効になります。 TiDBサーバーがOOMの危険にさらされている場合、TiProxyはそのサーバーからすべての接続を移行しようとします。通常、OOMの原因が暴走クエリである場合、進行中の暴走クエリは別のTiDBサーバーに移行されて再実行されることはありません。これは、これらの接続はトランザクションが完了した後にのみ移行できるためです。 diff --git a/tiproxy/tiproxy-overview.md b/tiproxy/tiproxy-overview.md index 339df8179882d..02ef393989b92 100644 --- a/tiproxy/tiproxy-overview.md +++ b/tiproxy/tiproxy-overview.md @@ -96,7 +96,7 @@ TiProxyが適しているシナリオではTiProxyを使用し、アプリケー ## インストールと使用方法 {#installation-and-usage} -このセクションでは、 TiUPを使用して TiProxy をデプロイおよび変更する方法について説明します。TiProxy をスケールアウトすることで、 [TiProxyを使用して新しいクラスターを作成します](#create-a-cluster-with-tiproxy)または[既存のクラスターで TiProxy を有効にする](#enable-tiproxy-for-an-existing-cluster)のいずれかを選択できます。 +このセクションでは、 TiUPを使用して TiProxy をデプロイおよび変更する方法について説明します。 [TiProxyを使用して新しいクラスターを作成する](#create-a-cluster-with-tiproxy)か、TiProxyをスケールアウトすることで[既存のクラスターで TiProxy を有効にする](#enable-tiproxy-for-an-existing-cluster)かのいずれかを選択できます。 > **Note:** > @@ -290,7 +290,7 @@ TiProxyは、以下のシナリオでは接続を移行できないため、ク - セッションは[ローカル一時テーブル](/temporary-tables.md#local-temporary-tables)を作成します。 - このセッションでは[ユーザーレベルのロック](/functions-and-operators/locking-functions.md)が行われます。 - このセッションでは[テーブルロック](/sql-statements/sql-statement-lock-tables-and-unlock-tables.md)が行われます。 -- セッションでエラーコード[プリペアドステートメント](/develop/dev-guide-prepared-statement.md)が作成され、プリペアドステートメントが無効になります。たとえば、プリペアドステートメントに関連付けられたテーブルが、プリペアドステートメントの作成後に削除された場合などです。 +- セッションは[プリペアドステートメント](/develop/dev-guide-prepared-statement.md)を作成しますが、そのプリペアドステートメントが無効です。たとえば、プリペアドステートメントに関連付けられたテーブルが、プリペアドステートメントの作成後に削除された場合などです。 - セッションはセッションレベル[実行計画のバインディング](/sql-plan-management.md#sql-binding)を作成しますが、バインディングが無効です。たとえば、バインディングに関連付けられたテーブルは、バインディングが作成された後で削除されます。 - セッションが作成された後、そのセッションで使用されているユーザーが削除されるか、ユーザー名が変更されます。 @@ -302,10 +302,10 @@ TiProxyでは、クライアントが使用するコネクタが[認証プラグ | 言語 | コネクタ | サポートされている最小バージョン | | ---------- | ----------------- | ---------------- | -| Java | MySQL Connector/J | 2019年5月1日 | +| Java | MySQL Connector/J | 5.1.19 | | C | libmysqlclient | 5.5.7 | -| 行く | Go SQLDriver | 1.4.0 | -| JavaScript | MySQLコネクタ/Node.js | 1.0.2 | +| Go | Go SQLDriver | 1.4.0 | +| JavaScript | MySQL Connector/Node.js | 1.0.2 | | JavaScript | mysqljs/mysql | 2.15.0 | | JavaScript | node-mysql2 | 1.0.0-rc-6 | | PHP | mysqlnd | 5.4 | diff --git a/tiproxy/troubleshoot-tiproxy.md b/tiproxy/troubleshoot-tiproxy.md index 2fe3bda505928..6ff8727220fa3 100644 --- a/tiproxy/troubleshoot-tiproxy.md +++ b/tiproxy/troubleshoot-tiproxy.md @@ -25,8 +25,8 @@ summary: TiProxy の一般的な問題、原因、および解決策について 次の手順に従って、問題をトラブルシューティングできます。 -1. [TiProxyの制限](/tiproxy/tiproxy-overview.md#limitations)満たされていないかどうか。TiProxy ログを確認することで、これをさらに確認できます。 -2. [`security.session-token-signing-cert`](/tidb-configuration-file.md#session-token-signing-cert-new-in-v640) [`security.session-token-signing-key`](/tidb-configuration-file.md#session-token-signing-key-new-in-v640) [`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)で正しく構成されているかどうか。 +1. [TiProxyの制限](/tiproxy/tiproxy-overview.md#limitations)が満たされていないかどうか。TiProxy ログを確認することで、これをさらに確認できます。 +2. [`security.session-token-signing-cert`](/tidb-configuration-file.md#session-token-signing-cert-new-in-v640)、 [`security.session-token-signing-key`](/tidb-configuration-file.md#session-token-signing-key-new-in-v640)、 [`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)がTiDBで正しく構成されているかどうか。 ## TiDBサーバーの CPU 使用率が不均衡 {#unbalanced-cpu-usage-on-tidb-server}