注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
このページでは、Syncsに関するいくつかの一般的な問題とデバッグの手順について説明します。
PKIX例外やその他のSSLHandshakeExceptionは、エージェントが正しい証明書を持っておらず、そのためにソースと認証できない場合に発生します。正しい証明書がインストールされていることを確認するには、Data Connectionと証明書のドキュメントを参照してください。
同期がResponse 421 received. Server closed connectionというエラーで失敗した場合、サポートされていないSSLプロトコル/ポートの組み合わせで接続している可能性があります。たとえば、ポート991を使用した暗黙的FTPSは、古くてサポートされていない標準です。この場合、ポート21を使用した明示的SSLが推奨されます。
同期がFTP/S同期の場合、エグレスプロキシロードバランサーを使用していないことを確認してください。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)というエラーで失敗する場合、エグレスプロキシを通過する際にエラーが発生していることを意味します。このエラーが発生した場合、以下のシナリオが適用されるかどうかを確認してください。
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
ソースシステムに対して実行された正確なクエリを確認するには、_data-ingestion.logを参照してください。
同期が増分同期である場合、単調増加する列（たとえば、タイムスタンプやID）とこの列の初期値を提供したことを確認してください。
増分列を選択したら、同期設定ページのSQLクエリに?演算子を追加する必要があります（?は「増分」値に置き換えられ、単一の?のみ使用可能です）。たとえば、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値が同期されると、現在の状態が同期された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 / ディレクトリ / 同期：フェッチ段階でのハング
ファイルベースの同期がフェッチ段階でハングする最も一般的な理由は、エージェントが大規模なファイルシステムをクロールしているためです。
ファイルシステムをクロールする同期は、完全なクロールを2回行います（別途設定されていない限り）。これは、同期が現在書き込み中または何らかの方法で変更されているファイルをアップロードしないようにするためです。
REQUEST_ENTITY_TOO_LARGEエラーで同期が失敗する場合大きなファイルのダウンロード、処理、アップロードはエラーが発生しやすく、遅くなります。REQUEST_ENTITY_TOO_LARGEサービス例外は、個々のファイルがエージェントのアップロード先に設定された最大サイズを超えた場合に発生します。data-proxyアップロード戦略では、これがデフォルトで100GBに設定されています。
この制限を上書きすることは推奨されません。可能であれば、このデータに小さなファイルのコレクションとしてアクセスする方法を見つけてください。ただし、一時的な回避策としてこの制限を上書きする場合は、以下の手順を使用します。
Data Connection内でエージェントに移動し、Advanced構成タブを選択します。
「エージェント」タブを選択します。
destinationsブロックに次の設定を含めて、制限を150Gbに引き上げます。
Copied!1 2 3uploadStrategy: type: data-proxy maximumUploadedFileSizeBytes: 161061273600
BadPaddingExceptionエラーで同期が失敗する場合BadPaddingException例外は、エージェントに保存されているソース資格情報の暗号化キーが予期されるものと一致しないために発生します。これは通常、エージェントマネージャーが手動でアップグレードされ、古い/var/dataディレクトリが新しいインストール場所にコピーされていない場合に発生します。
これを解決する最も簡単な方法は、影響を受けたエージェントを使用している各ソースの資格情報を再入力することです。
JDBCソースから行が同期され、それらがタイムスタンプ列を含む場合、それらのタイムスタンプ列はFoundryでLong列にキャストされます。この動作は後方互換性のために存在します。
これらの列のデータ型を修正するには、このクリーニングを実行するために[Python
Copied!1 2# データフレームの"mytimestamp"カラムの値を1000で割り、タイムスタンプ型に変換して新しいカラム"mytimestamp"に格納します。 df = df.withColumn("mytimestamp", (F.col("mytimestamp") / 1000).cast("timestamp"))