مشاركة عبر

معلمات الخادم في Azure Database for MySQL - Flexible Server

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

إشعار

تحتوي هذه المقالة على مراجع لمصطلح الرقيق، والذي لم تعد Microsoft تستخدمه. عند إزالة المصطلح من البرنامج، بالتالي سنزيله من هذه المقالة.

ما هي المعلمات المتعلقة بالخادم؟

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

في Azure Database for MySQL - Flexible Server، يمكنك تغيير قيمة معلمات خادم MySQL المختلفة باستخدام تكوين معلمات الخادم في قاعدة بيانات Azure ل MySQL - الخادم المرن باستخدام مدخل Microsoft Azure ومعلمات تكوين الخادم في قاعدة بيانات Azure ل MySQL - الخادم المرن باستخدام Azure CLI لمطابقة احتياجات حمل العمل الخاص بك.

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

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

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

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

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

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

lower_case_table_names

بالنسبة إلى الإصدار 8.0+ من MySQL، يمكنك التكوين lower_case_table_names فقط عند تهيئة الخادم. اعرف المزيد. lower_case_table_names يحظر تغيير الإعداد بعد تهيئة الخادم. القيم المدعومة للإصدار 8.0 من MySQL هي 1 وفي 2 قاعدة بيانات Azure ل MySQL - الخادم المرن. القيمة الافتراضية هي 1.

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

لقطة شاشة توضح كيفية تكوين معلمة خادم اسم جدول الأحرف الصغيرة في وقت الإنشاء.

بالنسبة إلى الإصدار 5.7 من MySQL، تكون القيمة الافتراضية lower_case_table_names في 1 قاعدة بيانات Azure ل MySQL - الخادم المرن. على الرغم من أنه من الممكن تغيير القيمة المدعومة إلى 2، فإن العودة من 2 الخلف إلى 1 غير مسموح به. للمساعدة في تغيير القيمة الافتراضية، قم بإنشاء تذكرة دعم.

innodb_tmpdir

يمكنك استخدام المعلمة innodb_tmpdir في Azure Database for MySQL - Flexible Server لتعريف الدليل لملفات الفرز المؤقتة التي تم إنشاؤها أثناء العمليات عبر الإنترنت ALTER TABLE التي تعيد البناء.

وتكون القيمة الافتراضية لـ innodb_tmpdir هي /mnt/temp. يتوافق هذا الموقع مع التخزين المؤقت (SSD) ويتوفر في gibibytes (GiB) مع كل حجم حساب خادم. هذا الموقع مثالي للعمليات التي لا تتطلب مساحة كبيرة.

إذا كنت بحاجة إلى مساحة إضافية، يمكنك تعيين innodb_tmpdir إلى /app/work/tmpdir. يستخدم هذا الإعداد سعة التخزين المتوفرة على قاعدة بيانات Azure لخادم MySQL المرن. يمكن أن يكون هذا الإعداد مفيدا للعمليات الأكبر التي تتطلب تخزينا مؤقتا أكثر.

ضع في اعتبارك أن استخدام /app/work/tmpdir يؤدي إلى أداء أبطأ مقارنة بقيمة التخزين المؤقت الافتراضي (SSD/mnt/temp). قم بإجراء الاختيار بناء على المتطلبات المحددة للعمليات.

تنطبق المعلومات المقدمة على innodb_tmpdir المعلمات innodb_temp_tablespaces_dir وtmpdir slave_load_tmpdir حيث:

  • القيمة /mnt/temp الافتراضية شائعة.
  • الدليل البديل /app/work/tmpdir متاح لتكوين زيادة التخزين المؤقت، مع مفاضلة في الأداء استنادا إلى متطلبات تشغيلية محددة.

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 بالبقاء بأمان ك ON.

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

innodb_buffer_pool_size

للتعرف على المعلمة innodb_buffer_pool_size ، راجع وثائق MySQL.

يمثل حجم الذاكرة الفعلية في الجدول التالي ذاكرة الوصول العشوائي المتوفرة (RAM)، بالجيجابايت (GB)، على قاعدة بيانات Azure لخادم MySQL المرن.

