TiDB Cloud Lake よくある質問¶
アカウントと Lake DSN¶
TiDB Cloud アカウントがない場合はどうすればよいですか？¶
TiDB Cloud に登録してください。登録と初回認証が完了すると、システムは TiDB Cloud Lake に移動し、Connect が開きます。LakeSQL DSN をコピーした後、Guance に戻って設定を続行してください。
Connect または Lake DSN が見つからない¶
- 現在 TiDB Cloud Lake にアクセスしていることを確認してください。
- Lake ページで Connect を開いてください。
- 接続例で LakeSQL を選択してください。Python、Golang などの他の例はコピーしないでください。
- DSN に Database と
warehouseパラメータの両方が含まれていることを確認してください。
完全な手順はTiDB Cloud に登録して Lake DSN を取得するを参照してください。
Lake DSN の形式が正しくない、または Database、Warehouse を解析できない¶
Connect ページから完全な DSN を再コピーしてください。その内容を手動で削除したり書き換えたりしないでください。形式は次のようになります。
パスワードに特殊文字が含まれる場合は、TiDB Cloud Lake ページで生成された DSN を優先して使用し、手動で結合してエンコーディングエラーが発生しないようにしてください。
接続と認証¶
認証失敗が表示される¶
考えられる原因として、SQL ユーザーまたはパスワードの誤り、パスワードの更新、ユーザーの無効化などがあります。TiDB Cloud Lake でアカウントの状態を確認し、DSN を再取得して、Guance の設定を更新してください。
TiDB Cloud Lake に接続できないと表示される¶
以下を順に確認してください。
- DSN の Endpoint と Port が完全であること。
- 対象の Warehouse が利用可能であること。
- TiDB Cloud Lake サービスが正常であること。
- ネットワークポリシーで Guance サービスが Lake にアクセスできること。
- しばらくしてから接続テストを再実行し、一時的なネットワークまたは Warehouse の利用不可を除外してください。
パスワード変更後に行うべきことは？¶
Lake DSN を再コピーし、古いパスワードを使用しているすべての外部データソースとデータ転送ルールをそれぞれ更新する必要があります。これら 2 つの機能は設定を個別に保存するため、自動的に同期更新されることはありません。
外部データソースとクエリ¶
接続は成功したが、クエリで権限がないと表示される¶
接続が成功したことは、DSN と基本的な接続が有効であることのみを示します。SQL ユーザーが対象の Database、Schema、Table に対する読み取り専用クエリ権限を持っていること、および現在の Guance メンバーがその外部データソースの使用権限を持っていることを確認してください。
クエリデータソース一覧に Lake データソースが表示されない¶
以下を確認してください。
- データソースが保存されており、削除されていないこと。
- 現在のメンバーがそのデータソースの使用権限を持っていること。
- 現在のページが外部データソースクエリをサポートしていること。
- フィルターまたは検索条件でそのデータソースが非表示になっていないこと。
書き込み型 SQL が実行できないのはなぜですか？¶
Lake データを保護するため、外部データソースクエリは単一の読み取り専用 SELECT、WITH ... SELECT、または EXPLAIN のみをサポートします。書き込み、削除、DDL、トランザクション、マルチステートメントはサーバー側で拒否されます。観測データを書き込む必要がある場合は、TiDB Cloud Lake へのデータ転送を使用してください。
クエリがタイムアウトする、または返される数が制限を超える¶
1 回のクエリのデフォルトのタイムアウトは 60 秒で、最大 10,000 行が返されます。時間範囲を狭めたり、WHERE 条件を追加したり、スキャンするテーブルを減らしたり、LIMIT を追加したりしてください。
データ転送¶
接続テストは成功したが、なぜ対象テーブルが作成されないのですか？¶
接続テストでは、Lake DSN、Database、Warehouse、対象テーブルの存在、および関連する書き込み権限またはテーブル作成権限を検証し、対応する確認結果を提供しますが、テーブルは作成されません。対象テーブルが存在しない場合、システムはルールの作成が完了した時点で、現在転送するデータタイプの管理構造に従ってテーブル作成操作を実行します。
接続テストまたはルールの完了時に、書き込み権限またはテーブル作成権限がないと表示される¶
- 対象テーブルが既に存在する場合：SQL ユーザーに対象テーブルへの書き込み権限が必要です。
- 対象テーブルが存在しない場合：SQL ユーザーに対象 Database でテーブルを作成する権限も必要です。
権限を調整した後、接続テストを再実行し、ルールの作成を完了してください。
対象テーブルの書き込み権限またはテーブル構造のチェックが失敗した場合、またはシステムが対象テーブルの作成に失敗した場合でも、ルールは有効になり、ルール一覧に【！】のヒントが表示されます。ヒントに従って、権限、テーブル構造、またはテーブル作成の問題を修正し、後続のバッチが対象テーブルに書き込めるようにしてください。
対象テーブルの構造が互換性がないと表示される¶
既存の対象テーブルは、現在転送するデータタイプのシステム管理構造と互換性がある必要があります。新しいテーブル名を使用して、ルールの作成が完了したときにシステムが自動的に作成できるようにすることをお勧めします。既存のテーブルを使用する必要がある場合は、エラーヒントに従ってテーブル構造を調整してください。
ルールは有効になっているが、しばらくデータが確認できない¶
データ転送は、選択したデータ待機時間に従って Parquet Batch をファイル化し、Lake にロードするため、1 件ずつリアルタイムで書き込まれるわけではありません。以下を確認してください。
- ルールのデータタイプとフィルター条件に一致するデータがあるかどうか。
- 選択した 15 分、30 分、または 1 時間の待機時間を超えているかどうか。
- ルールとロードバッチに失敗が表示されていないかどうか。
- 使用するクエリの Database と Target Table がルールと一致しているかどうか。
Bucket、ストレージパス、IAM クレデンシャルを入力する必要がないのはなぜですか？¶
TiDB Cloud Lake 転送では、Guance が管理する中間ストレージとオブジェクトパスを使用します。ユーザーは Lake DSN と Target Table を提供するだけでよく、Bucket、オブジェクトパス、中間アクセスクレデンシャルはシステムによって管理されます。
セキュリティ調査¶
問題を報告する際にどのような情報を提供できますか？¶
以下を提供できます。
- データソース名または転送ルール名。
- マスクされた Endpoint、Database、Warehouse、Target Table。
- 失敗時刻、エラーコード、ページのエラーメッセージ。
- SQL フィンガープリント、または機密条件を除去した後のクエリ構造。
完全な Lake DSN、SQL ユーザーパスワード、内部 Bucket、一時クレデンシャル、または機密データを含む完全なクエリ結果は提供しないでください。