استخدام Phoenix مع ClickHouse Managed Postgres

​

المتطلبات الأساسية

• Elixir 1.15 أو إصدار أحدث، بالإضافة إلى Erlang/OTP. اختُبر هذا الدليل باستخدام Elixir 1.20.4 وErlang/OTP 29 وPhoenix 1.8.15 وecto_sql 3.14.0 وPostgrex 0.22.4.
• حساب على ClickHouse Cloud

​

إنشاء خدمة ClickHouse Managed Postgres

​

الحصول على بيانات الاتصال

​

إنشاء تطبيق Phoenix

mix archive.install hex phx_new
mix phx.new hello --install
cd hello

​

تهيئة اتصال قاعدة البيانات

mv ~/Downloads/your-service-ca-certificate.pem priv/ca-certificate.pem

config :hello, Hello.Repo,
  url: System.get_env("DATABASE_URL"),
  ssl: [cacertfile: Path.expand("../priv/ca-certificate.pem", __DIR__)],
  stacktrace: true,
  show_sensitive_data_on_connection_error: true,
  pool_size: 10

export DATABASE_URL="postgresql://postgres:<PASSWORD>@your-instance.pg.clickhouse.cloud:5432/guide_phoenix"

mix ecto.create

The database for Hello.Repo has been created

​

إنشاء مورد JSON وتشغيل الترحيل

mix phx.gen.json Todos Todo todos title:string done:boolean

  scope "/api", HelloWeb do
    pipe_through :api

    resources "/todos", TodoController, except: [:new, :edit]
  end

mix ecto.migrate

14:54:14.507 [info] == Running 20261001145404 Hello.Repo.Migrations.CreateTodos.change/0 forward
14:54:14.507 [info] create table todos
14:54:14.601 [info] == Migrated 20261001145404 in 0.0s

​

التشغيل والتحقق

mix run -e 'IO.inspect(Hello.Repo.query!("SELECT ssl, version, cipher FROM pg_stat_ssl WHERE pid = pg_backend_pid()").rows)'

[debug] QUERY OK db=43.9ms decode=2.0ms queue=646.0ms idle=0.0ms
SELECT ssl, version, cipher FROM pg_stat_ssl WHERE pid = pg_backend_pid() []
[[true, "TLSv1.3", "TLS_AES_256_GCM_SHA384"]]

PORT=3116 mix phx.server

[info] Access HelloWeb.Endpoint at http://localhost:3116

curl -X POST http://localhost:3116/api/todos -H "Content-Type: application/json" -d '{"todo": {"title": "Try Phoenix"}}'
curl -X POST http://localhost:3116/api/todos -H "Content-Type: application/json" -d '{"todo": {"title": "Write a migration"}}'
curl -X PATCH http://localhost:3116/api/todos/1 -H "Content-Type: application/json" -d '{"todo": {"done": true}}'
curl -X DELETE http://localhost:3116/api/todos/2

{"data":{"id":1,"done":true,"title":"Try Phoenix"}}

{"data":[{"id":1,"done":true,"title":"Try Phoenix"}]}

​

تهيئة بيئة الإنتاج

  config :hello, Hello.Repo,
    ssl: [cacertfile: Application.app_dir(:hello, "priv/ca-certificate.pem")],
    url: database_url,
    pool_size: String.to_integer(System.get_env("POOL_SIZE") || "10"),
    # For machines with several cores, consider starting multiple pools of `pool_size`
    # pool_count: 4,
    socket_options: maybe_ipv6

  config :hello, Hello.Repo,
    url: System.fetch_env!("DATABASE_URL"),
    ssl: [cacertfile: Application.app_dir(:hello, "priv/ca-certificate.pem")],
    pool_size: String.to_integer(System.get_env("POOL_SIZE") || "10")

​

استخدام PgBouncer

config :hello, Hello.Repo,
  url: System.get_env("DATABASE_URL"),
  ssl: [cacertfile: Path.expand("../priv/ca-certificate.pem", __DIR__)],
  prepare: :unnamed,
  stacktrace: true,
  show_sensitive_data_on_connection_error: true,
  pool_size: 10

