معلمات الخادم في قاعدة بيانات Azure ل MySQL - الخادم المرن

  • مقالة
  • قراءة خلال 7 دقائق

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

توفر هذه المقالة اعتبارات وإرشادات لتكوين معلمات الخادم في قاعدة بيانات Azure لخادم MySQL المرن.

ما هي متغيرات الخادم؟

يوفر محرك MySQL العديد من متغيرات/معلمات الخادم المختلفة التي يمكن استخدامها لتكوين سلوك المحرك وضبطه. يمكن تعيين بعض المعلمات ديناميكيا أثناء وقت التشغيل بينما البعض الآخر "ثابت"، مما يتطلب إعادة تشغيل الخادم من أجل التطبيق.

تعرض قاعدة بيانات Azure لخادم MySQL المرن القدرة على تغيير قيمة معلمات خادم MySQL المختلفة باستخدام مدخل Microsoft AzureوAzure CLI لمطابقة احتياجات حمل العمل الخاص بك.

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

يمكنك إدارة تكوين خادم Azure Database for MySQL Flexible Server باستخدام معلمات الخادم. يتم تكوين معلمات الخادم بالقيمة الافتراضية والموصى بها عند إنشاء الخادم. تعرض شفرة معلمة الخادم في مدخل Microsoft Azure كلا من معلمات الخادم القابلة للتعديل وغير القابلة للتعديل. معلمات الخادم غير القابلة للتعديل غير قابلة للتعديل باللون الرمادي.

قائمة معلمات الخادم المدعومة تنمو باستمرار. استخدم علامة تبويب معلمات الخادم في مدخل Microsoft Azure لعرض القائمة الكاملة وتكوين قيم معلمات الخادم.

راجع الأقسام التالية أدناه لمعرفة المزيد حول حدود العديد من معلمات الخادم المحدثة بشكل شائع. يتم تحديد الحدود بواسطة طبقة الحساب والحجم (vCores) للخادم.

ملاحظة

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

log_bin_trust_function_creators

في Azure Database for MySQL Flexible Server، يتم تمكين السجلات الثنائية دائما (أي، log_bin يتم تعيين إلى ON). يتم تعيين log_bin_trust_function_creators إلى ON بشكل افتراضي في الخوادم المرنة.

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

إذا تم تعيين [log_bin_trust_function_creators] إلى إيقاف التشغيل، إذا حاولت إنشاء مشغلات، فقد تحصل على أخطاء مشابهة لم يكن لديك امتياز SUPER ويتم تمكين التسجيل الثنائي (قد ترغب في استخدام المتغير الأقل أمانا log_bin_trust_function_creators ).

innodb_buffer_pool_size

راجع وثائق MySQL لمعرفة المزيد حول هذه المعلمة.

⁧⁩مستوى الأسعار⁧⁩ vCore(s) حجم الذاكرة (جيبي بايت) القيمة الافتراضية (بايت) الحد الأدنى للقيمة (بايت) الحد الأقصى للقيمة (بايت)
قابل للاندفاع (B1s) 1 1 134217728 33554432 134217728
قابل للاندفاع (B1ms) ⁧⁩1⁧⁩ 2 536870912 134217728 536870912
قابل للاندفاع 2 4 2147483648 134217728 2147483648
General Purpose 2 8 5368709120 134217728 5368709120
General Purpose 4 ⁧⁩16⁧⁩ 12884901888 134217728 12884901888
General Purpose 8 32 25769803776 134217728 25769803776
General Purpose ⁧⁩16⁧⁩ ⁧⁩64⁧⁩ 51539607552 134217728 51539607552
General Purpose 32 128 103079215104 134217728 103079215104
General Purpose 48 192 154618822656 134217728 154618822656
General Purpose ⁧⁩64⁧⁩ 256 206158430208 134217728 206158430208
مُحسّن للذاكرة 2 ⁧⁩16⁧⁩ 12884901888 134217728 12884901888
مُحسّن للذاكرة 4 32 25769803776 134217728 25769803776
مُحسّن للذاكرة 8 ⁧⁩64⁧⁩ 51539607552 134217728 51539607552
مُحسّن للذاكرة ⁧⁩16⁧⁩ 128 103079215104 134217728 103079215104
مُحسّن للذاكرة 32 256 206158430208 134217728 206158430208
مُحسّن للذاكرة 48 384 309237645312 134217728 309237645312
مُحسّن للذاكرة ⁧⁩64⁧⁩ 504 405874409472 134217728 405874409472

