المراقبة والمقاييس
كيف يمكنني الوصول إلى المقاييس الخاصة بمثيل ClickHouse Managed Postgres لدي؟
يمكنك مراقبة استخدام CPU والذاكرة وIOPS والتخزين مباشرةً من ClickHouse Cloud console، ضمن علامة التبويب Monitoring الخاصة بمثيل ClickHouse Managed Postgres لديك. بالإضافة إلى ذلك، يمكنك استعراض Query Performance Insights للحصول على تحليل مفصل لاستعلاماتك ضمن علامة التبويب Query Insights.النسخ الاحتياطي والاستعادة
ما خيارات النسخ الاحتياطي المتاحة؟
يتضمن ClickHouse Managed Postgres نسخًا احتياطية يومية تلقائية مع أرشفة مستمرة لسجل WAL، ما يتيح الاستعادة إلى أي نقطة زمنية ضمن فترة احتفاظ تمتد 7 أيام. وتُخزَّن النسخ الاحتياطية في تخزين الكائنات. للاطلاع على التفاصيل الكاملة بشأن وتيرة النسخ الاحتياطي، وفترة الاحتفاظ، وكيفية إجراء الاستعادة إلى نقطة زمنية محددة، راجع وثائق النسخ الاحتياطي والاستعادة.البنية التحتية والأتمتة
ما هي مزوّدات السحابة المدعومة؟
يتوفّر ClickHouse Managed Postgres على AWS ضمن مرحلة Public Beta، بينما يوجد GCP في مرحلة private preview. يمكنك التسجيل في قائمة انتظار private preview الخاصة بـ GCP من هنا، والاطلاع على الإعلان لمعرفة المزيد. راجع مزوّدات السحابة المدعومة لمزيد من التفاصيل.هل يتوفر دعم Terraform لـ ClickHouse Managed Postgres؟
نعم. يمكنك إنشاء خدمات ClickHouse Managed Postgres وإدارتها باستخدام Terraform provider الخاص بـ ClickHouse عبر الموردclickhouse_postgres_service. راجع مرجع Terraform لمزيد من التفاصيل. كما يمكنك استخدام ClickHouse Cloud console أو OpenAPI لإنشاء المثيلات وإدارتها.
الامتدادات والإعدادات
ما الامتدادات المتوفرة؟
يتضمن ClickHouse Managed Postgres أكثر من 90 امتدادًا لـ PostgreSQL، بما في ذلك امتدادات شائعة مثل PostGIS وpgvector وpg_cron وغيرها الكثير. للاطلاع على القائمة الكاملة بالامتدادات المتاحة وإرشادات التثبيت، راجع وثائق الامتدادات.هل يمكنني تخصيص معلمات إعداد PostgreSQL؟
نعم، يمكنك تعديل معلمات إعداد PostgreSQL وPgBouncer من خلال علامة التبويب Settings في Console. لمزيد من التفاصيل حول المعلمات المتاحة وكيفية تغييرها، راجع وثائق Settings.تجميع الاتصالات
لماذا تظهر لي أخطاء prepared statement does not exist عند المرور عبر PgBouncer؟
يشغّل ClickHouse Managed Postgres أداة PgBouncer في وضع تجميع المعاملات (transaction pooling). في هذا الوضع، لا يُخصَّص اتصال Postgres الخلفي لعميلك إلا طوال مدة معاملة واحدة، ثم يُعاد إلى مجمّع الاتصالات، وقد تُوجَّه المعاملة التالية من العميل نفسه إلى اتصال خلفي مختلف.
يتتبّع PgBouncer العبارات المُحضَّرة على مستوى البروتوكول، وهي العبارات التي ترسلها معظم المشغّلات عبر بروتوكول الاستعلام الموسّع (رسائل Parse وBind وExecute). وعندما تُنفَّذ عبارة على اتصال خلفي لم يسبق له التعامل معها، يُعِدّها PgBouncer عليه أولًا. ويحتفظ كل اتصال خلفي بما يصل إلى max_prepared_statements منها، والقيمة الافتراضية 200. ولهذا تعمل معظم المشغّلات عبر PgBouncer بإعداداتها الافتراضية.
ما لا يعمل عبر PgBouncer:
- العبارات المُحضَّرة على مستوى SQL. لا يتتبّع PgBouncer العبارتين
PREPAREوEXECUTEالمُرسلتين بصيغة SQL، لذا قد تصل عبارةEXECUTEإلى اتصال خلفي لم يُنفّذPREPAREقط. - تحرير العبارات باستخدام
DEALLOCATEفي SQL. يعيد PgBouncer تسمية العبارات على الاتصال الخلفي، ولذلك يفشل تنفيذDEALLOCATEعلى اسم العبارة كما يعرفه العميل. وإذا حدث ذلك داخل معاملة، فإنها تُلغى، وتفشل العبارات اللاحقة بالخطأcurrent transaction is aborted. أما المشغّلات المبنية على libpq 17 أو أحدث، فتحرّر العبارات برسالةCloseعلى مستوى البروتوكول بدلًا من ذلك، وهي رسالة يدعمها PgBouncer. - العبارات غير المسمّاة الموزّعة على عدة رحلات ذهاب وإياب. ترسل بعض أوضاع المشغّلات رسالة
Parseالخاصة بعبارة غير مسمّاة في رحلة ذهاب وإياب، ثم رسالةBindالخاصة بها في الرحلة التالية. وقد يُنفّذ PgBouncer الرحلة الثانية على اتصال خلفي مختلف، فتفشل بالخطأunnamed prepared statement does not exist، أو يُنفّذ بصمت عبارة تخص عميلًا آخر ويُعيد نتائجها.
- موجات متلاحقة من أخطاء
prepared statement does not exist، لا سيما أثناء عمليات ملء البيانات التاريخية أو عمليات الكتابة عالية التزامن - عمليات إدراج تبدو وكأنها “تفشل بصمت”، إذ تفشل العبارة فيعيد المشغّل المحاولة، وقد ينتهي الأمر بتطبيق الدفعة جزئيًا أو بفقدانها
- معاملات تفشل بالخطأ
current transaction is abortedبعد تحرير إحدى العبارات - صفوف تعود إلى استعلام آخر
إذا كان عبء العمل لديك يعتمد على
PREPARE على مستوى SQL، فاتصل مباشرةً بـ PostgreSQL (المنفذ 5432) بدلًا من المرور عبر وسيط تجميع الاتصالات PgBouncer. راجع الاتصال لمزيد من التفاصيل حول المفاضلة بين نقطة النهاية المجمّعة ونقطة النهاية المباشرة.
لماذا تفشل الاستعلامات بالخطأ cached plan must not change result type بعد الترحيل؟
يحتفظ PgBouncer بالعبارات المُحضَّرة على اتصالاته بـ Postgres، ويعيد استخدامها عند تكرار نص SQL نفسه. لذا، بعد أي تغيير في المخطط يُغيّر نوع عمود يُرجعه استعلام ما، كتغييره مثلًا من integer إلى bigint، يظل ذلك الاستعلام يفشل عبر PgBouncer بالخطأ cached plan must not change result type. ويستمر الفشل حتى مع اتصالات العميل الجديدة، إلى أن يستبدل PgBouncer اتصالاته بـ Postgres. وقد لا تُظهر بعض المشغّلات أي خطأ، بل تفكّ ترميز النتائج وفق الأنواع القديمة وتُرجع قيمًا خاطئة. أما عبر الاتصال المباشر، فيفشل كل اتصال مرة واحدة على الأكثر ثم يعود إلى العمل بشكل طبيعي.
لحل المشكلة، أغلق اتصالات PgBouncer بـ Postgres الخاصة بقاعدة البيانات تلك، وسيفتح PgBouncer اتصالات جديدة تلقائيًا. ونظرًا لأن PgBouncer يتصل بـ Postgres محليًا، فلا تحمل اتصالاته قيمة client_addr. نفّذ ما يلي عبر الاتصال المباشر (المنفذ 5432)، مستخدمًا المستخدم نفسه الذي يتصل به تطبيقك. يُنهي هذا الأمر اتصالات PgBouncer الخاصة بمستخدم تطبيقك فقط، لذا ستفشل المعاملات الجارية عبر PgBouncer في تلك اللحظة، بينما لن تتأثر الاتصالات المباشرة:
prepare: :unnamed، وpgx مع cache_describe.
لماذا يظهر الخطأ unsupported startup parameter عند الاتصال عبر PgBouncer؟
يرفض PgBouncer الإعدادات المُمرَّرة عند إنشاء الاتصال إذا تعذّر عليه تطبيقها بشكل متّسق على جميع اتصالات Postgres في مجمّع الاتصالات الخاص به، فيفشل الاتصال بالخطأ FATAL: unsupported startup parameter: ... أو unsupported startup parameter in options: .... وأكثر الحالات شيوعاً:
extra_float_digits: يرسله مع كل اتصال كلٌّ من sqlx وpgjdbc بالإصدار 42.7.4 وما قبله (مثلاً عند استخدامه مع Spring Boot 3). لحل المشكلة، رقِّ pgjdbc إلى الإصدار 42.7.5 أو أحدث. أما في sqlx، فاضبطextra_float_digits(None)علىPgConnectOptions.search_pathوغيره من الإعدادات المضمَّنة في سلسلة الاتصال، مثلcurrentSchemaفي عنوان URL الخاص بـ JDBC، أوSearch Pathفي سلسلة اتصال Npgsql، أوoptions=-c ...، أوOPTIONS["options"]في Django. بدلاً من ذلك، اضبط القيمة الافتراضية باستخدامALTER ROLE ... SETأوALTER DATABASE ... SET، أو استخدمSET LOCALداخل معاملة، أو اتصل مباشرةً دون المرور عبر PgBouncer.
application_name وTimeZone فمدعومان.
لماذا لا يستمر تأثير أوامر SET عبر PgBouncer؟
في وضع تجميع المعاملات، يسري الأمر SET المنفَّذ على مستوى الـ session على اتصال Postgres الذي نفّذه، لا على العميل الخاص بك. فقد تُنفَّذ المعاملات اللاحقة الصادرة عن عميلك عبر اتصالات أخرى لا يسري عليها هذا الإعداد، بينما قد يستخدم عملاء آخرون الاتصال الذي يسري عليه. وينطبق ذلك أيضًا على SET ROLE، ما يعني أن الدور الذي تتولّاه قد يسري على استعلامات عميل آخر. استخدم SET LOCAL داخل معاملة، أو اضبط القيم الافتراضية باستخدام ALTER ROLE ... SET أو ALTER DATABASE ... SET، أو اتصل مباشرةً لتشغيل أعباء العمل التي تعتمد على حالة الـ session.
لماذا تتعلّق عمليات الترحيل أو تفشل في تحرير قفل استشاري عبر PgBouncer؟
تحصل كثير من أدوات الترحيل على قفل استشاري على مستوى الـ session لضمان ألّا تعمل سوى عملية ترحيل واحدة في كل مرة، ثم تحرّره بعبارة منفصلة. وعند المرور عبر PgBouncer، قد تُنفَّذ عبارة التحرير على اتصال Postgres مختلف، فيبقى القفل قائمًا على أحد الاتصالات في مجمّع الاتصالات. ونتيجة لذلك، تظل عمليات الترحيل اللاحقة في حالة انتظار أو تفشل بأخطاء مثلfailed to release advisory lock، حتى عند استخدام الاتصال المباشر. ومن الأدوات التي تستخدم أقفالًا استشارية على مستوى الـ session: golang-migrate وsqlx وMigrator في Kysely وRails وFlyway مع transactional-lock=false وEcto مع migration_lock: :pg_advisory_lock.
شغّل عمليات الترحيل عبر الاتصال المباشر (المنفذ 5432). يُحتجَز القفل المُسرَّب من قِبل session خاملة، في حين تحتجز عملية الترحيل التي لا تزال قيد التشغيل قفلها من session نشطة. لإزالة الأقفال المُسرَّبة، أنهِ الـ sessions الخاملة وحدها التي تحتجز أقفالًا استشارية في قاعدة بياناتك، وذلك عبر الاتصال المباشر أيضًا:
ماذا يعني الإعداد max_client_conn في PgBouncer، وكيف يرتبط بـ max_connections في Postgres؟
يتحكم كلٌّ منهما في شيء مختلف:
max_connectionsفي Postgres يحدد الحد الأقصى لعدد الاتصالات الخلفية إلى PostgreSQL نفسه. وهذا هو الرقم الأعلى كلفة، لأن كل اتصال خلفي يستهلك ذاكرة وحصةً لعملية.max_client_connفي PgBouncer يحدد الحد الأقصى لعدد اتصالات العميل التي يمكن أن تكون مفتوحة في وسيط تجميع الاتصالات في الوقت نفسه. ويقوم PgBouncer بتجميع هذا العدد الكبير من اتصالات العميل فوق مجموعة أصغر بكثير من الاتصالات الخلفية.
max_connections على 500 ما يصل إلى 2500 اتصال عميل عند وسيط تجميع الاتصالات. إذا ظهرت لك أخطاء اتصال عند وسيط تجميع الاتصالات، فمن المرجح بدرجة كبيرة أنك وصلت إلى حد الاتصالات الخلفية الخاص بكل مجمّع اتصالات (default_pool_size، أو max_db_connections لكل قاعدة بيانات) لا إلى الحد الإجمالي المعلن لاتصالات العميل.
للاطلاع على القيم الخاصة بمثيلك، اتصل بقاعدة البيانات الخاصة pgbouncer عبر PgBouncer (المنفذ 6432) ونفّذ SHOW CONFIG:
إمكانات قاعدة البيانات
هل يمكنني إنشاء عدة قواعد بيانات ومخططات؟
نعم. يوفّر ClickHouse Managed Postgres وظائف PostgreSQL الأصلية كاملةً، بما في ذلك دعم عدة قواعد بيانات ومخططات ضمن مثيل واحد. يمكنك إنشاء قواعد البيانات والمخططات وإدارتها باستخدام أوامر PostgreSQL القياسية.هل يتوفر دعم للتحكم في الوصول المستند إلى الأدوار (RBAC)؟
لديك صلاحيات مستخدم فائق كاملة على مثيل ClickHouse Managed Postgres الخاص بك، مما يتيح لك إنشاء الأدوار وإدارة الأذونات باستخدام أوامر PostgreSQL القياسية.من المخطط طرح ميزات RBAC محسّنة مع تكامل مع Console خلال هذا العام.
الترقيات
كيف تُدار ترقيات إصدارات PostgreSQL؟
تُجرى ترقيات الإصدارات الثانوية والرئيسية عبر failover، وعادةً لا ينتج عنها سوى بضع ثوانٍ من التوقف. يمكنك تهيئة الترقيات المجدولة للتحكم في الأيام والنافذة الزمنية ذات الساعتين بتوقيت UTC التي تُطبَّق خلالها الترقيات. للاطلاع على التفاصيل الكاملة، راجع توثيق الترقيات.الترحيل
ما الأدوات المتاحة للترحيل إلى ClickHouse Managed Postgres؟
يدعم ClickHouse Managed Postgres عدة طرق للترحيل:- pg_dump and pg_restore: لقواعد البيانات الأصغر أو لعمليات الترحيل لمرة واحدة. راجع دليل pg_dump and pg_restore.
- Logical replication: لقواعد البيانات الأكبر التي تتطلب أقل وقت تعطل ممكن. راجع دليل Logical replication.
- PeerDB: للنسخ المتماثل المستند إلى CDC من مصادر Postgres الأخرى. راجع دليل PeerDB migration.
ستتوفر قريبًا تجربة ترحيل مُدارة بالكامل.