FAQ الخاصة بـ Managed Postgres

الأسئلة الشائعة حول ClickHouse Managed Postgres

​

المراقبة والمقاييس

​

كيف يمكنني الوصول إلى المقاييس الخاصة بمثيل Managed Postgres لدي؟

يمكنك مراقبة استخدام CPU والذاكرة وIOPS والتخزين مباشرةً من ClickHouse Cloud console، ضمن علامة التبويب Monitoring الخاصة بمثيل Managed Postgres لديك.

بالإضافة إلى ذلك، يمكنك استعراض Query Performance Insights للحصول على تحليل مفصل لاستعلاماتك ضمن علامة التبويب Query Insights.

​

النسخ الاحتياطي والاستعادة

​

ما خيارات النسخ الاحتياطي المتاحة؟

يتضمن Managed Postgres نسخًا احتياطية يومية تلقائية مع أرشفة مستمرة لسجل WAL، ما يتيح الاستعادة إلى أي نقطة زمنية ضمن فترة احتفاظ تمتد 7 أيام. وتُخزَّن النسخ الاحتياطية في S3.

للاطلاع على التفاصيل الكاملة بشأن وتيرة النسخ الاحتياطي، وفترة الاحتفاظ، وكيفية إجراء الاستعادة إلى نقطة زمنية محددة، راجع وثائق النسخ الاحتياطي والاستعادة.

​

البنية التحتية والأتمتة

​

هل يتوفر دعم Terraform لـ Managed Postgres؟

لا يتوفر دعم Terraform لـ Managed Postgres حاليًا. نوصي باستخدام ClickHouse Cloud console أو OpenAPI لإنشاء المثيلات وإدارتها.

​

الامتدادات والإعدادات

​

ما الامتدادات المتوفرة؟

يتضمن Managed Postgres أكثر من 90 امتدادًا لـ PostgreSQL، بما في ذلك امتدادات شائعة مثل PostGIS وpgvector وpg_cron وغيرها الكثير. للاطلاع على القائمة الكاملة بالامتدادات المتاحة وإرشادات التثبيت، راجع وثائق الامتدادات.

​

هل يمكنني تخصيص معلمات إعداد PostgreSQL؟

نعم، يمكنك تعديل معلمات إعداد PostgreSQL وPgBouncer من خلال علامة التبويب Settings في Console. لمزيد من التفاصيل حول المعلمات المتاحة وكيفية تغييرها، راجع وثائق Settings.

إذا كنت بحاجة إلى معلمة غير متاحة حاليًا، فتواصل مع الدعم لطلبها.

​

تجميع الاتصالات

​

لماذا تظهر لي أخطاء prepared statement does not exist عند استخدام PgBouncer؟

يُشغِّل Managed Postgres ‏PgBouncer في وضع تجميع المعاملات. في هذا الوضع، لا يُخصَّص اتصال Postgres خلفي لعميلك إلا طوال مدة معاملة واحدة، ثم يُعاد إلى المجمّع — وقد تُوجَّه المعاملة التالية من العميل نفسه إلى backend مختلف.

وهذا يُعطّل العبارات المُحضّرة من جهة الخادم، لأنها تكون مرتبطةً بالـ backend المحدد الذي نفّذ PREPARE (أو Parse في الاستعلام الموسَّع). وعندما يصل EXECUTE المقابل إلى backend مختلف، تظهر أخطاء مثل:

ERROR:  prepared statement "..." does not exist
ERROR:  unnamed prepared statement does not exist

الأعراض التي غالبًا ما ترجع إلى هذا السبب الجذري نفسه:

• دفعات من أخطاء prepared statement does not exist، خاصة أثناء عمليات backfill أو الكتابات عالية التزامن
• عمليات insert التي تبدو وكأنها “تفشل بصمت” — يفشل الـ statement، ويُعيد الـ driver المحاولة، وقد ينتهي الأمر بتطبيق الـ batch جزئيًا أو إسقاطها
• Returned values بنوع غير صحيح (على سبيل المثال، فك ترميز عمود BIGINT باعتباره نمط bit من نوع float64) — يحدث هذا عندما تعيد plan مخزنة مؤقتًا على جهة العميل استخدام رموز type/format قديمة مع backend لم يُرسل إليه Parse المطابق أصلًا