حجم الحساب وحدات vCore حجم الذاكرة الفعلية (GB) القيمة الافتراضية (بايت) قيمة الحد الأدنى (بايت) أقصى قيمة (بايت)
مندفع
Standard_B1s 1 1 134217728 33554432 268435456
Standard_B1ms 1 2 536870912 134217728 1073741824
Standard_B2s 2 4 2147483648 134217728 2147483648
Standard_B2ms 2 8 4294967296 134217728 5368709120
Standard_B4ms 4 16 12884901888 134217728 12884901888
Standard_B8ms 8 32 25769803776 134217728 25769803776
Standard_B12ms 12 48 51539607552 134217728 32212254720
Standard_B16ms 16 64 2147483648 134217728 51539607552
Standard_B20ms 20 80 64424509440 134217728 64424509440
الغرض العام
Standard_D2ads_v5 2 8 4294967296 134217728 5368709120
Standard_D2ds_v4 2 8 4294967296 134217728 5368709120
Standard_D4ads_v5 4 16 12884901888 134217728 12884901888
Standard_D4ds_v4 4 16 12884901888 134217728 12884901888
Standard_D8ads_v5 8 32 25769803776 134217728 25769803776
Standard_D8ds_v4 8 32 25769803776 134217728 25769803776
Standard_D16ads_v5 16 64 51539607552 134217728 51539607552
Standard_D16ds_v4 16 64 51539607552 134217728 51539607552
Standard_D32ads_v5 32 128 103079215104 134217728 103079215104
Standard_D32ds_v4 32 128 103079215104 134217728 103079215104
Standard_D48ads_v5 48 192 154618822656 134217728 154618822656
Standard_D48ds_v4 48 192 154618822656 134217728 154618822656
Standard_D64ads_v5 64 256 206158430208 134217728 206158430208
Standard_D64ds_v4 64 256 206158430208 134217728 206158430208
الأعمال الهامة
Standard_E2ds_v4 2 16 12884901888 134217728 12884901888
Standard_E2ads_v5، Standard_E2ds_v5 2 16 12884901888 134217728 12884901888
Standard_E4ds_v4 4 32 25769803776 134217728 25769803776
Standard_E4ads_v5، Standard_E4ds_v5 4 32 25769803776 134217728 25769803776
Standard_E8ds_v4 8 64 51539607552 134217728 51539607552
Standard_E8ads_v5، Standard_E8ds_v5 8 64 51539607552 134217728 51539607552
Standard_E16ds_v4 16 128 103079215104 134217728 103079215104
Standard_E16ads_v5، Standard_E16ds_v5 16 128 103079215104 134217728 103079215104
Standard_E20ds_v4 20 160 128849018880 134217728 128849018880
Standard_E20ads_v5، Standard_E20ds_v5 20 160 128849018880 134217728 128849018880
Standard_E32ds_v4 32 256 206158430208 134217728 206158430208
Standard_E32ads_v5، Standard_E32ds_v5 32 256 206158430208 134217728 206158430208
Standard_E48ds_v4 48 384 309237645312 134217728 309237645312
Standard_E48ads_v5، Standard_E48ds_v5 48 384 309237645312 134217728 309237645312
Standard_E64ds_v4 64 504 405874409472 134217728 405874409472
Standard_E64ads_v5 ، Standard_E64ds_v5 64 512 412316860416 134217728 412316860416
Standard_E80ids_v4 80 504 405874409472 134217728 405874409472
Standard_E96ds_v5 96 672 541165879296 134217728 541165879296

innodb_file_per_table

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

يؤدي تعيين innodb_file_per_table إلى OFF إلى قيام InnoDB بإنشاء جداول في بنية التخزين الجدولية للنظام. وبخلاف ذلك، يقوم InnoDB بإنشاء جداول في بنيات التخزين الجدولية file-per-table.

يدعم Azure Database for MySQL - Flexible Server بحد أقصى 8 تيرابايت (TB) في ملف بيانات واحد. إذا كان حجم قاعدة البيانات أكبر من 8 تيرابايت، يجب إنشاء الجدول في innodb_file_per_table مساحة الجدول. إذا كان لديك حجم جدول واحد أكبر من 8 تيرابايت، فيجب عليك استخدام جدول القسم.

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 من الافتراضي، فتحقق مما إذا كانت قيمة show global status like 'innodb_buffer_pool_pages_dirty' تبقى لمدة 0 30 ثانية لتجنب تأخير إعادة التشغيل.

