問題が起きたとき

パイプラインは正常終了したのにデータレイクが空

最もよくある症状で、ほとんどの場合はエラーではなく設定の問題です。

設定が不足していてもパイプラインは失敗しません。 データベースが選択されていない場合でも、スナップショットはエクスポートされ、Parquet は S3 に届き、コピージョブはそれらを黙って無視します。

可能性の高い順に挙げます。

原因	確認方法
データベースが 1 つも選択されていない	コンソールの概要画面に警告が表示されます
クラスターに新しいデータベースが現れた	同上。データベース名付きで表示されます
スナップショットイベントが無効	同上。この場合はエクスポートすら実行されません
テーブルのフィルターですべて除外された	Bancos（データベース）で選択済みのテーブル数を確認します

コピージョブのログにも、無視された内容が記録されます。

IGNORADO: 56 arquivos do banco "pagila" -- ele nao esta marcado
para ingestao, entao nada dele chega ao datalake.

テーブルがデータレイクから消えた

存在していたテーブルが表示されなくなった場合は、Partições（パーティション）でそのテーブルに対して 直接コピーを置き換える が有効かつパーティションが無効になっている設定がないか確認してください。この組み合わせでは、コピーはそのテーブルをスキップし、パーティショナーも実行されないため、誰も書き込みません。

パーティションを有効に戻すか、「直接コピーを置き換える」を無効にすれば解決します。

実行が失敗した

Execuções（実行履歴）で該当の実行を開くと、各ステップが順に表示されます。失敗したステップにはエラーメッセージとログが含まれます。

よくある原因は次のとおりです。

パーティション処理でのメモリ不足 — パーティションカラムの異なる値が非常に多いテーブルです。何階層まで使うかをご覧ください。
クロスアカウントの権限 — クロスアカウント構成のステップ 3 を実施していないと、エクスポートがバケットへの書き込みで失敗します。
タイムアウト — 各ジョブの上限は 1 時間です。ソートを設定した非常に大きなテーブルが最も疑わしい原因です。

1 つのテーブルが失敗しても他は巻き添えになりません。パイプラインはパーティション処理の個別の失敗を許容し、クローラーは書き込まれたものをカタログ化します。

スキーマに見慣れないカラムがある

1、2、3 といった値を持つ partition_0 カラムが現れる場合、RDS のパートディレクトリを平坦化するより前のバージョンがインストールされています。パッケージを更新して再処理してください。

同じ行が 2 回現れる

考えられる原因は 2 つです。

Postgres でパーティション化されたテーブル。 RDS は親テーブルと各子パーティションをエクスポートします。現行バージョンは子テーブルを検出して無視します。payment の隣に payment_p2024_01 のようなテーブルが見える場合は、パッケージを更新してください。

「直接コピーを置き換える」が無効なパーティション。 デフォルトでは、パーティション化されたテーブルは意図的に 2 回現れます。テーブル全体のコピーとパーティション化されたものです。パーティション化されたものだけが必要な場合は、このオプションを有効にします。

ログインできない

Cognito は localhost を除き、http のコールバック URL を拒否します。コンソールが http で応答している場合、ログインは始まる前に失敗します。setup-https.sh を実行してください。

証明書が信頼できないとブラウザーが警告する場合、それは自己署名証明書です。動作はしますが、警告をなくすには CERTIFICATE_ARN で独自の証明書を指定してください。

コンソールに到達できない

ロードバランサーは意図的に内部です。コンソールはインターネットに公開されません。 VPC 内から、VPN 経由で、または Session Manager のトンネル経由でアクセスします。

どのバージョンがその結果を生成したか調べる

各ジョブは起動時に自身のバージョンを記録し、実行がそれを保持します。 Execuções（実行履歴）の詳細に各コンポーネントのバージョンが表示されます。更新の前後で挙動が変わった場合に役立ちます。