• العبارات المُحضَّرة: افتراضيًا، يُنفّذ Ecto كل استعلام بوصفه عبارة مُحضَّرة مسمّاة، ويدعم PgBouncer المرفق العبارات المسمّاة. ويحرّر Postgrex العبارات برسالة Close على مستوى البروتوكول، ولا يستخدم عبارة SQL DEALLOCATE إطلاقًا. ومع ذلك، تظهر مشكلتان عبر PgBouncer عند استخدام الإعداد الافتراضي prepare: :named:
  • قد يتوقف استعلام يبلغ طول نص SQL الخاص به نحو 4 KB عن الاستجابة إلى أن تنتهي مهلته، فيتلقى المستدعي الخطأ DBConnection.ConnectionError بعد دقيقة تقريبًا.
  • بعد أن يغيّر ترحيلٌ نوعَ أحد الأعمدة، تظل الاستعلامات التي تقرأ هذا العمود تفشل مع الخطأ cached plan must not change result type، حتى بعد إعادة تشغيل التطبيق، لأن PgBouncer يعيد استخدام عبارته المُحضَّرة على الخادم.
  أما مع prepare: :unnamed، فيُحضّر Postgrex كل استعلام من جديد في كل مرة يُنفَّذ فيها، فتزول المشكلتان كلتاهما، مقابل رحلة ذهاب وإياب إضافية واحدة عبر الشبكة لكل استعلام.
• الترحيلات: يعمل mix ecto.migrate عبر PgBouncer باستخدام قفل الترحيل الافتراضي في Ecto، الذي يقفل الجدول schema_migrations داخل معاملة. لا تضبط migration_lock: :pg_advisory_lock لاتصال PgBouncer؛ إذ قد يُحرَّر القفل الاستشاري على مستوى الجلسة عبر اتصال Postgres مختلف، فيفشل ذلك مع الخطأ failed to release advisory lock ويبقى القفل محتجزًا، فتظل عمليات التشغيل اللاحقة تنتظره، بما فيها تلك التي تجري على المنفذ 5432. ولتشغيل الترحيلات عبر الاتصال المباشر، اضبط للأمر mix ecto.migrate قيمة DATABASE_URL تستخدم المنفذ 5432.
• حالة الجلسة: لا تسري عبارات SET، مثل SET search_path في دالة رد النداء after_connect، إلا على اتصال Postgres الخاص بالمعاملة الحالية. ويؤدي تحديد search_path في الخيار parameters الخاص بـ Postgrex إلى الفشل مع الخطأ unsupported startup parameter: search_path. أما LISTEN وNOTIFY، اللذان يستخدمهما Postgrex.Notifications، فيتطلبان اتصالًا مباشرًا.

​

استكشاف الأخطاء وإصلاحها

• CLIENT ALERT: Fatal - Unknown CA: لا يشير cacertfile إلى شهادة CA الخاصة بخدمتك، أو أنك ضبطت ssl: true. نزّل الشهادة مجددًا من Settings → CA Certificate، علمًا بأن لكل خدمة شهادة CA خاصة بها.
• CLIENT ALERT: Fatal - Bad Certificate مع hostname_check_failed: المضيف المحدد في DATABASE_URL لا يطابق شهادة الخادم، كأن تكون قد استخدمت عنوان IP مثلًا. استخدم اسم المضيف الظاهر في النافذة المنبثقة Connect.
• Invalid CA certificate file ... no such file or directory: مسار cacertfile غير صحيح. تحقّق من وجود الملف priv/ca-certificate.pem.

​

الخطوات التالية

• الاتصال: سلاسل الاتصال وPgBouncer وTLS
• الإعدادات: معلمات Postgres وPgBouncer، مثل max_connections
• النسخ المتماثلة للقراءة: وجّه عمليات القراءة إلى نسخة متماثلة باستخدام مستودعات النسخ المتماثلة في Ecto
• المزامنة مع ClickHouse: انسخ جداول Phoenix إلى ClickHouse لإجراء التحليلات