注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
このページでは、同期でよく発生する問題と、そのデバッグ手順について説明します。
PKIX および SSLHandshakeException エラーを含む、証明書と TLS のトラブルシューティングについては、証明書と TLS を参照してください。
同期が Response 421 received. Server closed connection エラーで失敗する場合、サポートされていない SSL プロトコルとポートの組み合わせで接続している可能性があります。たとえば、ポート991での暗黙的 FTPS は、古く、サポートされていない標準です。この場合は、ポート21での明示的 SSL が推奨されます。
FTP/S 同期の場合は、エグレスプロキシのロードバランサーを使用していないことを確認してください。FTP はステートフルなプロトコルのため、ロードバランサーを使用すると、連続するリクエストの送信元 IP が同じでない場合に同期に失敗することがあります。
負荷分散の性質上、失敗は非決定論的に発生します。負荷分散プロキシが配置されていても、同期やプレビューに成功することがあります。
また、HTTP プロキシは FTP および FTPS のアクティブモード転送をサポートしていません。アクティブモードでは FTP サーバーからクライアントに接続する必要がありますが、HTTP プロキシを介してこの接続を行うことはできません。FTP/FTPS 接続で HTTP プロキシを使用する場合、パッシブモード転送のみがサポートされます。HTTP プロキシ経由で接続する場合は、FTP ソースがパッシブモードを使用するように設定されていることを確認してください。
同期または探索が com.amazonaws.services.s3.model.AmazonS3Exception:Forbidden (Service: Amazon S3; Status Code: 403; Error Code: 403 Forbidden; Request ID: null; S3 Extended Request ID: null) エラーで失敗する場合、コマンドがエグレスプロキシを通過する際にエラーが発生していることを意味します。このエラーが発生した場合は、次のいずれかに該当するかどうかを確認してください。
S3 ソースの proxyConfiguration ブロックに、次を追加します。
Copied!1 2 3 4host: <address of deployment gateway or egress NLB> port: 8888 protocol: http nonProxyHosts: <bucket>.s3.<region>.amazonaws.com,s3.<region>.amazonaws.com,s3-<region>.amazonaws.com
例：すべての VPC バケットを許可リストに登録するには、次の設定を追加します。
Copied!1 2 3 4 5 6clientConfiguration: proxyConfiguration: host: <color>-egress-proxy.palantirfoundry.com port: 8888 protocol: http nonProxyHosts: *.s3.<region>.amazonaws.com, s3.<region>.amazonaws.com, s3-<region>.amazonaws.com
同期または探索が Could not list objects in bucket エラーで失敗する場合、リージョンと署名リージョンの両方が設定されているかどうかを確認してください。両方の値を設定すると、このエラーが発生することがあります。問題を解決するには、署名リージョンのみを設定します。
ソースシステムに対して実行された正確なクエリを確認するには、_data-ingestion.log を参照してください。
インクリメンタル同期の場合は、単調増加する列（たとえば、タイムスタンプや ID）と、その列の初期値が指定されていることを確認してください。
インクリメンタル列を選択したら、同期設定ページの SQL クエリに ? 演算子を追加していることを確認する必要があります（? はインクリメンタル値に置き換えられ、使用できる ? は1個のみです）。たとえば、SELECT * FROM table WHERE id > ? です。
同期済みデータセットに行が不足している、または以前に同期した行が正しく更新されていないと思われる場合は、次を確認してください。
ID を使用していて、前回の同期で最後に同期された ID の値が10だった場合、その後で ID が5の行を追加しても、ID が5の行は同期されません。既存の行が再同期されていると思われる場合は、次を確認してください。
LONG または STRING（ISO-8601 形式）にキャストする必要があります。インクリメンタル同期で NullPointerException がスローされる場合、SQL クエリが、インクリメンタル列に null 値が含まれる行をデータベースから取得している可能性があります。
SELECT * FROM table WHERE col > ? OR timestamp > 1 を考えます。ここで、col は同期に使用されるインクリメンタル列です。OR を使用しているため、このクエリでは col に null 以外の値のみが含まれることは保証されません。いずれかの行で col の null 値が同期されると、Data Connection が同期のインクリメンタル状態を更新しようとした際に、現在の状態が同期された null 値と比較されてエラーがスローされるため、同期に失敗します。SELECT * FROM table WHERE (col > ? OR timestamp > 1) AND col IS NOT NULL のように書き換えることでエラーを回避できます。同期に使用するインクリメンタル列を変更する場合は、新しい同期を作成することを推奨します。
Agent ホストの <bootvisor-directory>/var/data/processes ディレクトリで ls -lrt を実行し、最も新しく作成された bootstrapper~<uuid> ディレクトリを探します。
cd でそのディレクトリに移動し、/var/log/ に移動します。magritte-agent-output.log の内容を確認します。OutOfMemory Exception エラーが表示される場合、Agent が割り当てられたワークロードを処理できないことを意味します。
同期が停止する一般的な原因と、それぞれの対処方法を以下に示します。
すべての同期：取得段階での停止
同期が取得段階で停止している場合は、ソースが利用可能であり、正常に動作しているかを確認します。
JDBC 同期：取得段階での停止
同期の取得段階が完了するまでに予想より時間がかかっている場合、Agent が大量のネットワーク呼び出しとデータベース呼び出しを行っていることが原因かもしれません。同期中に行われるネットワーク呼び出しとデータベース呼び出しの回数を調整するには、フェッチサイズパラメーターを変更できます。
JDBC 同期：アップロード段階での停止
同期でファイルのアップロードに時間がかかっている場合や、アップロード段階で失敗する場合は、ネットワークリンクに過剰な負荷がかかっている可能性があります。この場合、最大ファイルサイズパラメーターの調整を推奨します。
FTP / SFTP / ディレクトリ / 同期：取得段階での停止
ファイルベースの同期が取得段階で停止する最も一般的な原因は、Agent が大規模なファイルシステムをクロールしていることです。
ファイルシステムをクロールする同期では、別途設定しない限り、ファイルシステム全体を2回クロールします。これは、書き込み中のファイルや、何らかの変更が加えられているファイルを同期でアップロードしないようにするためです。
ファイルベースの同期はトランザクションとして処理されます。同期の途中で失敗すると、トランザクションは中止され、その実行で処理されたファイルはどれもデータセットにコミットされません。たとえば、100万個のファイルをアップロードするように同期が設定されており、最後の1個を除くすべてのファイルをアップロードした後にネットワークエラーが発生すると、トランザクション全体が中止されます。アップロード済みのファイルはどれもコミットされず、データセットのビューは変更されません。
このようなトランザクション動作のため、1回の実行で大量のファイルを処理する同期は、一時的なネットワークの問題やソースシステムの問題の影響を受けやすくなります。同期の失敗による影響を軽減するには、以下の方法を使用します。
SNAPSHOT 同期の代わりにインクリメンタル APPEND 同期を使用します。こうすることで、失敗した場合でも、すべてのファイルではなく現在のバッチのみを再同期すれば済みます。
詳しくは、同期失敗時の動作とファイルベースの同期を最適化するを参照してください。
REQUEST_ENTITY_TOO_LARGE エラーで失敗する場合大きなファイルのダウンロード、処理、アップロードは、エラーが発生しやすく、時間がかかります。個々のファイルが Agent のアップロード先に設定された最大サイズを超えると、REQUEST_ENTITY_TOO_LARGE サービス例外が発生します。data-proxy アップロード方式では、デフォルトで100 GBに設定されています。
制限のオーバーライドは推奨しません。可能であれば、このデータを小さなファイルに分割してアクセスする方法を探してください。ただし、一時的な回避策としてこの制限をオーバーライドする場合は、以下の手順を使用します。
Data Connection で Agent に移動し、詳細設定の設定タブを選択します。
「Agent」タブを選択します。
destinations ブロックに以下を追加して、制限を150 Gbに増やします。
Copied!1 2 3uploadStrategy: type: data-proxy maximumUploadedFileSizeBytes: 161061273600
BadPaddingException エラーで失敗する場合BadPaddingException 例外は、Agent 内に保存されているソースの資格情報の暗号化キーが、期待されるものと異なるために発生します。これは通常、Agent マネージャーを手動でアップグレードした際に、古い /var/data ディレクトリを新しいインストール場所にコピーしなかった場合に発生します。
最も簡単な解決方法は、影響を受ける Agent を使用しているソースごとに資格情報を再入力することです。
JDBC ソースから同期される行にタイムスタンプ列が含まれている場合、そのタイムスタンプ列は Foundry で Long 列にキャストされます。この動作は下位互換性を維持するためのものです。
これらの列のデータ型を修正するには、Python トランスフォーム環境を使用して、このクレンジングを行うことを推奨します。以下は、列 "mytimestamp" をタイムスタンプ形式に戻すコードスニペットの例です。
Copied!1df = df.withColumn("mytimestamp", (F.col("mytimestamp") / 1000).cast("timestamp"))