注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
このページでは、Syncsのいくつかの一般的な問題とデバッグ手順を説明しています。
PKIX例外やその他のSSLHandshakeExceptionは、エージェントが正しい証明書を持っていないため、ソースとの認証ができないと発生します。正しい証明書がインストールされていることを確認するには、Data Connectionと証明書のガイドに従ってください。
同期がエラーResponse 421 received. Server closed connectionで失敗した場合、サポートされていないSSLプロトコル/ポートの組み合わせで接続している可能性があります。例として、古くてサポートされていない標準であるポート991の暗黙的なFTPSがあります。この場合、ポート21の明示的なSSLが推奨されます。
同期がFTP/S同期の場合、egressプロキシロードバランサーを使用していないことを確認してください。FTPはステートフルなプロトコルであるため、ロードバランサーを使用すると、連続したリクエストが同じIPから発信されないため、同期が失敗する可能性があります。
ロードバランシングの性質上、失敗は非決定的であり、ロードバランシングプロキシが存在しても、同期やプレビューが時々成功することがあります。
同期や探索がエラー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)で失敗した場合、これはコマンドがegressプロキシを通過する際にエラーが発生していることを意味します。このエラーが発生した場合、以下のシナリオのいずれかが適用されるかどうかを確認してください。
S3ソースproxyConfigurationブロックに以下を追加します。
Copied!1 2 3 4host: <deployment gatewayまたは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
ソースシステムに対して実行された正確なクエリを確認するには、_data-ingestion.logを参照してください。
同期がインクリメンタル同期の場合、単調増加する列（例：タイムスタンプまたはID）と、この列の初期値を指定していることを確認してください。
インクリメンタル列を選択したら、同期設定ページのSQLクエリに?演算子を追加して、'incremental'値と置き換える必要があります（?は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のように書き換えることでエラーを回避できます。同期で使用するインクリメンタル列を変更したい場合は、新しい同期を作成することをお勧めします。
エージェントホスト上で、<bootvisor-directory>/var/data/processesディレクトリでls -lrtを実行して、最も最近に作成されたbootstrapper~<uuid>ディレクトリを見つけます。
cdして、/var/log/に移動します。magritte-agent-output.logの内容を確認します。エラーOutOfMemory Exceptionが表示される場合、エージェントが割り当てられたワークロードを処理できないことを意味します。
以下は、ハングアップする同期の一般的な原因とそれに対応する修正です。
すべての同期：フェッチステージでハングアップ
同期がフェッチステージでハングアップしている場合、ソースが利用可能であり、操作が可能であることを確認してください。
JDBC同期：フェッチステージでハングアップ
同期がフェッチステージの完了に予想よりも時間がかかっている場合、これはエージェントが多数のネットワークおよびデータベース呼び出しを行っているためです。同期中に行われるネットワークおよびデータベース呼び出しの数を調整するには、「Fetch Size」パラメータを変更できます。
Fetch Sizeパラメータは、ソース設定の「詳細オプション」セクションにあり、指定されたクエリのデータベースのラウンドトリップごとにフェッチされる行の数を定義します。従って：
Fetch Sizeパラメータを減らすと、データベースへの呼び出しごとに返される行が少なくなり、より多くの呼び出しが必要になります。ただし、これによりエージェントはより少ないメモリを使用することになります。なぜなら、一度にエージェントのヒープに格納される行が少なくなるからです。Fetch Sizeパラメータを増やすと、データベースへの呼び出しごとに返される行が多くなり、呼び出しが少なくて済みます。ただし、これによりエージェントはより多くのメモリを使用することになります。なぜなら、一度にエージェントのヒープに格納される行の数が多くなるからです。Fetch Size：500から始めて調整することをお勧めします。JDBC同期：アップロードステージでハングアップ
同期がファイルのアップロードに時間がかかっているか、アップロードステージで失敗している場合、ネットワークリンクに過負荷がかかっている可能性があります。この場合、「Max file size」パラメータを調整することをお勧めします。
Max file sizeパラメータは、ソース設定の「詳細オプション」セクションにあり、Foundryにアップロードされる出力ファイルの最大サイズ（バイトまたは行）を定義します。従って：
Max file sizeパラメータを減らすと、ネットワーク上でより小さいファイルが頻繁にアップロードされるため、ネットワークにかかる負荷が増加します。ただし、ファイルのアップロードが失敗した場合、再アップロードのコストが低くなります。Max file sizeパラメータを増やすと、合計帯域幅が少なくて済むようになりますが、アップロードが失敗する可能性が高くなります。Max file size：120mbをお勧めします。FTP / SFTP / Directory /同期：フェッチステージでハングアップ
ファイルベースの同期がフェッチステージでハングアップする最も一般的な理由は、エージェントが大規模なファイルシステムをクロールしているためです。
ファイルシステムをクロールする同期は、ファイルシステムを2回完全にクロールします（他に設定されていない場合）。これは、同期が現在書き込まれているか、何らかの方法で変更されているファイルをアップロードしないようにするためです。
REQUEST_ENTITY_TOO_LARGE エラーで失敗した場合大きなファイルのダウンロード、処理、およびアップロードはエラーが発生しやすく、遅くなります。REQUEST_ENTITY_TOO_LARGEサービス例外は、個々のファイルがエージェントのアップロード先で設定された最大サイズを超えている場合に発生します。data-proxyアップロード戦略では、これはデフォルトで100GBに設定されています。
この制限を無視することはお勧めしません。可能であれば、より小さなファイルのコレクションとしてこのデータにアクセスする方法を見つけてください。ただし、一時的な回避策としてこの制限を上書きしたい場合は、次の手順を使用してください。
Data Connectionで、エージェントに移動し、詳細設定タブを選択します。
"Agent"タブを選択します。
destinationsブロックの下に、以下を含めて制限を150Gbに増やします。
Copied!1 2 3uploadStrategy: type: data-proxy maximumUploadedFileSizeBytes: 161061273600
BadPaddingExceptionエラーで失敗した場合BadPaddingException例外は、エージェント内に保存されたソース資格情報の暗号化キーが期待されたものではないために発生します。これは、エージェントマネージャが手動でアップグレードされたが、古い/var/dataディレクトリが新しいインストール先にコピーされなかった場合によく発生します。
これを解決する最も簡単な方法は、影響を受けるエージェントを使用している各ソースの資格情報を再入力することです。
JDBCソースから行が同期され、タイムスタンプ列が含まれている場合、それらのタイムスタンプ列はFoundry内でlong列にキャストされます。この動作は、後方互換性の理由から存在します。
これらの列のデータ型を修正するために、Python Transform環境を使用してこのクリーニングを実行することをお勧めします。以下は、列"mytimestamp"をタイムスタンプ形式に戻す例のコードスニペットです：
Copied!1 2# データフレームの"mytimestamp"カラムの値を1000で割り、タイムスタンプ型に変換して新しいカラム"mytimestamp"に格納します。 df = df.withColumn("mytimestamp", (F.col("mytimestamp") / 1000).cast("timestamp"))