innodb_file_per_table

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

تدعم قاعدة بيانات Azure لخادم MySQL المرن أكبر 4 تيرابايت في ملف بيانات واحد. إذا كان حجم قاعدة البيانات أكبر من 4 تيرابايت، فيجب إنشاء الجدول في innodb_file_per_table tablespace. إذا كان لديك حجم جدول واحد أكبر من 4 تيرابايت، فيجب عليك استخدام جدول القسم.

innodb_log_file_size

innodb_log_file_size هو حجم وحدات البايت لكل ملف سجل في مجموعة سجل. لا يمكن أن يتجاوز الحجم المدمج لملفات السجل (innodb_log_file_size * innodb_log_files_in_group) الحد الأقصى للقيمة الأقل قليلا من 512 غيغابايت). حجم ملف سجل أكبر هو أفضل للأداء، ولكن لديه عيب أن وقت الاسترداد بعد حدوث عطل سيكون مرتفعا. تحتاج إلى موازنة وقت الاسترداد في الحدث النادر لاسترداد الأعطال مقابل زيادة معدل النقل في أثناء عمليات الذروة. يمكن أن تؤدي هذه أيضا إلى أوقات إعادة تشغيل أطول. يمكنك تكوين innodb_log_size إلى أي من هذه القيم - 256 ميغابايت أو 512 ميغابايت أو 1 غيغابايت أو 2 غيغابايت لقاعدة بيانات Azure لخادم MySQL المرن. المعلمة ثابتة وتتطلب إعادة تشغيل.

ملاحظة

إذا قمت بتغيير المعلمة innodb_log_file_size من الافتراضي، فتحقق مما إذا كانت قيمة "إظهار الحالة العمومية مثل "innodb_buffer_pool_pages_dirty" تبقى عند 0 لمدة 30 ثانية لتجنب تأخير إعادة التشغيل.

max_connections

يتم تحديد قيمة max_connection بواسطة حجم ذاكرة الخادم.

⁧⁩مستوى الأسعار⁧⁩ vCore(s) حجم الذاكرة (جيبي بايت) القيمة الافتراضية أدنى قيمة أقصى قيمة
قابل للاندفاع (B1s) 1 1 85 10 171
قابل للاندفاع (B1ms) ⁧⁩1⁧⁩ 2 171 10 341
قابل للاندفاع 2 4 341 10 683
General Purpose 2 8 683 10 1365
General Purpose 4 ⁧⁩16⁧⁩ 1365 10 2731
General Purpose 8 32 2731 10 5461
General Purpose ⁧⁩16⁧⁩ ⁧⁩64⁧⁩ 5461 10 10923
General Purpose 32 128 10923 10 21845
General Purpose 48 192 16384 10 32768
General Purpose ⁧⁩64⁧⁩ 256 21845 10 43691
مُحسّن للذاكرة 2 ⁧⁩16⁧⁩ 1365 10 2731
مُحسّن للذاكرة 4 32 2731 10 5461
مُحسّن للذاكرة 8 ⁧⁩64⁧⁩ 5461 10 10923
مُحسّن للذاكرة ⁧⁩16⁧⁩ 128 10923 10 21845
مُحسّن للذاكرة 32 256 21845 10 43691
مُحسّن للذاكرة 48 384 32768 10 65536
مُحسّن للذاكرة ⁧⁩64⁧⁩ 504 43008 10 86016

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

ERROR 1040 (08004): اتصالات كثيرة جدا

هام

للحصول على أفضل تجربة، نوصي باستخدام تجمع اتصال مثل ProxySQL لإدارة الاتصالات بكفاءة.

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

ملاحظة

ProxySQL هو أداة مجتمع مصدر مفتوح. وهي مدعومة من قبل Microsoft على أساس أفضل جهد. للحصول على دعم الإنتاج مع إرشادات موثوقة، يمكنك تقييم دعم منتج ProxySQL والوصول إليه.