الحل: عطّل server-side prepared statements في الـ driver الذي تستخدمه. يعتمد الإعداد الدقيق على مكتبة الـ client لديك:

Driver	Setting
pgx (Go)	statement_cache_capacity=0 and default_query_exec_mode=exec (or simple_protocol)
psycopg3 (Python)	prepare_threshold=None
asyncpg (Python)	statement_cache_size=0
JDBC (Java)	prepareThreshold=0
node-postgres / pg (Node.js)	لا تمرّر name إلى query() (فالاستعلامات المُسمّاة تصبح مُحضّرة على الخادم)

إذا كانت الـ workload لديك تعتمد على prepared statements، فاتصل مباشرةً بـ PostgreSQL (المنفذ 5432) بدلًا من PgBouncer pooler — فالاتصالات المباشرة تدعم prepared statements بشكل طبيعي. راجع الاتصال للحصول على تفاصيل حول الاختيار بين endpoints المجمّعة والمباشرة.

​

ماذا يعني الإعداد max_client_conn في PgBouncer، وكيف يرتبط بـ max_connections في Postgres؟

يتحكم كلٌّ منهما في شيء مختلف:

• max_connections في Postgres يحدد الحد الأقصى لعدد اتصالات backend إلى PostgreSQL نفسه. وهذا هو الرقم الأعلى كلفة، لأن كل backend يستهلك ذاكرة وحصةً لعملية.
• max_client_conn في PgBouncer يحدد الحد الأقصى لعدد اتصالات client التي يمكن أن تكون مفتوحة في pooler في الوقت نفسه. ويقوم PgBouncer بتجميع هذا العدد الكبير من اتصالات client فوق مجموعة أصغر بكثير من اتصالات backend.

عادةً ما يُضبط مثيل Managed Postgres بحيث يقبل PgBouncer عددًا من اتصالات client يزيد بنحو 10× على عدد backends في Postgres (مثلًا 5000 client / 500 backend). إذا ظهرت لك أخطاء connection عند pooler، فمن المرجح بدرجة كبيرة أنك وصلت إلى حد backend الخاص بكل pool (default_pool_size) لا إلى الحد الإجمالي المعلن لاتصالات client.

​

إمكانات قاعدة البيانات

​

هل يمكنني إنشاء عدة قواعد بيانات ومخططات؟

نعم. يوفّر Managed Postgres وظائف PostgreSQL الأصلية كاملةً، بما في ذلك دعم عدة قواعد بيانات ومخططات ضمن مثيل واحد. يمكنك إنشاء قواعد البيانات والمخططات وإدارتها باستخدام أوامر PostgreSQL القياسية.

​

هل يتوفر دعم للتحكم في الوصول المستند إلى الأدوار (RBAC)؟

لديك صلاحيات مستخدم فائق كاملة على مثيل Managed Postgres الخاص بك، مما يتيح لك إنشاء الأدوار وإدارة الأذونات باستخدام أوامر PostgreSQL القياسية.

من المخطط طرح ميزات RBAC محسّنة مع تكامل مع Console خلال هذا العام.

​

الترقيات

​

كيف تُدار ترقيات إصدارات PostgreSQL؟

تُجرى ترقيات الإصدارات الثانوية والرئيسية عبر failover، وعادةً لا ينتج عنها سوى بضع ثوانٍ من التوقف. يمكنك تهيئة نافذة صيانة للتحكم في توقيت تطبيق الترقيات. للاطلاع على التفاصيل الكاملة، راجع توثيق الترقيات.

​

الترحيل

​

ما الأدوات المتاحة للترحيل إلى Managed Postgres؟

يدعم Managed Postgres عدة طرق للترحيل:

• pg_dump and pg_restore: لقواعد البيانات الأصغر أو لعمليات الترحيل لمرة واحدة. راجع دليل pg_dump and pg_restore.
• Logical replication: لقواعد البيانات الأكبر التي تتطلب أقل وقت تعطل ممكن. راجع دليل Logical replication.
• PeerDB: للنسخ المتماثل المستند إلى CDC من مصادر Postgres الأخرى. راجع دليل PeerDB migration.

ستتوفر قريبًا تجربة ترحيل مُدارة بالكامل.