الحدود في قاعدة بيانات Azure الخاصة بـ PostgreSQL - الخادم المرن

  • مقالة

يطبق على: قاعدة بيانات Azure لـ PostgreSQL - الخادم المرن

تصف الأقسام التالية السعة والحدود الوظيفية في قاعدة بيانات Azure لخادم PostgreSQL المرن. إذا كنت ترغب في التعرف على مستويات الموارد (الحوسبة والذاكرة والتخزين)، فشاهد مقالات الحوسبة والتخزين.

الحد الأقصى للاتصالات

يعرض الجدول التالي الحد الأقصى الافتراضي لعدد الاتصالات لكل مستوى تسعير وتكوين vCore. تحتفظ قاعدة بيانات Azure لخادم PostgreSQL المرن ب 15 اتصالا للنسخ المتماثل الفعلي ومراقبة قاعدة بيانات Azure لمثيل خادم PostgreSQL المرن. وبالتالي، يتم تقليل قيمة الحد الأقصى لاتصالات المستخدم المدرجة في الجدول بمقدار 15 من إجمالي الحد الأقصى للاتصالات.

اسم المنتج وحدات vCore حجم الذاكرة الحد الأقصى للاتصالات الحد الأقصى لاتصالات المستخدم
مندفع
B1ms 1 2 GiB 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_connectionssuperuser_reserved_connections).

يتم حساب القيمة الافتراضية لمعلمة max_connections الخادم عند توفير مثيل قاعدة بيانات Azure لخادم PostgreSQL المرن، استنادا إلى اسم المنتج الذي تحدده لحسابه. لن يكون لأي تغييرات لاحقة في تحديد المنتج على الحساب الذي يدعم الخادم المرن أي تأثير على القيمة الافتراضية لمعلمة max_connections الخادم لهذا المثيل. نوصي بأنه كلما قمت بتغيير المنتج المعين إلى مثيل، فإنك تقوم أيضا بضبط قيمة المعلمة max_connections وفقا للقيم الموجودة في الجدول السابق.

تغيير قيمة max_connections

عند إعداد قاعدة بيانات Azure لمثيل خادم Postgres المرن لأول مرة، فإنه يقرر تلقائيا أكبر عدد من الاتصالات التي يمكنه التعامل معها بشكل متزامن. يستند هذا الرقم إلى تكوين الخادم الخاص بك ولا يمكن تغييره.

ومع ذلك، يمكنك استخدام max_connections الإعداد لضبط عدد الاتصالات المسموح بها في وقت معين. بعد تغيير هذا الإعداد، تحتاج إلى إعادة تشغيل الخادم للحد الجديد لبدء العمل.

تنبيه

على الرغم من max_connections أنه من الممكن زيادة قيمة ما بعد الإعداد الافتراضي، فإننا ننصح بعدم ذلك.

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

إذا كنت بحاجة إلى المزيد من الاتصالات، نقترح عليك بدلا من ذلك استخدام PgBouncer، حل Azure المضمن لإدارة تجمع الاتصال. استخدمه في وضع المعاملة. للبدء، نوصي باستخدام القيم المحافظة عن طريق ضرب vCores ضمن نطاق 2 إلى 5. بعد ذلك، راقب استخدام الموارد وأداء التطبيق بعناية لضمان التشغيل السلس. للحصول على معلومات مفصلة حول PgBouncer، راجع PgBouncer في قاعدة بيانات Azure ل PostgreSQL - الخادم المرن.

عندما تتجاوز الاتصالات الحد الأقصى، قد تتلقى الخطأ التالي:

FATAL: sorry, too many clients already.

عند استخدام قاعدة بيانات Azure لخادم PostgreSQL المرن لقاعدة بيانات مشغولة مع عدد كبير من الاتصالات المتزامنة، قد يكون هناك ضغط كبير على الموارد. يمكن أن يؤدي هذا الضغط إلى استخدام وحدة المعالجة المركزية بشكل كبير، خاصة عندما يتم إنشاء العديد من الاتصالات في وقت واحد وعندما يكون للاتصالات مدد قصيرة (أقل من 60 ثانية). يمكن أن تؤثر هذه العوامل سلبا على الأداء العام لقاعدة البيانات عن طريق زيادة الوقت المستغرق في معالجة الاتصالات وقطع الاتصال.

