i18n(ja): fix severe false-friend mistranslations in tiproxy and faq

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}
 

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}
 

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}
 

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を超えてしまいます。