概要
首題のとおり。
ここにたどり着く人はどはまりしてどうしようもなくなって泣きながらたどり着いてるだろうから細かい説明は省き、正解と決め台詞だけ書きます。
現在の時刻は 2024-02-23 11:24 JST
で後々こっそり修正が入るかもしれません特に前提の2
説明
- password_encriptionがmd5の状態で作成されたUSER(ROLE)であること
- Glue, ConnectionsのDriverをS3から読み込む部分はバグってるかなんなのかわからんけど有効ではないため後述のコードでカバーする
- (未確認だけど要素として記載) accepted_password_auth_method が md5+scram であること、少なくともscramの単体ではないこと
1の解説
たとえばPostgreSQL 13 以前のRDSからバージョンアップしてきた古参の USER はパスワードが md5 で保存されているためにGlueから利用できる。
PostgreSQL 15以降はpassword_encryption が scram-sha-256
(おそらくデフォルト値がこれ)であるためその状態で作成されたユーザはGlueから接続するとfailする。
対策としてGlueからアクセスしたいユーザがある場合は psql などで password_encryption を md5に設定したうえで CREATE ROLE すること。
pgsql15db=> show password_encryption ;
password_encryption
---------------------
scram-sha-256
(1 row)
pgsql15db=> set password_encryption = 'md5';
SET
pgsql15db=> show password_encryption ;
password_encryption
---------------------
md5
(1 row)
CREATE ROLE ...;
2に対する対策のコード
AWSのバグかなにかではないかと…。
タチガワルイことに何事もなかったかのようにデフォルトで用意してあるクソ古いjarを噛ませてくるから問題の解析をややこしくしている。
Connection設定のUIにて異なるバージョンのpostgres jdbc driver のjarファイルを噛ませているがstack traceが行数含めて全く変わらなくて、なにか別なjarを参照しているのでは?という疑惑を持つ。
試しに手元でpgsqlのドライバをビルドして配置しても変わらなかったのでしこたまデバッグメッセージを仕込む。
ある段階でpythonのコードにjarの配置箇所を記述することでやっと別なjarを利用できることに気づく。
customJdbcDriverS3Path と customJdbcDriverClassName.
PostgreSQL_node1 = glueContext.create_dynamic_frame.from_options(
connection_type="postgresql",
connection_options={
"useConnectionProperties": "true",
"connectionName": "Postgresql connection",
"dbtable": "tbl_xxxxx_xxxxx",
"customJdbcDriverS3Path": "s3://****test-bucket/postgresql-42.7.0-SNAPSHOT.jar",
"customJdbcDriverClassName": "org.postgresql.Driver",
},
transformation_ctx="PostgreSQL_node1",
)
これによって以後デバッグが効くようになり、問題の解析につながった。
3の説明
バージョンアップしたインスタンスであり、最初から md5+scram であったため検証はしていなくて試せていないけれど、絶対関係あるのでパラメータをチェックしてほしい。
決め台詞
お前の前にいるのは、20年以上生きたJava使いだ。
ありがとう