max_connections

يحدد حجم ذاكرة الخادم قيمة max_connections. يمثل حجم الذاكرة الفعلية في الجدول التالي ذاكرة الوصول العشوائي المتوفرة، بالجيجابايت، على قاعدة بيانات Azure لخادم MySQL المرن.

حجم الحساب وحدات vCore حجم الذاكرة الفعلية (GB) القيمة الافتراضية أدنى قيمة أقصى قيمة
مندفع
Standard_B1s 1 1 85 10 171
Standard_B1ms 1 2 171 10 341
Standard_B2s 2 4 341 10 683
Standard_B2ms 2 4 683 10 1365
Standard_B4ms 4 16 1365 10 2731
Standard_B8ms 8 32 2731 10 5461
Standard_B12ms 12 48 4097 10 8193
Standard_B16ms 16 64 5461 10 10923
Standard_B20ms 20 80 6827 10 13653
الغرض العام
Standard_D2ads_v5 2 8 683 10 1365
Standard_D2ds_v4 2 8 683 10 1365
Standard_D4ads_v5 4 16 1365 10 2731
Standard_D4ds_v4 4 16 1365 10 2731
Standard_D8ads_v5 8 32 2731 10 5461
Standard_D8ds_v4 8 32 2731 10 5461
Standard_D16ads_v5 16 64 5461 10 10923
Standard_D16ds_v4 16 64 5461 10 10923
Standard_D32ads_v5 32 128 10923 10 21845
Standard_D32ds_v4 32 128 10923 10 21845
Standard_D48ads_v5 48 192 16384 10 32768
Standard_D48ds_v4 48 192 16384 10 32768
Standard_D64ads_v5 64 256 21845 10 43691
Standard_D64ds_v4 64 256 21845 10 43691
الأعمال الهامة
Standard_E2ds_v4 2 16 1365 10 2731
Standard_E2ads_v5، Standard_E2ds_v5 2 16 1365 10 2731
Standard_E4ds_v4 4 32 2731 10 5461
Standard_E4ads_v5، Standard_E4ds_v5 4 32 2731 10 5461
Standard_E8ds_v4 8 64 5461 10 10923
Standard_E8ads_v5، Standard_E8ds_v5 8 64 5461 10 10923
Standard_E16ds_v4 16 128 10923 10 21845
Standard_E16ads_v5، Standard_E16ds_v5 16 128 10923 10 21845
Standard_E20ds_v4 20 160 13653 10 27306
Standard_E20ads_v5، Standard_E20ds_v5 20 160 13653 10 27306
Standard_E32ds_v4 32 256 21845 10 43691
Standard_E32ads_v5، Standard_E32ds_v5 32 256 21845 10 43691
Standard_E48ds_v4 48 384 32768 10 65536
Standard_E48ads_v5، Standard_E48ds_v5 48 384 32768 10 65536
Standard_E64ds_v4 64 504 43008 10 86016
Standard_E64ads_v5، Standard_E64ds_v5 64 512 43691 10 87383
Standard_E80ids_v4 80 504 43008 10 86016
Standard_E96ds_v5 96 672 50000 10 100000

عندما تتجاوز الاتصالات الحد، قد تتلقى الخطأ التالي: "ERROR 1040 (08004): اتصالات كثيرة جدا."

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

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

إشعار

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

innodb_strict_mode

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

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

إشعار

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

time_zone

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

innodb_temp_data_file_size_max

بالنسبة إلى قاعدة بيانات Azure لخادم MySQL المرن (الإصدار 5.7 فقط)، تحدد innodb_temp_data_file_size_max المعلمة الحد الأقصى لحجم ملفات بيانات مساحة الجدول المؤقتة في InnoDB بالميغابايت. يعني تعيين القيمة على 0 عدم وجود حد ، مما يسمح بالنمو حتى حجم التخزين الكامل. يتم تقريب أي قيمة غير صفرية أقل من 64 ميغابايت إلى 64 ميغابايت، بينما يتم تطبيق القيم التي تزيد عن 64 ميغابايت كما هو محدد. هذا متغير ثابت ويتطلب إعادة تشغيل الخادم حتى تصبح التغييرات سارية المفعول.