innodb_strict_mode

إذا تلقيت خطأ مشابها ل "حجم الصف كبير جدا (> 8126)"، فقد تحتاج إلى إيقاف تشغيل المعلمة innodb_strict_mode. لا يسمح بتعديل معلمة الخادم innodb_strict_mode بشكل عام على مستوى الخادم لأنه إذا كان حجم بيانات الصف أكبر من 8k، فسيتم اقتطاع البيانات دون حدوث خطأ، مما قد يؤدي إلى فقدان محتمل للبيانات. نوصي بتعديل المخطط ليناسب حد حجم الصفحة.

يمكن تعيين هذه المعلمة على مستوى جلسة العمل باستخدام init_connect. لتعيين innodb_strict_mode على مستوى جلسة العمل، راجع تعيين معلمة غير مدرجة.

ملاحظة

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

time_zone

عند النشر الأولي، يتضمن Azure for MySQL Flexible Server جداول النظام لمعلومات المنطقة الزمنية، ولكن لا يتم ملء هذه الجداول. يمكن ملء جداول المنطقة الزمنية عن طريق استدعاء mysql.az_load_timezone الإجراء المخزن من أداة مثل سطر أوامر MySQL أو منضدة عمل MySQL. راجع مقالات مدخل Azure أو Azure CLI لمعرفة كيفية استدعاء الإجراء المخزن وتعيين المناطق الزمنية العمومية أو على مستوى الجلسة.

binlog_expire_logs_seconds

في Azure Database for MySQL تحدد هذه المعلمة عدد الثوانية التي تنتظرها الخدمة قبل إزالة ملف السجل الثنائي.

يحتوي السجل الثنائي على "أحداث" تصف تغييرات قاعدة البيانات مثل عمليات إنشاء الجدول أو التغييرات في بيانات الجدول. كما يحتوي على أحداث لعبارات من المحتمل أن تكون قد أجريت تغييرات. يتم استخدام السجل الثنائي بشكل رئيسي لغرضين، النسخ المتماثل وعمليات استرداد البيانات. عادة، يتم إزالة السجلات الثنائية بمجرد أن يكون المقبض خاليا من الخدمة أو النسخ الاحتياطي أو مجموعة النسخ المتماثلة. في حالة وجود نسخة متماثلة متعددة، سينتظر أبطأ نسخة متماثلة لقراءة التغييرات قبل إزالتها. إذا كنت ترغب في الاحتفاظ بالسجلات الثنائية لمدة زمنية أكثر، يمكنك تكوين المعلمة binlog_expire_logs_seconds. إذا تم تعيين binlog_expire_logs_seconds إلى 0 وهي القيمة الافتراضية، فسيتم إزالته بمجرد تحرير المقبض إلى السجل الثنائي. إذا binlog_expire_logs_seconds > 0، فسينتظر حتى الثوان التي تم تكوينها قبل إزالتها. بالنسبة لقاعدة بيانات Azure ل MySQL، تتم معالجة الميزات المدارة مثل النسخ الاحتياطي وإزالة النسخة المتماثلة للقراءة من الملفات الثنائية داخليا. عند نسخ البيانات نسخا متماثلا من خدمة Azure Database for MySQL، يجب تعيين هذه المعلمة في الأساسي لتجنب إزالة السجلات الثنائية قبل قراءة النسخة المتماثلة من التغييرات من الأساسي. إذا قمت بتعيين binlog_expire_logs_seconds إلى قيمة أعلى، فلن يتم إزالة السجلات الثنائية قريبا بما فيه الكفاية ويمكن أن تؤدي إلى زيادة في فوترة التخزين.

معلمات الخادم غير القابلة للتعديل

تعرض شفرة معلمة الخادم على مدخل Microsoft Azure كلا من معلمات الخادم القابلة للتعديل وغير القابلة للتعديل. معلمات الخادم غير القابلة للتعديل غير قابلة للتعديل باللون الرمادي. إذا كنت ترغب في تكوين معلمة خادم غير قابلة للتعديل على مستوى جلسة العمل، فراجع مقالة مدخل Azure أو Azure CLI لتعيين المعلمة على مستوى الاتصال باستخدام init_connect.

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