يجب أن تدرك أن كل اتصال في قاعدة بيانات Azure لخادم PostgreSQL المرن، بغض النظر عما إذا كان خامدة أو نشطة، يستهلك كمية كبيرة من الموارد من قاعدة البيانات الخاصة بك. يمكن أن يؤدي هذا الاستهلاك إلى مشكلات في الأداء تتجاوز الاستخدام العالي لوحدة المعالجة المركزية، مثل التنازع على القرص والتأمين. تتناول مقالة عدد الاتصال قاعدة البيانات في PostgreSQL Wiki هذا الموضوع بمزيد من التفصيل. لمعرفة المزيد، راجع تحديد أداء الاتصال وحله في قاعدة بيانات Azure لخادم PostgreSQL المرن.

القيود الوظيفية

تسرد الأقسام التالية اعتبارات ما هو وغير مدعوم في قاعدة بيانات Azure لخادم PostgreSQL المرن.

عمليات تغيير الحجم

  • في هذا الوقت، يتطلب توسيع نطاق تخزين الخادم إعادة تشغيل الخادم.
  • يمكن تغيير حجم تخزين الخادم بزيادات 2x فقط، راجع التخزين للحصول على التفاصيل.
  • لا يتم دعم تقليل حجم تخزين الخادم حاليًا. الطريقة الوحيدة للقيام بذلك هي تفريغ واستعادته إلى قاعدة بيانات Azure جديدة لمثيل خادم PostgreSQL المرن.

التخزين

  • بعد تكوين حجم التخزين، لا يمكنك تقليله. يجب عليك إنشاء خادم جديد بحجم التخزين المطلوب، وإجراء عملية تفريغ واستعادة يدوية، وترحيل قواعد البيانات إلى الخادم الجديد.
  • عندما يصل استخدام التخزين إلى 95٪ أو إذا كانت السعة المتوفرة أقل من 5 غيغابايت (أيهما أكثر)، يتم تبديل الخادم تلقائيا إلى وضع القراءة فقط لتجنب الأخطاء المرتبطة بالمواقف الكاملة للقرص. في حالات نادرة، إذا تجاوز معدل نمو البيانات الوقت المستغرق للتبديل إلى وضع القراءة فقط، فقد لا يزال الخادم الخاص بك نفاد التخزين. يمكنك تمكين التحجيم التلقائي للتخزين لتجنب هذه المشكلات وتوسيع نطاق التخزين تلقائيا بناء على متطلبات حمل العمل.
  • نوصي بتعيين قواعد التنبيه ل storage used أو storage percent عندما تتجاوز حدودا معينة بحيث يمكنك اتخاذ إجراء استباقي مثل زيادة حجم التخزين. على سبيل المثال، يمكنك تعيين تنبيه إذا تجاوزت نسبة التخزين 80٪ من الاستخدام.
  • إذا كنت تستخدم النسخ المتماثل المنطقي، يجب إسقاط فتحة النسخ المتماثل المنطقية في الخادم الأساسي إذا لم يعد المشترك المقابل موجودا. وإلا، تتراكم ملفات تسجيل الكتابة المسبقة (WAL) في الأساسي وتملأ التخزين. إذا تجاوز التخزين حدا معينا وإذا لم تكن فتحة النسخ المتماثل المنطقي قيد الاستخدام (بسبب مشترك غير متوفر)، فإن قاعدة بيانات Azure لخادم PostgreSQL المرن تسقط تلقائيا فتحة النسخ المتماثل المنطقية غير المستخدمة. يصدر هذا الإجراء ملفات WAL المتراكمة ويمنع الخادم من أن يصبح غير متوفر بسبب تعبئة التخزين.
  • لا ندعم إنشاء مساحات الجداول. إذا كنت تقوم بإنشاء قاعدة بيانات، فلا توفر اسم مساحة جدول. يستخدم خادم Azure Database for PostgreSQL المرن الخادم الافتراضي الموروث من قاعدة بيانات القالب. من غير الآمن توفير مساحة جدول مثل مساحة الجدول المؤقتة، لأننا لا يمكننا التأكد من أن هذه الكائنات ستظل مستمرة بعد أحداث مثل إعادة تشغيل الخادم وتجاوز الفشل عالي التوفر (HA).