إشعار

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

binlog_expire_logs_seconds

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

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

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

إذا كنت تريد الاحتفاظ بالسجلات الثنائية لمدة أطول، يمكنك تكوين المعلمة binlog_expire_logs_seconds . إذا binlog_expire_logs_seconds تم تعيين إلى القيمة الافتراضية ل 0، يتم حذف سجل ثنائي بمجرد تحرير المقبض إليه. إذا كانت قيمة binlog_expire_logs_seconds أكبر من 0، يتم حذف السجل الثنائي بعد عدد الثوان المكون.

قاعدة بيانات Azure ل MySQL - يعالج الخادم المرن الميزات المدارة، مثل النسخ الاحتياطي وحذف النسخة المتماثلة للقراءة من الملفات الثنائية، داخليا. عند نسخ البيانات من Azure Database for MySQL - Flexible Server، يجب تعيين هذه المعلمة في الأساسي لتجنب حذف السجلات الثنائية قبل قراءة النسخة المتماثلة من التغييرات في الأساسي. إذا قمت بتعيين binlog_expire_logs_seconds إلى قيمة أعلى، فلن يتم حذف السجلات الثنائية قريبا بما فيه الكفاية. يمكن أن يؤدي هذا التأخير إلى زيادة في فوترة التخزين.

القيود

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

event_scheduler

في Azure Database for MySQL - Flexible Server، تدير معلمة event_scheduler الخادم إنشاء الأحداث وجدولتها وتشغيلها. أي أن المعلمة تدير المهام التي تعمل وفقا لجدول زمني بواسطة مؤشر ترابط MySQL Event Scheduler خاص. عند تعيين المعلمة event_scheduler إلى ON، يتم سرد مؤشر ترابط Event Scheduler كعملية خفي في إخراج SHOW PROCESSLIST.

بالنسبة إلى خوادم الإصدار 5.7 من MySQL، يتم تشغيل معلمة event_scheduler الخادم تلقائيا "إيقاف التشغيل" عند بدء النسخ الاحتياطي وإعادة تشغيل معلمة event_scheduler الخادم مرة أخرى بعد اكتمال النسخ الاحتياطي بنجاح. في الإصدار 8.0 من MySQL لقاعدة بيانات Azure ل MySQL - الخادم المرن، يظل event_scheduler غير متأثر أثناء النسخ الاحتياطية. لضمان عمليات أكثر سلاسة، يوصى بترقية خوادم MySQL 5.7 إلى الإصدار 8.0 باستخدام ترقية إصدار رئيسي.

يمكنك إنشاء الأحداث وجدولتها باستخدام بناء جملة SQL التالي:

CREATE EVENT <event name>
ON SCHEDULE EVERY _ MINUTE / HOUR / DAY
STARTS TIMESTAMP / CURRENT_TIMESTAMP
ENDS TIMESTAMP / CURRENT_TIMESTAMP + INTERVAL 1 MINUTE / HOUR / DAY
COMMENT '<comment>'
DO
<your statement>;

لمزيد من المعلومات حول إنشاء حدث، راجع الوثائق التالية حول Event Scheduler في الدليل المرجعي MySQL:

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

يوضح السيناريو التالي إحدى الطرق لاستخدام المعلمة event_scheduler في قاعدة بيانات Azure ل MySQL - الخادم المرن.

لتوضيح السيناريو، ضع في اعتبارك المثال التالي لجدول بسيط:

mysql> describe tab1;
+-----------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
| +-----------+-------------+------+-----+---------+----------------+ |
| id | int(11) | NO | PRI | NULL | auto_increment |
| CreatedAt | timestamp | YES | | NULL | |
| CreatedBy | varchar(16) | YES | | NULL | |
| +-----------+-------------+------+-----+---------+----------------+ |
| 3 rows in set (0.23 sec) |
| ``` |
| To configure the `event_scheduler` server parameter in Azure Database for MySQL - Flexible Server, perform the following steps: |

1. In the Azure portal, go to your Azure Database for MySQL - Flexible Server instance. Under **Settings**, select **Server parameters**.
1. On the **Server parameters** pane, search for `event_scheduler`. In the **VALUE** dropdown list, select **ON**, and then select **Save**.

    > [!NOTE]
    > Deployment of the dynamic configuration change to the server parameter doesn't require a restart.

1. To create an event, connect to the Azure Database for MySQL - Flexible Server instance and run the following SQL command:
    ```sql

    CREATE EVENT test_event_01
    ON SCHEDULE EVERY 1 MINUTE
    STARTS CURRENT_TIMESTAMP
    ENDS CURRENT_TIMESTAMP + INTERVAL 1 HOUR
    COMMENT 'Inserting record into the table tab1 with current timestamp'
    DO
    INSERT INTO tab1(id,createdAt,createdBy)
    VALUES('',NOW(),CURRENT_USER());

    ```
1. To view the Event Scheduler details, run the following SQL statement:
    ```sql

    SHOW EVENTS;

    ```
    The following output appears:
    ```sql

    mysql> show events;
    +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
    | Db | Name | Definer | Time zone | Type | Execute at | Interval value | Interval field | Starts | Ends | Status | Originator | character_set_client | collation_connection | Database Collation |
    | +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ |
    | db1 | test_event_01 | azureuser@% | SYSTEM | RECURRING | NULL | 1 | MINUTE | 2023-04-05 14:47:04 | 2023-04-05 15:47:04 | ENABLED | 3221153808 | latin1 | latin1_swedish_ci | latin1_swedish_ci |
    | +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ |
    | 1 row in set (0.23 sec) |
    | ``` |

1. After a few minutes, query the rows from the table to begin viewing the rows inserted every minute according to the `event_scheduler` parameter that you configured:

    ```azurecli
    mysql> select * from tab1;
    +----+---------------------+-------------+
    | id | CreatedAt | CreatedBy |
    | +----+---------------------+-------------+ |
    | 1 | 2023-04-05 14:47:04 | azureuser@% |
    | 2 | 2023-04-05 14:48:04 | azureuser@% |
    | 3 | 2023-04-05 14:49:04 | azureuser@% |
    | 4 | 2023-04-05 14:50:04 | azureuser@% |
    | +----+---------------------+-------------+ |
    | 4 rows in set (0.23 sec) |
    | ``` |
| 1. After an hour, run a `select` statement on the table to view the complete result of the values inserted into table every minute for an hour (as `event_scheduler` is configured in this case): |
    ```azurecli

    mysql> select * from tab1;
    +----+---------------------+-------------+
    | id | CreatedAt | CreatedBy |
    | +----+---------------------+-------------+ |
    | 1 | 2023-04-05 14:47:04 | azureuser@% |
    | 2 | 2023-04-05 14:48:04 | azureuser@% |
    | 3 | 2023-04-05 14:49:04 | azureuser@% |
    | 4 | 2023-04-05 14:50:04 | azureuser@% |
    | 5 | 2023-04-05 14:51:04 | azureuser@% |
    | 6 | 2023-04-05 14:52:04 | azureuser@% |
    | ..< 50 lines trimmed to compact output >.. |
    | 56 | 2023-04-05 15:42:04 | azureuser@% |
    | 57 | 2023-04-05 15:43:04 | azureuser@% |
    | 58 | 2023-04-05 15:44:04 | azureuser@% |
    | 59 | 2023-04-05 15:45:04 | azureuser@% |
    | 60 | 2023-04-05 15:46:04 | azureuser@% |
    | 61 | 2023-04-05 15:47:04 | azureuser@% |
    | +----+---------------------+-------------+ |
    | 61 rows in set (0.23 sec) |
    | ``` |

#### Other scenarios

You can set up an event based on the requirements of your specific scenario. A few examples of scheduling SQL statements to run at various time intervals follow.

To run a SQL statement now and repeat one time per day with no end:

```sql
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;

لتشغيل عبارة SQL كل ساعة دون نهاية:

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;

لتشغيل عبارة SQL كل يوم بدون نهاية:

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS str_to_date( date_format(now(), '%Y%m%d 0200'), '%Y%m%d %H%i' ) + INTERVAL 1 DAY
COMMENT 'Comment'
DO
<your statement>;

القيود

