المشكلة الأساسية

في مجموعة Galera، يجب على كافة العقد تطبيق نفس مجموعات الكتابة بنفس الترتيب للحفاظ على الاتساق. ولكن ليست كل العقد متساوية: بعضها أسرع (أجهزة حديثة، حمل خفيف)، والبعض الآخر أبطأ (أجهزة قديمة، طلبات ثقيلة).

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

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

كيف يعمل التحكم في التدفق

يعتمد التحكم في التدفق على حد بسيط: gcs.fc_limit.

تحتفظ كل عقدة Galera بقائمة انتظار تلقي (قائمة انتظار التسجيل) التي تخزن مجموعات الكتابة التي تنتظر التطبيق. عندما يتجاوز حجم قائمة الانتظار هذه gcs.fc_limit، ترسل العقدة رسالة FC_PAUSE إلى كافة العقد الأخرى في المجموعة.

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

عندما تنخفض قائمة انتظار الاستقبال الخاصة بالعقدة البطيئة إلى ما دون gcs.fc_limit × gcs.fc_factor، ترسل العقدة رسالة FC_CONTINUE وتستأنف المجموعة العمل العادي.

المتغيرات الخمسة الحاسمة wsrep

لمراقبة التحكم في التدفق، هناك خمسة متغيرات للحالة ضرورية:

SHOW GLOBAL STATUS WHERE Variable_name IN (
    'wsrep_local_recv_queue',
    'wsrep_local_recv_queue_avg',
    'wsrep_flow_control_paused',
    'wsrep_flow_control_paused_ns',
    'wsrep_flow_control_sent'
);

wsrep_local_recv_queue

الحجم الحالي لقائمة انتظار Recv. في التشغيل العادي، يجب أن تكون هذه القيمة قريبة من 0. إذا ارتفعت بشكل منتظم فوق gcs.fc_limit، فإن العقدة في مشكلة.

wsrep_local_recv_queue_avg

المتوسط المتحرك لrecv الذيل. إنه المؤشر الأكثر موثوقية للكشف عن الاتجاهات. متوسط فوق 0.5 يستحق التحقيق.

wsrep_flow_control_paused

جزء من الوقت المستغرق في التحكم في التدفق (بين 0 و1). إذا تجاوزت هذه القيمة 0.1 (10% من الوقت)، فهذا يعني أن الكتلة تواجه مشكلة خطيرة في الأداء.

wsrep_flow_control_paused_ns

إجمالي الوقت المستغرق في التحكم في التدفق بالنانو ثانية. مفيد لحساب وقت الاستراحة المطلق خلال فترة ما.

wsrep_flow_control_sent

عدد رسائل FC_PAUSE المرسلة بواسطة هذه العقدة. إذا أرسلت عقدة واحدة أغلبية FC_PAUSEs، فهذا هو عنق الزجاجة الذي يجب معالجته.

معلمات الضبط الستة

gcs.fc_limit

عتبة تشغيل التحكم في التدفق. القيمة الافتراضية: 16. تؤدي زيادة هذه القيمة إلى حدوث تأخير أكبر قبل تشغيل المكابح، ولكنها تزيد من استهلاك الذاكرة.

gcs.fc_factor

معامل الاسترداد. القيمة الافتراضية: 0.5. عندما يعود ذيل التسجيل إلى الأسفل إلى fc_limit × fc_factor، يتم تحرير التحكم في التدفق. مع حد fc_limit قدره 100 ومعامل fc_factor قدره 0.8، يرتاح FC عند 80 مجموعة كتابة.

wsrep_slave_threads

عدد سلاسل تطبيقات مجموعة الكتابة. المزيد من المواضيع = تطبيق أسرع لمجموعات الكتابة المستلمة = قائمة انتظار التسجيل التي يتم إفراغها بشكل أسرع. التوصية: 2 × عدد نوى وحدة المعالجة المركزية.

wsrep_cert_deps_distance

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

gcs.recv_q_hard_limit

الحد المطلق لقائمة انتظار التسجيل بالبايت. إذا تم تجاوزها، سيتم إحباط العقدة. هذا هو الملاذ الأخير لتجنب OOM. التوصية: نصف ذاكرة الوصول العشوائي + المبادلة المتاحة.

gcs.max_throttle

الحد الأدنى لمعدل التدفق مضمون حتى في التحكم في التدفق (بين 0 و1). القيمة الافتراضية 0.25 تعني أنه حتى في الموارد البشرية، يتم الحفاظ على 25% من التدفق الطبيعي. اضبط على 0 للتوقف الكامل في الموارد البشرية.

توصيات الخبراء

بعد سنوات من إدارة مجموعات Galera في الإنتاج، إليك التوصيات الموحدة:

تحجيم المواضيع التابعة

wsrep_slave_threads = 2 × CPU_CORES

إذا كان خادمك يحتوي على 8 مراكز، فابدأ بـ wsrep_slave_threads = 16. مراقب wsrep_cert_deps_distance — إذا كان أقل من عدد الخيوط التابعة، قم بتقليله.

fc_limit يعتمد على الخيوط التابعة

gcs.fc_limit = 5 × wsrep_slave_threads

مع 16 خيط تابع، gcs.fc_limit = 80. وهذا يعطي مساحة كافية للخيوط للعمل بالتوازي دون تشغيل FC في وقت مبكر جدًا.

fc_factor للتعافي التدريجي

gcs.fc_factor = 0.8

يسمح عامل fc_factor بقيمة 0.8 (بدلاً من العامل الافتراضي 0.5) باستئناف حركة المرور بشكل تدريجي، مع تجنب تذبذبات FC_PAUSE / FC_CONTINUE.

الحد الصعب للسلامة

gcs.recv_q_hard_limit = HALF_RAM_PLUS_SWAP

على خادم به 32 جيجابايت من ذاكرة الوصول العشوائي و16 جيجابايت من المبادلة، ضع gcs.recv_q_hard_limit = 24G. هذه هي شبكة الأمان ضد OOM.

تحديد العقدة الإشكالية

عندما يتم تشغيل التحكم في التدفق بشكل متكرر، يجب تحديد العقدة البطيئة:

-- Sur chaque nœud
SELECT @@hostname,
       VARIABLE_VALUE AS fc_sent
FROM information_schema.GLOBAL_STATUS
WHERE VARIABLE_NAME = 'wsrep_flow_control_sent';

العقدة التي ترسل معظم FC_PAUSEs هي عنق الزجاجة. الأسباب المعتادة:

أجهزة رديئة: محركات أقراص أبطأ، وذاكرة وصول عشوائي أقل
استعلامات ثقيلة: جدول ALTER TABLE أو SELECT ضخم يحتكر الموارد
النسخ الاحتياطي قيد التقدم: يستهلك mariabackup/xtrabackup قدرًا كبيرًا من عمليات الإدخال/الإخراج
تحميل التطبيق غير المتوازن: هناك عدد كبير جدًا من عمليات القراءة على العقدة والتي يجب أن تطبق أيضًا مجموعات الكتابة

الخلاصة

التحكم في التدفق هو حارس الاتساق في Galera. يعد فهم كيفية عملها ومعلماتها أمرًا ضروريًا للحفاظ على مجموعة عالية الأداء.

القواعد الذهبية: slave_threads = 2 × CPU، fc_limit = 5 × threads، fc_factor = 0.8، الحد الثابت = نصف ذاكرة الوصول العشوائي + المبادلة. قم بمراقبة wsrep_flow_control_paused والتفاعل بمجرد أن تتجاوز القيمة 10%.

تم نشر هذه المقالة في الأصل على متوسط.

Galera: فهم التحكم في التدفق