إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
تصف الأقسام التالية السعة والحدود الوظيفية لقاعدة بيانات Azure لمثيلات خادم PostgreSQL المرنة. إذا كنت ترغب في التعرف على مستويات الموارد (الحوسبة والذاكرة والتخزين)، فراجع مقالات الحوسبة والتخزين .
الحد الأقصى للاتصالات
يعرض الجدول التالي الحد الأقصى الافتراضي لعدد الاتصالات لكل طبقة تسعير وتكوين vCore. يحتفظ مثيل الخادم المرن Azure Database for PostgreSQL ب 15 اتصالا للنسخ المتماثل الفعلي ومراقبة قاعدة بيانات Azure لمثيل الخادم المرن PostgreSQL. وبالتالي، يقلل الجدول قيمة الحد الأقصى لاتصالات المستخدم بمقدار 15 من إجمالي الحد الأقصى للاتصالات.
| اسم المنتج | vCores | حجم الذاكرة | الحد الأقصى للاتصالات | الحد الأقصى لاتصالات المستخدم |
|---|---|---|---|---|
| Burstable | ||||
| B1ms | 1 | 2 جيبي بايت | 50 | 35 |
| B2s | 2 | 4 جيجابيت | 429 | 414 |
| B2ms | 2 | 8 جيجابيت | 859 | 844 |
| B4ms | 4 | 16 جيجابيت | 1,718 | 1,703 |
| B8ms | 8 | 32 غيغابايت | 3,437 | 3,422 |
| B12ms | 12 | 48 جيبي بايت | 5,000 | 4,985 |
| B16ms | 16 | 64 جيبي بايت | 5,000 | 4,985 |
| B20ms | 20 | 80 جيبي بايت | 5,000 | 4,985 |
| الغرض العام | ||||
| D2s_v3 / D2ds_v4 / D2ds_v5 / D2ads_v5 | 2 | 8 جيجابيت | 859 | 844 |
| D4s_v3 / D4ds_v4 / D4ds_v5 / D4ads_v5 | 4 | 16 جيجابيت | 1,718 | 1,703 |
| D8s_v3 / D8ds_V4 / D8ds_v5 / D8ads_v5 | 8 | 32 غيغابايت | 3,437 | 3,422 |
| D16s_v3 / D16ds_v4 / D16ds_v5 / D16ads_v5 | 16 | 64 جيبي بايت | 5,000 | 4,985 |
| D32s_v3 / D32ds_v4 / D32ds_v5 / D32ads_v5 | 32 | 128 جيبي بايت | 5,000 | 4,985 |
| D48s_v3 / D48ds_v4 / D48ds_v5 / D48ads_v5 | 48 | 192 جيجابايت | 5,000 | 4,985 |
| D64s_v3 / D64ds_v4 / D64ds_v5 / D64ads_v5 | 64 | 256 غيغابايت | 5,000 | 4,985 |
| D96ds_v5 / D96ads_v5 | 96 | 384 جيجابايت | 5,000 | 4,985 |
| مُحسّن للذاكرة | ||||
| E2s_v3 / E2ds_v4 / E2ds_v5 / E2ads_v5 | 2 | 16 جيجابيت | 1,718 | 1,703 |
| E4s_v3 / E4ds_v4 / E4ds_v5 / E4ads_v5 | 4 | 32 غيغابايت | 3,437 | 3,422 |
| E8s_v3 / E8ds_v4 / E8ds_v5 / E8ads_v5 | 8 | 64 جيبي بايت | 5,000 | 4,985 |
| E16s_v3 / E16ds_v4 / E16ds_v5 / E16ads_v5 | 16 | 128 جيبي بايت | 5,000 | 4,985 |
| E20ds_v4 / E20ds_v5 / E20ads_v5 | 20 | 160 جيجابايت | 5,000 | 4,985 |
| E32s_v3 / E32ds_v4 / E32ds_v5 / E32ads_v5 | 32 | 256 غيغابايت | 5,000 | 4,985 |
| E48s_v3 / E48ds_v4 / E48ds_v5 / E48ads_v5 | 48 | 384 جيجابايت | 5,000 | 4,985 |
| E64s_v3 / E64ds_v4 / E64ds_v5 / E64ads_v5 | 64 | 432 جيجابايت | 5,000 | 4,985 |
| E96ds_v5 / E96ads_v5 | 96 | 672 جيبي بايت | 5,000 | 4,985 |
يمكن تغيير فتحات الاتصال المحجوزة، في الوقت الحالي عند 15. ننصح بالتحقق بانتظام من إجمالي الاتصالات المحجوزة على الخادم. يمكنك حساب هذا الرقم عن طريق جمع قيم reserved_connections معلمات الخادم و superuser_reserved_connections . الحد الأقصى لعدد اتصالات المستخدم المتوفرة هو max_connections - (reserved_connections + superuser_reserved_connections).
يحسب النظام القيمة الافتراضية لمعلمة max_connections الخادم عند توفير مثيل قاعدة بيانات Azure لخادم PostgreSQL المرن، استنادا إلى اسم المنتج الذي تحدده لحسابه. لن يكون لأي تغييرات لاحقة في تحديد المنتج على الحساب الذي يدعم المثيل أي تأثير على القيمة الافتراضية لمعلمة الخادم max_connections لهذا المثيل. نوصي بأنه كلما قمت بتغيير المنتج المعين إلى مثيل، فإنك تقوم أيضا بضبط قيمة المعلمة max_connections وفقا للقيم الموجودة في الجدول السابق.
تغيير قيمة max_connections
عند إعداد قاعدة بيانات Azure لمثيل خادم Postgres المرن لأول مرة، فإنه يقرر تلقائيا أكبر عدد من الاتصالات التي يمكنه التعامل معها بشكل متزامن. يحدد تكوين الخادم هذا الرقم ولا يمكنك تغييره.
ومع ذلك، يمكنك استخدام max_connections الإعداد لضبط عدد الاتصالات المسموح بها في وقت معين. بعد تغيير هذا الإعداد، تحتاج إلى إعادة تشغيل الخادم للحد الجديد لبدء العمل.
Caution
على الرغم من max_connections أنه من الممكن زيادة قيمة ما بعد الإعداد الافتراضي، فإننا ننصح بعدم ذلك.
قد تواجه المثيلات صعوبات عند توسيع حمل العمل ويتطلب المزيد من الذاكرة. مع زيادة عدد الاتصالات، يرتفع أيضا استخدام الذاكرة. قد تواجه المثيلات ذات الذاكرة المحدودة مشكلات مثل الأعطال أو زمن الانتقال العالي. على الرغم من أن قيمة أعلى ل max_connections قد تكون مقبولة عندما تكون معظم الاتصالات الخامة، إلا أنها قد تؤدي إلى مشاكل كبيرة في الأداء بعد أن تصبح نشطة.
إذا كنت بحاجة إلى المزيد من الاتصالات، نقترح عليك بدلا من ذلك استخدام PgBouncer، حل Azure المضمن لإدارة تجمع الاتصال. استخدمه في وضع المعاملة. للبدء، نوصي باستخدام القيم المحافظة عن طريق ضرب vCores ضمن نطاق 2 إلى 5. بعد ذلك، راقب استخدام الموارد وأداء التطبيق بعناية لضمان التشغيل السلس. للحصول على معلومات مفصلة حول PgBouncer، راجع PgBouncer في قاعدة بيانات Azure ل PostgreSQL.
عندما تتجاوز الاتصالات الحد الأقصى، قد تتلقى الخطأ التالي:
FATAL: sorry, too many clients already.
عند استخدام Azure Database for PostgreSQL مثيل خادم مرن لقاعدة بيانات مشغولة بها عدد كبير من الاتصالات المتزامنة، قد يكون هناك ضغط كبير على الموارد. يمكن أن يؤدي هذا الضغط إلى استخدام وحدة المعالجة المركزية بشكل كبير، خاصة عندما يتم إنشاء العديد من الاتصالات في وقت واحد وعندما يكون للاتصالات مدد قصيرة (أقل من 60 ثانية). يمكن أن تؤثر هذه العوامل سلبا على الأداء العام لقاعدة البيانات عن طريق زيادة الوقت المستغرق في معالجة الاتصالات وقطع الاتصال.
يستهلك كل اتصال في Azure Database for PostgreSQL مثيل خادم مرن، بغض النظر عما إذا كان خاملا أو نشطا، قدرا كبيرا من الموارد من قاعدة البيانات الخاصة بك. يمكن أن يؤدي هذا الاستهلاك إلى مشكلات في الأداء تتجاوز الاستخدام العالي لوحدة المعالجة المركزية، مثل التنازع على القرص والتأمين. تتناول مقالة عدد اتصالات قاعدة البيانات في PostgreSQL Wiki هذه المقالة بمزيد من التفصيل. لمعرفة المزيد، راجع تحديد أداء الاتصال وحله في Azure Postgres.
القيود الوظيفية
تسرد الأقسام التالية اعتبارات لما هو مدعوم وما هو غير مدعوم لقاعدة بيانات Azure لمثيلات خادم PostgreSQL المرنة.
عمليات التوسع
- في هذا الوقت، يتطلب توسيع نطاق تخزين الخادم إعادة تشغيل الخادم.
- يمكن تغيير حجم تخزين الخادم بزيادات 2x فقط. راجع التخزين للحصول على التفاصيل.
- لا ندعم حاليا تقليل حجم تخزين الخادم. الطريقة الوحيدة للقيام بهذه العملية هي تفريغها واستعادتها إلى قاعدة بيانات Azure جديدة لمثيل خادم PostgreSQL المرن.
Storage
- بعد تكوين حجم التخزين، لا يمكنك تقليله. يجب عليك إنشاء خادم جديد بحجم التخزين المطلوب، وإجراء عملية تفريغ واستعادة يدوية، وترحيل قواعد البيانات إلى الخادم الجديد.
- عندما يصل استخدام التخزين إلى 95% أو إذا كانت السعة المتوفرة أقل من 5 جيجابايت (أيهما أكثر)، يقوم النظام تلقائيا بتبديل الخادم إلى وضع القراءة فقط لتجنب الأخطاء المرتبطة بحالات امتلاء القرص. في حالات نادرة، إذا تجاوز معدل نمو البيانات الوقت المستغرق للتبديل إلى وضع القراءة فقط، فقد لا يزال الخادم الخاص بك نفاد التخزين. يمكنك تمكين التحجيم التلقائي للتخزين لتجنب هذه المشكلات وتوسيع نطاق التخزين تلقائيا بناء على متطلبات حمل العمل.
- نوصي بتعيين قواعد التنبيه ل
storage usedأوstorage percentعندما تتجاوز حدودا معينة بحيث يمكنك اتخاذ إجراء استباقي مثل زيادة حجم التخزين. على سبيل المثال، يمكنك تعيين تنبيه إذا تجاوزت نسبة التخزين 80٪ من الاستخدام. - إذا كنت تستخدم النسخ المتماثل المنطقي، يجب إسقاط فتحة النسخ المتماثل المنطقية في الخادم الأساسي إذا لم يعد المشترك المقابل موجودا. وإلا، تتراكم ملفات تسجيل الكتابة المسبقة (WAL) في الأساسي وتملأ التخزين. إذا تجاوز التخزين حدا معينا وإذا لم تكن فتحة النسخ المتماثل المنطقي قيد الاستخدام (بسبب مشترك غير متوفر)، فإن مثيل خادم Azure Database for PostgreSQL المرن يسقط تلقائيا فتحة النسخ المتماثل المنطقي غير المستخدمة. يصدر هذا الإجراء ملفات WAL المتراكمة ويمنع الخادم من أن يصبح غير متوفر بسبب تعبئة التخزين.
- لا ندعم إنشاء مساحات الجداول. إذا كنت تقوم بإنشاء قاعدة بيانات، فلا توفر اسم مساحة جدول. يستخدم مثيل الخادم المرن Azure Database for PostgreSQL مساحة الجدول الافتراضية التي ترثها قاعدة بيانات القالب. من غير الآمن توفير مساحة جدول مثل مساحة الجدول المؤقتة، لأننا لا يمكننا التأكد من أن هذه الكائنات ستظل مستمرة بعد أحداث مثل إعادة تشغيل الخادم وتجاوز الفشل عالي التوفر (HA).
- ملفات البيانات القديمة واختلافات استخدام القرص: في حالات نادرة، قد يترك PostgreSQL ملفات بيانات يتيمة على الأقراص — وهي ملفات لم تعد تحتوي على إدخالات مقابلة في فهرس نظام قاعدة البيانات (الذي يتتبع جميع الجداول والبيانات). يمكن أن يحدث ذلك إذا تم إنشاء جدول وملؤه ضمن معاملة لم تكتمل بنجاح (مثلا بسبب تعطل الخادم أو انقطاع)، مما يؤدي إلى عدم تطابق بين حجم قاعدة البيانات المبلغ عنه والاستخدام الفعلي للقرص. هذا السلوك مأخوذ من قاعدة شيفرة مجتمع PostgreSQL وليس خاصا ب Azure. مجتمع PostgreSQL على دراية بالمشكلة ويستكشفون تحسينات للتنظيف التلقائي في الإصدارات المستقبلية. لمزيد من التفاصيل، انظر: PostgreSQL: الملفات الأيتيمة في PostgreSQL. قد يؤدي ذلك إلى استهلاك أقراص أو تخزين مرتفع بشكل غير متوقع.
-
كيفية الكشف: قارن حجم قاعدة البيانات المبلغ عنها (باستخدام استعلامات مثل
SELECT pg_database_size('your_database')) مع مقاييس بوابة Azure لاستخدام القرص الفعلي. إذا كان هناك فرق كبير، فقد تكون الملفات اليتيمة هي السبب. إذا كان الأمر كذلك:- شغل VACUUM FULL على الطاولات المتأثرة لاستعادة المساحة (ملاحظة: هذا يتطلب موارد كبيرة، ويتطلب قفل الطاولة، وقد يتطلب وقتا للانتظار).
- بدلا من ذلك، استخدم أدوات مثل pg_repack أو pg_squeeze التوسعات لإعادة التنظيم بدون توقف وقتي، لكن الاختبار أولا في بيئة غير إنتاجية.
- راقب عبر بوابة Azure مقاييس استخدام القرص. إذا استمرت المشكلة أو لم تكن متأكدا، تواصل مع دعم Azure للحصول على المساعدة.
- كيفية المنع: تأكد من إدارة المعاملات بشكل صحيح في تطبيقاتك لتقليل العمليات غير المكتملة. راقب استخدام القرص بانتظام من خلال مقاييس بوابة Azure. قد تتضمن الترقية إلى أحدث إصدار مدعوم من PostgreSQL إصلاحات من المجتمع لمشاكل ذات صلة.
-
كيفية الكشف: قارن حجم قاعدة البيانات المبلغ عنها (باستخدام استعلامات مثل
Networking
- لا ندعم حاليا الانتقال من وإلى شبكة ظاهرية.
- لا ندعم حاليا الجمع بين الوصول العام والنشر في شبكة ظاهرية.
- لا تدعم الشبكات الظاهرية قواعد جدار الحماية. يمكنك استخدام مجموعات أمان الشبكة بدلا من ذلك.
- يمكن لخوادم قاعدة بيانات الوصول العام الاتصال بالإنترنت العام؛ على سبيل المثال، من خلال
postgres_fdw. لا يمكنك تقييد هذا الوصول. يمكن أن تكون الخوادم في الشبكات الظاهرية مقيدة بالوصول الصادر من خلال مجموعات أمان الشبكة.
التوافر العالي
- راجع قيود التوفر العالي.
مجموعات التوافر
- لا ندعم حاليا نقل الخوادم يدويا إلى منطقة توفر مختلفة. ومع ذلك، باستخدام منطقة التوفر المفضلة كمنطقة الاستعداد، يمكنك تشغيل قابلية الوصول العالية. بعد إنشاء منطقة الاستعداد، يمكنك تجاوز الفشل فيها ثم إيقاف تشغيل HA.
محرك Postgres والملحقات وPgBouncer
- يدعم مثيل الخادم المرن Azure Database for PostgreSQL جميع ميزات محرك PostgreSQL، بما في ذلك التقسيم والنسخ المتماثل المنطقي وأغلفة البيانات الأجنبية.
- يدعم مثيل الخادم المرن Azure Database for PostgreSQL جميع
contribالملحقات والمزيد. لمزيد من المعلومات، راجع ملحقات PostgreSQL. - لا تتمتع الخوادم القابلة للاندفاع حاليا بالوصول إلى تجمع اتصال PgBouncer المضمن.
إيقاف / بدء العمليات
- بعد إيقاف مثيل خادم Azure Database for PostgreSQL المرن، يبدأ تلقائيا بعد سبعة أيام.
الصيانة المجدولة
- يمكنك تغيير نافذة الصيانة المخصصة إلى أي يوم/وقت من الأسبوع. ومع ذلك، لن يكون لأي تغييرات تجريها بعد تلقي إشعار الصيانة أي تأثير على الصيانة التالية. تسري التغييرات فقط مع الصيانة الشهرية المجدولة التالية.
النسخ الاحتياطية للخادم
يدير النظام النسخ الاحتياطية. لا يمكنك حاليا تشغيل النسخ الاحتياطية يدويا. نوصي باستخدام
pg_dumpبدلا من ذلك.اللقطة الأولى هي نسخة احتياطية كاملة، واللقطات المتتالية هي نسخ احتياطية تفاضلية. النسخ الاحتياطية التفاضلية النسخ الاحتياطية فقط البيانات التي تم تغييرها منذ النسخ الاحتياطي للقطة الأخيرة.
على سبيل المثال، إذا كان حجم قاعدة البيانات الخاصة بك 40 غيغابايت والتخزين المتوفر 64 غيغابايت، فإن النسخ الاحتياطي الأول للقطة هو 40 غيغابايت. الآن، إذا قمت بتغيير 4 غيغابايت من البيانات، فسيكون حجم النسخ الاحتياطي للقطة التفاضلية التالية 4 غيغابايت فقط. سجلات المعاملات (سجلات الكتابة المسبقة) منفصلة عن النسخ الاحتياطية الكاملة والتفاضلية، ويتم أرشفتها باستمرار.
استعادة الخادم
- عند استخدام ميزة الاستعادة في نقطة زمنية (PITR)، يقوم النظام بإنشاء الخادم الجديد بنفس تكوينات الحوسبة والتخزين مثل الخادم الذي يستند إليه.
- يستعيد النظام خوادم قاعدة البيانات في الشبكات الظاهرية إلى نفس الشبكات الظاهرية عند الاستعادة من نسخة احتياطية.
- لا يشمل الخادم الجديد الذي تم إنشاؤه في أثناء عملية الاستعادة قواعد جدار الحماية الموجودة على الخادم الأصلي. تحتاج إلى إنشاء قواعد جدار الحماية بشكل منفصل للخادم الجديد.
- لا ندعم الاستعادة إلى اشتراك مختلف. كحل بديل، يمكنك استعادة الخادم ضمن نفس الاشتراك ثم ترحيل الخادم المستعادة إلى اشتراك مختلف.
Security
- يقوم Postgres 14 والإصدارات الأحدث بتعطيل تجزئة MD5 وتجزئة النظام كلمات مرور Postgres الأصلية باستخدام أسلوب SCRAM-SHA-256 فقط.