بالنسبة للخوادم ذات التوفر العالي المكونة، عند حدوث تجاوز الفشل، من الممكن تعيين معلمة event_scheduler الخادم إلى OFF. إذا حدث ذلك، عند اكتمال تجاوز الفشل، قم بتكوين المعلمة لتعيين القيمة إلى ON.

innodb_ft_user_stopword_table

innodb_ft_user_stopword_table هي معلمة خادم في MySQL تحدد اسم الجدول الذي يحتوي على كلمات توقف مخصصة للبحث في النص الكامل ل InnoDB. يجب أن يكون الجدول في نفس قاعدة البيانات مثل الجدول المفهرس للنص الكامل، ويجب أن يكون العمود الأول من النوع VARCHAR. في Azure Database for MySQL - Flexible Server، يؤدي الإعداد الافتراضي لكافة sql_generate_invisible_primary_key=ON الجداول بدون مفتاح أساسي صريح إلى تضمين مفتاح أساسي غير مرئي تلقائيا. يتعارض هذا السلوك مع متطلبات innodb_ft_user_stopword_table، حيث يصبح المفتاح الأساسي غير المرئي العمود الأول من الجدول، مما يمنعه من العمل كما هو مقصود أثناء البحث في النص الكامل. لحل هذه المشكلة، يجب تعيين sql_generate_invisible_primary_key=OFF في جلسة العمل نفسها قبل إنشاء جدول كلمة التوقف المخصصة. على سبيل المثال:

SET sql_generate_invisible_primary_key = OFF;
CREATE TABLE my_stopword_table (
    stopword VARCHAR(50) NOT NULL
);
INSERT INTO my_stopword_table (stopword) VALUES ('and'), ('or'), ('the');

وهذا يضمن أن جدول كلمة التوقف يفي بمتطلبات MySQL ويسمح لكلمات التوقف المخصصة بالعمل بشكل صحيح.

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

يعرض جزء معلمات الخادم في مدخل Microsoft Azure معلمات الخادم القابلة للتعديل وغير القابلة للتعديل. معلمات الخادم غير القابلة للتعديل غير متوفرة. يمكنك تكوين معلمة خادم غير قابلة للتعديل على مستوى الجلسة باستخدام init_connect في مدخل Microsoft Azure أو Azure CLI.

متغيرات نظام Azure mysql

azure_server_name

azure_server_name يوفر المتغير اسم الخادم الدقيق لمثيل Azure Database for MySQL - Flexible Server. يكون هذا المتغير مفيدا عندما تحتاج التطبيقات أو البرامج النصية إلى استرداد اسم مضيف الخادم المتصل به برمجيا، دون الاعتماد على التكوينات الخارجية ويمكن استرداده عن طريق تشغيل الأمر التالي داخل MySQL.

mysql> SHOW GLOBAL VARIABLES LIKE 'azure_server_name';
+-------------------+---------+
| Variable_name     | Value   |
+-------------------+---------+
| azure_server_name | myflex  |
+-------------------+---------+

ملاحظة: يرجع azure_server_name باستمرار اسم الخادم الأصلي الذي تستخدمه للاتصال بالخدمة (على سبيل المثال، myflex) لكل من خادم HA-enabled وHA-disabled

logical_server_name

logical_server_name يمثل المتغير اسم مضيف المثيل حيث يتم تشغيل Azure Database for MySQL - Flexible Server. هذا المتغير مفيد لتحديد المضيف حيث يتم تشغيل الخدمة حاليا، والمساعدة في استكشاف الأخطاء وإصلاحها ومراقبة تجاوز الفشل. يمكنك استرداد هذا المتغير عن طريق تنفيذ الأمر التالي داخل MySQL.

mysql> SHOW GLOBAL VARIABLES LIKE 'logical_server_name';
+---------------------+--------------+
| Variable_name       | Value        |
+---------------------+--------------+
| logical_server_name | myflex	     |
+---------------------+--------------+

ملاحظة: بالنسبة للخادم الذي يدعم قابلية الوصول العالية، logical_server_name يعكس المتغير اسم مضيف المثيل الذي يعمل كخادم أساسي. بالنسبة للخادم حيث يتم تعطيل قابلية الوصول العالية، تكون قيمة logical_server_name هي نفس azure_server_name المتغير نظرا لوجود مثيل واحد فقط.

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

  • Last updated on