الشبكات

  • الانتقال داخل وخارج شبكة ظاهرية غير مدعوم حاليا.
  • الجمع بين الوصول العام والنشر في شبكة ظاهرية غير مدعوم حاليا.
  • قواعد جدار الحماية غير مدعومة على الشبكات الظاهرية. يمكنك استخدام مجموعات أمان الشبكة بدلا من ذلك.
  • يمكن لخوادم قاعدة بيانات الوصول العام الاتصال بالإنترنت العام؛ على سبيل المثال، من خلال postgres_fdw. لا يمكنك تقييد هذا الوصول. يمكن أن تكون الخوادم في الشبكات الظاهرية مقيدة بالوصول الصادر من خلال مجموعات أمان الشبكة.

التوافر العالي

مجموعات التوافر

  • نقل الخوادم يدويًا إلى منطقة توافر مختلفة غير مدعوم حاليًا. ومع ذلك، باستخدام منطقة التوفر المفضلة كمنطقة الاستعداد، يمكنك تشغيل قابلية الوصول العالية. بعد إنشاء منطقة الاستعداد، يمكنك تجاوز الفشل فيها ثم إيقاف تشغيل HA.

محرك Postgres والملحقات وPgBouncer

  • لا يتم دعم إصدارات Postgres 10 والإصدارات الأقدم، لأن المجتمع مفتوح المصدر قام بإيقافها. إذا كان يجب عليك استخدام أحد هذه الإصدارات، فستحتاج إلى استخدام خيار خادم Azure Database for PostgreSQL الفردي، والذي يدعم الإصدارات الرئيسية الأقدم 9.5 و9.6 و10.
  • يدعم خادم Azure Database for PostgreSQL المرن جميع contrib الملحقات والمزيد. لمزيد من المعلومات، انظر مقالة ملحقات PostgreSQL.
  • تجمع اتصال PgBouncer المضمن غير متوفر حاليا للخوادم القابلة للاندفاع.

إيقاف/بدء العمليات

  • بعد إيقاف مثيل خادم Azure Database for PostgreSQL المرن، يبدأ تلقائيا بعد 7 أيام.

الصيانة المجدولة

  • يمكنك تغيير نافذة الصيانة المخصصة إلى أي يوم/وقت من الأسبوع. ومع ذلك، لن يكون لأي تغييرات تجريها بعد تلقي إشعار الصيانة أي تأثير على الصيانة التالية. تسري التغييرات فقط مع الصيانة الشهرية المجدولة التالية.

النسخ الاحتياطية للخادم

  • يدير النظام النسخ الاحتياطية. لا توجد حاليا طريقة لتشغيل النسخ الاحتياطية يدويا. نوصي باستخدام pg_dump بدلا من ذلك.

  • اللقطة الأولى هي نسخة احتياطية كاملة، واللقطات المتتالية هي نسخ احتياطية تفاضلية. النسخ الاحتياطية التفاضلية النسخ الاحتياطية فقط البيانات التي تم تغييرها منذ النسخ الاحتياطي للقطة الأخيرة.

    على سبيل المثال، إذا كان حجم قاعدة البيانات الخاصة بك 40 غيغابايت والتخزين المتوفر 64 غيغابايت، فسيكون النسخ الاحتياطي الأول للقطة 40 غيغابايت. الآن، إذا قمت بتغيير 4 غيغابايت من البيانات، فسيكون حجم النسخ الاحتياطي للقطة التفاضلية التالية 4 غيغابايت فقط. سجلات المعاملات (سجلات الكتابة المسبقة) منفصلة عن النسخ الاحتياطية الكاملة والتفاضلية، ويتم أرشفتها باستمرار.

استعادة الخادم

  • عند استخدام ميزة الاستعادة في نقطة زمنية (PITR)، يتم إنشاء الخادم الجديد بنفس تكوينات الحوسبة والتخزين مثل الخادم الذي يستند إليه.
  • تتم استعادة خوادم قاعدة البيانات في الشبكات الظاهرية إلى نفس الشبكات الظاهرية عند الاستعادة من نسخة احتياطية.
  • لا يشمل الخادم الجديد الذي تم إنشاؤه في أثناء عملية الاستعادة قواعد جدار الحماية الموجودة على الخادم الأصلي. تحتاج إلى إنشاء قواعد جدار الحماية بشكل منفصل للخادم الجديد.
  • الاستعادة إلى اشتراك مختلف غير مدعومة. كحل بديل، يمكنك استعادة الخادم ضمن نفس الاشتراك ثم ترحيل الخادم المستعادة إلى اشتراك مختلف.

المحتوى ذو الصلة